Trí tuệ nhân tạo (AI) đang thay đổi bộ mặt của bảo mật tấn công (offensive security), nhưng nó vẫn chưa thay đổi được tiêu chuẩn quan trọng nhất: một phát hiện phải được chứng minh trước khi nó trở nên hữu ích. Các công cụ hỗ trợ AI có thể đọc mã nhanh chóng, tạo payload, tóm tắt bề mặt tấn công, giải thích các API lạ và thực hiện các quy trình kiểm thử lặp đi lặp lại với tốc độ ấn tượng. Đó là một lợi thế thực sự cho các đội ngũ bảo mật. Tuy nhiên, nó cũng tạo ra một loại áp lực mới, vì ngành này giờ đây có thể tạo ra nhiều kết quả "trông giống như lỗ hổng" hơn bao giờ hết.
Vấn đề là kết quả đầu ra không đồng nghĩa với bằng chứng. Một báo cáo do AI tạo ra có thể nghe rất chuyên nghiệp, bao gồm xếp hạng mức độ nghiêm trọng và thậm chí chứa một bản proof-of-concept trông có vẻ hợp lý ngay cái nhìn đầu tiên. Nhưng không có điều nào trong số đó chứng minh được lỗi tồn tại trong môi trường thực tế. Không có gì chứng minh được khả năng khai thác (exploitability), tác động hoặc rủi ro. Trong kiểm thử tấn công, phần khó nhất chưa bao giờ là viết một thứ gì đó nghe giống như một báo cáo lỗ hổng. Phần khó nhất là chứng minh điều gì thực sự đúng.
Sự phân biệt đó ngày càng trở nên quan trọng khi AI trở nên phổ biến hơn trong các quy trình bảo mật. AI có thể tăng tốc quá trình khám phá, nhưng việc xác thực vẫn phụ thuộc vào kiến thức: kiến thức về hệ thống, giao thức, hành vi ứng dụng, ranh giới định danh, memory corruption, logic kinh doanh và tất cả các chi tiết triển khai ngăn cách giữa một lý thuyết suông và một exploit thực sự. Tương lai của bảo mật tấn công sẽ không thuộc về những người chỉ đơn thuần tạo ra số lượng phát hiện lớn nhất. Nó sẽ thuộc về những người và những đội ngũ có thể chứng minh được những gì thực sự quan trọng.
Ngành bảo mật đang chứng kiến cái giá của kết quả AI hời hợt
Các dấu hiệu cảnh báo đã hiện rõ. Các chương trình bug bounty và những người duy trì hệ thống đang phải đối mặt với làn sóng báo cáo do AI tạo ra với chất lượng thấp, thường được gửi kèm với bằng chứng mỏng manh, ngôn ngữ theo khuôn mẫu và ít có sự xác thực ý nghĩa. Bugcrowd đã công khai giải quyết mô hình này trong các thay đổi chính sách về các báo cáo do AI tạo ra, mô tả chúng là loại báo cáo trông thì bóng bẩy nhưng lại tạo ra gánh nặng phân loại (triage) không cần thiết thay vì đưa ra một tín hiệu bảo mật hữu ích.
Đây không chỉ là vấn đề của bug bounty. Đó là hình ảnh xem trước của những gì sẽ xảy ra ở bất cứ nơi nào AI được sử dụng để tạo ra các phát hiện bảo mật mà không có đủ sự đánh giá của con người. Nếu một công cụ có thể tạo ra một bài viết thuyết phục trong vài giây, các tổ chức sẽ nhận được nhiều báo cáo hơn, nhiều cảnh báo hơn và nhiều tuyên bố hơn. Trừ khi những tuyên bố đó được xác thực, kết quả sẽ không phải là bảo mật tốt hơn, mà chỉ là một hàng đợi dài hơn.
Các đội ngũ bảo mật vốn đã quá tải với kết quả quét từ scanner, cảnh báo phụ thuộc (dependency alerts), các vấn đề cấu hình cloud và các phát hiện tuân thủ. Việc thêm các suy đoán do AI tạo ra vào đống đó sẽ không giúp ích gì trừ khi tiêu chuẩn chất lượng cũng được nâng cao đồng thời. Một phát hiện nên trả lời các câu hỏi cơ bản một cách rõ ràng: điều gì đã xảy ra, nó được tái hiện như thế nào, kẻ tấn công kiểm soát những gì, ranh giới nào đã bị vượt qua và tác động thực tế đã được chứng minh là gì. Nếu không có những điều đó, báo cáo có thể thú vị, nhưng nó chưa sẵn sàng để thúc đẩy hành động kỹ thuật.
"Trông có vẻ hổng" không có nghĩa là "Có lỗ hổng"
Một trong những thói quen nguy hiểm nhất trong kiểm thử tấn công là nhầm lẫn giữa một mẫu nghi vấn với một lỗ hổng đã được xác thực. AI có thể làm cho thói quen đó trở nên tồi tệ hơn vì nó rất giỏi trong việc giải thích tại sao một thứ gì đó có thể là xấu. Một mô hình có thể thấy đầu vào của người dùng gần một truy vấn cơ sở dữ liệu và mô tả đó là SQL injection. Nó có thể thấy một hành động lấy URL và gợi ý SSRF. Nó có thể thấy một API nguy hiểm trong một đường dẫn mã và mô tả remote code execution (RCE). Đôi khi mô hình chỉ đúng một vấn đề thực tế. Những lúc khác, nó lại bỏ qua các điều kiện quyết định liệu vấn đề đó có quan trọng hay không.
Một kiểm thử viên (tester) vẫn phải chứng minh khả năng tiếp cận (reachability). Đầu vào do kẻ tấn công kiểm soát có thực sự chạm tới thao tác nguy hiểm không? Có yêu cầu xác thực (authentication) không? Phân quyền (authorization) có được thực thi ở nơi khác không? Tính năng dễ bị tổn thương có được bật không? Cấu hình sản xuất có để lộ đường dẫn mã đó không? Ứng dụng có chuẩn hóa, mã hóa, làm sạch hoặc từ chối payload trước khi nó gây hại không? Vấn đề có vượt qua ranh giới tin cậy (trust boundary) hay chỉ ảnh hưởng đến một đường dẫn nội bộ không có tác động bảo mật thực tế?
Những câu hỏi này là nơi bảo mật tấn công thực sự bắt đầu. Chúng cũng là nơi mà sự tự động hóa hời hợt thường thất bại. AI có thể tạo ra các giả thuyết nhanh chóng, nhưng giả thuyết không phải là phát hiện. Một tester giỏi coi đầu ra của AI là một manh mối để điều tra, không phải là một kết luận để chuyển tiếp.
Tại sao kiến thức vẫn quan trọng
Những chuyên gia bảo mật tấn công giỏi nhất có giá trị vì họ hiểu hệ thống, chứ không phải vì họ biết chạy công cụ. Công cụ luôn là một phần của công việc, nhưng kết quả của công cụ chưa bao giờ là đủ. Một scanner web có thể xác định một tham số phản chiếu đầu vào. Một bộ phân tích tĩnh có thể gắn cờ một hàm nguy hiểm. Một fuzzer có thể tạo ra một vụ sập (crash). Một mô hình ngôn ngữ có thể mô tả một lộ trình tấn công hợp lý. Trong mọi trường hợp, ai đó vẫn cần hiểu tín hiệu đó có nghĩa là gì.
Sự hiểu biết đó thường có được thông qua sự lặp đi lặp lại. Các nhà nghiên cứu cao cấp đã dành nhiều năm làm việc thủ công: theo dõi các yêu cầu (requests), đọc mã nguồn, dịch ngược (reverse engineering) các tệp thực thi, gỡ lỗi crash, phá vỡ các quy trình xác thực và học cách các hệ thống thực tế thất bại. Quá trình đó xây dựng trí nhớ và bản năng. Nó dạy cho người thực hành biết khi nào một phát hiện có thể là thật, khi nào một công cụ đang bị đánh lừa và khi nào một lỗi nhỏ có thể trở nên nghiêm trọng nếu được chuỗi (chained) với một thứ khác.
Loại kiến thức này rất khó để làm giả. Nó thể hiện qua những câu hỏi mà tester đặt ra. Nó thể hiện qua cách một báo cáo được viết. Nó thể hiện qua việc liệu tester có thể giải thích lộ trình khai thác mà không cần ẩn mình sau những ngôn từ chung chung hay không. Quan trọng nhất, nó xuất hiện khi nỗ lực đầu tiên thất bại. Một người hiểu hệ thống có thể thích nghi. Một người chỉ chấp nhận lời giải thích của công cụ thường sẽ bị kẹt lại.
AI có thể giúp tester giỏi nhanh hơn, nhưng cũng có thể làm con người "lục nghề"
Có một mối lo ngại thực sự trong số những người thực hành dày dạn kinh nghiệm rằng sự phụ thuộc quá mức vào AI có thể khiến con người bị "lục nghề". Đây không phải là một lập luận chống lại AI. Đó là một lập luận về việc học tập của con người. Khi một công cụ trả lời mọi câu hỏi ngay lập tức, người ta dễ bị cám dỗ để ngừng ghi nhớ các chi tiết. Khi nó viết phiên bản đầu tiên của mọi kịch bản (script), người ta dễ bị cám dỗ để ngừng luyện tập. Khi nó giải thích mọi đường dẫn mã, payload, crash và thông báo lỗi, người ta dễ bị cám dỗ để ngừng tự xây dựng mô hình tư duy cho chính mình.
Sự tiện lợi đó đi kèm với một cái giá. Bảo mật tấn công đòi hỏi chiều sâu, khả năng nhận diện mẫu và khả năng truy hồi kỹ thuật. Những phát hiện khó nhất thường đến từ việc nhận ra rằng một hành vi ở khu vực này vi phạm một giả định ở nơi khác. Chúng đến từ việc biết cách các parser, framework, allocator, nhà cung cấp định danh và hệ thống ủy quyền đã từng thất bại trước đây. Chúng đến từ việc nhìn thấy mối liên hệ giữa các chi tiết nhỏ trông không có vẻ quan trọng khi đứng biệt lập.
Nếu những người thực hành ngừng rèn luyện những kỹ năng đó, họ sẽ mất đi chính kỹ năng làm nên sự hiệu quả của mình. Rủi ro không phải là AI làm cho các chuyên gia bảo mật trở nên vô dụng. Rủi ro là con người để AI suy nghĩ quá nhiều và quá sớm, sau đó nhầm lẫn sự trôi chảy với năng lực thực sự. Prompting là hữu ích, nhưng nó không thể thay thế cho sự phán đoán.
Hầu hết các thử nghiệm hỗ trợ bởi AI vẫn sử dụng các kỹ thuật quen thuộc
Rất nhiều hoạt động tiếp thị bảo mật AI có thể khiến bạn cảm thấy như thể học máy đang khám phá ra các lỗ hổng thông qua một loại suy luận hoàn toàn mới. Đôi khi các mô hình thực sự phát hiện ra các mẫu mà con người có thể bỏ lỡ, đặc biệt là trên các kho mã lớn và lạ lẫm. Điều đó rất hữu ích. Nhưng trong nhiều quy trình kiểm thử tấn công thực tế, các kỹ thuật cơ bản vẫn rất quen thuộc: liệt kê các endpoint, kiểm tra tham số, theo dõi luồng dữ liệu, so sánh hành vi có xác thực và không xác thực, tạo payload, chạy fuzzer, quan sát phản hồi và xác định xem trạng thái ứng dụng có thay đổi theo cách liên quan đến bảo mật hay không.
Nói cách khác, nhiều hệ thống hỗ trợ AI đang điều phối các kỹ thuật kiểm thử đã biết ở quy mô lớn. Chúng có thể lập kế hoạch, thực hiện, quan sát và lặp lại nhanh hơn một con người làm thủ công mọi thứ. Đó là một cải tiến có ý nghĩa, nhưng nó không loại bỏ nhu cầu hiểu kết quả. Nếu hệ thống báo cáo một lỗi ủy quyền, ai đó vẫn phải biết liệu mối quan hệ giữa các đối tượng có quan trọng hay không. Nếu nó báo cáo một lỗi memory corruption, ai đó vẫn phải suy luận về khả năng tiếp cận, ngữ cảnh crash, các biện pháp giảm thiểu và khả năng khai thác. Nếu nó báo cáo một điểm yếu API, ai đó vẫn phải xác định xem hành vi quan sát được có vi phạm mô hình tin cậy của ứng dụng hay không.
Cách sử dụng AI giá trị nhất không phải là để thay thế những quyết định đó. Đó là để giảm bớt các công việc cơ học xung quanh chúng để các tester lành nghề có thể dành nhiều thời gian hơn cho việc phân tích và xác thực.
Thế nào là một sự xác thực tốt?
Một phát hiện tấn công đã được xác thực phải cụ thể, có thể tái hiện và gắn liền với tác động. Nó không nên yêu cầu người đọc phải đoán tại sao vấn đề đó lại quan trọng. Báo cáo nên làm cho lộ trình khai thác đủ rõ ràng để một kỹ sư có thể tái hiện nó và một lãnh đạo bảo mật có thể hiểu được rủi ro. Điều đó không có nghĩa là mọi vấn đề đều cần một chuỗi khai thác kịch tính hay một bản proof-of-concept kiểu phim ảnh. Nó có nghĩa là bằng chứng phải hỗ trợ cho tuyên bố.
Đối với kiểm thử hỗ trợ bởi AI, các đội ngũ nên vạch ra một ranh giới rõ ràng giữa "manh mối" (leads) và "phát hiện đã xác thực" (validated findings). Một manh mối là thứ đáng để điều tra. Một phát hiện đã xác thực là thứ đã được kiểm tra và chứng minh. Việc trộn lẫn hai loại này sẽ tạo ra sự nhầm lẫn và lãng phí thời gian. Một quy trình làm việc tốt hoàn toàn có thể sử dụng AI để tạo ra các manh mối, nhưng việc nâng cấp từ manh mối lên phát hiện phải yêu cầu bằng chứng.
Danh sách kiểm tra xác thực thực tế
Một tiêu chuẩn xác thực thực tế không cần phải phức tạp. Trước khi một manh mối trở thành một phát hiện được báo cáo, tester nên có khả năng trả lời các câu hỏi như sau:
- Hành vi cụ thể nào đã được quan sát và nó xảy ra ở đâu?
- Yêu cầu đầu vào, định danh hoặc trạng thái nào do kẻ tấn công kiểm soát?
- Ranh giới bảo mật nào đã bị vượt qua (ví dụ: xác thực, ủy quyền, quyền hạn, hoặc an toàn bộ nhớ)?
- Các bước chính xác để tái hiện hành vi trong môi trường mục tiêu là gì?
- Tác động thực tế đã được chứng minh là gì, không chỉ là trường hợp xấu nhất trên lý thuyết?
- Bằng chứng nào cho thấy vấn đề có thể tiếp cận được và có liên quan trong cấu hình đã triển khai?
- Một bản vá sẽ cần thay đổi những gì và làm thế nào để đội ngũ có thể xác nhận rằng bản vá đó hoạt động?
Vai trò của con người vẫn mang tính kỹ thuật cao
Một trong những thực tế ít được đánh giá cao của các nền tảng bảo mật AI là sự xác thực của con người vẫn đóng vai trò cực kỳ quan trọng ở phía sau. Điều này không có gì ngạc nhiên. Bảo mật tấn công luôn đòi hỏi sự phán đoán, và sự phán đoán đặc biệt quan trọng khi các phát hiện mang lại hậu quả lớn. Người xem xét bằng chứng phải quyết định xem lộ trình khai thác có thực tế hay không, môi trường có quan trọng không, vấn đề là đơn lẻ hay có thể tạo chuỗi, và liệu tuyên bố về mức độ nghiêm trọng có chính đáng hay không.
Đây không chỉ là chức năng kiểm soát chất lượng hành chính. Đó là công việc kỹ thuật. Các lỗi ủy quyền thường phụ thuộc vào logic kinh doanh và mối quan hệ đối tượng. Các lỗ hổng API có thể yêu cầu hiểu cách các vai trò, người dùng và tài nguyên tương tác. Memory corruption yêu cầu suy luận về trạng thái crash, khả năng kiểm soát và các cơ chế khai thác. AI có thể hỗ trợ tất cả những điều này, nhưng nó không loại bỏ nhu cầu về một người thực sự hiểu họ đang nhìn thấy gì.
Tránh phóng đại tác động
Các báo cáo do AI tạo ra cũng có thể phóng đại mức độ nghiêm trọng. Đầu vào được phản xạ không phải là cross-site scripting (XSS) cho đến khi việc thực thi tập lệnh được chứng minh. Một hành động lấy URL không phải là SSRF có ý nghĩa cho đến khi tester có thể cho thấy quyền truy cập vào thứ gì đó mà kẻ tấn công không nên chạm tới. Những sai lầm này không chỉ gây bối rối; chúng làm xói mòn lòng tin giữa đội ngũ bảo mật và đội ngũ kỹ thuật. Thường xuyên xảy ra trường hợp một phát hiện được xếp hạng CVSS 9.8, trong khi trên thực tế nó thậm chí có thể không phải là một lỗ hổng.
Những nhà nghiên cứu giàu kinh nghiệm rất cẩn thận với tác động vì họ biết rằng nó phải được chứng minh. Một lỗi trong tính năng chỉ dành cho quản trị viên không mang lại rủi ro giống như một lỗi không cần xác thực đối mặt với internet. Một vụ crash có thể là lỗi từ chối dịch vụ (DoS), một đường dẫn đến thực thi mã, hoặc đơn giản là một vấn đề về độ tin cậy không thể khai thác, tùy thuộc vào ngữ cảnh. Cách duy nhất để biết là xác thực.
Cách các đội ngũ nên sử dụng AI mà không làm mất đi kỹ năng
Mục tiêu đúng đắn không phải là né tránh AI. Công nghệ này quá hữu ích để làm điều đó. Mục tiêu đúng đắn là sử dụng nó theo cách tăng cường kiểm thử tấn công thay vì làm yếu đi những người thực hiện nó. AI nên giúp tester di chuyển nhanh hơn, khám phá nhiều giả thuyết hơn và giảm bớt các công việc lặp đi lặp lại. Nó không nên trở thành vật thay thế cho việc học cách các hệ thống vận hành.
Các nhà lãnh đạo bảo mật có thể khuyến khích sự cân bằng đó bằng cách đặt ra các kỳ vọng xung quanh bằng chứng và đào tạo. Các tester cấp thấp vẫn nên học các kiến thức cơ bản trước khi thuê ngoài quá nhiều quy trình cho AI. Các tester cấp cao nên sử dụng AI như một công cụ nhân sức mạnh, không phải là một cơ quan có thẩm quyền tối cao. Các đội ngũ nên xem xét không chỉ liệu một phát hiện có được tạo ra hay không, mà còn liệu tester có thể giải thích và tái hiện nó hay không.
Một chương trình kiểm thử tấn công hỗ trợ bởi AI lành mạnh nên thưởng cho tác động đã được xác thực thay vì số lượng. Nó nên đo lường chất lượng tín hiệu, không chỉ đếm số lượng phát hiện. Nó cũng nên sử dụng AI như một công cụ giảng dạy: khi mô hình gợi ý một vấn đề, tester nên hỏi tại sao, kiểm tra tuyên bố đó và học hỏi từ kết quả.
Tiêu chuẩn không thay đổi: Hãy chứng minh đi!
AI sẽ tiếp tục được cải thiện. Các Agent sẽ trở nên giỏi hơn trong việc điều hướng ứng dụng, đọc mã, tạo payload và lập tài liệu kết quả. Nhưng bảo mật tấn công không thể trở thành một trò chơi về số lượng, nơi mọi lý thuyết hợp lý đều trở thành gánh nặng phân loại của người khác.
Tiêu chuẩn cốt lõi của lĩnh vực này vẫn rất đơn giản: hãy chứng minh điều đó. Chứng minh lỗ hổng tồn tại. Chứng minh kẻ tấn công có thể chạm tới nó. Chứng minh tác động. Chứng minh rủi ro kinh doanh. Chứng minh bản vá hoạt động. AI không làm hạ thấp tiêu chuẩn đó. Nếu có, nó còn làm tăng tầm quan trọng của việc thực thi tiêu chuẩn này, bởi vì những kết quả đầu ra thuyết phục nhưng chưa được chứng minh giờ đây dễ dàng được tạo ra hơn bao giờ hết.
Biết khi nào nên dừng lại, kiểm tra, thử nghiệm và suy nghĩ sẽ vẫn là một lợi thế cạnh tranh. Kiến thức vẫn quan trọng vì sự xác thực vẫn quan trọng, và trong bảo mật tấn công, xác thực là ranh giới giữa tiếng ồn và sự thật.
Tôi sẽ mở rộng về chủ đề này trong khóa học SEC660: Advanced Penetration Testing, Exploit Writing, and Ethical Hacking tại sự kiện SANS Network Security 2026. Bản cập nhật khóa học của chúng tôi kết hợp giữa sự hiểu biết thủ công về các chủ đề phức tạp và hướng dẫn cách tận dụng AI để hỗ trợ tự động hóa các tác vụ cụ thể.
Lưu ý: Bài viết này được viết và đóng góp bởi Stephen Sims, chuyên gia tại SANS.
