Zaid Al Hamani, CEO và Người sáng lập của Boost Security – Loạt phỏng vấn

Zaid Al Hamani, CEO và Người sáng lập của Boost Security, là một lãnh đạo về an ninh mạng và DevSecOps với hơn hai thập kỷ kinh nghiệm xây dựng và mở rộng các hoạt động công nghệ toàn cầu. Kể từ khi thành lập Boost Security vào năm 2020, ông đã tập trung vào việc hiện đại hóa cách các tổ chức bảo mật phát triển phần mềm, dựa trên các vai trò trước đây bao gồm VP của Application Security tại Trend Micro và Co-Founder/CEO của IMMUNIO. Trước đó, ông đã giữ các vị trí lãnh đạo cấp cao tại Canonical, dẫn đầu các sáng kiến sản phẩm, kỹ thuật và hỗ trợ toàn cầu, và tại SITA, nơi ông quản lý các hoạt động CNTT lớn và quan trọng. Sự nghiệp của ông phản ánh một thành tích mạnh mẽ trong việc xây dựng đội ngũ, tối ưu hóa hệ thống và thúc đẩy các thực hành an ninh hiện đại.

Boost Security là một công ty an ninh mạng tập trung vào việc bảo mật chuỗi cung ứng phần mềm hiện đại thông qua một nền tảng DevSecOps dành cho nhà phát triển. Công nghệ của nó tích hợp trực tiếp vào các đường ống CI/CD để tự động phát hiện, ưu tiên và khắc phục các lỗ hổng, giảm thiểu gánh nặng thủ công trong khi duy trì tốc độ phát triển. Bằng cách thống nhất an ninh ứng dụng và an ninh chuỗi cung ứng vào một hệ thống duy nhất, nền tảng cung cấp khả năng hiển thị đầy đủ trên mã, phụ thuộc và cơ sở hạ tầng, giúp các tổ chức tăng cường khả năng chống chịu trong các môi trường đám mây bản địa phức tạp.

Trước đây bạn đã lãnh đạo an ninh ứng dụng tại Trend Micro và đồng sáng lập IMMUNIO. Điều gì đã dẫn bạn đến việc thành lập Boost Security, và bạn đã xác định khoảng trống trên thị trường như thế nào?

IMMUN.IO là một trong những công ty RASP đầu tiên được thành lập – và kinh nghiệm của chúng tôi cho đến thời điểm đó là WAF như một công nghệ an ninh thời gian chạy là không thể duy trì và không hiệu quả. Chúng tôi đã hình dung một cách mà WAF sẽ được thay thế bằng một giải pháp chính xác hơn, dễ dàng duy trì hơn – bằng cách thiết bị ứng dụng.

Đó là vào năm 2012, DevOps vẫn còn trong giai đoạn đầu, hầu hết các đội không phải là Agile, và Kubernetes chưa phải là một thứ gì đó hiện hữu.

Trend Micro đã mua lại IMMUN.IO vào năm 2017. Đến thời điểm đó, đã có nhiều thực hành DevOps hơn: đường ống CI/CD, thực hành phát triển Agile, chu kỳ phát hành nhanh hơn, đám mây, v.v. Các đội phát triển phần mềm đã tốt hơn trong việc xây dựng phần mềm và giao hàng nhanh hơn. An ninh vẫn bị hỏng tuy nhiên:

• Quét quá chậm, hoặc kết quả đến quá muộn
• Kết quả quá phức tạp cho nhà phát triển để thực hiện
• Có một tỷ lệ dương tính giả không thể chấp nhận được
• Nhiều loại artifact mới không được quét: mã cơ sở hạ tầng, container, API, v.v.

Sản xuất phần mềm nhanh hơn là dễ dàng. Sản xuất phần mềm an toàn nhanh hơn vẫn còn khó.

Đó là vấn đề ban đầu chúng tôi đặt ra để giải quyết. Làm cho DevSecOps hoạt động trong thế giới thực; bạn có thể nhận được một đội phát triển phần mềm dễ dàng thêm an ninh vào SDLC, với tốc độ phù hợp với tiêu chuẩn tốc độ mới? Bạn có thể làm cho phạm vi rộng – nơi một nền tảng là tất cả những gì bạn cần? Bạn có thể làm cho nó trở nên như vậy mà các nhà phát triển, không chỉ chấp nhận công nghệ, mà còn chấp nhận và thấy được lợi ích? Bạn có thể làm cho nó trở nên quy mô để bạn không cần một đội an ninh chuyên nghiệp để theo kịp số lượng mã được viết…

Chúng tôi đã giúp các công ty tiêm an ninh vào SDLC trong thời đại DevOps. Đó là đi từ 1 đến 10. Chúng tôi hiện đang trong thời đại mã hóa đại lý – nơi các đại lý viết một lượng mã khổng lồ – nhưng về cơ bản đó là cùng một vấn đề – tốc độ và khối lượng mã chỉ đi từ 10 đến 100; và chúng tôi nhằm tiếp tục cùng một quỹ đạo.

Bạn đã lập luận rằng chu kỳ phát triển phần mềm (SDLC) đã thay đổi cơ bản. Bạn đã nhận ra rằng các phương pháp DevSecOps truyền thống không còn đủ ở thời điểm nào?

Đó là khi xem cách các kẻ tấn công thực sự xâm nhập. Chúng tôi tiếp tục thấy cùng một mẫu: một workflow GitHub Actions bị lộ mà không ai đã xem xét kể từ khi repo được fork, một token với quyền truy cập sản xuất đám mây nhúng trong một cấu hình runner, một công việc CI hợp pháp bị chiếm quyền để triển khai payload của kẻ tấn công. Những điều này đã trở thành được biết đến như các cuộc tấn công “sống ngoài đường ống” vì đối thủ sử dụng tự động hóa của bạn chống lại bạn, với các thông tin đăng nhập mà đội an ninh của bạn đã phê duyệt.

Bộ DevSecOps chúng tôi đã xây dựng trong hơn một thập kỷ không có câu trả lời cho điều đó. SAST quét mã nguồn ứng dụng. SCA quét các phụ thuộc ứng dụng. Cả hai đều giả định rằng đường ống chạy chúng là đáng tin cậy. Trong khi đó, đường ống chính nó là một tệp YAML với các lệnh shell, quyền truy cập mạng và thông tin đăng nhập nhạy cảm, và hầu như không ai xem xét nó.

Khi điều đó trở thành con đường ít kháng cự nhất, bạn có thể giao phần mềm sạch sẽ và vẫn trao cho kẻ tấn công đám mây của bạn.

Như thế nào các doanh nghiệp nên suy nghĩ lại về SDLC trong một thế giới nơi các đại lý AI đang tạo ra mã liên tục chứ không phải các nhà phát triển viết từng bước?

Chúng tôi đã vượt quá việc nghĩ về SDLC như một chuỗi các điểm kiểm tra. Các đại lý AI đã thu hẹp khoảng thời gian giữa “ai đó đã viết điều này” và “điều này đang trong sản xuất” từ vài tuần đến vài phút. Mô hình cũ giả định một nhịp điệu con người giữa xem xét mã, SAST, SCA và triển khai, nhưng chúng tôi đã vượt quá điều đó.

An ninh phải sống ở nơi đại lý hoạt động: trên máy của nhà phát triển, trong bối cảnh prompt, trong các kết nối của đại lý với các máy chủ MCP và mô hình bên ngoài. Bằng thời điểm mã đạt đến đường ống, bạn đã mất cơ hội để định hình nó. Đại lý đã kéo phụ thuộc. Mô hình đã thấy thông tin đăng nhập. Di chuyển các điều khiển lên dòng, đến nơi công việc thực sự xảy ra.

Nhiều tổ chức vẫn coi các công cụ mã hóa AI như các lớp sản xuất đơn giản. Tại sao bạn tin rằng chúng đại diện cho một bề mặt tấn công hoàn toàn mới chứ không chỉ là một phần mở rộng của các luồng công việc hiện có?

Coi các công cụ mã hóa AI như một lớp sản xuất là như coi một nhà phát triển trẻ với quyền truy cập root như một lớp sản xuất. Nhãn là chính xác về mặt kỹ thuật, nhưng nó không cung cấp cho bạn một khuôn khổ hữu ích để suy nghĩ về những gì có thể sai.

Một công cụ mã hóa đại lý đọc tệp hệ thống của bạn, cào các biến môi trường để lấy bối cảnh, lấy các phụ thuộc từ các kho đăng ký công cộng, mở các kết nối xuất ra các nhà cung cấp mô hình và máy chủ MCP từ xa, và thực thi các lệnh shell. Mỗi hành động đó trước đây yêu cầu một người trong vòng lặp. Bây giờ chúng xảy ra trong vài mili giây, với cùng các đặc quyền như nhà phát triển đã khởi chạy đại lý.

Sự sụp đổ đó hợp nhất các ranh giới tin cậy đã từng riêng biệt: quyền của nhà phát triển, những gì một công cụ bên ngoài có thể lấy, và những gì mã không đáng tin cậy có thể thực thi. Điều đó tạo ra các cơ hội mới cho các kẻ tấn công và các điểm mù mà các đội phòng thủ thậm chí không thể nhìn thấy, chứ không nói đến việc bảo vệ.

Boost mô tả máy tính xách tay của nhà phát triển như một mặt điều khiển mới. Những rủi ro nào tồn tại ở điểm cuối mà các đội an ninh hiện đang bỏ qua?

Rủi ro lớn nhất là hàng tồn kho. Hầu hết các đội an ninh không thể cho bạn biết các đại lý AI nào đang chạy trên máy tính xách tay nào, các máy chủ MCP nào những đại lý đó đang kết nối, hoặc các tiện ích mở rộng IDE nào đang cào nội dung kho hiện tại. EDR không có khả năng hiển thị vào lớp đại lý; SIEM cũng không thể nhìn thấy những gì các đại lý đó làm cục bộ.

Dưới đó là sự lộn xộn thông tin đăng nhập. Chúng tôi đã xây dựng một công cụ mã nguồn mở có tên là Bagel một phần để làm cho điều này cụ thể. Một máy tính xách tay nhà phát triển điển hình giữ các token GitHub với quyền truy cập ghi vào các kho sản xuất, thông tin đăng nhập đám mây có thể khởi động cơ sở hạ tầng, token npm hoặc PyPI có thể xuất bản đến hàng triệu người dùng, và các khóa dịch vụ AI mà các kẻ tấn công bán lại. Không có gì trong số đó được củng cố theo cách một runner CI được củng cố. Cùng máy tính đó giữ các thông tin đăng nhập cũng duyệt web và cài đặt các tiện ích mở rộng VS Code ngẫu nhiên.

Ghép cặp cả hai và bạn có bề mặt tấn công thực sự. Một tiện ích mở rộng không đáng tin cậy chạy với đặc quyền nhà phát triển trong một môi trường đầy các khóa đám mây là mục tiêu có lợi nhất trong doanh nghiệp hiện đại. Hầu hết các đội chưa bắt đầu xem xét nó.

Bạn đã nhấn mạnh “bẫy bối cảnh”, nơi các đại lý AI có thể truy cập các tệp cục bộ, biến môi trường và cấu hình. Rủi ro rò rỉ dữ liệu nhạy cảm thông qua các lệnh gọi như thế nào, và tại sao lại khó phát hiện?

Phổ biến đến mức chúng tôi coi đó là trạng thái mặc định của bất kỳ môi trường nhà phát triển nào không được quản lý. Mỗi đại lý mã hóa chúng tôi đã kiểm tra kéo bối cảnh cục bộ một cách hung hăng. Chúng đọc các tệp dot, biến môi trường, tệp gần đây, đôi khi toàn bộ cây thư mục, và gửi bối cảnh đó đến một mô hình từ xa. Các công cụ được thiết kế để hoạt động theo cách này; việc kéo bối cảnh hung hăng là điều khiến chúng hữu ích.

Vấn đề phát hiện bắt đầu vì lưu lượng truy cập từ một sự rò rỉ trông giống hệt với việc sử dụng sản phẩm bình thường. Nó là TLS đến api.openai.com hoặc api.anthropic.com. Nó đến từ một ứng dụng kinh doanh được phê duyệt. DLP tiêu chuẩn không nhìn thấy nhà phát triển sử dụng công cụ AI mà công ty vừa mua giấy phép. Nó không nhìn thấy rằng một trong các chuỗi trong lệnh gọi đó là một khóa bí mật AWS mà đại lý đã lấy từ một tệp .env bị lãng quên trong một thư mục anh em.

Bạn chỉ bắt được nó bằng cách kiểm tra các lệnh gọi trước khi chúng rời khỏi máy tính xách tay, điều mà hầu như không có ngăn xếp an ninh nào hiện tại được đặt.

Bạn có đề cập đến các cuộc tấn công chuỗi cung ứng tốc độ máy. Bạn có thể mô tả một kịch bản thực tế nơi một đại lý AI giới thiệu một lỗ hổng bảo mật nhanh hơn các công cụ an ninh truyền thống có thể xác định nó?

Đây là một kịch bản chúng tôi đã thấy nhiều biến thể lặp lại. Nhà phát triển yêu cầu một đại lý thêm một tính năng cần một thư viện retry HTTP. Đại lý đề xuất một tên gói. Gói đó nghe có vẻ hợp lý nhưng không tồn tại trên npm. Trong vòng một giờ, một kẻ tấn công đăng ký nó, điền vào nó với logic retry hoạt động cộng với một kịch bản cài đặt sau nhỏ đọc ~/.aws/credentials và đăng nội dung lên một webhook. Đại lý chạy npm install mà không kiểm tra, vì các đại lý không kiểm tra danh tiếng. Thông tin đăng nhập đã biến mất trước khi nhà phát triển thậm chí chạy mã.

Cuộc tấn công itu không phải là phức tạp về mặt kỹ thuật, nhưng khuôn khổ an ninh chuỗi cung ứng truyền thống được xây dựng xung quanh các lỗ hổng đã biết trong các gói đã biết: CVE, SBOM, quét giấy phép. Khuôn khổ đó không có gì để nói về một gói không tồn tại khi quét được chạy lần cuối, được tạo ra cụ thể để phù hợp với ảo giác AI, và được tiêu thụ trước khi bất kỳ nguồn tin tức mối đe dọa nào được cập nhật.

Cửa sổ từ xuất bản đến thỏa hiệp hiện được đo bằng phút. Bất cứ điều gì kiểm tra sau sự kiện đều kiểm tra quá muộn.

Các phụ thuộc ảo đang trở thành một trong những rủi ro lớn nhất trong phát triển AI, và các tổ chức có thể thực hiện các bước thực tế nào để bảo vệ chống lại chúng?

Chúng đã trở thành một trong những rủi ro lớn nhất. Các kẻ tấn công tích cực theo dõi các công cụ AI phổ biến để ảo giác và đăng ký các tên gói được đề xuất trong vài phút. Các nhà nghiên cứu một vài năm trước, khi nó bắt đầu xảy ra, gọi nó là slopsquatting và tên đã dính. Một khi một tên gói được ảo giác đủ thường, ngồi trên nó là một cuộc tấn công chuỗi cung ứng bị động với nỗ lực gần như không.

Các biện pháp phòng thủ thực tế trông khác so với những gì hầu hết các đội hiện có. Bắt đầu từ việc tiêu thụ. Chặn các gói bị đánh cắp và mới đăng ký tại thời điểm npm install hoặc pip install chạy, trên máy của nhà phát triển, trước khi bất cứ điều gì chạm vào đĩa. Phát hiện sau khi chết trong CI không giúp ích khi một kịch bản cài đặt sau đã xuất thông tin đăng nhập. Sau đó, hãy cung cấp cho đại lý các đường ray để hoạt động bên trong. Tiêm danh sách phụ thuộc được phê duyệt của bạn trực tiếp vào bối cảnh của đại lý, để mô hình nhìn thấy những gì được phép trước khi nó tạo ra một đề xuất. Yêu cầu các nhà phát triển viết “lệnh gọi an toàn” không phải là một chiến lược. Nếu bạn đang chiến lược, điều đó có nghĩa là an ninh thiết lập ranh giới, đại lý thừa hưởng nó. Và bắt đầu theo dõi một Bill of Materials AI. Hầu hết các đội không thể cho bạn biết các đại lý, mô hình và gói nào đang chạm vào các kho nào. Bạn không thể bảo vệ những gì bạn không thể kiểm kê.

Bạn đã nói rằng an ninh không thể bắt đầu tại CI/CD. Một đường ống an ninh hiện đại trông như thế nào khi bảo vệ cần bắt đầu sớm hơn trong quy trình phát triển?

Nếu an ninh bắt đầu tại CI/CD, bạn đã nhường toàn bộ giai đoạn trước khi cam kết cho một môi trường bạn không kiểm soát. Đại lý đã tiêu thụ bối cảnh, thông tin đăng nhập của bạn có thể đã ở trong nhật ký của ai đó khác.

Một đường ống hiện đại bắt đầu trên máy tính xách tay. Điều đó có nghĩa là kiểm kê các đại lý và tiện ích mở rộng đang chạy ở đó, xác thực những máy chủ MCP và mô hình nào chúng được phép nói chuyện, làm sạch những gì rời khỏi máy, và chặn các gói độc hại trước khi chúng cài đặt. Từ đó, chính sách theo công việc vào IDE. Chúng tôi tiêm các tiêu chuẩn an ninh trực tiếp vào cửa sổ bối cảnh của đại lý để mã được tạo vẫn nằm trong các đường ray từ token đầu tiên. Đường ống vẫn chạy, thực hiện xác minh cuối cùng về các điều khiển đã được thực thi trước đó.

Đường ống chính nó không biến mất. Vai trò của nó trở thành xác minh: xác nhận rằng các biện pháp kiểm soát thượng nguồn đã hoạt động.

Khi các tổ chức tiếp tục áp dụng các đại lý mã hóa AI, những thay đổi quan trọng nhất họ phải thực hiện ngày hôm nay để đảm bảo môi trường phát triển của họ vẫn an toàn trong vài năm tới là gì?

Sai lầm lớn nhất là bảo mật chỉ những gì được cam kết. Rủi ro thú vị hiện sống trong tám giờ trước khi cam kết xảy ra. Bi kịch không nhìn thấy có thể diễn ra trên máy tính xách tay, trong lệnh gọi, hoặc trong cài đặt gói. Nếu các công cụ của bạn bắt đầu từ PR, bạn đang bảo vệ nửa sai của luồng công việc.

Closely liên quan: ngừng coi các đại lý mã hóa như phần mềm năng suất. Chúng là người dùng không phải con người với quyền truy cập shell, quyền ghi repo và kết nối mạng xuất, và các nhật ký kiểm toán. Quản lý chúng theo cách bạn quản lý bất kỳ danh tính đặc quyền nào, với một hàng tồn kho, khả năng được phê duyệt và các nhật ký kiểm toán.

Sự thay đổi cuối cùng là khó hơn về mặt văn hóa. Hầu hết các công cụ “an ninh AI” hiện nay đưa ra các phát hiện và định tuyến chúng đến con người. Con người không thể phân loại ở tốc độ mà các đại lý tạo ra. Bất cứ điều gì bạn áp dụng phải giải quyết các vấn đề tự động bên trong luồng công việc, với lý do có thể theo dõi, hoặc nó sẽ trở thành một bảng điều khiển khác mà không ai đọc.

Cảm ơn bạn vì cuộc phỏng vấn tuyệt vời, người đọc muốn tìm hiểu thêm nên truy cập Boost Security.