Anthropic bảo mật vòng đời phát triển phần mềm AI-native như thế nào?

Code

Các chuyên gia bảo mật trong một tổ chức kỹ thuật AI-native có một đòn bẩy mới: họ có thể trực tiếp định hình cách mã nguồn được tạo ra, giúp ngăn chặn các lỗ hổng ngay từ nguồn.

Trước đây, các nhóm thường quan sát thấy những lỗ hổng lặp đi lặp lại và tạo ra các hướng dẫn lập trình an toàn để giải quyết chúng, nhưng những hướng dẫn đó rất khó thực thi và hiếm khi được chuẩn hóa.

Tại Anthropic, các hướng dẫn đó được mã hóa trong các tệp CLAUDE.md và các tham chiếu đến các kỹ năng trên toàn tổ chức, nhờ đó mã nguồn tuân thủ các phương pháp tốt nhất này ngay khi vừa được tạo ra. Điều này được thực hiện như một phần của vòng lặp khép kín. Khi một tác nhân (agent) phát hiện ra một loại lỗi, tệp liên quan sẽ được cập nhật để ngăn chặn lỗi đó tái diễn trong mã nguồn tương lai.

Tất nhiên, điều đó không có nghĩa là mọi mã nguồn tạo ra đều hoàn hảo. Nhóm của chúng tôi bắt đầu với một tệp CLAUDE.md hướng dẫn tác nhân chạy lệnh /security-review như một bước cuối cùng trước khi mở một PR (Pull Request). Lệnh phổ biến này, phiên bản thương mại hóa từ quy trình đánh giá nội bộ của nhóm chúng tôi, sẽ tìm kiếm những nơi mà dữ liệu đầu vào có khả năng bị kẻ tấn công kiểm soát xâm nhập, quét các liên kết đáng ngờ và sau đó xác minh các kết quả tìm thấy.

Ngày nay, các đánh giá này diễn ra ngay trong khi Claude tạo mã. Sau khi plugin hướng dẫn bảo mật được cài đặt, Claude sẽ xem xét cuộc trò chuyện và mã nguồn trong thời gian thực. Nó đề xuất các cải tiến bảo mật và giải quyết các lỗ hổng phổ biến ngay trong cùng phiên làm việc khi nó tạo mã.

Các gợi ý khác tại thời điểm PR thúc đẩy các nhóm nội bộ, phi kỹ thuật chuyển sang lưu trữ ứng dụng của họ trên nền tảng lưu trữ ứng dụng low-code của chúng tôi, tránh tình trạng shadow IT vốn là vấn đề đau đầu đối với các nhóm bảo mật truyền thống.

Một số khách hàng của chúng tôi chọn tích hợp /security-review với hook PreToolUse, biến bước này thành một cổng kiểm soát chặt chẽ hơn. Cách này cũng hiệu quả, nhưng nhóm của chúng tôi đã chọn kết hợp cổng kiểm soát đánh giá mã nguồn nghiêm ngặt ở giai đoạn kiểm thử/CI của chu kỳ.

Ngoài việc định hình và đánh giá mã nguồn, việc kiểm soát phạm vi ảnh hưởng (blast radius) là một trong những mối quan tâm hàng đầu của chúng tôi ở giai đoạn này. Chúng tôi thực hiện điều này bằng cách thiết lập các ranh giới cứng xung quanh danh tính (sẽ nói thêm ở phần giám sát) và thiết lập cho các nhà phát triển của chúng tôi lập trình trên các máy ảo (VM).

Việc chuyển sang lập trình trên các máy ảo từ xa là một sự thay đổi tương đối dễ dàng và mang lại cho chúng tôi khả năng kiểm soát cũng như tầm nhìn tốt hơn so với việc chỉ sử dụng máy tính xách tay. Lưu lượng truy cập của tác nhân trên các máy ảo này được đưa vào danh sách cho phép (egress-allowlisted).

Các kiểm soát đầu ra (egress) chặt chẽ này đặc biệt quan trọng khi tác nhân đang đọc dữ liệu đầu vào không đáng tin cậy, vốn có thể chứa payload tiêm lệnh (prompt-injection). Một lệnh được tiêm không thể tiếp cận các đích tùy ý trên internet: các đường dẫn rò rỉ dữ liệu bị giới hạn trong một tập hợp nhỏ các dịch vụ được giám sát.

Ở đây, bạn có thể thấy một sự thích nghi rõ ràng cho quy trình phát triển phần mềm (SDLC) AI-native. Lập trình từ xa trước đây chủ yếu được sử dụng để bảo vệ sở hữu trí tuệ (IP), và ngày nay chúng ta đang thấy các nhóm lập trình AI trưởng thành hơn áp dụng các môi trường này như một phương tiện để kiểm soát các tác nhân.

Nguyên tắc bền vững: "Shifting left" (chuyển dịch sang trái) trong một tổ chức kỹ thuật AI-native có nghĩa là đóng vòng lặp giữa việc phát hiện lỗ hổng và cập nhật hướng dẫn để tùy chỉnh cách Claude tạo mã. Hãy giới hạn phạm vi ảnh hưởng (Nguyên tắc ít đặc quyền nhất - Principle of Least Agency) và những gì một tác nhân có thể truy cập bằng các ranh giới cứng khi cần thiết.

Kiểm thử (CI)

Theo kinh nghiệm của tôi, giai đoạn kiểm thử hoặc CI nhanh chóng trở thành nút thắt cổ chai đau đớn nhất đối với các nhóm kỹ thuật đang trong quá trình chuyển đổi sang AI-native. Tại Anthropic, khi hầu hết các nhà phát triển đều sử dụng các công cụ lập trình có tính tác nhân (agentic coding tools) và chạy nhiều tác nhân cùng một lúc, rõ ràng là nhóm chỉ có thể tiến nhanh bằng tốc độ con người đánh giá mã nguồn.

Hãy làm rõ: trách nhiệm giải trình của con người vẫn là trọng tâm trong quy trình của chúng tôi. Những gì chúng tôi đã làm là tăng tốc quy trình đánh giá bằng cách kết hợp các đánh giá tự động của tác nhân và đánh giá xác định (deterministic), đồng thời dành riêng việc đánh giá của con người cho các mã nguồn được quản lý chặt chẽ hoặc thực sự quan trọng.

Trong lịch sử, đánh giá mã nguồn bởi con người được coi là tiêu chuẩn, tuy nhiên bằng chứng thực nghiệm cho thấy nó không hoàn hảo. Các lỗi bảo mật vẫn thường xuyên xuất hiện trong phần mềm trên khắp thế giới. Quy trình đánh giá của chúng tôi có khả năng xem xét nhiều mã nguồn hơn và phát hiện các vấn đề đặc biệt phức tạp, giúp giảm thiểu những rủi ro này.

Tỷ lệ các PR nhận được các bình luận đánh giá thực chất đã tăng từ 16% lên 54% khi chúng tôi có thêm niềm tin vào các kết quả tìm thấy bằng cách yêu cầu các tác nhân viết bằng chứng xác nhận rằng phát hiện của chúng là hợp lệ. Chúng tôi cũng xác định rằng khoảng một phần ba số lỗi đằng sau các sự cố claude.ai trước đây sẽ được phát hiện bởi các quy trình tự động mà chúng tôi đã triển khai hiện nay.

Chúng tôi không phải là tổ chức duy nhất nhận thấy điều này là đúng. Intercom đã chia sẻ rằng họ tự động phê duyệt 19% số PR của mình. Việc triển khai đã tăng gấp đôi trong khi thời gian ngừng hoạt động do các thay đổi mã nguồn gây lỗi đã giảm 35%. CircleCI cũng đạt được kết luận tương tự khi xây dựng Chunk, một tác nhân tự hành trên Claude giúp giải quyết các vấn đề bảo trì CI/CD và tự xác thực các bản sửa lỗi của chính nó trước khi con người nhìn thấy chúng. Cách tiếp cận này đã tăng gấp đôi tỷ lệ các tác vụ của tác nhân chuyển đổi thành các pull request hoàn chỉnh.

Khi một PR được mở tại Anthropic, nhiều tác nhân sẽ tự động đánh giá nó. Mỗi tác nhân đánh giá được thiết kế và giới hạn trong một phạm vi cụ thể, hẹp và tận dụng RAG để có thêm ngữ cảnh và bộ nhớ về các sự cố trong quá khứ.

Cách này hiệu quả hơn nhiều so với một mega-prompt hoặc một siêu tác nhân bảo mật vì một vài lý do:

Cần làm rõ rằng các tác nhân không tự ý hợp nhất (merge) mã nguồn vào môi trường production mà không được kiểm tra. Chúng tôi phân loại cơ sở mã theo mức độ rủi ro và đưa ra các quyết định có chủ đích về việc phần nào cần tự động hóa. Toàn bộ cơ sở mã đều có quy trình phê duyệt nghiêm ngặt bởi con người.

Trách nhiệm giải trình của con người vẫn là trọng tâm đối với mã nguồn được Claude đánh giá và hợp nhất. Mỗi phê duyệt đều được ghi lại cùng với các tín hiệu và lý do đằng sau nó, và một mẫu được đánh giá theo trọng số rủi ro sẽ được con người kiểm tra lại. Một vòng kiểm thử khác tập trung vào các bất biến như "người dùng A không bao giờ có thể đọc dữ liệu của người dùng B" và kích hoạt các đánh giá thủ công bổ sung. Chúng tôi cũng kết hợp các bản quét tác nhân với các công cụ SAST, vốn đăng kết quả trực tiếp lên các PR.

Hầu hết các phương pháp quét, dù là tác nhân hay xác định, đều dựa trên mức tiêu thụ. Chi phí sẽ tăng khi lưu lượng mã nguồn tăng, và các nhóm sẽ cần quyết định mức độ bao phủ nào là phù hợp với họ.

Tại Anthropic, chúng tôi chấp nhận chi phí ở đây sẽ tăng khi tốc độ mã nguồn của chúng tôi tăng, nhưng dự đoán chi phí đơn vị sẽ giảm. Các mô hình ngày nay lập trình tốt hơn nhiều so với tất cả các mô hình từ vài năm trước, và chúng tôi dự đoán mô hình này sẽ tiếp tục.

Nguyên tắc bền vững: Đánh giá tự động là một loại rủi ro khác được kiểm soát theo cách khác (thông qua nhiều cổng và các tác nhân với các cửa sổ ngữ cảnh riêng biệt). Con người vẫn nằm trong vòng lặp, nhưng có thể ở các vị trí khác nhau trong vòng đời tùy thuộc vào bản chất của cơ sở mã.

Triển khai (CD)

Anthropic duy trì một môi trường staging mạnh mẽ, nơi chúng tôi thực hiện các phương pháp bảo mật tốt nhất phổ biến như kiểm thử xâm nhập (pentesting) bên ngoài cho các đợt ra mắt lớn và quét DAST định kỳ để phát hiện các lỗi logic mà các bản quét tĩnh đã bỏ sót hoặc không thể nhìn thấy.

Giống như các giai đoạn SDLC khác, AI mang đến cả thách thức và giải pháp mới cho các nhóm bảo mật. Một mặt, ít lỗ hổng hơn lọt đến giai đoạn này. Mặt khác, những lỗ hổng còn sót lại lại là những lỗ hổng tinh vi và khó phát hiện nhất.

Kết hợp với khối lượng mã nguồn lớn hơn được vận chuyển thường xuyên hơn, việc kiểm thử động định kỳ dường như không còn "động" nữa.

Tin tốt là các mô hình AI giỏi hơn trong việc suy luận đa bước, đa thành phần, có thể phát hiện tỷ lệ lớn hơn các lỗ hổng phức tạp này. Ví dụ, vào tháng 2, chúng tôi đã tiết lộ rằng Claude đã phát hiện và giúp sửa hơn 500 lỗ hổng OSS mức độ nghiêm trọng cao.

Tại Anthropic, chúng tôi đang triển khai các bản quét DAST hỗ trợ bởi AI liên tục trong môi trường staging. Các bản quét này tìm kiếm lỗ hổng ở cấp độ hệ thống, nơi các giả định giữa hai hoặc nhiều dịch vụ không chính xác. Hiện nay có một số nhà cung cấp cung cấp các khả năng này.

Nguyên tắc bền vững: Kiểm thử động nên khớp với nhịp độ triển khai.

Giám sát

Như bất kỳ nhóm bảo mật giỏi nào cũng biết, công việc chưa kết thúc khi mã nguồn được đẩy lên môi trường production. Chúng ta có thể giả định rằng bất kỳ lỗ hổng nào cũng sẽ nhanh chóng bị xác định bởi những kẻ tấn công ngày càng tinh vi.

Nhóm bảo mật của chúng tôi đã triển khai các chương trình ở đây như các thực tiễn tiêu chuẩn như chương trình tiền thưởng tìm lỗi (bug bounty) công khai, các cuộc tấn công mô phỏng bởi đội ngũ red team, và quét định kỳ các lỗ hổng trên các phần phụ thuộc, bí mật, chuỗi cung ứng, trạng thái đám mây và container.

Claude đóng một vai trò lớn trong những việc này, nhưng chúng tôi sẽ tập trung vào những thay đổi lớn hơn đối với các nỗ lực giám sát của mình do kết quả của quy trình SDLC AI-native: phân loại cảnh báo và di chuyển mã nguồn.

Khi một cảnh báo được kích hoạt tại Anthropic, Claude bắt đầu: