Kiểm thử bảo mật AI có thể thay thế SAST, DAST và pentest không?

Câu hỏi hữu ích là tác nhân tạo được niềm tin ở đâu. Tôi tin nó có thể mở rộng phạm vi đánh giá, kết nối manh mối giữa các tệp, tạo kiểm thử có mục tiêu và biến vết quét khó hiểu thành một bản sửa lỗi mà lập trình viên hiểu được. Tôi không tin nó có thể suy ra quy tắc phân quyền của một công ty từ tên route, chứng minh mọi ranh giới tenant đều vững chắc, hoặc tự quyết một quy trình tài chính bất thường là lạm dụng khi chưa có người nêu quy tắc. Hãy xem tác nhân như một người đánh giá chủ động trong chương trình kiểm thử nhiều lớp, chứ không phải chính chương trình đó.

Đánh giá bằng tác nhân là cách diễn giải, không phải một loại kiểm thử mới

Tác nhân AI thay đổi cách thu thập và hiểu bằng chứng, chứ không tạo ra một loại bằng chứng mới. Nếu nó đọc mã nguồn mà không chạy ứng dụng, nó đang thực hiện một dạng đánh giá tĩnh linh hoạt. Nếu nó gửi yêu cầu đến một mục tiêu đang chạy, nó đang kiểm thử động. Nếu nó khám phá mục tiêu, thay đổi chiến thuật và theo dõi hành vi bất ngờ, nó giống người kiểm thử xâm nhập, nhưng sự giống nhau đó không trao cho nó thẩm quyền hay ngữ cảnh nghiệp vụ của người kiểm thử.

Điều này quan trọng khi nhà cung cấp nói tác nhân của họ «thay thế máy quét». Hãy hỏi hệ thống thực sự có thể quan sát gì. Nó có nhận được toàn bộ kho mã, mã được tạo, cờ build, chính sách hạ tầng và tệp khóa phụ thuộc không? Nó có thể xác thực với tư cách nhiều người dùng và xác minh trạng thái cơ sở dữ liệu sau mỗi yêu cầu không? Nó có biết hành động nào bị chính sách cấm thay vì chỉ không xuất hiện trong giao diện không? Một lời giải thích trau chuốt không thể bù cho đầu vào còn thiếu.

Tác nhân thực sự giỏi kết hợp các tín hiệu yếu. Một quy tắc thông thường có thể đánh dấu tham số yêu cầu đi tới trình dựng truy vấn. Tác nhân có thể kiểm tra lớp bao, nhận ra một nơi gọi bỏ qua điều kiện tenant, soạn yêu cầu kiểm thử và giải thích vì sao hàm trợ giúp tưởng như an toàn lại không an toàn trên đường đi đó. Nó cũng có thể loại bỏ một ứng viên khi giá trị đi qua API tham số hóa thực sự. Đây là phân loại tốt hơn, không phải bằng chứng rằng phân tích tĩnh hay động đã lỗi thời.

Ranh giới rõ rệt nằm giữa đánh giá và xác minh. Đánh giá hỏi: «Với những gì tôi thấy, phần triển khai này có vẻ không an toàn không?» Xác minh hỏi: «Trong các điều kiện đã nêu, tác nhân này có thể gây ra kết quả bị cấm không?» AI hỗ trợ cả hai, nhưng cổng bảo mật nên ghi rõ mình đang đưa ra tuyên bố nào. Nhóm sẽ gặp rủi ro khi một nhận xét đánh giá hùng hồn được nâng thành khai thác đã xác minh, hoặc một lần thử khai thác thất bại bị xem là bằng chứng an toàn.

Hành vi mô hình tạo thêm một khác biệt: năng lực không đồng nghĩa với khả năng lặp lại. Một tác nhân có thể phát hiện đường đi tinh vi trong một lần chạy và bỏ sót sau khi mô hình, prompt, chỉ mục truy xuất hoặc chính sách công cụ thay đổi. Khi kết quả quan trọng, hãy lưu prompt, quyền công cụ, tệp được truy xuất, yêu cầu đã tạo và mã định danh mô hình. Sau đó biến các phát hiện đã xác nhận thành kiểm thử mà điều kiện đạt không phụ thuộc vào việc mô hình tự tìm lại ý tưởng của mình.

SAST vẫn nắm lợi thế về phạm vi mã nguồn có thể lặp lại

SAST vẫn là cách rẻ nhất để áp dụng các kiểm tra ổn định cho mọi thay đổi trên kho mã lớn. Nó có thể liệt kê nguồn và điểm đích, thực thi API bị cấm, kiểm tra luồng dữ liệu và báo cáo chính xác phiên bản đã phân tích. Một quy tắc xác định cho cùng kết quả vào ngày mai, điều này quan trọng khi cổng phát hành cần lý do có thể kiểm toán để cho qua hoặc chặn.

Tác nhân bổ sung ngữ cảnh mà bộ máy quy tắc thường thiếu. Nó có thể theo dõi các lớp bao riêng của dự án, đọc chú thích với sự thận trọng, so sánh một handler với các handler lân cận và đề xuất truy vấn cho một mẫu mới. Nó có thể nhận ra thiếu sót đáng ngờ, chẳng hạn chín endpoint gọi authorizeProject() còn endpoint thứ mười tải trực tiếp bản ghi. Nó cũng hữu ích khi mã được tạo hoặc framework lạ khiến bộ quy tắc chuẩn không hoạt động tốt.

Nhưng phạm vi mã nguồn của tác nhân thường khó chứng minh hơn. Cửa sổ ngữ cảnh, thứ hạng truy xuất, tệp bị bỏ qua, hiện vật được tạo và hết thời gian công cụ có thể khiến một phần mã không được đọc. Yêu cầu «đánh giá kho mã này để tìm injection» không chứng minh mọi điểm đích đã được tiếp cận. Báo cáo SAST ít nhất có thể nêu tệp, quy tắc và phiên bản đã phân tích. Tác nhân cần một sổ theo dõi phạm vi tương đương trước khi có thể đảm nhận một cổng bắt buộc.

NIST SP 800-218 đưa ra khuyến nghị hợp lý: dùng phân tích mã sớm và xác minh thủ công các tính năng, biện pháp giảm thiểu bảo mật. Giá trị nằm ở sự kết hợp. Quy tắc ổn định bắt các dạng lỗi đã biết ở mọi lần commit; tác nhân điều tra ngoại lệ, viết kiểm thử hồi quy tập trung và giúp tinh chỉnh quy tắc khi cùng mẫu lặp lại. Loại bỏ SAST vì tác nhân tìm được vài lỗi thông minh sẽ đổi bề rộng có thể đo lường lấy những giai thoại ấn tượng.

SAST cũng thấy mã mà kiểm thử đang chạy có thể không bao giờ chạm tới: đường lỗi, cờ tính năng, tiện ích migration, endpoint quản trị không hoạt động và nhánh riêng cho nền tảng. Nó không thể cho biết môi trường triển khai có bật các đường đó không. Sự không chắc chắn này là lý do để thêm bằng chứng lúc chạy, không phải để bỏ phạm vi tĩnh.

Có giới hạn cho những gì nên thuộc về quy tắc SAST chặn phát hành. Mẫu chính xác cho một nguyên thủy mật mã bị cấm có thể chặn ngay. Một heuristic rộng hỏi liệu kiểm tra phân quyền «có vẻ đủ gần» thường chỉ nên tạo tác vụ đánh giá cho đến khi nhóm đo được độ chính xác. Tác nhân có thể giúp nâng heuristic thành quy tắc bằng cách thu thập ví dụ đúng, phản ví dụ và các hàm bao phổ biến trong kho mã đó. Cách này giữ cổng nghiêm ngặt mà không khiến lập trình viên quen với việc phớt lờ nó.

Bản sửa lỗi được tạo cũng cần được xem xét kỹ như phát hiện. Mô hình có thể làm vết taint biến mất bằng cách thêm xác thực ở sai lớp, bắt ngoại lệ rồi để lỗi lọt qua, hoặc thay cuộc gọi nguy hiểm nhưng thay đổi hành vi. Hãy chạy bằng chứng ban đầu trên bản vá, chạy kiểm thử chức năng thông thường và xem xét kiểm soát mới tại nơi thiết lập niềm tin. Quét lại sạch chỉ chứng minh quy tắc ban đầu không còn khớp.

DAST chứng minh hành vi mà kho mã không thể hé lộ

DAST quan sát ứng dụng thực sự đang chạy, gồm quy tắc proxy, header, tuần tự hóa, middleware xác thực, mặc định framework và lỗi triển khai. Đánh giá mã nguồn có thể nói endpoint dường như được bảo vệ. Kiểm thử động có thể cho thấy route production bỏ qua middleware vì gateway viết lại đường dẫn.

Đây là nơi tác nhân có thể khiến kiểm thử động bớt máy móc hơn nhiều. Cung cấp cho nó mô tả API, danh tính kiểm thử, phạm vi được phép và môi trường có thể hủy, nó có thể xây dựng chuỗi yêu cầu thay vì phun payload chung chung. Nó có thể mang mã định danh tài nguyên từ phản hồi này sang phản hồi khác, làm mới phiên, so sánh hai vai trò và kiểm tra liệu một lần ghi có thay đổi các lần đọc sau đó không. DAST thông thường thường gặp khó với các luồng có trạng thái như vậy.

Tác nhân vẫn cần giới hạn vận hành nghiêm ngặt. Trình thu thập dữ liệu không biết gửi email, tạo lô hàng hay gọi tích hợp trả phí có an toàn không. Môi trường kiểm thử vẫn có thể kết nối tới dịch vụ thật. Hãy xác định host được phép, tài khoản, tốc độ yêu cầu, hành động phá hủy và điều kiện dừng bên ngoài prompt của mô hình, rồi thực thi chúng trong trình chạy. Một câu nói «tránh hành động nguy hiểm» không phải kiểm soát.

Hãy giữ nền tảng kiểm thử động thông thường cho các kiểm tra đã hiểu rõ như header bảo mật, tệp bị lộ, đầu vào phản chiếu, các thăm dò injection phổ biến và cấu hình TLS. Những kiểm tra này rẻ, có thể so sánh giữa các bản phát hành và dễ theo dõi xu hướng. Hãy để tác nhân dùng ngân sách cho các đường đi đã xác thực và hành vi chuỗi. Nếu cả hai hệ thống bao phủ cùng một thăm dò đơn giản, giữ lại hệ thống có bằng chứng rõ hơn và độ biến thiên thấp hơn.

DAST cũng có thể tạo cảm giác đầy đủ sai lệch vì nó chỉ báo cáo những gì đã tiếp cận. Hãy ghi nhận phạm vi route, danh tính đã dùng, cờ tính năng và dữ liệu khởi tạo cùng kết quả. Một lần quét sạch với tài khoản gần như trống không chứng minh được nhiều về ứng dụng mà các nhánh nguy hiểm chỉ xuất hiện sau phê duyệt, mời tham gia, thanh toán hoặc nhập dữ liệu.

Thiết lập xác thực cần bằng chứng riêng. Hãy ghi cách kiểm thử có được từng phiên, yếu tố thứ hai hay kiểm tra thiết bị nào bị bỏ qua trong môi trường kiểm thử, và token có cùng claim cùng thời hạn với token production hay không. Token quản trị tự tạo có thể mở ra phạm vi hữu ích nhưng bỏ qua chính các chuyển đổi phiên và đặc quyền cần kiểm thử. Hãy để các lối tắt này hiện rõ trong báo cáo.

Kiểm thử động lại nên bắt đầu bằng chuỗi yêu cầu đã lưu, không phải một lượt thu thập tự động mới. Phát lại bằng chứng đã xác nhận trên bản build đã vá, xác minh hiệu ứng bị cấm đã dừng, rồi thay đổi các đầu vào lân cận để phát hiện bộ lọc quá hẹp. Sau đó mới để tác nhân khám phá. Thứ tự này tách «bản sửa chặn khai thác đã biết» khỏi tuyên bố rộng hơn rằng cả lớp lỗi đã được loại bỏ.

Kiểm thử phân quyền cần danh tính và kết quả bị cấm

Phân quyền không phải là «endpoint đã trả về 403 một lần». Một kiểm thử hữu ích nêu rõ ai hành động, họ nhắm tới đối tượng nào, cố thực hiện thao tác gì và kết quả nào phải luôn không thể xảy ra. Tác nhân có thể tạo các tổ hợp, nhưng chủ sở hữu sản phẩm và người đánh giá bảo mật phải cung cấp chính sách.

OWASP ASVS nói ứng dụng nên thực thi kiểm soát truy cập ở lớp dịch vụ đáng tin cậy và áp dụng nguyên tắc đặc quyền tối thiểu cho chức năng lẫn dữ liệu. Tôi đồng ý về yêu cầu lớp dịch vụ, nhưng các nhóm thường xác minh quá hẹp. Họ kiểm tra handler HTTP hiển thị mà quên job nền, xuất dữ liệu, chỉ mục tìm kiếm, đăng ký websocket và URL lưu trữ đối tượng trực tiếp. Cùng chính sách phải tồn tại trên mọi đường đến đối tượng.

Một ma trận nhỏ có thể thực thi sẽ cho thấy nhiều hơn hướng dẫn mơ hồ «kiểm thử IDOR». Đoạn shell sau giả định một môi trường có thể hủy, hai bearer token và tài liệu thuộc người dùng A. Nó kiểm tra cả trạng thái lẫn việc phản hồi của B không có dấu hiệu bí mật của A:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

Kết quả mong đợi là không có đầu ra và mã thoát bằng không. Khi CI thất bại, cần lưu trạng thái, nội dung đã làm sạch, danh tính thực hiện, chủ sở hữu mục tiêu, route và phiên bản build. Không lưu thông tin xác thực đang hoạt động hoặc dữ liệu phản hồi không liên quan.

Bây giờ hãy thay đổi từng chiều một: đọc so với cập nhật, ID trực tiếp so với tìm kiếm, tư cách thành viên còn hiệu lực so với đã thu hồi, route thông thường so với xuất dữ liệu, và token người dùng so với token dịch vụ. Tác nhân có thể tạo và chạy các trường hợp này hiệu quả. Con người phải xem ma trận có khớp chính sách không và 404, 403, kết quả trống hay đối tượng được che bớt có phải kết quả mong muốn không. Nếu không, tác nhân có thể ăn mừng hành vi mà doanh nghiệp xem là vi phạm.

Bằng chứng phủ định cần được xử lý cẩn thận. Một lần cập nhật bị từ chối vẫn có thể tiết lộ đối tượng có tồn tại hay không qua thời gian phản hồi, văn bản lỗi hoặc bộ đếm phiên bản. Một lần đọc bị từ chối có thể tăng lượt xem hoặc ghi bản ghi kiểm toán chứa siêu dữ liệu bí mật. Hãy quyết định tác dụng phụ nào được phép, rồi kiểm tra chúng. Kiểm thử bảo mật chỉ xem phản hồi có thể bỏ lỡ kênh liệt kê hữu ích hoặc thao tác ghi gây hại.

Cũng cần kiểm thử thay đổi chính sách trong một phiên. Xóa người dùng khỏi dự án, chuyển quyền sở hữu, vô hiệu hóa tài khoản hoặc thu hẹp vai trò dịch vụ, rồi dùng lại token cũ và mở kết nối. Thời gian thu hồi kỳ vọng phải xuất phát từ chính sách sản phẩm. «Cuối cùng» không thể kiểm thử, và thu hồi ngay có thể không cần thiết, nhưng nhóm phải chọn một giới hạn rồi xác minh trên yêu cầu API, công việc trong hàng đợi, lượt tải xuống và đăng ký trực tiếp.

Cô lập tenant thất bại ngoài đường yêu cầu hiển nhiên

Cô lập tenant cần kiểm thử ở ranh giới lưu trữ, cache, hàng đợi, tìm kiếm, tệp, phân tích và quản trị. Lỗi phổ biến không phải thiếu tenant_id ở endpoint liệt kê chính. Nó nằm ở đường phụ sao chép, lập chỉ mục, lưu đệm hoặc xuất dữ liệu mà không mang theo ngữ cảnh tenant.

Hãy bắt đầu với hai tenant có bản ghi cố ý giống nhau và mỗi bên có một dấu hiệu không thể nhầm lẫn. Dùng người dùng, phiên riêng biệt và nếu kiến trúc cho phép, thông tin xác thực dịch vụ riêng biệt. Thực hiện tạo, đọc, cập nhật, xóa, liệt kê, tìm kiếm, xuất, nhập, truy cập tệp đính kèm, gửi thông báo và xử lý nền. Sau mỗi hành động, kiểm tra phản hồi mà người dùng thấy và trạng thái lưu bền. Một yêu cầu bị từ chối nhưng vẫn xếp job xuyên tenant vào hàng đợi là lỗi.

Tác nhân hữu ích vì chúng có thể theo dõi mã định danh qua các lớp và tạo hoán vị mà con người thấy tẻ nhạt. Chúng có thể nhận ra khóa cache dùng document_id còn truy vấn cơ sở dữ liệu dùng cả tenant_id và document_id. Chúng có thể so sánh worker xuất dữ liệu với handler tương tác và hỏi vì sao chỉ một bên thiết lập ngữ cảnh cấp hàng. Đó là các bước đánh giá giá trị cao.

Chúng cũng có một giả định nguy hiểm: tên gọi ngụ ý ranh giới. Hàm tên getTenantDocument có thể nhận đối số tenant tùy ý từ yêu cầu. Chính sách cơ sở dữ liệu có thể có trong migration nhưng không có ở bảng mới. Bộ lọc tìm kiếm có thể được áp dụng sau khi đếm kết quả, làm lộ hoạt động của tenant khác. Việc xác minh phải kiểm tra điều kiện được thực thi rồi thử đọc và ghi xuyên tenant.

Đừng để tác nhân tự tạo tiêu chí kiểm tra bằng cách đọc cùng mã mà nó kiểm thử. Hãy suy ra quyền truy cập mong đợi từ bảng chính sách độc lập, được duy trì cùng yêu cầu sản phẩm. Nếu phần triển khai và kiểm thử cùng hiểu sai một quy tắc, chúng sẽ hoàn toàn đồng thuận trong khi vẫn làm lộ dữ liệu.

Đường bất đồng bộ cần các kiểm tra trễ. Kích hoạt job xuất dữ liệu, thông báo, ảnh thu nhỏ hoặc lập chỉ mục với tenant A, thay đổi quyền sở hữu hoặc tư cách thành viên trước khi worker chạy, rồi kiểm tra kết quả đi tới đâu. Hãy quyết định worker nên dùng quyền được ghi nhận lúc yêu cầu hay kiểm tra lại quyền hiện tại lúc thực thi. Cả hai lựa chọn đều có thể đúng với một thao tác cụ thể, nhưng sự pha trộn vô tình tạo ra rò rỉ và nhật ký kiểm toán hỏng.

Công cụ quản trị cần danh tính riêng và kiểm tra việc ghi log. Quyền truy cập hỗ trợ thường được thiết kế để vượt qua ranh giới tenant, nên quy tắc đơn giản «tenant khác phải thất bại» là sai. Hãy kiểm tra người vận hành có vai trò và ngữ cảnh hồ sơ cần thiết, chính sách hiển thị với khách hàng có được tuân thủ, quyền truy cập có hết hạn và sự kiện kiểm toán có nhận diện người vận hành thay vì mạo danh khách hàng hay không.

Logic nghiệp vụ cần một câu chuyện về lạm dụng

Kiểm thử logic nghiệp vụ bắt đầu bằng một câu chuyện bị cấm: người dùng nhận được giá trị, quyền hạn hoặc trạng thái mà họ không đáng có bằng cách thực hiện các hành động hợp lệ theo thứ tự hoặc tổ hợp không hợp lệ. Nhãn lỗ hổng chung chung là quá yếu. Người kiểm thử cần biết lời mời, phê duyệt, hạn mức, hoàn tiền, tín dụng, chuyển quyền sở hữu và hủy bỏ phải tương tác với nhau thế nào.

OWASP Web Security Testing Guide yêu cầu người kiểm thử thử bỏ qua bước quy trình, lặp chức năng, làm giả yêu cầu, thay đổi thời điểm và lạm dụng tính năng hợp lệ. Phần giới thiệu cũ hơn về logic nghiệp vụ nói thẳng rằng tự động hóa bằng máy quét không thể cung cấp kiến thức hoặc sự sáng tạo riêng cho từng ứng dụng. Tác nhân hiện đại cải thiện tự động hóa, nhưng không xóa khoảng trống kiến thức. Mô hình có thể gợi ý mã giảm giá có thể dùng lại, nhưng không thể biết việc dùng lại là khuyến mãi hay gian lận nếu chưa có ai nêu quy tắc.

Hãy cung cấp cho tác nhân mô hình trạng thái với các chuyển đổi được phép và bất biến. Với luồng phê duyệt, một bất biến có thể là: «Người yêu cầu không được phê duyệt khoản thanh toán của chính mình, kể cả sau khi chuyển quyền sở hữu». Sau đó yêu cầu nó tạo các chuỗi liên quan đến đổi vai trò, yêu cầu trùng lặp, hủy, thử lại, đồng thời và phiên cũ. Tác nhân có thể khám phá nhiều chuỗi hơn rất nhiều so với số chuỗi một người thực hiện thủ công.

Các trường hợp khó liên quan đến hậu quả ngoài phản hồi HTTP. Hai yêu cầu đổi thưởng đồng thời đều có thể trả về thành công trong khi đối soát sau đó loại một yêu cầu. Việc hủy có thể dừng job hiển thị nhưng không thu hồi lượt tải xuống đã ký. Lời mời được chấp nhận sau khi người mời mất quyền có thể tạo tư cách thành viên không có chủ. Kiểm thử phải quan sát sổ cái, hàng đợi, quyền đối tượng và trạng thái sau đó, không chỉ mã trạng thái.

Người kiểm thử là con người có giá trị khi thách thức mô hình đã nêu. Họ hỏi liệu nhân viên hỗ trợ có thể kết hợp các chức năng vô hại không, người vận hành có thể ảnh hưởng nhật ký kiểm toán của chính mình không, hoặc đối tượng «hết hạn» có còn dùng được qua kênh khác không. Tác nhân hoạt động trong các mục tiêu và công cụ được giao. Con người có thể nhận ra mục tiêu đang bỏ qua phần nguy hiểm của nghiệp vụ.

Rủi ro phụ thuộc không chỉ là một phiên bản có lỗ hổng

Kiểm thử phụ thuộc có bốn câu hỏi riêng: có những gói nào, các phiên bản đã biết của chúng có lỗ hổng được báo cáo không, bản build có lấy đúng hiện vật dự kiến không, và ứng dụng có thực sự phơi bày hành vi dễ tổn thương không. Phân tích thành phần phần mềm (SCA) và kiểm soát nguồn gốc trả lời ba câu đầu đáng tin cậy hơn đánh giá hội thoại đơn thuần.

Tác nhân hữu ích sau khi đã có kiểm kê. Nó có thể kiểm tra cách gọi một phụ thuộc, xác định hàm bị ảnh hưởng có thể tiếp cận không, tìm kiểm soát bù trừ và soạn bản vá nâng cấp kèm kiểm thử hồi quy. Nó cũng có thể đánh dấu hành vi gói rủi ro chưa có mã định danh lỗ hổng, như script cài đặt có quyền truy cập mạng hoặc thư viện mới nhận bí mật trong môi trường.

Đừng yêu cầu mô hình nhớ dữ liệu lỗ hổng hiện tại. Hãy cung cấp cho nó nguồn cảnh báo có dấu thời gian, lockfile đã được phân giải và kho hiện vật đã build. Trí nhớ mô hình không phải cơ sở dữ liệu lỗ hổng, còn manifest gói không chứng minh được những gì đã được phát hành. Nguồn gốc SLSA đưa ra một phân biệt liên quan: nguồn gốc mô tả hiện vật được tạo ở đâu, khi nào và bằng cách nào. Nó không tuyên bố hiện vật an toàn.

Khả năng tiếp cận có thể giảm mức ưu tiên phân loại, nhưng không nên xóa trách nhiệm. Cờ tính năng thay đổi, mã chết quay lại và phụ thuộc gián tiếp được gọi theo những cách bất ngờ. Hãy ghi vì sao một phát hiện bị hoãn, phiên bản và đường gọi nào đã được đánh giá, cùng sự kiện nào cần mở lại. Tác nhân có thể duy trì lập luận đó, trong khi kiểm kê xác định theo dõi sự kiện.

Tên gói cũng tạo bẫy nhận diện. Phụ thuộc có tên dự kiến có thể đến từ registry sai, lockfile có thể trỏ tới vị trí có thể thay đổi, hoặc bước build có thể tải mã không có trong manifest. Hãy kiểm tra nguồn đã phân giải, hash, chữ ký ở nơi hệ sinh thái hỗ trợ và quyền truy cập mạng của build. Tác nhân có thể giải thích khác biệt, nhưng hệ thống build phải thực thi những nguồn mà nó chấp nhận.

Nâng cấp không tự động là thay đổi an toàn. Bản phát hành bảo mật có thể thay đổi việc phân tích cú pháp, mặc định phân quyền hoặc tuần tự hóa theo cách làm hỏng ứng dụng. Hãy tạo tái hiện tối thiểu cho cảnh báo, áp dụng nâng cấp trong nhánh cô lập và chạy cả bằng chứng bảo mật lẫn kiểm thử chức năng. Bằng chứng thu được hỗ trợ quyết định; việc mô hình nói phiên bản mới «nên tương thích» thì không.

Cảnh báo sai là vấn đề thiết kế bằng chứng

Một phát hiện chỉ đáng để lập trình viên dành thời gian khi có tuyên bố, bằng chứng, tác động và đường tái tạo. Báo cáo do AI tạo thường nghe có vẻ đầy đủ nhưng thiếu một trong các phần đó. Văn bản khắc phục trôi chảy khiến bằng chứng yếu khó nhận ra hơn.

Yêu cầu mỗi phát hiện của tác nhân xác định phiên bản và môi trường đã phân tích, thành phần bị ảnh hưởng, điều kiện tiên quyết của kẻ tấn công, ranh giới bảo mật bị vượt qua, kết quả quan sát hoặc suy luận, bước tái tạo và mức độ không chắc chắn. Đánh dấu phát hiện nguồn được suy luận khác với khai thác đã thực thi. Nếu tác nhân không thể chạy ứng dụng, nó phải nói điều đó trong phát hiện, không giấu giới hạn trong ghi chú cấp độ quét.

Sau đó áp dụng bộ từ vựng xử lý đơn giản: đã xác nhận, có khả năng, cần ngữ cảnh, không tái tạo được, rủi ro được chấp nhận hoặc đã sửa. «Cảnh báo sai» nên nghĩa là tuyên bố bảo mật sai, không phải nhóm không thích mức độ nghiêm trọng hoặc chọn hoãn công việc. Trộn các quyết định đó sẽ phá hỏng phản hồi. Tác nhân không thể biết quy tắc nào thất bại nếu mọi ticket không mong muốn đều nhận cùng một nhãn.

AI có thể giảm nhiễu bằng cách gom cụm vết trùng lặp, kiểm tra bộ làm sạch và kiểm thử lại sau khi sửa. Nó cũng có thể khuếch đại nhiễu bằng cách tạo mười biến thể thuyết phục của cùng một nghi ngờ yếu. Hãy loại trùng theo nguyên nhân gốc và ranh giới, không theo URL. Một kiểm tra quyền sở hữu bị thiếu, được tám endpoint sử dụng, là một lỗi kỹ thuật với tám điểm phơi bày.

Theo dõi độ chính xác theo danh mục và nguồn kiểm thử. Nếu báo cáo cross-site scripting do tác nhân tạo thường đúng nhưng tuyên bố về race condition hiếm khi tái tạo, hãy xử lý chúng theo cách khác. Đừng giảm hiệu năng thành một điểm duy nhất cho các loại lỗi không liên quan. Cổng nên thất bại dựa trên bằng chứng và chính sách, không dựa trên tính từ tự tin của mô hình.

Trách nhiệm khép lại vòng lặp. Mọi phát hiện được chấp nhận cần một người hoặc nhóm chịu trách nhiệm khắc phục, phương pháp kiểm thử lại dự kiến và bằng chứng được lưu để người kiểm thử khác có thể chạy. Nếu báo cáo chỉ tồn tại trong cuộc trò chuyện với tác nhân, nó sẽ biến mất khi cuộc trò chuyện, mô hình hoặc nhà cung cấp thay đổi. Công việc bảo mật trở nên bền vững khi bằng chứng còn tồn tại sau công cụ đã tạo ra nó.

Quyền riêng tư cũng quan trọng khi phân loại. Mã nguồn, nội dung yêu cầu, log và mẫu cơ sở dữ liệu có thể chứa thông tin xác thực hoặc dữ liệu khách hàng. Hãy giảm thiểu những gì tác nhân nhận được, che thông tin trong bản ghi lưu lại, tách dữ liệu kiểm thử khỏi dữ liệu production và áp dụng quy tắc xử lý dữ liệu đã được tổ chức phê duyệt cho nhà cung cấp mô hình cùng công cụ của họ. Phát hiện tốt hơn không biện minh cho việc sao chép toàn bộ sự cố production vào prompt không được kiểm soát.

Pentest do con người thực hiện kiểm tra các giả định xung quanh bài kiểm thử

Người kiểm thử xâm nhập giỏi thay đổi kế hoạch khi ứng dụng mâu thuẫn với bản mô tả. Đó là phần mà tác nhân chưa thay thế được. Con người phỏng vấn chủ sở hữu, giải quyết quy tắc mơ hồ, nhận ra lối tắt vận hành, yêu cầu thêm danh tính và quyết định khi nào hành vi lạ đáng để thực hiện một chuỗi thử nghiệm dài hơn.

Con người cũng chịu trách nhiệm về phán đoán khi bằng chứng không đầy đủ. Họ có thể phân biệt hành động khả thi về kỹ thuật với đường tấn công đáng tin, giải thích lỗi tổng hợp cho lãnh đạo và kỹ sư, đồng thời thương lượng bằng chứng an toàn khi khai thác có thể làm hỏng dữ liệu. Tác nhân tự động phải dừng ở ranh giới do người vận hành đặt ra. Nếu nó âm thầm mở rộng ranh giới đó, nó trở thành một rủi ro bảo mật khác.

Điều này không có nghĩa mỗi bản phát hành cần một đợt thuê ngoài kéo dài cả tuần. Hãy dùng kiểm thử con người ở nơi thay đổi gặp hậu quả: mô hình phân quyền mới, kiến trúc tenant, luồng thanh toán hoặc tín dụng, mặt phẳng quản trị, tích hợp nhạy cảm, migration lớn hoặc ra mắt công khai. Lập lịch công việc rộng hơn định kỳ theo rủi ro và kiểm thử lại các bản sửa nghiêm trọng. Bản phát hành thường lệ vẫn cần phạm vi tự động.

Hãy cung cấp cho người kiểm thử đầu ra của tác nhân, vết SAST, phạm vi DAST, ghi chú kiến trúc, tài khoản kiểm thử và các giả định chưa giải quyết. Tác nhân có thể xử lý trinh sát và các biến thể lặp lại trong khi người kiểm thử theo đuổi hành vi bất ngờ. Cách này giúp thời gian của con người hiệu quả hơn mà không giả vờ rằng nó không cần thiết.

Hãy thận trọng với tuyên bố «pentest tự động» được đo bằng số lượng phát hiện. Mười phát hiện injection quen thuộc không tương đương một đường đã được chứng minh qua gán vai trò, phân quyền cũ và lưu trữ xuất dữ liệu. Hãy đánh giá công việc theo ranh giới đã kiểm thử, chất lượng bằng chứng và các giả định quan trọng đã được thách thức.

Hãy hỏi ai chịu trách nhiệm dọn dẹp trước khi bắt đầu đợt kiểm thử. Tài khoản thử, tệp đã tải lên, tin nhắn xếp hàng, vai trò tạm thời và cờ tính năng đã thay đổi có thể tồn tại sau lần quét. Người dẫn dắt là con người nên phê duyệt bằng chứng có tính phá hủy, liên lạc với bộ phận vận hành và xác minh việc khôi phục. Tác nhân có thể theo script dọn dẹp, nhưng không thể tự quyết trạng thái production không giải thích được là an toàn để xóa.

Người kiểm thử giỏi cũng báo cáo những gì không thể kiểm thử. Bản build di động thiếu, vai trò không có sẵn, giới hạn tốc độ, callback bên thứ ba và môi trường không ổn định đều làm giảm mức đảm bảo. Tác nhân thường tiếp tục làm việc quanh trở ngại và trình bày những đường đã hoàn thành. Báo cáo cuối cùng phải làm nổi bật các phần loại trừ để kết quả sạch không bị hiểu nhầm là phạm vi đầy đủ.

Xây dựng một cổng từ nhiều loại bằng chứng

Chương trình đúng đắn giao việc cho từng phương pháp và khiến đầu ra của chúng gặp nhau tại cùng yêu cầu bảo mật. Dùng SAST cho mẫu mã nguồn xác định và phạm vi thay đổi rộng. Dùng SCA cùng nguồn gốc cho sự thật về phụ thuộc và build. Dùng DAST cho hành vi đã triển khai và kiểm tra thời gian chạy cơ bản. Dùng tác nhân để kết nối bằng chứng, khám phá luồng đã xác thực, tạo kiểm thử và cải thiện phân loại. Dùng con người để xác định chính sách, thách thức giả định nghiệp vụ và điều tra thay đổi có hậu quả lớn.

Khi đó chính sách phát hành có thể cụ thể. Chặn bản build khi quy tắc xác định mức nghiêm trọng cao khớp với đường đi chưa được phê duyệt, khi bất biến phân quyền bắt buộc không đạt, khi dấu hiệu xuyên tenant xuất hiện hoặc khi khai thác đã xác nhận vẫn còn mở. Chuyển các phát hiện tác nhân chưa chắc chắn sang đánh giá với hạn chót dựa trên mức phơi bày. Đừng để độ tự tin do mô hình tự báo cáo quyết định việc production có được phát hành hay không.

Hãy giữ bằng chứng có thể mang theo. Xuất phát hiện, kiểm thử được tạo, bản ghi yêu cầu, phiên bản công cụ, phiên bản mã, danh tính, phạm vi và trạng thái xử lý ở định dạng mà nhóm có thể xem mà không cần tác nhân. Điều này quan trọng cho kiểm toán, đánh giá sự cố, thay đổi nhà cung cấp và cả ngày bình thường khi bản cập nhật mô hình làm thay đổi hành vi.

Với ứng dụng được tạo qua trò chuyện, sự phân tách tương tự vẫn áp dụng. Koder.ai có thể tạo ứng dụng web, server và di động, đồng thời xuất mã nguồn của chúng, nhưng phần mềm được tạo vẫn cần yêu cầu bảo mật rõ ràng và kiểm thử độc lập với kết quả đã triển khai. Việc tạo nhanh khiến một cổng rõ ràng càng hữu ích vì kiến trúc và mã có thể thay đổi nhanh.

Hãy chạy tác nhân liên tục, nhưng nâng những phát hiện tốt nhất của nó thành kiểm thử hồi quy xác định. Mỗi lần vượt qua phân quyền đã xác nhận nên trở thành một trường hợp chính sách. Mỗi lần rò rỉ tenant nên bổ sung một bất biến tại ranh giới đã thất bại. Mỗi quy tắc nhiều nhiễu nên có trạng thái xử lý được ghi lại. Theo thời gian, tác nhân nên để lại hệ thống kiểm thử chính xác hơn khi nó bắt đầu.

Đừng hỏi công cụ đơn lẻ nào thắng. Hãy hỏi mỗi tuyên bố quan trọng có bằng chứng độc lập không: đường mã đã được đánh giá, hành vi đã triển khai đã được thực hiện, quy tắc nghiệp vụ đến từ chủ sở hữu và một người đã thách thức các giả định ở nơi thất bại sẽ gây tổn hại. Nếu một trong các dòng đó để trống, lời «mọi thứ đều ổn» do AI tạo ra không thể lấp đầy nó.