devsecops-os

Who hurts, and what this does about it

CISOs and platform teams in regulated organisations hurt in three places: (1) every team assembles its security pipeline differently, so there is no standard path that reaches the controls just by being followed; (2) compliance policy lives in Word/PDF documents and is translated by hand into configuration at audit time, while evidence is gathered manually from everywhere; (3) scanner results from commercial vendors (Harness, GitHub Advanced Security, Snyk…) live inside each vendor's closed system — the cross-cutting governance and evidence layer for a specific regulatory framework still has to be built in-house.

This system builds exactly that missing part: policy-as-code that lives in the organisation's own repositories (no third-party server holds the data), CI gates that block at calibrated points, and audit evidence generated automatically from the pipeline runs themselves — the pipeline does not only block faults, it proves that it did.

What it does

• Policy-as-code gates: a working policy pack of 14 policies (harness 34/34), with the same control intent compiled down to OPA/Rego, Kyverno and GitHub Actions gates — policy at the centre, enforcement at many points.
• 10 CI security gates as reusable workflows plus local scripts, run for real on a sample workload.
• Automated audit evidence: an evidence collector and bundle with a SHA-256 manifest and one-command verification. Each CI run's evidence bundle is signed keyless with Cosign via OIDC and verifies itself inside the job.
• Golden path: service templates (api-service) that have been dogfooded to build a second service.
• Demo: a raw terminal capture from a real run — the gate suite running on both variants of the sample workload, an evidence-bundle verification, and a 1-byte edit that makes verification FAIL — nothing staged. The recording and text transcript are in the repository under release/demo/.

Design principles: vendor-neutral by structure (scanners and connectors speak open formats — SARIF, CycloneDX/SPDX, Sigstore, SLSA — so swapping a scanning tool must not break policy or evidence); identity-first (no long-lived static credentials in the pipeline; people through SSO/OIDC, workloads through OIDC federation for short-lived tokens, artefacts signed with Cosign and SLSA provenance); evidence as an automatic by-product of operations, not extra work at audit time; no data leaves the user's infrastructure (every component runs in the organisation's own CI, runners and clusters).

Control framework mappings

The policy pack ships pre-mapped to the control frameworks below. These are reference mappings to support audit preparation — not a compliance certification.

Do not use this repository to claim compliance with any control framework: the mappings are reference mappings for audit preparation, not a compliance certification.

Integrations

devsecops-os integrates with the platforms an organisation already runs — GitHub, GitLab, Harness — instead of replacing them, and it is not one more scanner. Phase 1 implements GitHub Actions; the GitLab and Jenkins/on-prem integration points are designed, not yet implemented.

Repository layout: docs/ (reference architecture and guides, including golden paths); examples/payments-sample/ (sample workload in two variants, clean / planted faults, for verifying the gates); examples/checkout-sample/ (second service, built from the golden path); policies/ (policy packs mapped to control frameworks); gates/ (the 10 CI security gates); evidence/ (evidence collector and bundle); templates/ (golden-path service templates); release/ (release dossier, dogfood record, demo, landing content).

Try it now (locally — the same scripts CI calls)

# 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

Commands copied exactly from the devsecops-os README (“Try it now”). No package-manager install command is shown because the README gives none: it is run from a checkout of the repository with the local scripts above. Expected result (verified at milestones M3–M5): the clean variant passes all 10 gates; the planted variant is blocked at exactly gate 1 (secret), gate 4 (IaC — security group open to the Internet), gate 5 (end-of-life base image) and gate 8 (dependency in CISA KEV), and is not blocked at any other gate.

Sample workload: examples/payments-sample/ is a minimal payments application (Python/Starlette API backend, static frontend, Terraform for AWS, Dockerfile, Kubernetes manifests) in two parallel variants: clean/ (correctly configured; expected to pass every gate) and planted/ (exactly 4 deliberate faults planted — fake secret, dependency carrying CVE-2026-48710 from CISA KEV, security group open to 0.0.0.0/0, old base image frozen since 2022). Each fault and its expected gate are listed in examples/payments-sample/planted/PLANTED.md.

Measured numbers (README, real GitHub Actions)

• Phase 1 status: milestones M1–M5 complete — a working policy pack (14 policies, harness 34/34), 10 CI gates run for real on a sample workload with a full result matrix.
• Master workflow on this repository's main branch: ran 3 times — 54, 66 and 58 seconds, median 58 seconds (acceptance limit: 15 minutes).
• Planted-fault variant: blocked at exactly gates 1, 4, 5 and 8 on CI; the clean variant passes everything.
• Golden path: built a service from the template and its CI was green on the first run, 5 minutes 42 seconds total for build + CI (limit: 30 minutes).
• Evidence verification in both directions: bundles packaged and verified with a single command — edit 1 byte → verification FAILS.
• Evidence traceability: covers 13 of 14 phase-1 control-mapping rows; the one partial row belongs to gate 10, which is off by design in phase 1.
• Evidence bundle of each CI run: signed keyless with Cosign via OIDC and verifies itself inside the job.

Full release dossier: release/RELEASE-DOSSIER.md in the repository.

What this is NOT — and where rivals beat us

• Commercial platforms (Harness, GitHub Advanced Security, Snyk) are far ahead of this system in scanning depth, enterprise support and the vendors' own certifications; this system does not claim to replace them.
• Its wedge is the layer those platforms leave to you: governance and verifiable audit evidence, in your own infrastructure, across the tools you already run.
• It is not one more scanner: it integrates with the platforms an organisation already runs instead of replacing them.

Source + README on GitHub → · Report an issue → · ask@techdev.fun

Limits

• This project makes no claim to be used by, endorsed by, or certified for any organisation — it is a blueprint plus a working reference implementation, verified on a sample workload.
• The control-framework mappings are reference mappings for audit preparation, not a compliance certification.
• GitLab and Jenkins/on-prem integration points are designed, not yet implemented in phase 1.
• Gate 10 is off by design in phase 1, which is why evidence traceability covers 13 of 14 phase-1 control-mapping rows.
• The AI PR Review Gate (the factory's flagship #1) is an optional gate, off by default in phase 1, and is only enabled once flagship #1 passes its own separate release gate.

License

MIT — see LICENSE in the repository.

Related tools

More open-source tools from 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

Have a say

Vote for this tool, suggest a feature, or discuss it with other operators on the community board.