Lợi nhuận:
- Khả năng sử dụng trí tuệ nhân tạo làm con mắt thứ hai và gắn cờ các lỗ hổng của lớp OWASP (tiêm, bí mật cứng, kiểm soát truy cập) trong mã bằng cách đưa ra ngữ cảnh
- Khả năng loại bỏ các kết quả dương tính giả do trí tuệ nhân tạo tạo ra theo ngữ cảnh và ngăn chặn việc coi mỗi phát hiện là một lỗ hổng thực sự mà không xác thực nó
- Khả năng nhận ra rằng bản sửa lỗi do trí tuệ nhân tạo đề xuất có thể gây ra các lỗ hổng/lỗi mới và chuyển từng bản vá qua cổng xem xét và kiểm tra
Các lỗ hổng trong phần mềm là một trong những lỗ hổng đắt giá nhất vì chúng được nhúng trong sản phẩm ngay từ đầu và được phân phối tới hàng triệu người dùng. Đánh giá mã an toàn là quá trình đọc từng dòng mã nguồn và phát hiện các lỗ hổng - SQL SQL, lỗ hổng xác thực, mật khẩu mã hóa cứng, ủy quyền không chính xác - trước khi chúng đi vào sản xuất. Khi làm bằng tay thì chậm và mệt mỏi; Rất dễ bỏ sót lỗ hổng trong cơ sở mã lớn.
AI có khả năng đánh giá mã rất mạnh vì hai lý do: mã cũng là một ngôn ngữ và AI giỏi nhận dạng mẫu. AI có thể nhanh chóng gắn cờ các mẫu nguy hiểm trong một đoạn mã (đưa dữ liệu đầu vào của người dùng trực tiếp vào truy vấn, lưu trữ dữ liệu không được mã hóa, thiếu xác thực đầu vào), giải thích lý do tại sao mỗi mẫu đều có rủi ro và đề xuất cách khắc phục. Nhưng AI không nhìn thấy toàn bộ bối cảnh hoạt động của mã (đầu vào có thể bị xóa ở lớp khác), nó có thể phát minh ra một lỗ hổng không tồn tại (dương tính giả) hoặc bỏ sót một lỗ hổng thực sự (âm tính giả) và quan trọng nhất là việc "sửa chữa" mà nó đề xuất có thể tạo ra một lỗ hổng hoặc lỗi mới. AI là con mắt thứ hai và là con trỏ trong việc đánh giá mã; Nhà phát triển và chuyên gia bảo mật quyết định xem phát hiện đó có phải là lỗ hổng thực sự hay không và liệu bản sửa lỗi có chính xác và an toàn hay không.
Các bước xem xét mã
- Đưa ra phạm vi và bối cảnh. Ngôn ngữ nào, framework nào, mã này lấy đầu vào ở đâu, đầu ra ở đâu, hoạt động ở lớp nào? Đánh giá mã mà không có ngữ cảnh sẽ tạo ra kết quả dương tính giả.
- Quét các mẫu nguy hiểm. Tìm kiếm các lớp lỗ hổng AI đã biết (chẳng hạn như OWASP Top 10): chèn, xác thực, tiết lộ dữ liệu nhạy cảm, kiểm soát truy cập.
- Có mỗi phát hiện hợp lý. Đối với mỗi cờ: dòng nào, lớp lỗ hổng nào, có thể khai thác như thế nào, bằng chứng là gì. Một phát hiện không chính đáng không được coi trọng.
- Loại bỏ dương tính giả. Đầu vào có thực sự bị xóa không, đường dẫn đó có thực sự có thể truy cập được không - hãy kiểm tra ngữ cảnh.
- Xác minh bản sửa lỗi. Xác nhận rằng bản vá do AI đề xuất thực sự đóng lỗ hổng, không gây ra lỗ hổng/lỗi mới và đã vượt qua thử nghiệm.
- Sự chấp thuận của con người. Nhà phát triển + chuyên gia bảo mật xem xét việc phát hiện và khắc phục; Đó là cách nó đi vào kho mã.
Điều khoản: SAST (Kiểm tra bảo mật ứng dụng tĩnh - kiểm tra bảo mật tĩnh phân tích mã nguồn mà không cần chạy nó). DAST (Dynamic - thử nghiệm động để kiểm tra ứng dụng đang chạy bên ngoài). OWASP Top 10 là danh sách tiêu chuẩn về các lỗ hổng ứng dụng web phổ biến nhất. Nội dung chèn là một lỗ hổng gây ra bằng cách diễn giải thông tin đầu vào của người dùng dưới dạng lệnh/truy vấn (ví dụ: nội dung SQL). Truy vấn được tham số hóa là phương pháp chính xác giúp ngăn chặn việc chèn bằng cách tách đầu vào khỏi mã.
Bảng các lớp lỗ hổng phổ biến
Lớp dễ bị tổn thương
Triệu chứng (trong mã)
giải pháp đúng đắn
cái bẫy của AI
SQL tiêm
Kết hợp đầu vào vào truy vấn
Truy vấn được tham số hóa
Có thể bỏ qua việc vệ sinh
bí mật được mã hóa cứng
Mật khẩu/chìa khóa trong mã
két sắt bí mật (vault), env
Dương tính giả (mẫu/xét nghiệm)
Xác thực yếu
Kiểm soát thiếu/không chính xác
Kiểm soát tập trung, mạnh mẽ
bỏ lỡ bối cảnh
Kiểm soát truy cập bị lỗi
Không có kiểm tra ủy quyền
Ủy quyền phía máy chủ
Không hiểu dòng chảy phức tạp
Tiết lộ dữ liệu nhạy cảm
Lưu trữ/ghi nhật ký không cần mật khẩu
Mã hóa, che giấu
Không thể biết phê phán
Tuần tự hóa không an toàn
Giải tuần tự hóa dữ liệu không đáng tin cậy
Phân tích cú pháp an toàn
Thiếu mẫu hiếm
ba trường hợp nhỏ
Trường hợp 1 - Bắt được mũi tiêm thực tế. Nhà phát triển có AI kiểm tra chức năng truy cập dữ liệu. AI đánh dấu dòng trong đó giá trị userId từ người dùng được nối trực tiếp vào văn bản SQL và nói "đây là cách chèn SQL cổ điển, hãy biến nó thành một truy vấn được tham số hóa"; Cung cấp hiệu chỉnh mẫu. Nhà phát triển xác nhận rằng đầu vào chưa được làm sạch ở nơi nào khác, xác minh rằng đó là một lỗ hổng thực sự, triển khai truy vấn được tham số hóa được đề xuất và viết thử nghiệm. AI đã nêu bật lỗ hổng; kiểm tra xác minh và chỉnh sửa đến từ nhà phát triển.
Trường hợp 2 - Bí mật cố định dương tính giả. AI nhìn thấy dòng mật khẩu = "test1234" trong một tệp và nói "quan trọng: mật khẩu được mã hóa cứng". Nhà phát triển kiểm tra ngữ cảnh: đây là tệp thử nghiệm đơn vị, dữ liệu thử nghiệm giả, chưa được phát hành vào sản xuất và không được chuyển sang hệ thống thực. Kết quả này là dương tính giả. Nhà phát triển ghi lại điều này nhưng không thực hiện hành động vì nó không phải là bí mật thực sự. Bài học: Dấu hiệu “bí mật khó” của AI phải được loại bỏ theo ngữ cảnh; Không phải mọi chuỗi đều là bí mật.
Trường hợp 3 - Sửa lỗ hổng mới. AI đề xuất cách khắc phục lỗ hổng XSS (cross-site scripting); nhưng mã mà anh ấy gợi ý sẽ xóa đầu vào sai vị trí và bỏ qua mã hóa đầu ra ở một khu vực khác; Kết quả là khoảng cách không được đóng lại hoàn toàn. Chuyên gia bảo mật xem xét bản sửa lỗi, nhận thấy phần mã hóa bị thiếu và sửa nó ở đúng lớp. Bài học: Bản vá mà AI khuyến nghị không tự động bảo mật; Mọi bản sửa lỗi đều được xem xét và thử nghiệm.
Dấu nhắc yếu / Dấu nhắc mạnh
Dấu nhắc yếu:
Code này có lỗ hổng không, sửa lại đi: [code]
Lời nhắc này không đưa ra ngữ cảnh (ngôn ngữ, khuôn khổ, nguồn đầu vào), không yêu cầu biện minh, không đặt câu hỏi về kết quả dương tính giả và sẵn sàng chấp nhận một cách mù quáng sự điều chỉnh do AI tạo ra. AI có nhiều dấu hiệu lẫn lộn giữa lỗ hổng thực sự và lỗ hổng không tồn tại.
Lời nhắc mạnh mẽ:
Vai trò của bạn: trợ lý là CON MẮT THỨ HAI đối với nhà phát triển trong việc đánh giá mã bảo mật. Ra quyết định; xem xét việc sửa lỗi được áp dụng trực tiếp. Mã: [chỉ định ngôn ngữ/khuôn khổ]. Ngữ cảnh: hàm này [nguồn đầu vào: ví dụ: nhận [yêu cầu HTTP bên ngoài], ghi vào [đích đầu ra]. Nhiệm vụ của bạn: (1) gắn cờ các lỗ hổng có thể xảy ra với lớp OWASP, đưa ra số dòng + lý do rủi ro + cách khai thác + bằng chứng cho mỗi lỗ hổng, (2) viết ít nhất 1 kịch bản dương tính giả cho mỗi phát hiện (ví dụ: nếu đầu vào đã được làm sạch ở một lớp khác), (3) đề xuất cách khắc phục nhưng có ký hiệu "[review + write test]"; Đồng thời đánh giá xem bản sửa lỗi có gây ra lỗ hổng/lỗi mới hay không. Thêm một lỗ hổng giả mạo.[code]
Lời nhắc mạnh mẽ đưa ra bối cảnh, yêu cầu lớp OWASP và bằng chứng, đặt câu hỏi về kết quả dương tính giả và rủi ro khắc phục, buộc con người phải xem xét.
Mẫu lời nhắc có thể sao chép
MẪU QUÉT LỖI LỪA ĐẢO Kiểm tra mã [ngôn ngữ/khung] cho OWASP Top 10. Đối với mỗi phát hiện có thể xảy ra: số dòng, loại lỗ hổng, tại sao nó nguy hiểm, khai thác mẫu, độ mạnh của bằng chứng (chắc chắn/có khả năng/yếu). Bối cảnh: đầu vào [nguồn], đầu ra [đích]. Thêm những phát hiện bịa đặt; Nếu bạn không chắc chắn, hãy nhập "[phải được xác minh]". Mã: [dán]
MẪU LOẠI BỎ TÍCH CỰC SAI Để tìm mã sau đây, hãy liệt kê các tình huống KHÔNG có lỗ hổng thực sự: đầu vào có thể bị xóa ở lớp khác không, đường dẫn này có thể truy cập được không, giá trị này có phải là thử nghiệm/mẫu không, khung có được bảo vệ tự động không. Viết cách xác nhận cho từng người. Tìm kiếm: [dán]
KHẮC PHỤC MẪU ĐÁNH GIÁ Đề xuất cách khắc phục lỗ hổng sau; sau đó phê bình cách khắc phục của riêng bạn: (1) nó có thực sự khắc phục được lỗ hổng không, (2) nó có gây ra lỗ hổng/lỗi mới không, (3) tôi nên viết bài kiểm tra nào (trường hợp tích cực và tiêu cực), (4) tác động đến hiệu suất/chức năng. Mình sẽ xem xét và test cách khắc phục. Lỗ hổng + mã: [dán]
MẪU GIẢNG DẠY MẪU AN TOÀN cho lớp dễ bị tổn thương [ví dụ: SQL SQL] tương đối hiển thị kiểu gõ an toàn và các kiểu lỗi phổ biến trong ngôn ngữ/khung này. Quy tắc chung + đưa ra mã ví dụ; nhưng tôi muốn bạn hỏi ngữ cảnh trước khi triển khai nó trong mã của tôi. Ngôn ngữ/khuôn khổ: [viết]
Những lỗi thường gặp
- Đánh giá không có ngữ cảnh. Nếu không có ngôn ngữ, khuôn khổ và bối cảnh đầu vào/đầu ra, AI sẽ nhầm lẫn cả những phát hiện thực và giả; Hãy chắc chắn để đưa ra bối cảnh.
- Nhầm mọi dấu hiệu là điểm yếu thực sự. AI tạo ra kết quả dương tính giả (dữ liệu thử nghiệm, đầu vào được làm sạch ở lớp khác); Sàng lọc từng phát hiện với bối cảnh.
- Áp dụng một cách mù quáng sự điều chỉnh của AI. Bản vá được đề xuất có thể gây ra các lỗ hổng/lỗi mới; xem xét và viết bài kiểm tra.
- Tin tưởng vào âm tính giả. Ngay cả khi AI nói "không có lỗ hổng", hãy tự mình kiểm tra các đường dẫn quan trọng; Quét tĩnh không phát hiện mọi lỗ hổng.
- Cung cấp mã/bí mật cho công cụ bên ngoài. Mã riêng và bí mật thực sự (khóa, mật khẩu) là tài sản trí tuệ và tính dễ bị tổn thương; ẩn danh hoặc sử dụng các công cụ riêng biệt của công ty.
Mẹo: Khi có mã đánh giá AI, bộ lọc hiệu quả nhất là yêu cầu “mức độ mạnh của bằng chứng” (chắc chắn/có khả năng/yếu) cho mỗi phát hiện. Hầu hết các phát hiện được đánh dấu là “yếu” đều là dương tính giả; bạn phân bổ năng lượng của mình cho những việc “chắc chắn”.
Thận trọng: Bản sửa lỗi bảo mật được đề xuất của AI không được vào kho khi chưa được kiểm tra. Một "bản sửa lỗi" không chính xác có thể vừa để lộ lỗ hổng vừa dẫn đến lỗi chức năng trong quá trình sản xuất; Mỗi bản vá đều đi qua cổng xem xét và thử nghiệm.
Tóm lại
Đánh giá mã an toàn là cách rẻ nhất để phát hiện các lỗ hổng trước khi chúng được đưa vào sản xuất và vì mã là ngôn ngữ nên AI trở thành con mắt thứ hai đầy quyền lực ở đây: gắn cờ các mô hình nguy hiểm, giải thích rủi ro, đề xuất cách khắc phục. Nhưng AI không nhìn thấy toàn bộ bối cảnh hoạt động, tạo ra các kết quả dương tính giả và âm tính giả, đồng thời bản vá mà nó đề xuất có thể gây ra các lỗ hổng mới. Vì vậy, quá trình xem xét có sáu bước (ngữ cảnh, sàng lọc, biện minh, loại bỏ dương tính giả, xác minh bản sửa lỗi, phê duyệt của con người) và quyết định thuộc về nhà phát triển và chuyên gia bảo mật. Ba nguyên tắc: không phát hiện nào được giải thích mà không có ngữ cảnh, mọi dấu hiệu đều bị loại bỏ theo ngữ cảnh, không có bản sửa lỗi nào được đưa vào kho lưu trữ mà chưa được kiểm tra. Và mã/bí mật không bao giờ được trao cho một công cụ bên ngoài mà không được ẩn danh.
Nhiệm vụ ứng dụng
Lấy đoạn mã mẫu (xóa các phần nhạy cảm khỏi mã của riêng bạn hoặc mã mẫu có lỗ hổng). Yêu cầu AI kiểm tra nó bằng mẫu “Quét lỗ hổng”; Áp dụng mẫu "Loại bỏ tích cực sai" cho mỗi phát hiện và loại bỏ những kết quả thực. Thực hiện việc sửa lỗi phát hiện nghiêm trọng nhất bằng mẫu "Đánh giá khắc phục", tự xem xét và viết một trường hợp kiểm tra dương tính + một âm tính. Lưu ý có bao nhiêu phát hiện là dương tính giả.
danh sách kiểm tra
- [ ] Tôi đã cung cấp ngôn ngữ, khung và bối cảnh đầu vào/đầu ra trước khi xem lại mã.
- [ ] Tôi đã hỏi số dòng, loại lỗ hổng, đường dẫn khai thác và bằng chứng cho mỗi phát hiện.
- [ ] Tôi đã sàng lọc từng phát hiện để tìm ra kết quả dương tính giả dựa trên ngữ cảnh.
- [ ] Tôi đã không mù quáng áp dụng sự điều chỉnh của AI; Tôi đã xem xét và viết một bài kiểm tra.
- [ ] Mặc dù kết quả đầu ra là "Không có lỗ hổng", nhưng tôi đã tự mình kiểm tra các đường dẫn quan trọng.
- [ ] Tôi đã ẩn danh mã/bí mật hoặc sử dụng công cụ riêng biệt của công ty.
- [ ] Tôi đã vượt qua việc khám phá và sửa lỗi thông qua phê duyệt của nhà phát triển + bảo mật.