Trong nhiều năm, tin tặc thường nhắm vào từng ứng dụng một. Giờ đây, chúng đã thay đổi chiến thuật: tại sao phải tấn công một ứng dụng khi có thể tấn công cả một ứng dụng? pipeline Cái nào xây dựng được nhiều thế? Của Xygeni Cảnh báo sớm phần mềm độc hại (MEW) phát hiện 4,452 gói phần mềm độc hại vào năm 2025 và Tính đến thời điểm hiện tại, sẽ có thêm 1,281 ca nữa trong năm 2026.Mỗi sự cố nghiêm trọng trong vài năm gần đây đều ảnh hưởng đến một mắt xích khác nhau trong chuỗi cung ứng phần mềm:
- SolarWind (2020)Lỗ hổng bảo mật môi trường xây dựng; các bản cập nhật có cài đặt cửa hậu đã được phát tán đến 18,000 khách hàng.
- Codecov (2021)Một lỗi cấu hình ảnh Docker đã cho phép kẻ tấn công sửa đổi một tập lệnh tải lên bash, đánh cắp thông tin bí mật CI từ hơn 23,000 khách hàng.
- CircleCI (2023)Vụ đánh cắp cookie phiên trên máy tính xách tay của một kỹ sư đã dẫn đến việc chiếm đoạt mã thông báo truy cập sản phẩm; mọi khách hàng đều được yêu cầu xoay vòng mọi mã bí mật.
- Cửa hậu của XX Utils (2024) :một chiến dịch tấn công phi kỹ thuật kéo dài nhiều năm, gần như lan đến mọi bản phân phối Linux.
- tj-actions (2025) — Một sự cố dây chuyền trong chuỗi cung ứng GitHub Actions đã làm hỏng một thành phần được sử dụng bởi hơn 23,000 kho lưu trữ.
- Tấn công vào Trò chơi đố vui dưới nước và checkmarx (2026) — Chiến dịch TeamPCP đã biến hai công cụ quét bảo mật được sử dụng rộng rãi thành các công cụ tấn công, sau đó sử dụng thông tin bị đánh cắp. CI/CD Thông tin xác thực sẽ được chuyển tiếp xuống các hệ thống npm, OpenVSX và PyPI.
Mỗi cuộc tấn công đều khai thác một phần khác nhau của... pipeline: môi trường xây dựng, công cụ CI, các phụ thuộc, thông tin xác thực nhà phát triển, độ tin cậy của người bảo trì, các tham chiếu có thể thay đổi đến các tạo phẩm. Hầu hết các tổ chức phản hồi bằng cách kiểm soát điểm, một trình quét trong CI, xác thực hai yếu tố trên IdP, bảo vệ nhánh trên mainĐiều thường thiếu chính là cách để hỏi. Chúng ta có được bảo hiểm một cách có hệ thống không? chứ không phải là Chúng ta có nhớ bật X sau sự cố lần trước không?
Các nhà cung cấp bảo mật ứng dụng đang nằm trong tầm ngắm, việc xâm phạm một sản phẩm của họ sẽ ảnh hưởng đến mọi khách hàng tin tưởng vào các sản phẩm của họ. Áp lực chuyển từ các biện pháp kiểm soát phản ứng sang tư thế chủ động không chỉ là lý thuyết. Đó là điều đã được chứng minh.cisĐiều gì đã thúc đẩy việc áp dụng OWASP SPVS? standard là dự án ưu tiên hàng đầu.
SPVS là gì và tại sao cấu trúc của nó lại quan trọng
Câu chuyện nguồn gốc rất đơn giản. Tại LASCON 2023, Farshad Abasi và Cameron Walters liên tục hỏi nhau cùng một câu hỏi: ASVS dành cho ai vậy? pipelineOWASP ASVS đã cung cấp cho bảo mật ứng dụng một tiêu chuẩn toàn diện và có thể kiểm chứng được. standardKhông có thứ gì tương đương tồn tại cho CI/CD.
Có danh sách OWASP Top 10. CI/CD Rủi ro, vốn tập trung vào nhận thức chứ không thể kiểm thử; SLSA, chỉ tập trung vào nguồn gốc bản dựng; S2C2F, chỉ tập trung vào việc tiêu thụ các phụ thuộc; và OpenSSF Bảng điểm bao gồm các bước kiểm tra kho lưu trữ cụ thể. Mỗi bảng điểm chỉ bao gồm một phần, không bảng nào bao gồm toàn bộ.
| Khung hoặc Dự án | Phạm vi chính |
|---|---|
| Top 10 của OWASP CI/CD Rủi ro | Hướng đến nhận thức CI/CD Hướng dẫn về rủi ro, không phải là xác minh có thể kiểm chứng. standard. |
| SLSA | Xây dựng nguồn gốc xuất xứ và tính toàn vẹn của hiện vật. |
| S2C2F | Tiêu thụ phụ thuộc một cách an toàn. |
| OpenSSF Thẻ điểm | Các bước kiểm tra bảo mật cụ thể ở cấp độ kho lưu trữ. |
Khoảng cách: mỗi khuôn khổ đều bao gồm một phần quan trọng của software supply chain securitynhưng không có giải pháp nào cung cấp một quy trình kiểm chứng từ đầu đến cuối. standard cho toàn bộ CI/CD pipeline.
Cuộc thảo luận đó đã trở thành hai năm làm việc, và vào tháng 1.0 năm 2025, nhóm làm việc SPVS đã phát hành phiên bản 1.0: 127 yêu cầu xuyên suốt vòng đời, Lập kế hoạch, Phát triển, Tích hợp, Phát hành, Vận hành, được phân loại thành ba cấp độ trưởng thành: L1 Cơ bản, L2 Standardvà L3 Nâng cao. Mọi yêu cầu đều được đối chiếu với NIST SP 800-53, OWASP. CI/CD Top 10 và CWE.
Cấu trúc mới là điểm mấu chốt. Theo lời của chính các tác giả SPVS:
“Hãy xác minh toàn bộ pipelineKhông chỉ một phần. Đây là điểm mà hầu hết các tổ chức gặp khó khăn. Họ quét các phụ thuộc nhưng bỏ qua việc quản lý phát hành. Họ ký các tạo phẩm nhưng không lập mô hình mối đe dọa. pipeline Kiến trúc. Họ giám sát quá trình sản xuất nhưng không giám sát môi trường xây dựng của họ.”
Đây là điểm mà hầu hết các tổ chức đều gặp khó khăn. Họ quét các phụ thuộc nhưng bỏ qua việc quản lý phát hành. Họ ký các tạo phẩm nhưng không lập mô hình mối đe dọa. pipeline Kiến trúc. Họ giám sát môi trường sản xuất nhưng không giám sát môi trường xây dựng.
Đây là luận điểm biện minh cho nỗ lực này. Điểm mạnh ở giai đoạn này không thể bù đắp cho điểm yếu ở giai đoạn khác. Kẻ tấn công chỉ cần phá vỡ một mắt xích. Một vòng đời. standard Nó buộc bạn phải kiểm tra tất cả, và quá trình chuyển đổi từ L1 sang L2 sang L3 cho phép bạn làm điều đó mà không cần phải tốn quá nhiều công sức. SPVS không thay thế SLSA, S2C2F, Scorecard hay Sigstore; nó cung cấp cho bạn khung sườn giúp bạn biết mỗi công cụ đó phù hợp ở đâu.
Điều chỉnh Standard Gửi đến Tổ chức của bạn
Bước đầu tiên và tự nhiên nhất là kiểm tra toàn diện cơ sở hạ tầng phần mềm và tổ chức của bạn so với từng yêu cầu. Một bảng tính Google Sheet được tạo từ nguồn chính thức. Yêu cầu SPVS CSV Nó hoạt động tốt như một điểm khởi đầu. Ba góc nhìn hữu ích: ma trận yêu cầu với trạng thái và người chịu trách nhiệm cho mỗi kiểm soát, bản đồ nhiệt cho mỗi kho lưu trữ và một... dashboard tiến độ được thể hiện theo từng giai đoạn và cấp độ. Kết quả đầu ra được tích hợp một cách tự nhiên vào lộ trình kỹ thuật, một tài liệu sống động bao gồm mọi giai đoạn từ lập kế hoạch đến vận hành.
Hầu hết các tổ chức kỹ thuật đã trưởng thành sẽ nhận thấy mình đang ở mức độ L2 khi thực hiện việc lập bản đồ ban đầu này. Trên thực tế, đó là một vị trí tốt: điều đó có nghĩa là giai đoạn đầu tiên có thể tập trung vào việc khắc phục những thiếu sót cụ thể thay vì xây dựng nền tảng từ đầu.
Tuy nhiên, bảng tính chỉ là một ảnh chụp nhanh, và SPVS yêu cầu nhiều hơn thế. Phiên bản 1.1.7 yêu cầu kiểm toán định kỳ hàng quý đối với quản trị viên VCS; các phiên bản 5.1.1 đến 5.1.3 bổ sung thêm kiểm toán người dùng thường xuyên, xem xét nhật ký truy cập và giám sát quyền truy cập đặc quyền; một số tính năng kiểm soát trong các phiên bản 2.1.x, 3.3.x và 4.2.x yêu cầu duy trì vệ sinh quy trình làm việc YAML. Nếu thực hiện thủ công trên toàn tổ chức, việc này sẽ mất nửa ngày theo dõi thao tác nhấp chuột mỗi quý, với nguy cơ bỏ sót những lỗi nhỏ. Đây là loại công việc hoặc sẽ được tự động hóa hoặc chỉ được xem xét lại sau khi xảy ra sự cố.
Một số biện pháp kiểm soát SPVS không phải là các mục kiểm tra một lần. Chúng đòi hỏi việc xem xét định kỳ, bằng chứng kiểm toán và phát hiện sự sai lệch trên các kho lưu trữ, người dùng, quy trình làm việc và quyền truy cập đặc quyền.
| Khu vực SPVS | Loại yêu cầu |
|---|---|
V1.1.7 | Kiểm toán định kỳ hàng quý đối với các quản trị viên VCS. |
V5.1.1–V5.1.3 | Kiểm tra định kỳ người dùng, xem xét nhật ký truy cập và giám sát quyền truy cập đặc quyền. |
V2.1.x, V3.3.x, V4.2.x | Đảm bảo quy trình làm việc luôn được tối ưu hóa (YAML). |
Giải pháp là xây dựng hoặc áp dụng các công cụ hoạt động dưới danh tính chủ sở hữu tổ chức và tạo ra một gói báo cáo định kỳ hàng quý có cấu trúc: danh sách quản trị viên, bảo vệ nhánh, phạm vi CODEOWNERS, làm sạch YAML quy trình làm việc với các hành động được ghim, quyền hạn rõ ràng, pull_request_target Kiểm soát truy cập, xác thực hai yếu tố thành viên, ứng dụng GitHub đã cài đặt và khóa triển khai. Những việc từng mất nửa ngày để tìm kiếm thông tin trên bảng tính giờ chỉ còn là một lệnh duy nhất tạo ra dữ liệu JSON và Markdown. Đánh giá hàng quý giữa... CISQuản trị viên O và tổ chức trở thành một decisCuộc họp này không phải là cuộc họp thu thập dữ liệu, và những phát hiện có thể hành động được sẽ trở thành vấn đề tồn đọng với các thỏa thuận mức dịch vụ (SLA) dựa trên mức độ nghiêm trọng.
Chính sách danh sách cho phép, bao gồm quản trị viên được phê duyệt, ứng dụng được phê duyệt và quyền theo chức năng cho kho lưu trữ và quy trình làm việc, nên được lưu trữ dưới dạng YAML trong kho lưu trữ được kiểm soát phiên bản, được nhóm bảo mật xem xét bằng yêu cầu kéo (PR). Bất kỳ thay đổi nào trong danh sách cho phép đều để lại dấu vết xem xét, do đó bằng chứng kiểm toán sẽ tự tạo ra. Hiệu quả là biến các biện pháp kiểm soát mang tính lý tưởng, chẳng hạn như "chúng ta nên kiểm toán hàng quý", thành các biện pháp kiểm soát thường xuyên, chẳng hạn như "báo cáo kiểm toán quý này đã được gửi vào thứ Hai", và cung cấp cho tổ chức một cơ chế lặp lại để phát hiện sự thay đổi mà nguyên tắc từ đầu đến cuối yêu cầu.
Những trở ngại bạn cần lên kế hoạch
Kiểm soát kỹ thuật là phần dễ. Con người mới là phần khó hơn.
Ví dụ nổi bật nhất hầu như luôn là CODEOWNERS. Thêm vào đó... .github/workflows/ @your-org/security Việc này nghe có vẻ đơn giản trên mọi kho lưu trữ. Chỉ một tệp, một dòng. Nhưng điều đó có nghĩa là các kỹ sư đã tự hợp nhất các thay đổi quy trình làm việc trong nhiều năm nay cần được xem xét về mặt bảo mật. Ngay cả những người quan tâm đến bảo mật cũng phản đối: Tôi đã viết quy trình làm việc này, tôi hiểu nó, tại sao tôi lại phải chờ đợi?
Cần có cuộc đối thoại thực sự để làm rõ lý do. Quy trình làm việc có thể đánh cắp thông tin đăng nhập, chuyển hướng các sản phẩm và gây hại cho người dùng ở khâu tiếp theo. Việc có thêm một người kiểm tra không phải là dấu hiệu của sự nghi ngờ; đó là cùng một logic như việc kiểm tra chéo (bốn người cùng xem xét) đối với các thay đổi cơ sở dữ liệu sản xuất. Việc có một sự cố chuỗi cung ứng cụ thể, gần đây để chỉ ra, dù là từ ngành công nghiệp hay môi trường của chính bạn, sẽ giúp ích rất nhiều. Không có gì làm rõ tầm quan trọng của một biện pháp kiểm soát tốt hơn là một ví dụ thực tế về sự thiếu sót của nó.
Các ma sát khác cũng có hình dạng tương tự:
- Quyền hạn cụ thể: Các trở ngại trong quy trình làm việc gây ra lỗi CI cho đến khi người đóng góp hiểu được phạm vi quyền hạn. Đây không phải là vấn đề về quyền hạn, mà là vấn đề về mô hình tư duy.
- Tính bất biến của thẻ: Phá vỡ công cụ phát hành vốn đã âm thầm gắn thẻ lại trong nhiều năm.
- Ký commits: Việc này tạo ra sự khó khăn trong quá trình thiết lập ban đầu cho đến khi các khóa GPG hoặc SSH được thiết lập chính xác trên tất cả các máy trạm. SPVS yêu cầu điều này bắt buộc trên mọi kho lưu trữ và người đóng góp, không chỉ riêng các kho chính.
- Thay thế các mã truy cập cá nhân truyền thống: Nó trải rộng trên nhiều kho lưu trữ và tệp quy trình làm việc, ảnh hưởng đến hầu hết mọi nhóm.
Mô hình hiệu quả là: giới thiệu từng biện pháp kiểm soát với một mối đe dọa cụ thể mà nó ngăn chặn, thử nghiệm trên một hoặc hai kho lưu trữ, triển khai với các ngoại lệ được cho phép, và loại bỏ các ngoại lệ theo một lịch trình xác định. Những kỹ sư phản đối mạnh mẽ nhất, thường lại trở thành những người ủng hộ mạnh mẽ nhất một khi họ hiểu được lý do hợp lý.
Một điểm quan trọng hơn nữa: nguyên tắc "từ đầu đến cuối" rất quan trọng ở đây. Bạn không thể chọn lọc từng bước. Việc tăng cường kiểm soát giai đoạn xây dựng trong khi để lỏng lẻo việc quản lý phát hành sẽ tạo ra sự tự tin sai lầm, và đó chính xác là lỗi mà các tác giả của SPVS đã chỉ ra. Mọi giai đoạn phải tiến triển đồng bộ, ngay cả khi một biện pháp kiểm soát cụ thể nào đó có vẻ không cân xứng khi đứng riêng lẻ.
Chi phí: Khoảng một tháng thời gian kỹ thuật đã trôi qua cho Giai đoạn 1, tập trung vào việc tuân thủ L2 cho một tổ chức nhỏ, trải rộng trên các nhóm DevOps, Bảo mật và các chuyên gia đánh giá kỹ thuật. Khoản đầu tư này dễ dàng thu hồi vốn. Chỉ cần ngăn chặn được một sự cố trong chuỗi cung ứng là đã bù đắp được chi phí gấp nhiều lần. Các tổ chức lớn hơn nên dành ngân sách nhiều hơn tương ứng, nhưng cấu trúc theo từng giai đoạn từ L1 đến L2 đến L3 có nghĩa là giá trị được tạo ra trước khi chương trình hoàn tất.
Tiếp theo là gì
Phiên bản SPVS v1.5 sắp ra mắt với các tính năng kiểm soát liên quan đến AI: nguồn gốc của mã được hỗ trợ bởi AI, guardrails Đối với các quy trình CI gọi LLM, hãy xem xét các dấu vết cho các quy trình do AI tạo ra. pull requestsvà các biện pháp phòng vệ chống lại các mối đe dọa mới nổi như slopsquatting, trong đó kẻ tấn công đăng ký tên gói phần mềm mà các trợ lý lập trình AI tạo ra một cách ảo tưởng, và phần mềm độc hại do AI tạo ra mà CrowdStrike báo cáo trong thực tế. Các tổ chức đã gắn thẻ hỗ trợ AI commitCác chuyên gia và nhà cung cấp dịch vụ khách hàng trong hướng dẫn phát triển nội bộ của họ sẽ thấy sự điều chỉnh này là một bước thích ứng dần dần hơn là một chương trình công việc mới.
Phiên bản 2.0 dự kiến sẽ tăng cường giám sát thời gian thực và các yêu cầu về vòng đời chứng chỉ. Một lộ trình tổ chức hợp lý: khắc phục các lỗ hổng L3 còn lại vào cuối quý 2 năm 2026, bao gồm: SLSA provenance tích hợp vào standard CI/CDCác cổng thủ công cho việc triển khai sản phẩm và nhà cung cấp danh tính tập trung, sau đó chuyển sang chế độ bảo trì. Mỗi kho lưu trữ mới đều bắt đầu tuân thủ các quy định và mỗi cuộc kiểm toán hàng quý đều phát hiện ra sự sai lệch sớm.
Tôi xin chân thành cảm ơn Farshad Abasi, Cameron Walters và nhóm làm việc OWASP SPVS. Những dự án như thế này giúp giảm bớt rào cản cho mọi tổ chức muốn thực hiện bảo mật chuỗi cung ứng một cách có hệ thống thay vì chỉ phản ứng khi sự cố xảy ra.
Các nội dung chính
Một vài điều có thể áp dụng ngoài bối cảnh cụ thể của chúng ta:
- Để thử: Tải xuống tệp CSV chứa các yêu cầu của SPVS và đối chiếu các biện pháp kiểm soát hiện tại của bạn với bảng tính. Bạn sẽ biết trong vòng một ngày liệu nó có phù hợp hay không.
- Hãy chọn một mục tiêu cụ thể và hoàn thành nó trước khi chuyển sang mục tiêu tiếp theo. Việc chuyển từ L1 sang L2 sang L3 là một tính năng, chứ không phải là một hạn chế.
- pipeline là mục tiêu. Các biện pháp kiểm soát tập trung vào ứng dụng là cần thiết nhưng chưa đủ; hãy xử lý... pipeline như một bề mặt tấn công hạng nhất.
- Xác minh toàn bộ pipelineKhông phải một mảnh. Năng lực trong việc quét các phụ thuộc không thể bù đắp cho việc quản lý phát hành yếu kém hoặc môi trường xây dựng không được giám sát.
- Bảng tính chỉ phản ánh tình trạng tại một thời điểm nhất định; sự thay đổi diễn ra liên tục. Xây dựng hệ thống tự động hóa, ngay cả một công cụ nội bộ đơn giản, để phát hiện sự sai lệch giữa các cuộc kiểm toán.
- Công tác tổ chức khó hơn công tác kỹ thuật. Hãy dành thời gian cho việc thảo luận và thử nghiệm trước khi triển khai, đồng thời giải thích mối đe dọa cụ thể mà mỗi biện pháp kiểm soát có thể ngăn chặn.
Để đọc thêm
- OWASP: Bảo mật Pipeline Xác minh Standard (SPVS) v1.0Trang dự án OWASP.
- Farshad Abasi: Vì sao chúng tôi tạo ra OWASP SPVSCác bài viết về OWASP SPVS.
- Farshad Abasi: Pipeline Các cuộc tấn công đang ngày càng trở nên nghiêm trọng. Dưới đây là cách chuẩn bị.Các bài viết về OWASP SPVS.
- Farshad Abasi: So sánh OWASP SPVS với các khung quản lý chuỗi cung ứng khácCác bài viết về OWASP SPVS.
- OWASP: Top 10 CI/CD Rủi ro bảo mậtTrang dự án OWASP.
- SLSA: Các cấp độ chuỗi cung ứng cho các thành phần phần mềm. slsa.dev.
- OpenSSF: Thẻ điểmsecurityscorecards.dev.
