Bảo mật chuỗi cung ứng phần mềm và tính toàn vẹn bản build dựa trên SLSA
1. Tổng quan
SLSA (Supply-chain Levels for Software Artifacts) là một khung bảo mật biểu diễn quan hệ tin cậy giữa mã nguồn, nền tảng build, các phụ thuộc và sản phẩm đầu ra bằng provenance (nguồn gốc·lịch sử tạo ra) và các yêu cầu theo từng cấp độ, nhằm giảm rủi ro giả mạo·nhiễm độc trong chuỗi cung ứng phần mềm.
Tấn công chuỗi cung ứng phần mềm không xâm nhập trực tiếp vào máy chủ đang vận hành mà lợi dụng niềm tin trong quá trình phát triển·build·triển khai. Mã độc có thể lẫn vào gói mã nguồn mở mà lập trình viên sử dụng, quyền của CI runner có thể bị chiếm đoạt, hoặc một tệp nhị phân trông như được tạo từ mã nguồn hợp lệ có thể bị thay thế sau khi build. Nếu chỉ kiểm tra giá trị băm của tệp cuối cùng, tổ chức khó trả lời được câu hỏi "tệp này được tạo ra bằng gì, ở đâu, với đầu vào nào".
Đặc biệt, pipeline CI/CD hiện đại kết nối kho mã nguồn, kho gói, container registry, action bên ngoài, bộ đệm build, hệ thống ký số và nhiều tài khoản đám mây. Nếu quyền ở một bước bị cấp quá mức hoặc lịch sử tạo ra có thể bị giả mạo, kẻ tấn công có thể chèn sản phẩm độc hại vào ngay trong quy trình triển khai bình thường. Vì vậy, bảo mật chuỗi cung ứng không chỉ là vấn đề của tường lửa hay phần mềm diệt virus lúc chạy, mà là vấn đề chứng minh và kiểm chứng chính quá trình phần mềm được tạo ra.
SLSA chia vấn đề này thành "bằng chứng có thể kiểm chứng về cách sản phẩm được tạo ra" và "mức độ có thể tin cậy vào bằng chứng đó". Build track xử lý quan hệ giữa sản phẩm build và nền tảng build, còn Source track xử lý niềm tin trong quá trình mã nguồn được đưa vào kho và thay đổi. Mỗi track không ép mọi tổ chức phải đạt ngay cấp cao nhất, mà giúp đo lường mức kiểm soát hiện tại và nâng dần lên.
Trong bài luận, nếu chỉ mô tả SLSA như một công cụ đơn thuần hoặc một sản phẩm ký số thì chưa đủ. Thứ nhất, cần phân biệt SBOM là danh sách thành phần, còn SLSA provenance là bằng chứng về quá trình tạo ra. Thứ hai, không nên khẳng định rằng chỉ cần có chữ ký là an toàn, mà phải giải thích đồng thời chủ thể ký·bảo vệ khóa·cô lập build·kiểm chứng chính sách. Thứ ba, cần cân bằng giữa sự thuận tiện của lập trình viên và kiểm soát bảo mật để đề xuất chiến lược áp dụng theo từng giai đoạn dựa trên rủi ro.
A. Bối cảnh ra đời và sự cần thiết
Bối cảnh thứ nhất là sự mở rộng bề mặt tấn công. Khác với thời kỳ một ứng dụng chỉ gồm mã do chính mình viết, hiện nay ứng dụng kết hợp hàng trăm gói, plugin build, container image và action triển khai. Việc xác nhận một gói là phiên bản hợp lệ và việc xác nhận gói đó thực sự đã được dùng trong bản build là hai vấn đề riêng biệt. SLSA làm lộ rõ mối liên kết này thông qua provenance mô tả đầu vào và môi trường thực thi.
Bối cảnh thứ hai là sự khác biệt giữa "bản build có vẻ tái lập được" và "bản build đáng tin cậy". Dù có thể build lại từ cùng một commit mã nguồn, kết quả vẫn có thể khác nếu trong quá trình build có giá trị bí mật tùy ý được chèn vào hoặc tệp tải từ bên ngoài bị thay đổi. Tính tái lập là thuộc tính chất lượng hữu ích, nhưng không tự động bảo đảm chủ thể build là hợp lệ hay provenance không bị giả mạo. Do đó, phải thiết kế tính tái lập, bằng chứng được ký và môi trường build cô lập như những biện pháp kiểm soát riêng biệt.
Bối cảnh thứ ba là sự thay đổi trong yêu cầu của quy định·mua sắm·khách hàng. Trong lĩnh vực công·tài chính·y tế, không chỉ thành phần và việc xử lý lỗ hổng của phần mềm được bàn giao, mà cả kiểm soát phát triển·build cũng trở thành hạng mục đánh giá quan trọng. Sau khi xảy ra sự cố, tổ chức phải truy vết được "bản build nào được tạo từ mã nguồn và phụ thuộc nào", và cũng phải nhận các tuyên bố của nhà cung cấp dưới dạng bằng chứng có thể kiểm chứng. Áp dụng đồng thời SLSA và NIST SSDF cho phép liên kết các hạng mục thực hành của quy trình phát triển với bằng chứng tạo ra sản phẩm.
B. Mục tiêu và phạm vi
Mục tiêu của SLSA không phải là ngăn chặn mọi cuộc tấn công, mà là phát hiện·kìm hãm lỗi và giả mạo xảy ra trong chuỗi cung ứng, đồng thời giúp bên tiêu thụ đánh giá chính sách về con đường tạo ra sản phẩm. Ví dụ, tổ chức có thể xây dựng chính sách "image triển khai lên môi trường vận hành phải được build từ commit được bảo vệ trong kho được phê duyệt, bằng nền tảng CI trung tâm, và để lại provenance đã ký". Policy engine đọc provenance của image và tự động phán định xem có thỏa mãn điều kiện này hay không.
Phạm vi trải dài từ kiểm soát thay đổi ở kho mã nguồn, thu thập phụ thuộc, thực thi build, tạo sản phẩm, phát hành provenance, ký·lưu trữ, đến kiểm chứng trước triển khai. Ngược lại, riêng SLSA không thay thế được toàn bộ lỗ hổng của ứng dụng đang vận hành, việc phê duyệt nghiệp vụ, đào tạo bảo mật cho lập trình viên hay kiểm thử xâm nhập. Cần làm rõ phạm vi của khung để tránh sự tự tin thái quá sau khi áp dụng kiểu "đã đạt SLSA nên mọi rủi ro chuỗi cung ứng đã bị loại bỏ".
2. Khái niệm cốt lõi và cấu trúc của SLSA
Chìa khóa để hiểu SLSA là mối quan hệ giữa sản phẩm (artifact), đầu vào (input), nền tảng build (build platform), provenance và bên kiểm chứng (verifier). Sản phẩm là kết quả mà bên tiêu thụ cài đặt hoặc triển khai như tệp nhị phân·gói·container image, còn đầu vào là các yếu tố ảnh hưởng đến kết quả như mã nguồn·phụ thuộc·tham số build·build image. Nền tảng build nhận đầu vào, tạo ra sản phẩm và phát hành bằng chứng mô tả quá trình đó. Bên kiểm chứng liên kết digest của sản phẩm với subject của provenance, sau đó quyết định có cho phép triển khai hay không theo chính sách của tổ chức.
flowchart LR
S["Kho mã nguồn\ncommit·tag·quy tắc bảo vệ"] --> I["Tập đầu vào\nphụ thuộc·build image·tham số"]
I --> B["Nền tảng build tin cậy\ncô lập·quyền·log"]
B --> A["Sản phẩm\ngói·image·tệp nhị phân"]
B --> P["SLSA provenance\nai·build cái gì·như thế nào"]
A --> V["Bên kiểm chứng·policy engine"]
P --> V
V --> D["Cho phép hoặc chặn triển khai"]
A. Sản phẩm và digest
Đối tượng kiểm chứng nên được định danh bằng digest mật mã thay vì tên tệp. Tên tệp và chuỗi phiên bản có thể thay đổi khi di chuyển kho hoặc đóng gói lại, nhưng digest của các byte sản phẩm chỉ thay đổi khi nội dung thay đổi. Do đó, subject của provenance ghi tên và digest của sản phẩm, và khi kiểm chứng sẽ tính lại digest của tệp thực tế đã tải về để xác nhận có khớp hay không.
Khớp digest là điều kiện cần chứ không phải điều kiện đủ. Nếu kẻ tấn công tạo provenance giả khớp với digest của tệp độc hại, hoặc đánh cắp khóa ký của nền tảng build hợp lệ, thì phép so sánh chuỗi đơn thuần không giải quyết được vấn đề. Bên kiểm chứng phải kiểm tra đồng thời digest, chữ ký provenance, danh tính người ký, đường build, commit đầu vào và điều kiện chính sách.
Ví dụ, nếu registry cho phép ghi đè tag container payment-api:2.4.1 bằng cùng tên, hệ thống triển khai phải cố định immutable digest thay vì tag.
Sau đó xác nhận digest mà provenance trỏ tới có trùng với digest của image nhận từ registry hay không.
Thủ tục này có ý nghĩa ở chỗ bảo đảm "triển khai đúng các byte đã được kiểm chứng" chứ không phải "đã nhận image có tên gì".
B. Provenance
Provenance là bằng chứng có thể ký, thể hiện sản phẩm đã được tạo ra qua những đầu vào và quá trình thực thi nào. Thông thường nó bao gồm định nghĩa build, tham số bên ngoài, các phụ thuộc đã được phân giải, workspace build, định danh nền tảng build và sản phẩm được tạo ra. Bên tiêu thụ dùng thông tin này để đánh giá đó có phải commit mã nguồn được cho phép, dịch vụ build được phê duyệt, và có đầu vào bên ngoài ngoài dự kiến nào chen vào hay không.
Provenance không thể có được niềm tin chỉ bằng một bản tuyên bố do lập trình viên tự viết. Nếu bước build do người dùng kiểm soát có thể tùy ý thay đổi nội dung provenance, kẻ tấn công có thể thực tế dùng đầu vào độc hại mà vẫn khẳng định đã dùng đầu vào hợp lệ. Do đó, ở cấp cao hơn, bằng chứng phải được tạo trong vùng kiểm soát của nền tảng build, khóa ký phải được cô lập khỏi lệnh build của người dùng, và phải xác nhận bằng chứng được gắn đúng với sản phẩm.
Provenance được SLSA khuyến nghị là định dạng dùng cùng in-toto attestation framework. Attestation là phong bì chứa tuyên bố về sản phẩm, còn predicate chứa ý nghĩa cụ thể của tuyên bố đó như build hay kiểm thử. Cấu trúc này có thể mở rộng để xử lý các loại bằng chứng khác nhau ngoài build provenance như quét lỗ hổng, kết quả kiểm thử, kiểm tra giấy phép trong cùng một hệ thống chính sách.
C. Build track và Source track
SLSA v1.2 phân biệt Build track và Source track. Build track đánh giá theo cấp độ việc nền tảng build tạo provenance, provenance đó mô tả chính xác sản phẩm và đầu vào build, và môi trường build chống chịu giả mạo đến mức nào. Source track xử lý việc mã nguồn đến từ đâu và đã qua kiểm soát thay đổi nào để trở thành trạng thái mã nguồn tin cậy. Tách hai track giúp phân tích riêng biệt "trường hợp build an toàn nhưng build commit độc hại" và "trường hợp mã nguồn được phê duyệt nhưng nền tảng build bị giả mạo".
Các Build level từ SLSA v1.0 trở đi được mô tả từ L0 đến L3. L0 là trạng thái không có bảo đảm, L1 yêu cầu sự tồn tại của build provenance. L2 là cấp mà nền tảng build được lưu trữ (hosted) tạo và ký provenance, nâng cao khả năng phòng thủ trước giả mạo sau build. L3 là cấp yêu cầu nền tảng build cô lập mạnh và chống giả mạo, giảm thêm rủi ro bị giả mạo trong quá trình build.
| Phân loại | Bảo đảm cốt lõi | Rủi ro tiêu biểu được giảm thiểu | Câu hỏi khi áp dụng |
|---|---|---|---|
| Build L0 | Không có bảo đảm riêng | Trạng thái không có kiểm soát có hệ thống | Có giải thích được con đường tạo ra sản phẩm không |
| Build L1 | Có provenance | Lỗi·thiếu khả năng truy vết | Mọi bản phát hành có để lại lịch sử tạo ra không |
| Build L2 | Provenance được ký và build được lưu trữ | Giả mạo bằng chứng sau build | Chủ thể ký và danh tính CI có đáng tin không |
| Build L3 | Nền tảng build được tăng cường·cô lập | Thao túng trong khi build | Có bảo vệ ranh giới giữa khóa·workspace·các bản build không |
Các cấp độ này không phải là điểm trưởng thành tổng thể về bảo mật sản phẩm. Ví dụ, dù nền tảng build ở cấp L3, nếu ứng dụng dùng thư viện có lỗ hổng hoặc kiểm soát truy cập máy chủ vận hành yếu thì rủi ro tổng thể vẫn còn. Do đó, tổ chức phải ánh xạ track·cấp độ với mức độ quan trọng của tài sản và kịch bản tấn công, đồng thời quản lý cùng với SBOM·quản lý lỗ hổng·SSDF·bảo mật runtime.
D. Producer và Consumer
Producer bao gồm nền tảng build tạo phần mềm và phát hành provenance cùng tổ chức sử dụng nền tảng đó. Trách nhiệm của Producer là định danh chính xác đầu vào và kết quả build, tạo provenance phù hợp với cấp yêu cầu, và bảo vệ khóa ký cùng môi trường build. Consumer là tổ chức·dịch vụ cài đặt gói hoặc triển khai image, và phải dùng provenance vào việc ra quyết định chính sách thực tế.
Nếu bên tiêu thụ không kiểm chứng, provenance chỉ dừng lại ở mức log trang trí. Ví dụ, dù provenance được lưu cùng trong registry, nếu pipeline triển khai lấy tag mới nhất mà không kiểm tra người ký hay kho mã nguồn thì kiểm soát bảo mật không hoạt động. Bên tiêu thụ phải định nghĩa bằng chính sách các builder, nhánh, kho, tổ chức, tham số build, điều kiện phụ thuộc được cho phép, và phân biệt thủ tục chặn·ngoại lệ·phê duyệt khi thất bại.
3. Kịch bản tấn công chuỗi cung ứng và cách SLSA ứng phó
Đặc điểm của tấn công chuỗi cung ứng là lỗi của lập trình viên và tấn công từ bên ngoài sử dụng cùng một con đường. Nếu đánh cắp token CI bằng email lừa đảo, chiếm tài khoản phát hành của kho mã nguồn mở, hoặc gây dependency confusion bằng cách làm nhầm lẫn tên gói, kẻ tấn công có thể phân phối sản phẩm độc hại mà không đi ngược luồng phát triển bình thường. SLSA không xóa bỏ tấn công như phép màu, mà làm rõ các ranh giới tin cậy mà kẻ tấn công phải vượt qua và để lại bằng chứng kiểm chứng hậu kiểm.
A. Phụ thuộc độc hại và dependency confusion
Kẻ tấn công có thể tạo gói công khai trùng tên với gói nội bộ để công cụ build ưu tiên chọn gói bên ngoài. Hoặc có thể chiếm tài khoản người bảo trì của gói hợp lệ rồi phát hành phiên bản mới chứa mã độc. Khi đó SBOM cho biết các gói có trong sản phẩm cuối cùng, nhưng cần xác nhận thêm gói đó đến từ kho·digest·quá trình build nào.
Biện pháp ứng phó gồm giới hạn kho phụ thuộc bằng danh sách cho phép, rà soát lockfile và checksum, và kiểm chứng provenance cùng chữ ký khi thu thập phụ thuộc. Ngay cả khi cache gói bên ngoài qua proxy nội bộ, cũng không được tin vô điều kiện các tệp chưa được kiểm chứng. Không chỉ tên phụ thuộc mà cả nguồn gốc, phiên bản, digest, người ký và transitive dependency đều phải là đối tượng của chính sách.
B. Chiếm đoạt thông tin xác thực CI/CD và build runner
Nếu kẻ tấn công đọc được khóa triển khai đám mây hay khóa ký provenance trên CI runner, chúng có thể tạo sản phẩm độc hại thông qua pipeline bình thường. Đặc biệt, nếu giá trị bí mật bị lộ cho PR bên ngoài hoặc untrusted input do script build xử lý, quyền thay đổi mã nguồn và quyền phát hành có thể bị chiếm đoạt dây chuyền.
Biện pháp ứng phó chia thành đặc quyền tối thiểu theo từng bước build, token ngắn hạn, giới hạn phạm vi chèn giá trị bí mật, phê duyệt nhánh tin cậy, ephemeral runner và hạn chế network egress. Khóa ký không được đặt dưới dạng tệp trong workspace nơi lệnh build thực thi, mà thiết kế để dịch vụ ký trong ranh giới tin cậy chỉ ký cho các yêu cầu giới hạn. Provenance ghi lại builder nào đã thực thi, và bên kiểm chứng chặn triển khai nếu không phải builder được phê duyệt.
C. Thay thế sản phẩm sau build
Tấn công thay thế tệp trong registry hoặc kho triển khai sau khi build bình thường là vấn đề sản phẩm tiêu thụ cuối cùng bị khác đi dù quá trình tạo ra là bình thường. Để ngăn chặn, gắn digest sản phẩm vào subject của provenance, ký provenance, và băm lại các byte đã tải về khi tiêu thụ. Kết hợp immutable tag của registry, kiểm chứng chữ ký, transparency log và phân tách quyền truy cập có thể giảm tác động khi một kho đơn lẻ bị xâm phạm.
Ở đây, cốt lõi của chữ ký là "ai đã ký". Vì kẻ tấn công ký tệp độc hại bằng khóa của chính mình không hề khó, bên kiểm chứng phải xác nhận chứng chỉ·chủ thể OIDC·định danh workflow build mà tổ chức tin cậy cùng thời điểm ký. Việc xử lý sản phẩm cũ khi khóa được thay hoặc thu hồi, và cách phân chia phạm vi tin cậy trước và sau khi khóa bị xâm phạm, cũng phải được quy định trong chính sách vận hành.
| Kịch bản tấn công | Điểm bị xâm phạm | Bằng chứng·kiểm soát cần thiết | Kiểm chứng hoặc ứng phó |
|---|---|---|---|
| Bản phát hành mã nguồn mở độc hại | Kho phụ thuộc·tài khoản quản trị | Nguồn gốc gói, checksum, provenance của phụ thuộc | Áp dụng chính sách kho cho phép và chữ ký·lỗ hổng |
| dependency confusion | Thứ tự phân giải gói | Ưu tiên kho nội bộ, chính sách namespace | Chặn tên bên ngoài·cố định proxy |
| Chiếm đoạt CI runner | Môi trường thực thi build | Danh tính builder, cô lập, log đặc quyền tối thiểu | Chỉ cho phép builder và provenance đã được phê duyệt |
| Giả mạo provenance | Kho bằng chứng·khóa ký | Chữ ký, bảo vệ khóa, transparency | Kiểm chứng người ký·subject·điều kiện chính sách |
| Thay thế sản phẩm | Registry·kho triển khai | Gắn digest, lưu trữ immutable | Kiểm chứng lại digest ngay trước triển khai |
4. Triển khai CI/CD và quy trình kiểm chứng
Triển khai SLSA không phải là "thêm một công cụ vào pipeline" mà là công việc thiết kế lại ranh giới tin cậy của con đường build. Trước tiên, lập danh mục sản phẩm nào quan trọng, đầu vào nào ảnh hưởng đến kết quả và builder nào sẽ được tin cậy. Sau đó, lần lượt bổ sung việc tạo provenance, ký·lưu trữ và kiểm chứng phía bên tiêu thụ.
sequenceDiagram
participant DEV as Lập trình viên·PR
participant SCM as Kho mã nguồn được bảo vệ
participant CI as CI builder cô lập
participant ATT as Dịch vụ Attestation·ký
participant REG as Kho sản phẩm·bằng chứng
participant DEP as Policy engine triển khai
DEV->>SCM: Commit·review·phê duyệt
SCM->>CI: Chỉ kích hoạt build cho thay đổi được phép
CI->>CI: Cố định đầu vào·phân giải phụ thuộc·kiểm thử·build
CI->>ATT: Gửi digest sản phẩm và thông tin build
ATT-->>REG: Lưu provenance đã ký
CI->>REG: Push sản phẩm
DEP->>REG: Truy vấn sản phẩm·provenance
DEP->>DEP: Kiểm chứng subject·người ký·nguồn·builder·chính sách
DEP-->>REG: Triển khai nếu hợp lệ, chặn nếu vi phạm
A. Đường cơ sở và phân loại tài sản
Nếu ép cùng một mức kiểm soát cho mọi kho, luồng phát triển của các nhóm nhỏ có thể bị chậm quá mức. Ngược lại, nếu áp tiêu chuẩn thấp cho API thanh toán công khai trên Internet hoặc image phát hành công cộng thì chi phí sự cố sẽ lớn. Do đó, cần phân loại sản phẩm theo mức độ quan trọng, mức độ lộ ra bên ngoài, việc xử lý thông tin cá nhân, tần suất thay đổi, mức phụ thuộc chuỗi cung ứng, khả năng phục hồi và xác định cấp mục tiêu.
Ví dụ, công cụ phát triển nội bộ có thể bắt đầu từ việc tạo provenance để có khả năng truy vết ở cấp L1, còn image dịch vụ tài chính phát hành cho khách hàng có thể yêu cầu bằng chứng được ký, CI trung tâm, cô lập·thông tin xác thực ngắn hạn. Xác định mục tiêu dựa trên rủi ro như vậy giúp giải thích mối quan hệ giữa mối đe dọa thực tế và kiểm soát thay vì "cạnh tranh con số cấp SLSA". Đường cơ sở cũng phải bao gồm người phê duyệt ngoại lệ và ngày hết hạn, và ngoại lệ vĩnh viễn phải được đánh giá lại định kỳ để không trở thành lối vòng tránh kiểm soát trên thực tế.
B. Cố định mã nguồn và đầu vào build
Đầu vào mã nguồn được cố định dưới dạng có thể truy vết thay đổi như digest commit hay tag được bảo vệ.
Nếu chỉ ghi là build trạng thái mới nhất của main, sẽ khó tái hiện chính xác commit nào đã được chọn lúc build.
Action bên ngoài và build image cũng được cố định bằng digest hoặc phiên bản có thể kiểm chứng thay vì tag, và kết quả phân giải gói được kiểm soát bằng lockfile.
Cố định đầu vào không chỉ để phục vụ tính tái lập. Đó là biện pháp kiểm soát bảo mật giúp bên kiểm chứng xác nhận quan hệ giữa commit mã nguồn khai báo trong provenance và sản phẩm thực tế. Tuy nhiên, không thể cố định tĩnh mọi biến môi trường, nên phải liệt kê tường minh các tham số bên ngoài và rà soát riêng xem thông tin nhạy cảm có bị lộ vào provenance hay không.
C. Tạo và lưu trữ provenance
Sau khi sản phẩm được tạo, nền tảng build tính digest của tệp kết quả và tạo provenance trong ranh giới tin cậy. Bằng chứng bao gồm các thông tin như định danh nền tảng build, vị trí và commit mã nguồn, định nghĩa build, danh sách đầu vào, subject kết quả và thời điểm tạo. Để có thể truy vấn bằng chứng quá khứ khi xảy ra sự cố chuỗi cung ứng, cũng cần xác định thời hạn lưu giữ, sao lưu, quyền truy cập và chính sách xóa của sản phẩm và provenance.
Kho bằng chứng có yêu cầu khác với kho log thông thường. Phải phát hiện được log có bị sửa đổi hay không, và phải quản lý khóa công khai·chuỗi chứng chỉ cần thiết cho việc kiểm chứng chữ ký. Nhóm bảo mật phải giám sát tỷ lệ tạo provenance thành công, tỷ lệ kiểm chứng thất bại, bất thường trong sử dụng khóa ký, builder ngoài dự kiến để phát hiện cả sự cố của chính biện pháp kiểm soát.
D. Kiểm chứng phía bên tiêu thụ và phán định chính sách
Bên kiểm chứng trước tiên so sánh digest sản phẩm với subject của provenance. Tiếp theo, xác nhận chữ ký provenance được tạo từ khóa hoặc danh tính tin cậy và đối tượng được ký không bị giả mạo. Sau đó lần lượt đánh giá kho mã nguồn·nhánh·commit, định danh builder, cấp build, đầu vào được phép và chính sách lỗ hổng.
Tách kết quả chính sách thành cho phép·chặn·phê duyệt thủ công sẽ phù hợp hơn cho vận hành. Ví dụ, triển khai vận hành bị chặn ngay nếu không phải kho và builder được phê duyệt, còn môi trường phát triển có thể cho phép kèm cảnh báo và phát hành ticket. Tuy nhiên, phải ghi lại thời gian hết hạn, người phê duyệt, rà soát sau sự kiện và phạm vi ảnh hưởng để ngoại lệ triển khai khẩn cấp không tự động biến thành cho phép vĩnh viễn.
E. Xử lý thất bại và phục hồi
Nếu vẫn lặng lẽ triển khai khi không có provenance hoặc kiểm chứng chữ ký thất bại, kiểm soát SLSA sẽ bị vô hiệu hóa. Policy engine phải trả về lý do thất bại kèm ID sản phẩm, quy tắc, bằng chứng đã xác nhận và hướng dẫn xử lý. Lập trình viên phải biết cần sửa trường nào, và nhóm bảo mật phải tổng hợp các thất bại lặp lại thành nhiệm vụ cải tiến pipeline.
Khi xác nhận khóa hoặc builder bị xâm phạm, chỉ đơn giản ký bằng khóa mới là không đủ. Phải định danh provenance và sản phẩm được tạo trong thời gian bị xâm phạm, truy vết ngược các phụ thuộc và môi trường triển khai bị ảnh hưởng, đồng thời thu hồi·thay thế danh sách cho phép·khóa·token. Provenance càng phong phú thì càng giúp thu hẹp phạm vi ảnh hưởng và quyết định đối tượng cần build lại.
5. So sánh và liên kết với các công nghệ liên quan
A. SLSA và SBOM
SBOM biểu diễn dưới dạng danh sách các thành phần, phiên bản và quan hệ có trong sản phẩm. Vì vậy nó mạnh ở việc xác nhận "bên trong có gì" và thực hiện phân tích tác động lỗ hổng·giấy phép. SLSA provenance giải thích "sản phẩm đó được tạo ra qua mã nguồn·phụ thuộc·nền tảng build nào". Hai thứ không thay thế nhau mà phải được liên kết cùng với một sản phẩm.
Ví dụ, dù SBOM ghi có openssl 3.x, điều đó không tự động chứng minh gói đó được lấy từ kho phê duyệt nội bộ, được tải từ URL bên ngoài khác, hay thực sự nằm trong digest image thực tế.
Ngược lại, dù provenance mô tả quá trình build tin cậy, nó không cung cấp thuận tiện danh sách thư viện có lỗ hổng bên trong sản phẩm.
SBOM được đặt cho phân tích thành phần, provenance cho kiểm chứng con đường tạo ra.
B. SLSA và NIST SSDF
NIST SSDF là khung quy trình tổng hợp các thực hành phát triển an toàn thành các hạng mục chuẩn bị·bảo vệ·sản xuất·ứng phó. SLSA tập trung vào các biện pháp kiểm soát cụ thể và định dạng bằng chứng để đo lường·chứng minh tính toàn vẹn của chuỗi cung ứng phần mềm và quá trình tạo sản phẩm trong số đó. Tổ chức có thể dùng SSDF để thiết lập chính sách·vai trò·quy trình xử lý lỗ hổng, và dùng SLSA provenance để để lại bằng chứng có thể kiểm chứng về build·phát hành.
Khi so sánh hai hệ thống, không được khẳng định cái này chứng nhận hay bao hàm hoàn toàn cái kia. Chỉ tuân thủ SSDF không bảo đảm provenance của sản phẩm không bị giả mạo, và chỉ SLSA L3 cũng không có nghĩa là mô hình hóa mối đe dọa·lập trình an toàn·xử lý lỗ hổng đã hoàn tất. Trong bài thi Kỹ sư chuyên nghiệp (Professional Engineer), nên trình bày quản trị quy trình và việc tạo bằng chứng kỹ thuật như quan hệ bổ trợ lẫn nhau.
| Phân loại | SLSA | SBOM | NIST SSDF |
|---|---|---|---|
| Câu hỏi trọng tâm | Được tạo ra như thế nào và có đáng tin không | Bên trong có gì | Có vận hành thực hành phát triển an toàn không |
| Sản phẩm tiêu biểu | provenance·attestation | Danh sách thành phần | Bằng chứng chính sách·thủ tục·thực hành |
| Điểm mạnh | Kiểm chứng đường build·chữ ký·tính toàn vẹn | Phân tích lỗ hổng·giấy phép·tác động | Quy trình tổ chức và vòng đời phát triển |
| Hạn chế | Không tự loại bỏ lỗ hổng của ứng dụng | Không tự mình bảo đảm con đường tạo ra và độ tin cậy chữ ký | Có thể thiếu bằng chứng build kiểm chứng được bằng máy |
| Liên kết | Gắn SBOM attestation vào digest sản phẩm | Kiểm chứng phía bên tiêu thụ cùng provenance | Dùng làm hệ thống cấp trên về vai trò·chính sách·đào tạo·ứng phó |
C. Chữ ký và provenance
Chữ ký số là phương tiện xác nhận tính toàn vẹn của dữ liệu và việc được phát hành bởi một khóa cụ thể. Tuy nhiên, nếu chủ thể giữ khóa ký đã ký lên tệp độc hại, hoặc bên kiểm chứng tin một khóa tùy ý, thì chữ ký không dẫn đến kết luận an toàn. Provenance chứa đầu vào build·nền tảng·kết quả bên trong tuyên bố được ký, và bên kiểm chứng đánh giá đồng thời danh tính người ký và sự phù hợp chính sách của nội dung.
Do đó, không nên diễn đạt "đã ký nên an toàn" mà phải là "tuyên bố rằng builder tin cậy đã tạo ra sản phẩm mong đợi với đầu vào được phép đã được kiểm chứng". Sự khác biệt này đặc biệt quan trọng trong quản lý chứng chỉ và thiết kế policy engine. Phải đưa việc thay·thu hồi khóa, hết hạn chứng chỉ, thay đổi tổ chức, thay đổi workflow builder vào các kịch bản vận hành.
6. Ví dụ áp dụng và hiệu quả kỳ vọng
A. Ví dụ dịch vụ thanh toán dựa trên container
Giả sử một tổ chức vận hành dịch vụ thanh toán triển khai container image hằng tuần.
Trước đây, họ build dựa trên Git tag và cụm vận hành kéo payment-api:latest, nhưng gặp vấn đề tag bị tái sử dụng và cùng một runner cũng chạy cho PR bên ngoài.
Tổ chức trước tiên xác lập đường cơ sở gồm nhánh phát hành được bảo vệ, CI trung tâm được phê duyệt, cố định digest image, tạo SBOM và ký provenance.
Khi build hoàn tất, digest image, commit mã nguồn, workflow builder, thông tin base image và phụ thuộc được liên kết với provenance và SBOM attestation. Chính sách triển khai kiểm tra người ký có phải builder phát hành của tổ chức không, mã nguồn có phải commit đã phê duyệt của nhánh được bảo vệ không, image có lỗ hổng nghiêm trọng không, và subject của provenance có trùng digest image thực tế không. Chỉ cần một điều kiện thất bại, triển khai vận hành bị chặn, còn ở môi trường phát triển sẽ tạo ticket phê duyệt.
Hiệu quả của thiết kế này không chỉ dừng ở việc ngăn chặn tấn công. Người điều tra sự cố có thể truy vết ngược commit mã nguồn và builder từ image vận hành, và có thể định danh hàng loạt sản phẩm trong thời gian một builder cụ thể bị xâm phạm. Ngoài ra, nhóm phát triển có thể xem chính sách thất bại và cách sửa ngay trong kết quả CI thay vì thủ tục mơ hồ "nhóm bảo mật kiểm tra thủ công".
B. Ví dụ đánh giá nhà cung cấp gói mã nguồn mở
Giả sử doanh nghiệp nhận gói từ đối tác bên ngoài và tích hợp vào sản phẩm nội bộ. Thay vì chỉ ghi nghĩa vụ thông báo lỗ hổng trong hợp đồng, nếu yêu cầu cung cấp digest gói·SBOM·provenance cho mỗi bản phát hành và công khai nền tảng build được phê duyệt cùng danh tính ký, khả năng kiểm chứng sẽ tăng lên. Tổ chức mua đưa bằng chứng do nhà cung cấp cung cấp vào policy engine nội bộ để đánh giá các điều kiện mã nguồn·builder·chữ ký·lỗ hổng.
Tuy nhiên, không được tin nguyên vẹn tuyên bố cấp độ khung của nhà cung cấp. Phải xác nhận cấp độ nào được áp dụng cho phạm vi sản phẩm nào, các ngoại lệ·bước thủ công·đầu vào bên ngoài là gì, và bằng chứng được lưu giữ từ khi nào. Mong muốn là bộ phận mua sắm·pháp chế·phát triển·bảo mật cùng đưa danh sách bằng chứng tối thiểu và thủ tục build lại·thông báo·thu hồi khi có sự cố vào hợp đồng.
7. Chuyên sâu: SLSA v1.2 và định hướng áp dụng mới nhất
Theo tài liệu chính thức của SLSA, v1.2 mô tả đồng thời các yêu cầu L0~L3 của Build track và Source track, đồng thời đưa ra các định dạng khuyến nghị như provenance·verification summary attestation. Trong thực tế, thay vì tổ chức tuyên bố con số cao, cần xác nhận yêu cầu của mỗi cấp giảm thiểu mối đe dọa nào và biện pháp kiểm soát tương ứng có quan sát được trong pipeline thực tế hay không.
Source track quan trọng ở chỗ xử lý niềm tin mã nguồn trước khi build như một vấn đề riêng. Dù build được cô lập hoàn toàn, nếu kẻ tấn công hợp nhất commit độc hại vào kho không được bảo vệ, builder tin cậy vẫn có thể build mã nguồn độc hại một cách bình thường. Ngược lại, dù kiểm soát thay đổi mã nguồn mạnh, nếu builder có thể dùng đầu vào bên ngoài tùy ý hoặc giả mạo provenance thì độ tin cậy của kết quả vẫn thiếu. Do đó, cần tách ba ranh giới thay đổi mã nguồn, build, triển khai và liên kết bằng chứng cho từng ranh giới.
Hướng áp dụng tiếp theo của SLSA là mở rộng sang thu thập phụ thuộc và bằng chứng môi trường build. Nếu để lại evidence trong provenance về việc phụ thuộc được tiếp nhận từ đâu và qua kiểm chứng nào, có thể chính sách hóa tính toàn vẹn của con đường ingestion vượt ra ngoài việc chỉ kiểm tra tên gói. Ngoài ra, việc đo lường·chứng thực dựa trên phần cứng và kiểm chứng trạng thái môi trường build đang được thảo luận, nhưng các yêu cầu ở giai đoạn dự thảo·thử nghiệm phải được áp dụng tách biệt với đặc tả ổn định đã được phê duyệt.
Trong bài thi Kỹ sư chuyên nghiệp (Professional Engineer), khi đề cập phiên bản mới nhất, nên ghi kèm ngày áp dụng và phiên bản tài liệu chính thức, và không nên diễn đạt tính năng dự thảo như nghĩa vụ đã được xác định. Lộ trình thực tế của tổ chức có thể được thiết kế theo thứ tự: lập danh mục sản phẩm phát hành → hiển thị hóa provenance L1 → tăng cường L2 bằng CI trung tâm·ký số → hướng tới L3 bằng cô lập·bảo vệ khóa·kiểm chứng chính sách → liên kết với Source·track phụ thuộc.
8. Các điểm cần lưu ý và hàm ý
A. Quản trị và trách nhiệm
Nếu chỉ giao trách nhiệm áp dụng SLSA cho nhóm bảo mật, nhóm phát triển có thể coi công cụ kiểm tra là kiểm soát từ bên ngoài và tìm cách lách. Phải tách trách nhiệm của chủ sở hữu mã nguồn, người vận hành nền tảng build, người phê duyệt phát hành và bên tiêu thụ triển khai theo RACI, đồng thời làm rõ chủ sở hữu bằng chứng ở mỗi bước. Dù nền tảng build phát hành provenance, trách nhiệm của nhóm phát triển chọn đầu vào và nhóm vận hành kiểm chứng trước triển khai không vì thế mà biến mất.
B. Cân bằng giữa bảo mật và năng suất phát triển
Nếu áp dụng mức cô lập cao nhất và phê duyệt thủ công cho mọi commit, tốc độ phát triển có thể giảm mạnh. Ngược lại, nếu chỉ để lại cảnh báo cho sản phẩm nguy hiểm, hiệu lực của kiểm soát sẽ yếu đi. Cần phân biệt cường độ chính sách giữa phát triển·staging·vận hành, và giảm vi phạm lặp lại bằng tự động sửa·template·builder tự phục vụ.
C. Quản lý khóa và danh tính
Khóa ký provenance là tài sản cốt lõi của chuỗi cung ứng, vì vậy phải tránh thiết kế phân phối khóa bí mật cố định dài hạn cho nhiều runner. Kết hợp danh tính ngắn hạn, hệ thống quản lý khóa, lưu giữ khóa bên ngoài, log kiểm toán ký và thủ tục thay·thu hồi khóa. Chính sách kiểm chứng nên được cấu hình để tin cậy mối quan hệ giữa danh tính tổ chức·workflow·builder và sản phẩm thay vì bản thân khóa, và phải phân tích tác động khi danh tính thay đổi.
D. Ngoại lệ và hệ thống cũ (legacy)
Có những trường hợp hệ thống build cũ hoặc nhà cung cấp bên ngoài không thể cung cấp provenance. Khi đó, thay vì cho phép ngoại lệ vĩnh viễn, ghi nhận các biện pháp kiểm soát bù tạm thời như kho cô lập, kiểm chứng thủ công, quét bổ sung, giới hạn phạm vi triển khai và kế hoạch build lại. Ngoại lệ phải có người chấp nhận rủi ro·căn cứ·ngày hết hạn·kiểm soát thay thế, và được tự động rà soát lại khi có bản phát hành mới hoặc gia hạn hợp đồng.
E. Đo lường và cải tiến liên tục
Nếu đo lường thành công chỉ bằng "số kho đạt cấp SLSA", có thể sa vào việc tạo bằng chứng mang tính hình thức. Cần xem xét đồng thời các chỉ số vận hành như tỷ lệ tạo provenance, tỷ lệ triển khai được kiểm chứng, thời gian trung bình giải quyết kiểm chứng thất bại, số lần phát hiện builder chưa phê duyệt, thời gian định danh sản phẩm bị ảnh hưởng khi xâm phạm. Phân loại thất bại chính sách là lỗi của lập trình viên hay khiếm khuyết của nền tảng, và phản ánh các thất bại lặp lại vào template pipeline và giá trị mặc định của nền tảng.
F. Chiến lược liên kết từ góc nhìn Kỹ sư chuyên nghiệp
SLSA được kết nối với SBOM·SCA·ký số·quản lý bí mật·CI/CD·container·Kubernetes admission control·SIEM. Nếu kiểm chứng provenance tại cổng triển khai, gửi sự kiện vi phạm đến SIEM và tính điểm rủi ro cùng với chính sách lỗ hổng·cấu hình·runtime, khả năng truy vết từ khi tạo ra đến vận hành sẽ tăng lên. Tuy nhiên, quan trọng hơn việc gắn thêm nhiều công cụ là tích hợp để bằng chứng thực sự được dùng vào quyết định chính sách, lấy ID sản phẩm và digest làm khóa chung.
9. Hướng ra đề dự kiến và chiến lược cấu trúc bài làm
Khi ra đề, có thể dùng nhiều cách diễn đạt như "phương án bảo mật chuỗi cung ứng phần mềm", "so sánh SLSA và SBOM", "bảo đảm tính toàn vẹn của pipeline CI/CD", "kiểm chứng triển khai dựa trên provenance". Bài làm sẽ triển khai ổn định nếu nêu vấn đề tin cậy chuỗi cung ứng ở phần định nghĩa và bối cảnh, và kết nối mã nguồn·đầu vào·builder·provenance·sản phẩm·bên kiểm chứng trong sơ đồ khái niệm.
Ở phần thân, sau khi giải thích Build/Source track và L0~L3, kết nối các kịch bản tấn công dependency confusion·chiếm đoạt CI·thay thế sản phẩm với biện pháp kiểm soát. Tiếp theo, nếu trình bày quy trình triển khai CI/CD, so sánh với SBOM·SSDF, và ví dụ container hoặc gói thì có thể tránh việc chỉ liệt kê thuật ngữ. Phần kết luận nêu các điểm cần lưu ý gồm áp dụng dựa trên rủi ro, khóa và danh tính, ngoại lệ, đo lường, tích hợp vận hành, và nhấn mạnh rằng phải có cả "tạo bằng chứng" lẫn "kiểm chứng phía bên tiêu thụ".
Tài liệu tham khảo
- Đặc tả chính thức SLSA v1.2: https://slsa.dev/spec/v1.2/
- Cơ bản và các cấp của SLSA Build track: https://slsa.dev/spec/v1.2/build-track-basics
- Yêu cầu về sản phẩm build của SLSA: https://slsa.dev/spec/v1.2/build-requirements
- Định dạng SLSA Provenance v1.0: https://slsa.dev/spec/v1.0/provenance
- in-toto Attestation Framework: https://github.com/in-toto/attestation
- NIST SP 800-218 SSDF v1.1: https://csrc.nist.gov/pubs/sp/800/218/final
- Dự thảo công khai ban đầu NIST SP 800-218 Rev.1 SSDF v1.2: https://csrc.nist.gov/pubs/sp/800/218/r1/ipd
Tóm tắt một câu: SLSA là khung bảo mật chuỗi cung ứng chứng minh con đường tạo ra phần mềm — điều mà chỉ SBOM không thấy được — bằng provenance và các kiểm soát build·mã nguồn theo cấp độ, đồng thời giúp bên tiêu thụ kiểm chứng chính sách digest·chữ ký·đầu vào·builder để chỉ triển khai các sản phẩm đáng tin cậy.