Live on Azure · Cosign-signed · WORM-archived

DevSecOps Pipeline: A Live Case Study

This application was built, scanned, signed, deployed, and tested by a 6-phase compliance-enabling CI/CD pipeline. Every commit triggers automated security checks across ten tools. Every release produces tamper-evident audit evidence mapped to DORA, NIS2, ISO 27001, SOC 2, and GDPR.

What you see below is not theory. It is the production pipeline that delivered this very webpage — documented in detail, end to end. Click anything to explore.

→ phases
0
Pipeline Phases
→ tools
0
Security Tools
→ frameworks
0
Frameworks
→ evidence
0
Evidence Artifacts
0
Static Secrets
01 — Executive Summary

What This Pipeline Is, And Why It Exists

CyberForge built this pipeline as a working reference implementation of a compliance-enabling secure software supply chain.

The pipeline takes a Node.js application and runs it through six sequential phases. Each phase produces machine-readable evidence.

The pipeline is designed for three audiences:

The implementation uses GitHub Actions, Azure, and ten open-source security tools. Total monthly cost: ~$18–23 USD. Total static secrets: zero.

Why This Page

Proof, Not Promises

The case for hardened CI/CD — DORA, NIS2, supply-chain attacks, blocked enterprise deals — is made on cyberforge.agency. This page is the technical proof underneath: a real pipeline you can inspect, signatures you can verify, evidence packs you can download.

The CyberForge thesis: Compliance evidence should be a byproduct of how you ship software, not a separate annual exercise.
03 — Architecture Overview

Six Phases, One Trust Boundary

The pipeline implements a zero-trust supply chain. Click any phase below to see what happens inside it.

1 Security Gate ~1m 2 Build & Scan ~4m 3 Sign & Attest ~45s 4 Deploy ~2m 5 DAST ~90s 6 Evidence ~30s WORM 5-yr archive git push main TRUST BOUNDARY: every artifact verified before next phase trusts it
Click any phase above
Hover or click a phase circle to see what happens inside it. Each phase produces machine-readable evidence consumed by Phase 6.
04 — Pipeline Phases

Inside Each Phase

Click any tool card to expand its full description, configuration, and gate behaviour.

Phase 1 — Security Gate

Phase 2 — Build & Scan

Phase 3 — Sign & Attest

Phase 4 — Deploy

Phase 5 — DAST

Phase 6 — Evidence Pack

05 — OIDC Federation

From GitHub to Azure Without a Static Secret

Traditional CI/CD stores a long-lived service principal secret. OIDC eliminates it.

GitHub Actions Workflow runner id-token: write Azure AD Federated Credential sub=repo:.../env:staging Azure Resources ACR · Container Apps Storage · Key Vault 1. OIDC token JWT with sub claim 2. AAD access token 3. ARM API call terraform / az cli Trust is established once. Tokens are minted per workflow run. No secret stored anywhere. No rotation needed. Token TTL: 5 minutes. 4 federated credential subjects: • repo:CyberForge-Agency/DevSecOps-Pipeline:ref:refs/heads/main • repo:CyberForge-Agency/DevSecOps-Pipeline:environment:staging • repo:CyberForge-Agency/DevSecOps-Pipeline:environment:production • repo:CyberForge-Agency/DevSecOps-Pipeline:pull_request
Common gotcha: The pull_request subject uses an underscore, not a hyphen.
06 — Compliance Matrix

Click a Framework to See the Mapping

0% coverage

Pipeline Coverage

  • Automated controls (pipeline-generated evidence)
  • Configured controls (one-time setup)
  • Organizational controls (require human execution)
DORA
4/4
Articles
NIS2
4/4
Articles
ISO 27001
4/4
Annex A
SOC 2
4/4
TSC
GDPR
5/5
Articles

DORA — Digital Operational Resilience Act

ArticleRequirementPipeline Coverage
Art. 16.1.aDocumented ICT risk management frameworkOPA policies, risk register, security gates, evidence pack
Art. 16.1.cSystem-update and patching proceduresTrivy SCA, Renovate config, vulnerability management policy
Art. 16.1.dAnomaly detectionAzure Monitor alerts, DAST auto-incident workflow
Art. 28ICT third-party / supply-chain riskSBOM, Cosign signing, SLSA provenance, vendor risk register

NIS2 — Network and Information Security 2

ArticleRequirementPipeline Coverage
Art. 21.2.bIncident handlingIncident runbook, ICT issue template, DAST auto-incident with SLAs
Art. 21.2.dSupply chain securitySBOM, signed image attestations, provenance, dependency scanning
Art. 21.2.eSecure SDLC and acquisitionAll Phase 1+2 controls — SAST, SCA, container scanning, mandatory code review
Art. 21.2.hCryptography policiesCosign keyless signing, OIDC federation, TLS 1.2 minimum

ISO/IEC 27001:2022 — Annex A

ControlTitlePipeline Evidence
A.8.4Access to source codeBranch protection, CODEOWNERS, signed commits, SHA256 manifest
A.8.9Configuration managementTerraform IaC, all infrastructure versioned, change tracked via PRs
A.8.25Secure development life cyclePhases 1–6, OPA policies, security gates, mandatory test coverage
A.8.28Secure codingCodeQL semantic analysis, MegaLinter, ZAP runtime testing

SOC 2 — Trust Services Criteria

CriterionDescriptionPipeline Evidence
CC6.1Logical access controlsOIDC federation, branch protection, GitHub environment approvals, RBAC
CC7.1System monitoringLog Analytics, Azure Monitor alerts, DAST findings, OPA evidence-completeness
CC8.1Change managementGit PRs, signed commits, branch protection 2 approvals, Terraform plans archived
PI1.1Processing integrityCosign signatures verifiable post-deploy, SHA256 manifest, OPA deployment-gate

GDPR / RODO

ArticleRequirementPipeline Evidence
Art. 5.1.cData minimisationPII scanner blocks PESEL/phone/email; logs sanitised before archival
Art. 5.1.eStorage limitationLifecycle deletes evidence after retention; deletion-schedule OPA policy
Art. 25Data protection by designPII scanner, data-flow diagram, sanitisation, secure infra by default
Art. 28Processor / sub-processorDPA compliance check tracking nine processors with status
Art. 30Records of processingData flow diagram, evidence pack metadata, vendor risk register
07 — Interactive API Demo

Try The Live API

The buttons below make real HTTP calls. First request after idle takes 30–60s (cold start).

Health Endpoint

Checking...

Items API

Checking...

Container Image

Cosign-signed via GitHub OIDC + Sigstore Fulcio

Authentication

Zero static secrets — OIDC federated

GET /api/items

// click to fetch

POST /api/items

// click POST to create
08 — Verify This Deployment

Don't Trust. Verify.

Everything above is just words. Below is the verifiable proof. The image digest, signing certificate, and Rekor entry are all public — anyone can independently confirm this deployment came from the pipeline described above.

Why this matters: Values below are fetched live from /api/build-info. They were baked in at Docker build time and injected at deploy time. The container cannot lie about its own digest.

Live Build Metadata

Image Digest

loading...

Image URI

loading...

Git Commit

loading...

Build Time

loading...

GitHub Actions Run

loading...

Rekor Transparency Log

loading...

Verify Yourself (Cosign)

Copy and run this exact command in a terminal with cosign installed. It validates the signature against the certificate identity and confirms the image at that digest was signed by this exact pipeline.

copyloading...

Fetch the SBOM

The SBOM is attached to the image as a signed Sigstore attestation. To download:

copyloading...

Public Audit Trail

These three links lead to permanent, publicly auditable records:

1. Source Commit

The exact commit that triggered this build.

View commit

2. Workflow Run

Full GitHub Actions log (private repo — invite needed).

View run

3. Rekor Log

Permanent Sigstore log — public regardless of repo visibility.

Search Rekor

What This Proves

09 — Auditor View

What This Proves to Auditors

If a SOC 2 Type I auditor or ISO 27001 certifier asked for evidence today:

1. End-to-end traceability

Pipeline-run.json contains commit SHA, author, timestamp, image digest, and gate results — combined with GitHub PR history, that's an unbroken chain from human to running container.

2. Cryptographic chain of custody

cosign-verification.log proves the signature is valid; certificate identity ties it to this repo at this commit; Rekor transparency log makes it publicly auditable.

3. Tamper-evident archive

SHA256 manifest + WORM Blob storage = no one (including Azure subscription owners) can modify the archive within 1825 days.

4. Automated, not aspirational

Every push to main produces a new evidence pack. The list of packs IS the release audit trail.

5. Regulatory mapping

compliance-matrix.json maps every artifact to specific articles. Generated automatically; auditable in source.

The honest caveat: Pipeline does technical controls. Organisational controls (management review, access reviews, training records) are templated but require human execution.