Cha đẻ của curl kêu gọi ưu tiên "xác minh" thay vì "tin tưởng" trong chuỗi cung ứng phần mềm

Trong một bài đăng blog được xuất bản vào tháng 3 năm 2026, Daniel Stenberg - cha đẻ và nhà phát triển chính của thư viện curl - đã đưa ra lập luận mạnh mẽ rằng quan điểm mặc định của ngành công nghiệp phần mềm là tin tưởng vào các thành phần nổi tiếng không còn phù hợp nữa. Stenberg lập luận rằng người dùng và các tổ chức nên chủ động xác minh phần mềm họ tiêu thụ, và ông sử dụng chính các thực hành của dự án curl như một ví dụ cụ thể về cách thực hiện điều này.

Curl đang hoạt động trên ước tính hàng chục tỷ thiết bị, khiến nó trở thành một trong những thành phần phần mềm được triển khai rộng rãi nhất hiện nay. Stenberg liệt kê một loạt các kịch bản mà một dự án ở quy mô này có thể bị xâm phạm, bao gồm một người đóng góp ác ý gộp mã độc, một người duyệt (committer) bị tấn công vô tình phát hành các bản sửa đổi, một thành viên trong nhóm bị tống tiền thực hiện các thay đổi không mong muốn, hoặc máy chủ phân phối bị hack cung cấp các tệp tin tarball đã bị thay đổi. Ông lưu ý rằng các kịch bản này có thể xảy ra độc lập hoặc liên tiếp nhanh chóng, và hậu quả của một cuộc tấn công thành công vào một dự án có phạm vi tiếp cận như curl có thể rất nghiêm trọng.

"An ninh phần mềm và kỹ thuật số nên dựa vào sự xác minh, thay vì sự tin tưởng. Tôi muốn khuyến khích mạnh mẽ nhiều người dùng và người tiêu dùng phần mềm hơn hãy xác minh curl. Và lý tưởng nhất là yêu cầu rằng bạn có thể thực hiện ít nhất mức độ xác minh này đối với các thành phần phần mềm khác trong chuỗi phụ thuộc của bạn." — Daniel Stenberg

Dự án curl đã đưa vào hoạt động một bộ điều khiển rộng rãi nhằm biến kho lưu trữ git thành nguồn sự thật chính xác và có thể kiểm toán. Các biện pháp này bao gồm thực thi phong cách mã nhất quán, cấm sử dụng các hàm C được coi là khó sử dụng an toàn, áp đặt trần độ phức tạp cho hàm, yêu cầu xem xét thủ công và tự động cho tất cả các yêu cầu kéo (pull request), và cấm các tệp nhị phân (binary blobs) cũng như hầu hết các việc sử dụng nội dung được mã hóa base64 - cả hai đều có thể được sử dụng để che giấu tải trọng độc hại. Stenberg cũng mô tả hơn 200 công việc CI chạy trên mỗi lần commit, các bản build sử dụng cài đặt trình biên dịch nghiêm ngặt coi cảnh báo là lỗi, fuzzing liên tục thông qua dự án OSS-Fuzz của Google, và xác thực hai yếu tố bắt buộc cho tất cả những người gửi mã. Mỗi biện pháp trong số này được thiết kế để làm cho bất kỳ sự lệch lạc nào khỏi hành vi mong đợi đều hiển thị với bất kỳ ai theo dõi dự án.

Bên cạnh các biện pháp kiểm soát nội bộ đó, Stenberg còn lập luận cho một hệ sinh thái xác minh rộng lớn hơn. Ông giải thích rằng dự án cung cấp các bản phát hành (artifacts) đã được ký và một trang xác minh chuyên biệt trên trang web curl, để người dùng độc lập có thể kiểm tra xem bản phát hành có chỉ chứa những gì nằm trong kho git hay không và nó có được ký bởi người quản lý bản phát hành hay không. Ông thừa nhận rằng ông không thể biết những người dùng đó là ai, hoặc liệu họ hiện có tồn tại hay không, nhưng lập luận rằng ngay cả một số lượng nhỏ người xác minh độc lập cũng đủ để cung cấp một sự kiểm tra ý nghĩa: một trong số họ có thể đưa ra cảnh báo nếu có bất cứ điều gì trông có vẻ sai lệch.

"Nếu ngay cả chỉ một vài người dùng xác minh rằng họ nhận được bản phát hành curl được ký bởi người quản lý bản phát hành của curl và họ xác minh rằng nội dung bản phát hành không bị làm ô nhiễm và chỉ chứa các bit có nguồn gốc từ kho git, thì chúng ta đang ở trong một trạng thái khá tốt." — Daniel Stenberg

Stenberg kết thúc bài đăng của mình với một lời khuyên trực tiếp yêu cầu xác minh này cho tất cả các phụ thuộc, stating rằng "an ninh phần mềm và kỹ thuật số nên dựa vào sự xác minh, thay vì sự tin tưởng". Cuộc thảo luận của cộng đồng từ trước tháng 4 năm 2025 đã đồng tình với quan điểm này theo nhiều cách. Trên LinkedIn, các chuyên gia về an ninh và kỹ sư nền tảng đã lập luận rằng sự kiện backdoor XZ Utils, được phát hiện vào năm 2024 và liên quan đến một nỗ lực kéo dài để chèn mã độc thông qua một người đóng góp đáng tin cậy, đã cho thấy giới hạn của sự tin tưởng dựa trên uy tín. Cuộc tấn công này, nhắm vào thành phần liblzma bằng cách giành được sự tin tưởng của những người bảo trì theo thời gian trước khi chèn các thay đổi mã, chính xác là loại kịch bản mà Stenberg mô tả trong danh sách các vector mối đe dọa của mình.

Một trong những công cụ cấu trúc hiện có để diễn đạt chính xác một phần mềm chứa đựng những gì là Hóa đơn Phần mềm (Software Bill of Materials - SBOM). Trong một bài nói chuyện tại QCon London 2026 được InfoQ đưa tin, Viktor Petersson, người sáng lập sbomify, đã lập luận rằng các nhóm đang cạn kiệt thời gian để áp dụng SBOM. Ông dẫn chứng Đạo luật Khả năng Chống chịu Mạng của EU (Cyber Resilience Act), mở ra cửa sổ thực thi đầu tiên vào tháng 9 năm 2026 và yêu cầu tuân thủ SBOM đầy đủ vào tháng 12 năm 2027, và cảnh báo rằng hậu quả của nó vượt ra ngoài tiền phạt: "CRA không chỉ là về tiền phạt. Họ thực sự có thể chặn bán hàng. Sản phẩm của bạn có thể bị chặn khỏi thị trường Châu Âu." Lệnh hành pháp 14028 của Mỹ, có hiệu lực từ năm 2021, biến SBOM thành điều kiện mua hàng cho phần mềm bán cho chính phủ liên bang, và FDA yêu cầu chúng đối với thiết bị y tế.

Bài nói chuyện của Petersson đã giải quyết toàn bộ vòng đời sản xuất SBOM, bao gồm cả bước mà hầu hết các nhóm bỏ qua: ký. Ông thẳng thắn rằng đây là một sai lầm, và rằng công cụ cụ thể ít quan trọng hơn hành động ký chính nó, vì điều này cung cấp một chuỗi lưu ký có thể xác minh. Petersson thẳng thắn: "Bất kỳ việc ký nào cũng tốt hơn không ký. Hãy ký SBOM của bạn trong pipeline của bạn, không phải trên máy của ai đó." Điều này kết nối trực tiếp với lập luận của Stenberg: curl đã cung cấp các bản phát hành đã được ký và chi tiết rõ ràng các bước xác minh, mang lại cho người tiêu dùng chuỗi lưu ký mà Petersson mô tả là mục tiêu.

Các pipeline CI/CD cũng là một điểm yếu tiềm ẩn. InfoQ đã đưa tin về việc xâm phạm một GitHub Action được sử dụng rộng rãi vào tháng 4 năm 2025, điều này làm nổi bật cách một hành động độc hại hoặc bị xâm phạm có thể lộ các bí mật và bản build (artifacts) trên nhiều dự án cùng một lúc. Sự cố này đã củng cố các lời kêu gọi kiểm soát chặt chẽ hơn đối với các hành động của bên thứ ba, cố định các phụ thuộc vào các băm commit cụ thể và giám sát các thay đổi bất ngờ trong công cụ CI. Cách tiếp cận của Stenberg giải quyết trực tiếp vấn đề này: các công việc CI của curl được cấu hình để truy cập kho lưu trữ nguồn ở chế độ chỉ đọc và được kiểm tra với công cụ zizmor để giảm thiểu rủi ro cấu hình công việc không an toàn.

Petersson cũng chỉ ra thách thức về vòng đời, lưu ý rằng một sản phẩm thực thường có hàng chục SBOM thay đổi trên mỗi lần chạy CI và các cơ quan quản lý có thể yêu cầu SBOM cho một bản phát hành cụ thể trong quá khứ. Ông so sánh thực hành hiện nay với phát triển phần mềm trước khi có kiểm soát phiên bản: "Xử lý SBOM ngày nay cảm giác giống như quản lý mã nguồn vào những năm 90, với các bản vá được gửi qua email." Vấn đề quản trị này nghiêng về điểm rộng lớn hơn của Stenberg. Công cụ để sản xuất, ký và xác minh các tạo tác phần mềm đã tồn tại, và áp lực quy định để sử dụng chúng đang tăng lên, vì vậy các tổ chức nên hoàn thiện vòng lặp bằng cách xác minh những gì họ tiêu thụ.