Case study · CRA & DevSecOps
CRA readiness, delivered as code
A division of a global industrial engineering group needed to know where its software platform stood against the EU Cyber Resilience Act — and to close the gap with engineering, not paperwork. I baselined security maturity with OWASP SAMM, mapped the results to the CRA's deadlines, and turned the organisation's own written standards into automated policy-as-code checks. The first automated sweep surfaced 23 live infrastructure breaches that manual review had missed; every one now fails a pipeline instead of waiting for an audit.
- —OWASP SAMM gave a scored security-maturity baseline across all fifteen practices, sequenced against the CRA's Sep 2026 and Dec 2027 deadlines.
- —The organisation's written cloud-security standards were translated into six automated policy-as-code controls running in CI.
- —The first automated sweep found 23 live infrastructure-as-code breaches that manual review had missed.
- —Compliance evidence is now generated by the pipeline as a by-product of delivery — audit-ready without audit panic.
The challenge
The client — a division of a global industrial engineering group, name withheld — ships software that will fall within scope of the EU Cyber Resilience Act. The Act's vulnerability-reporting obligations begin in September 2026 and its full obligations in December 2027, and the division needed two things: an honest picture of where it stood, and a way to close the gap that would survive contact with real delivery pressure. It had written security standards; what it did not have was any automated way of knowing whether the estate actually met them.
The approach
I ran the engagement as engineering, not audit:
- A scored OWASP SAMM baseline across all fifteen software-assurance practices — an evidence-based maturity picture rather than a self-assessment.
- A CRA gap map sequencing the SAMM findings against the Act's essential requirements and its two deadlines, so effort went where the regulation bites first.
- Standards turned into code. Six of the organisation's own written cloud-security policies were translated into automated policy-as-code checks (Rego), evaluated against infrastructure definitions in CI.
- Supply-chain and pipeline hardening — dependency and secret-push protection on the source platform, and a shift-left linter chain in the pipeline with the existing code-quality platform kept as the backstop rather than the only gate.
The results
- 23 live breaches surfaced immediately. The first automated sweep of existing infrastructure code found twenty-three violations of the organisation's own standards that manual review had missed — each now visible, owned and being remediated.
- Standards that enforce themselves. New infrastructure cannot merge in breach of the six codified policies; the document-versus-reality gap stops growing.
- A sequenced CRA roadmap with maturity targets tied to the September 2026 and December 2027 deadlines, owned by the engineering team rather than a compliance function.
- Evidence as a by-product. Every pipeline run generates the compliance evidence the CRA's accountability requirements expect — no year-end evidence hunt.
Why it matters
Regulation-readiness bought as paperwork decays the day the consultant leaves. Built as code, it compounds: every commit is checked, every breach is caught at the cheapest possible moment, and the audit trail writes itself. That is the difference between complying once and being compliant continuously.
Client identity withheld under confidentiality. Related services: CRA compliance & DevSecOps consulting, Azure governance & compliance and Azure DevOps & platform engineering.
Asked and answered.
How do you prepare for CRA compliance?+
Baseline where you actually stand — an OWASP SAMM assessment works well — then map the gaps to the CRA's essential requirements and deadlines, and close them with engineering controls: policy-as-code in CI, SBOMs, secure pipelines and a vulnerability-handling process. Evidence should fall out of the pipeline automatically.
What is a policy-as-code control?+
A written standard turned into an executable check — for example, a rule that flags any infrastructure definition with a public endpoint or missing encryption, evaluated automatically on every change. The standard stops being a document people should read and becomes a gate code cannot pass without meeting.
What did the automated sweep find that manual review missed?+
Twenty-three live breaches of the organisation's own cloud standards in existing infrastructure code — the kind of drift that accumulates invisibly when standards live in documents. Automation made them visible in minutes and keeps them from returning.