Zaid Al Hamani, Giám đốc điều hành và Người sáng lập của Boost Security – Loạt phỏng vấn

Zaid Al Hamani, Giám đốc điều hành và Người sáng lập của Boost Security, là một nhà 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 Phó Chủ tịch An ninh Ứng dụng tại Trend Micro và Đồng sáng lập / Giám đốc điều hành 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 quan trọng trên quy mô lớn. Sự nghiệp của ông phản ánh một hồ sơ theo dõi mạnh mẽ về 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 hướng đến 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 bản địa đám mây phức tạp.

Bạn trước đây đã 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 nào trên thị trường một cách độc đá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 ra 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ễ bảo 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ì đó.

Trend Micro đã mua lại IMMUN.IO vào năm 2017. Vào 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ỳ lặp lại nhanh hơn và chu kỳ phát hành, đá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à vận chuyển 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ệ sai dương không thể chấp nhận được
• Nhiều loại tác phẩm 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 đã dễ dàng hơn. Sản xuất phần mềm an toàn nhanh 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ể đưa 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 các 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ỉ áp dụng công nghệ, mà còn chấp nhận nó và thấy được lợi ích? Bạn có thể làm cho nó tăng quy mô để bạn không cần một đội an ninh chuyên nghiệp để theo kịp 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 đó vẫn là vấn đề相同 – tốc độ và khối lượng mã chỉ đi từ 10 đến 100; và chúng tôi nhằm mục đích tiếp tục cùng 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. Khi nào bạn nhận ra rằng các phương pháp DevSecOps truyền thống không còn đủ?

Đó là khi xem cách các kẻ tấn công thực sự xâm nhập. Chúng tôi liên 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 kho được fork, một token có quyền truy cập sản xuất đám mây được nhúng trong một tệp cấu hình runner, một công việc CI hợp pháp bị lợi dụng để triển khai các payload của kẻ tấn công. Những điều này được gọi là cuộc tấn công “sống ngoài đường ống” vì kẻ 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à nhóm an ninh của bạn đã phê duyệt.

Bộ DevSecOps mà 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 của ứ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ể vận chuyển mã sạch hoàn hảo 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 mà 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 tất cả phải ngừng 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 qua đ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 ngữ cảnh của lời nhắc, trong các kết nối của đại lý với máy chủ MCP và mô hình bên ngoài. Khi mã đế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ự diễn 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 quy trình hiện có?

Coerce một công cụ mã hóa AI như một lớp sản xuất là như đối xử với 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 đó về mặt kỹ thuật chính xác, 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 đại lý mã hóa đọc tệp hệ thống của bạn, thu thập các biến môi trường để lấy ngữ cảnh, lấy các phụ thuộc từ các kho công cộng, mở các kết nối ra ngoài đến các nhà cung cấp mô hình và máy chủ MCP, và thực hiện các lệnh shell. Mỗi hành động đó trước đây yêu cầu một con người trong vòng lặp. Bây giờ chúng xảy ra trong vài miligiâ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 hiện. Đ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 nhà 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 định hình laptop 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 nhóm 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 nhóm 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 mà các đại lý đó đang kết nối, hoặc các tiện ích mở rộng IDE nào đang thu thập nội dung kho ngay bây giờ. EDR không có khả năng hiển thị vào lớp đại lý; SIEM cũng không thể thấy những gì các đại lý làm cục bộ.

Dưới đó là tình trạng 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 đó 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 có thể bán lại. Không có gì trong số đó được tăng cường như một trình chạy CI.

Máy tính xách tay đó cũng duyệt web và cài đặt các tiện ích mở rộng VS Code tùy ý.

Kết hợ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 ngữ 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 lời nhắc 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 đều kéo ngữ cảnh 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 cả cây thư mục, và gửi ngữ 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 ngữ cảnh hung hăng là điều làm cho 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. Đó 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 thấy một nhà phát triển sử dụng công cụ AI mà công ty vừa mua bản quyền.

Bạn chỉ bắt gặp nó bằng cách kiểm tra lời nhắc 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 đang được đặt.

Bạn đề cập đến các cuộc tấn công chuỗi cung ứng có tốc độ máy. Bạn có thể mô tả một kịch bản thực tế mà một đại lý AI giới thiệu một lỗ hổng bảo mật nhanh hơn so với 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 lần. 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 logic retry hoạt động cộng với một kịch bản hậu cài đặt 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 an ninh chuỗi cung ứng truyền thống được xây dựng xung quanh các lỗ hổng bảo mật đã biết trong các gói đã biết: CVE, SBOM, quét giấy phép. Khung đó không có gì để nói về một gói không tồn tại khi lần quét cuối cùng được chạy, được tạo cụ thể để phù hợp với ảo giác của AI và được tiêu thụ trước khi bất kỳ nguồn cấp dữ liệu 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ứ thứ gì kiểm tra sau đó đều kiểm tra quá muộn.

Các phụ thuộc ảo có đang trở thành một trong những rủi ro lớn nhất trong phát triển AI không, và các tổ chức có thể thực hiện những 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.

Khi một tên phụ thuộc được ảo giác thường xuyên đủ, ngồi trên nó là một cuộc tấn công chuỗi cung ứng thụ độ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ứ thứ gì chạm vào đĩa. Phát hiện sau khi chết trong CI không giúp đỡ khi một kịch bản hậu cài đặt đã exfiltrated một thông tin đăng nhập.

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ụ ngữ cảnh, thông tin đăng nhập của bạn có thể đã nằm trong nhật ký của ai đó.

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à hàng tồn kho 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 mà 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.

Đườ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 đó.

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 mà họ phải thực hiện ngay 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ị bây giờ 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ể xảy ra trên máy tính xách tay, trong lời nhắc hoặc trong cài đặt gói.

Liên quan chặt chẽ: ngừng đối xử với các đại lý mã hóa như phần mềm sản xuấ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 vào kho và kết nối mạng ra ngoài. 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 hàng tồn kho, khả năng được phê duyệt và 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 đều đư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 đều phải giải quyết các vấn đề tự động bên trong quy trình làm 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, những người đọc muốn tìm hiểu thêm nên truy cập Boost Security.