- Khi việc phát hiện lỗ hổng bằng AI vượt qua tốc độ ứng phó của các maintainer, Akrites được thành lập như một nỗ lực hợp tác trong ngành để cùng củng cố các phần mềm mã nguồn mở cốt lõi
- Việc phát hiện lỗ hổng nghiêm trọng trước đây từng mất vài tuần đối với chuyên gia, nhưng giờ đây mô hình AI có thể tìm ra nhiều lỗ hổng chỉ trong vài phút, khiến gánh nặng ứng phó tăng vọt
- AWS, Anthropic, Chainguard, Cisco, Citi, Ericsson, Google, IBM, Microsoft cùng GitHub, NVIDIA, OpenAI, Red Hat, Rust Foundation và các bên khác sẽ phối hợp sửa lỗi upstream và công bố có trách nhiệm
- Akrites cung cấp một đầu mối điều phối bảo mật và Security Incident Response Team chuyên trách để giảm báo cáo trùng lặp và các bản vá xung đột, đồng thời cũng sẽ đảm nhận vai trò maintainer cuối cùng cho các gói cốt lõi không có maintainer
- Vì sau khi bản vá được công khai, kẻ tấn công có thể dùng AI để đảo ngược lỗ hổng, nên tiêu chí thành công không phải là công bố mà là bản vá được triển khai tới các hệ thống thực tế
Tốc độ mới của an ninh mã nguồn mở do AI tạo ra
- Mã nguồn mở đã trở thành nền tảng của hạ tầng và dịch vụ cốt lõi mà mọi người phụ thuộc mỗi ngày, như ngân hàng, viễn thông và tiện ích
- Khi cùng một thành phần mã nguồn mở được dùng rộng rãi trên toàn bộ stack công nghệ, nhiều hệ thống sẽ cùng chia sẻ các điểm lỗi tiềm ẩn giống nhau
- AI đang thay đổi thế cân bằng giữa kẻ tấn công và bên phòng thủ, đồng thời làm giảm chi phí phát hiện và tái sử dụng lỗ hổng
- Việc phát hiện lỗ hổng nghiêm trọng trước đây cần vài tuần với chuyên gia, nhưng nay máy móc có thể thực hiện trong vài phút
- Trong một lần chạy, mô hình AI đôi khi có thể trả về nhiều lỗ hổng cùng lúc
- Năng lực đó cũng có thể dùng cho phòng thủ, nhưng nếu bị lạm dụng thì việc tìm lỗ hổng có thể bị pipeline hóa
Cấu trúc báo cáo trùng lặp gây áp lực lên maintainer
- Quy trình ứng phó và công bố bảo mật hiện có vận hành theo cách nhiều tổ chức và nhóm tách rời, phối hợp lỏng lẻo, nên cùng một vấn đề có thể bị xử lý đồng thời hoặc tạo ra các bản vá xung đột và nhiều báo cáo khác nhau
- Nếu hàng chục công ty quét cùng một thư viện một cách độc lập và mỗi bên đều gửi báo cáo riêng, maintainer sẽ bị nhấn chìm trong nhiễu
- Càng nhiều bên biết về lỗ hổng chưa được vá thì khả năng rò rỉ trước khi sửa xong càng lớn, và rủi ro đó lan sang toàn bộ hệ sinh thái
- Ngay cả phản ứng thiện chí nhưng thiếu điều phối cũng có thể làm vấn đề tồi tệ hơn và lãng phí thời gian
Cách Akrites phối hợp ứng phó chung
- Akrites được khởi động như một nỗ lực triển khai hệ thống và công cụ chung để tìm, sửa và công bố có trách nhiệm các lỗ hổng trong phần mềm mã nguồn mở cốt lõi
- Các bên tham gia gồm Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft cùng GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, Zscaler và nhiều bên khác
- Trọng tâm của hoạt động ứng phó là upstream nơi có maintainer
- Cung cấp một địa điểm duy nhất, bảo mật và dựa trên niềm tin để điều phối việc phát hiện, sửa lỗi và công bố lỗ hổng
- Security Incident Response Team chuyên trách sẽ trở thành đối tác đơn nhất, có thể dự đoán được đối với maintainer, thay cho vô số báo cáo không điều phối
- Các bản sửa sẽ được đưa trở lại kho lưu trữ gốc của từng dự án và luồng làm việc của maintainer
- Nếu một gói cốt lõi không có maintainer, Akrites cho biết họ sẽ đảm nhận vai trò maintainer cuối cùng để bảo đảm bản sửa được chuyển đến đúng lúc
Vì sao triển khai quan trọng hơn công bố bản vá
- Khi bản vá được công khai, kẻ tấn công có thể dùng AI để nhanh chóng đảo ngược lỗ hổng thực tế, phát triển exploit và bắt đầu tấn công
- Vì vậy, thành công của Akrites phải được đo bằng việc bản vá đã được triển khai trên các hệ thống thực tế hay chưa, chứ không phải chỉ là đã công bố hay chưa
- Akrites muốn nâng cao mức độ điều phối bằng cách hợp tác với các chủ sở hữu và đơn vị vận hành hạ tầng cốt lõi, các nỗ lực xã hội dân sự và chính phủ
- Tính bảo mật không phải là thứ có thể đem ra thương lượng; các lỗi chưa công bố trong những gói được triển khai rộng rãi về thực chất giống như vũ khí, nên ngăn rò rỉ là ưu tiên hàng đầu
Gánh nặng và cam kết mà các tổ chức tham gia nhấn mạnh
- Endor Labs cho biết trong số hàng nghìn lỗ hổng mã nguồn mở được xác nhận trong vài tháng gần đây, tỷ lệ đã được vá là dưới 5%
- OpenInfra cho biết riêng trong quý này cộng đồng OpenStack đã phát hành 20 khuyến cáo bảo mật, trong khi cả năm 2025 mới có 2
- JPMorganChase cho rằng AI đã nén khoảng thời gian giữa phát hiện và khai thác lỗ hổng xuống gần mức thời gian thực, nên thời gian từ sửa lỗi đến triển khai cũng phải được rút ngắn
- Chainguard, Sonatype, RapidFort, Red Hat và các bên khác cho rằng việc sửa lỗ hổng nên được thực hiện trong phần mềm gốc và luồng maintainer thông qua điều phối upstream, thay vì bị phân tán trong các fork hay sau những bức tường sở hữu riêng
- Các tổ chức tham gia cam kết投入 nhân lực kỹ thuật, chuyên môn bảo mật, nguồn vốn và công nghệ AI để củng cố phần mềm dùng chung
1 bình luận
Ý kiến trên Hacker News
Nhiều người làm trong mảng mã nguồn mở hẳn sẽ không tránh khỏi hoài nghi khi nhìn vào danh sách các công ty tham gia này, và điều đó cũng có lý
Cốt lõi là sẽ triển khai việc “tìm, sửa và công bố có trách nhiệm các lỗ hổng trong phần mềm mã nguồn mở quan trọng” như thế nào. Nếu đóng góp qua các kênh hiện có và pull request thì có thể đồng hành cùng cộng đồng, nhưng nếu fork lấy danh nghĩa ‘bảo mật’ thì sẽ gạt cộng đồng ra ngoài, chia cắt nguồn lực và về lâu dài có thể giết chết nhiều dự án. Bug bounty có tiềm năng, nhưng với lỗi nghiêm trọng thì tốc độ và thời điểm công bố có thể không phù hợp, còn hỗ trợ tài chính cũng chỉ có hiệu quả hạn chế nếu không đi kèm hỗ trợ maintainer
PQCA cung cấp quyền truy cập phần cứng bằng AWS credit để chạy proof và CI, đồng thời cũng vận hành chương trình mentorship có trả phí. OWF cũng cung cấp AWS credit và host các dịch vụ phục vụ kiểm thử. LFDT đã hỗ trợ mentorship có trả phí, chi phí review của Trail of Bits, vận hành sự kiện, hội nghị maintainer summit ở New York, hỗ trợ các GitHub CI runner quy mô lớn, v.v. Đội của chúng tôi tính theo mảng quan hệ nhà phát triển của OWF/PQCA/LFDT chỉ có 3 nhân sự toàn thời gian, 1 contractor và 1 quản lý, nhưng vẫn làm việc khá tích cực để hỗ trợ các nhà phát triển
LFDT: https://www.lfdecentralizedtrust.org/
OWF: https://openwallet.foundation/
PQCA: https://pqca.org/
Ví dụ benchmark của PQCA: https://pq-code-package.github.io/mldsa-native/dev/bench/
Dù dưới hình thức nào thì nó cũng phải được phân tán để không một vị trí trung tâm hay một chủ thể duy nhất nào có thể nắm quyền kiểm soát
Họ nói đến đóng góp tài chính, nhưng đóng góp thế nào và cho mục đích gì cũng rất quan trọng. Phần lớn dự án chưa sẵn sàng để nhận hoặc sử dụng tiền tài trợ. Tuy vậy, sẽ rất tốt nếu mọi dự án mã nguồn mở đều có thể được cấp quyền truy cập đáng kể vào AI để rà soát codebase và pull request, qua đó giảm gánh nặng bảo trì, và hiện cũng đã có một số thử nghiệm như vậy
Chỉ là màn trình diễn kiểu doanh nghiệp
Microsoft nói rằng họ sẽ “đóng góp chuyên môn, nguồn lực và công nghệ AI để xác định và sửa lỗ hổng một cách có trách nhiệm”, nhưng Microsoft đang vận hành NPM và GitHub, đồng thời có quyền tiếp cận các mô hình AI hàng đầu và những trung tâm dữ liệu khổng lồ. Vậy mà bảo mật trong các sản phẩm của họ vẫn xuống cấp nhanh chóng, còn các dịch vụ thì đang trở thành trung tâm đầu mối nơi nhiều exploit lan rộng
Nếu muốn xem Microsoft xử lý vấn đề bảo mật trong chính các dự án mã nguồn mở của họ như thế nào, tôi khuyên nên xem thread GitHub này: https://github.com/dotnet/efcore/issues/38257
EF Core hiện đang phát hành một phiên bản SQLite có lỗ hổng nghiêm trọng. Vấn đề này đã được phát hiện hơn một năm trước, SQLite đã sửa trong vòng một tuần, nhưng EF Core đã không đánh dấu driver là dễ bị tấn công cho đến khi gần đây có người dùng báo lại và tranh luận với các nhà phát triển. Bản sửa cho phiên bản ổn định hiện tại của .NET Core dự kiến phải khoảng hai tháng nữa mới có
Sau khi mua lại, thay vì nối tiếp dòng chảy đó bằng VSCode, Microsoft lại tạo ra bầu không khí coi thường Electron, và giờ rất nhiều người ghét Electron mà thậm chí không giải thích được lý do. VSCode không fork Atom mà xây lại từ đầu theo hướng tương tự, lớn hơn, chậm hơn, và giờ còn gắn thêm Copilot. Cuối cùng tôi quay lại với Pulsar, một fork tốt của Atom
Microsoft lúc nào cũng nhìn vào cơ hội và thế cạnh tranh để mua lại, nhưng hiếm khi tận dụng tốt những gì đã mua. Họ loại bỏ nhân sự giỏi và code tốt rồi làm hỏng sản phẩm. Tôi vẫn không hiểu vì sao mọi người tiếp tục dùng sản phẩm Microsoft. Cần rời LinkedIn, và cùng nhau chuyển sang hệ thống quản lý phiên bản khác. Chừng nào các nhà phát triển mã nguồn mở còn chưa thể hiện bằng hành động chứ không chỉ lời nói, Microsoft sẽ còn tiếp tục tệ hơn nữa
Chúng ta sẽ không làm như vậy. Chúng ta sẽ không chỉ đưa ra những tuyên bố hoành tráng, rồi mặc cho các công ty thương mại phá hỏng mọi thứ, để sau đó than phiền dữ dội về tình trạng hiện tại trong khi chính chúng ta chẳng làm gì cả
Có lẽ sắp tới sẽ xuất hiện một xu hướng mà tôi gọi là undo fork. Đó là một nhánh fork quay trở lại thời điểm trước khi cơn điên bắt đầu để suy nghĩ lại từ đầu, và chỉ những người không bị trói buộc bởi các yêu cầu thương mại mới có thể làm điều đó
Tôi luôn khuyên những người quan tâm đến open source nên tránh xa Linux Foundation. Ngày nay nó đã trở thành một rào cản cản trở tự do phần mềm hơn là giúp nó trở nên khả thi
Muốn bảo vệ open source thì phải bắt đầu bằng sự hỗ trợ thực chất cho các dự án và nhà phát triển, chứ không phải lời nói
Từ góc nhìn của một nhà phát triển OpenBSD, việc cung cấp phần cứng mới cho nhà phát triển thực sự rất quan trọng. Nhiều người vẫn đang làm việc trên những chiếc ThinkPad đã 5~10 năm tuổi và cần được thay thế
https://www.openbsd.org/want.html
OpenBSD Foundation hiện vẫn còn thiếu khoảng 50% để đạt mục tiêu gây quỹ cho năm 2026
https://www.openbsdfoundation.org/campaign2026.html
https://brynet.ca/wallofpizza.html
Đến đoạn “Amazon Web Services đồng hành” thì toàn bộ độ tin cậy của bài viết này coi như biến mất
Điều này đọc lên giống như một nỗ lực hướng tới tập trung hóa và kiểm soát. Dù Akrites là ai đi nữa, rốt cuộc nó chỉ trao cho các đại gia công nghệ, bao gồm cả Google, sức mạnh để kiểm soát open source
Cảm ơn nhưng xin phép từ chối. Tôi vẫn nhớ việc Google đang định chặn cài đặt bên thứ ba qua
.apktrên Android vào tháng 9 nàyLiên quan đến chuyện này, hầu hết những người thông minh mà tôi biết đều cho rằng AI mã nguồn mở sẽ khiến Anthropic và OpenAI trở nên không khả thi về mặt tài chính. Nhiều công ty có tên ở đây gắn chặt với hai bên đó, và họ có động cơ làm lung lay AI mã nguồn mở trước khi khách hàng cảm nhận cú sốc giá. Tôi vẫn chờ xem nước đi tiếp theo của họ là gì, và đây có thể là một phần trong đó
Thông tin quan trọng nhất là đoạn nói rằng “những bên tham gia sẽ đóng góp nguồn lực kỹ thuật”
Cần chờ xem liệu có diễn ra đúng kế hoạch hay không. Ngoài điều đó ra, tôi không mấy ấn tượng với các tuyên bố của dự án này. Cấu trúc của nó có lợi cho sự tập trung hóa và các mạng lưới xoay quanh doanh nghiệp, hoàn toàn đi ngược với hướng mà đạo đức hacker từ lâu đã khuyến khích vì những lý do chính đáng
Nó cũng có thể trở thành một nguồn áp lực khác. Có thể nó sẽ lọc được các lỗ hổng thật sự khá tốt, nhưng kết quả là chúng sẽ bị đẩy tới maintainer với mức ưu tiên cao. Nhiều maintainer đã kiệt sức ngay cả khi chưa có nhiễu do AI gây ra, và ngay cả khi có sẵn bản vá thì họ vẫn phải review
Trong trường hợp tốt nhất, nó có thể giảm nhiễu, nhưng công việc thì vẫn còn đó. Toàn ngành nên tài trợ rộng rãi để các dự án open source có quyền tự xử lý việc này. Khả năng cao đó cũng là cách tốt nhất cho chất lượng. Nếu cần lọc nhiễu do AI thì cứ thêm chức năng đó, nhưng không nên là một cấu trúc bí mật và thiếu minh bạch kiểm soát mọi thứ
Tôi đang chờ đến ngày thấy những headline kiểu “Tất cả chúng ta đều phụ thuộc vào open source. Chúng ta sẽ cùng tài trợ cho nó”
Tôi thích cái tên “Akrites”
Với những người không phải người Hy Lạp thì có thể nó kém ấn tượng hơn, nhưng với người Hy Lạp thì nó gợi hình ảnh khá mạnh
akron có nghĩa là rìa hoặc biên giới, nên có thể hiểu là “người vùng biên” hoặc “những người của biên giới”. Điểm cốt lõi ở đây là không thể áp nguyên các xung đột hay định kiến hiện đại vào lịch sử cách đây một nghìn năm. Trong bối cảnh lịch sử, đó cũng giống nhiều vùng biên giới giữa các nền văn minh khác nhau, và điều quan trọng là đó là một tổ chức tập thể tập hợp lại để bảo vệ vùng đất của mình
[1] https://en.wikipedia.org/wiki/Mark_Carney%27s_Davos_speech
Tôi thấy đăng kiểu này lên Hacker News cũng chẳng có nhiều ý nghĩa. Phần lớn ở đây đón nhận rất sâu làn sóng AI và không mấy bận tâm
Hơn nữa, nhiều công ty trong danh sách là những đối tượng bị nghi ngờ chính đã góp phần khiến mã nguồn mở rơi vào tình trạng hiện nay
Tuy vậy, tôi đồng ý rằng nhiều công ty trong danh sách là những đối tượng bị nghi ngờ chính về tình trạng của mã nguồn mở. Trông đây giống một quảng cáo PR nhằm tẩy trắng hình ảnh cho các công ty đó hơn, và khó mà tin rằng họ thực sự quan tâm đến đạo đức mã nguồn mở