Your scanners pass. Your audit evidence doesn't exist. We built the missing layer.

Description and use

A regulated team uses a CI pipeline with the open‑source devsecops‑os layer to generate a signed evidence bundle that proves security controls ran and no vulnerabilities were found. The bundle is stored in the repo and can be verified by auditors.

Problem

Auditors need verifiable evidence that security controls ran on a specific commit, but teams spend weeks assembling screenshots from scanners.

Outcome

In a sample workload with four planted faults, the pipeline blocked at gates 1, 4, 5, and 8 exactly as expected; clean code passed all 10 gates. Evidence bundles covered 13 of 14 control‑mapping rows and were verified in‑job. Median CI run time was 58 s, with a golden path of 5 min 42 s.

Workflow

• 1. Define policy pack v1 with 14 policies and evidence schemas mapping to ISO 27001, NIST CSF, PCI DSS, APRA CPS 234, SOC 2.
• 2. Add 10 CI gates as reusable GitHub Actions workflows that invoke shell scripts identical to local runs.
• 3. Run the pipeline on a commit; gates block on planted faults or allow clean code.
• 4. Evidence collector harvests run records, validates against schemas, writes SHA‑256 manifest, and creates a bundle.
• 5. Bundle is keyless‑signed with Cosign via OIDC and verified in‑job.
• 6. Auditors retrieve the bundle and verify signatures and hashes to confirm evidence integrity.

Evidence

The sample workload ships in two variants that differ in exactly 4 planted faults. Measured with pinned tool versions, locally and on GitHub Actions:

Source

The clean variant passes all 10 gates. Gate 3 (SCA) independently reports 9 CVEs in the planted dependency set, including the KEV one — detection and blocking are separate, deliberate layers.

Source

Each CI run's evidence bundle was keyless‑signed via Cosign/OIDC and the signature verified in‑job.

Source

The evidence bundle for a run covers 13 of 14 phase‑1 control‑mapping rows with real, schema‑checked records.

Source