devsecops-os

Ai gặp khó, và công cụ giải quyết ra sao

CISO và đội platform trong các tổ chức chịu quản lý gặp khó ở ba điểm: (1) mỗi đội tự ráp pipeline bảo mật theo một cách khác nhau, nên không có lối đi chuẩn nào mà cứ đi theo là đạt được các control; (2) chính sách tuân thủ nằm trong tài liệu Word/PDF và được dịch bằng tay thành cấu hình vào lúc kiểm toán, trong khi bằng chứng phải thu thập thủ công từ khắp nơi; (3) kết quả quét từ các nhà cung cấp thương mại (Harness, GitHub Advanced Security, Snyk…) nằm trong hệ thống đóng của từng nhà cung cấp — lớp quản trị xuyên suốt và lớp bằng chứng cho một khung quản lý cụ thể vẫn phải tự xây trong nhà.

Hệ thống này xây đúng phần còn thiếu đó: policy-as-code nằm trong chính repo của tổ chức (không có server bên thứ ba nào giữ dữ liệu), cổng CI chặn tại các điểm đã căn chỉnh, và bằng chứng kiểm toán được tạo tự động từ chính các lần chạy pipeline — pipeline không chỉ chặn lỗi mà còn chứng minh được rằng nó đã chặn.

Công cụ làm gì

• Cổng policy-as-code: gói policy đang chạy gồm 14 policy (harness 34/34), với cùng một ý định control được biên dịch xuống cổng OPA/Rego, Kyverno và GitHub Actions — policy ở trung tâm, thực thi ở nhiều điểm.
• 10 cổng bảo mật CI dưới dạng workflow tái sử dụng kèm script local, đã chạy thật trên workload mẫu.
• Bằng chứng kiểm toán tự động: bộ thu thập và đóng gói bằng chứng với manifest SHA-256 và một lệnh kiểm chứng duy nhất. Gói bằng chứng của mỗi lần chạy CI được ký keyless bằng Cosign qua OIDC và tự kiểm chứng ngay trong job.
• Golden path: template dịch vụ (api-service) đã được dùng thử nội bộ (dogfood) để xây một dịch vụ thứ hai.
• Demo: bản ghi terminal thô từ một lần chạy thật — bộ cổng chạy trên cả hai biến thể của workload mẫu, một lần kiểm chứng gói bằng chứng, và một lần sửa 1 byte khiến kiểm chứng FAIL — không dàn dựng. Bản ghi và bản transcript nằm trong repo tại release/demo/.

Nguyên tắc thiết kế: trung lập nhà cung cấp về cấu trúc (scanner và connector dùng định dạng mở — SARIF, CycloneDX/SPDX, Sigstore, SLSA — nên đổi công cụ quét không được phép làm hỏng policy hay bằng chứng); identity-first (không có credential tĩnh dài hạn trong pipeline; con người qua SSO/OIDC, workload qua liên kết OIDC để lấy token ngắn hạn, artefact được ký bằng Cosign kèm provenance SLSA); bằng chứng là sản phẩm phụ tự động của vận hành, không phải việc làm thêm vào lúc kiểm toán; không dữ liệu nào rời khỏi hạ tầng của người dùng (mọi thành phần chạy trong chính CI, runner và cluster của tổ chức).

Ánh xạ khung control

Gói policy được giao kèm ánh xạ sẵn tới các khung control dưới đây. Đây là ánh xạ tham chiếu để hỗ trợ chuẩn bị kiểm toán — không phải chứng nhận tuân thủ.

Không dùng repo này để tuyên bố tuân thủ bất kỳ khung control nào: các ánh xạ là ánh xạ tham chiếu cho việc chuẩn bị kiểm toán, không phải chứng nhận tuân thủ.

Tích hợp

devsecops-os tích hợp với các nền tảng mà tổ chức đã chạy — GitHub, GitLab, Harness — thay vì thay thế chúng, và nó không phải thêm một scanner nữa. Giai đoạn 1 triển khai GitHub Actions; các điểm tích hợp GitLab và Jenkins/on-prem đã được thiết kế, chưa triển khai.

Bố cục repo: docs/ (kiến trúc tham chiếu và hướng dẫn, gồm golden path); examples/payments-sample/ (workload mẫu hai biến thể, sạch / lỗi cố tình, để kiểm chứng các cổng); examples/checkout-sample/ (dịch vụ thứ hai, xây từ golden path); policies/ (gói policy ánh xạ tới khung control); gates/ (10 cổng bảo mật CI); evidence/ (bộ thu thập và đóng gói bằng chứng); templates/ (template dịch vụ golden-path); release/ (hồ sơ phát hành, ghi nhận dogfood, demo, nội dung landing).

Dùng thử ngay (local — đúng script mà CI gọi)

# 1) Fetch the pinned toolset (versions + SHA-256 pinned)
bash gates/local/fetch_tools.sh            # TOOLS_DIR default: ~/workspace/tools

# 2) Run the full verification on both sample-workload variants
bash gates/verification/run_verification.sh all
#    -> result matrix: gates/verification/results.md

# 3) Collect + verify one run's evidence bundle (one verify command)
python3 evidence/bundle_tool.py collect evidence/output/local-clean \
    --run-id local-clean --out-dir evidence/bundles/local-clean

python3 evidence/verify_bundle.py evidence/bundles/local-clean

Lệnh chép đúng nguyên văn từ README của devsecops-os (mục “Try it now”). Không có lệnh cài đặt qua package manager vì README không đưa lệnh nào: công cụ chạy từ một bản checkout của repo với các script local trên. Kết quả kỳ vọng (đã kiểm chứng ở mốc M3–M5): biến thể clean qua cả 10 cổng; biến thể planted bị chặn đúng tại cổng 1 (secret), cổng 4 (IaC — security group mở ra Internet), cổng 5 (base image hết vòng đời) và cổng 8 (dependency nằm trong CISA KEV), và không bị chặn tại cổng nào khác.

Workload mẫu: examples/payments-sample/ là ứng dụng payments tối giản (backend API Python/Starlette, frontend tĩnh, Terraform cho AWS, Dockerfile, manifest Kubernetes) với hai biến thể song song: clean/ (cấu hình đúng; kỳ vọng qua mọi cổng) và planted/ (đúng 4 lỗi cố tình — secret giả, dependency mang CVE-2026-48710 từ CISA KEV, security group mở ra 0.0.0.0/0, base image cũ đóng băng từ 2022). Mỗi lỗi và cổng kỳ vọng của nó nằm trong examples/payments-sample/planted/PLANTED.md.

Số liệu đã đo (README, GitHub Actions thật)

• Trạng thái giai đoạn 1: các mốc M1–M5 đã hoàn thành — gói policy đang chạy (14 policy, harness 34/34), 10 cổng CI chạy thật trên workload mẫu với ma trận kết quả đầy đủ.
• Workflow master trên nhánh main của repo này: chạy 3 lần — 54, 66 và 58 giây, trung vị 58 giây (giới hạn chấp nhận: 15 phút).
• Biến thể lỗi cố tình: bị chặn đúng tại các cổng 1, 4, 5 và 8 trên CI; biến thể sạch qua tất cả.
• Golden path: xây một dịch vụ từ template và CI của nó xanh ngay lần chạy đầu tiên, tổng cộng 5 phút 42 giây cho build + CI (giới hạn: 30 phút).
• Kiểm chứng bằng chứng cả hai chiều: gói được đóng và kiểm chứng bằng một lệnh duy nhất — sửa 1 byte → kiểm chứng FAIL.
• Truy vết bằng chứng: bao phủ 13 trên 14 hàng ánh xạ control của giai đoạn 1; hàng còn lại một phần thuộc về cổng 10, vốn tắt theo thiết kế trong giai đoạn 1.
• Gói bằng chứng của mỗi lần chạy CI: được ký keyless bằng Cosign qua OIDC và tự kiểm chứng ngay trong job.

Hồ sơ phát hành đầy đủ: release/RELEASE-DOSSIER.md trong repo.

Đây KHÔNG phải gì — và đối thủ hơn chúng ta ở đâu

• Các nền tảng thương mại (Harness, GitHub Advanced Security, Snyk) vượt xa hệ thống này về độ sâu quét, hỗ trợ doanh nghiệp và chứng nhận riêng của nhà cung cấp; hệ thống này không tuyên bố thay thế chúng.
• Điểm mạnh riêng của nó là lớp mà các nền tảng đó để lại cho bạn: quản trị và bằng chứng kiểm toán có thể kiểm chứng, trong chính hạ tầng của bạn, trên các công cụ bạn đã chạy.
• Nó không phải thêm một scanner: nó tích hợp với các nền tảng tổ chức đã chạy thay vì thay thế chúng.

Source + README trên GitHub → · Báo lỗi → · ask@techdev.fun

Giới hạn

• Dự án này không tuyên bố được tổ chức nào sử dụng, chứng thực hay chứng nhận — nó là bản thiết kế kèm bản triển khai tham chiếu đang chạy, đã kiểm chứng trên workload mẫu.
• Các ánh xạ khung control là ánh xạ tham chiếu cho việc chuẩn bị kiểm toán, không phải chứng nhận tuân thủ.
• Các điểm tích hợp GitLab và Jenkins/on-prem đã được thiết kế, chưa triển khai trong giai đoạn 1.
• Cổng 10 tắt theo thiết kế trong giai đoạn 1, nên truy vết bằng chứng chỉ bao phủ 13 trên 14 hàng ánh xạ control của giai đoạn 1.
• AI PR Review Gate (flagship #1 của factory) là cổng tùy chọn, tắt theo mặc định trong giai đoạn 1, và chỉ được bật khi flagship #1 qua cổng phát hành riêng của chính nó.

Giấy phép

MIT — xem LICENSE trong repo.

Công cụ liên quan

Các công cụ mã nguồn mở khác của TECHDEV: sessguard, runverdict, gheist-guard, vetgate, context-diet, ci-failure-detective, agent-seatbelt, env-doctor, skill-audit, logtrim, testguard, breakcheck, keymap, memgraph, ggufit, leaseguard, factfence, jsonfold

Đóng góp ý kiến

Bình chọn cho công cụ này, đề xuất tính năng, hoặc thảo luận với các vận hành khác trên bảng cộng đồng.