DevSecOps

DevSecOps extends the DevOps practice of integrating development and operations by adding security as a core, automated component of the development pipeline. In a DevSecOps model, security testing (SAST, DAST, SCA), security configuration validation, and secret scanning are all automated and run on every code commit or build — security is 'shifted left' into the development process rather than being a separate audit gate. The goal is to detect security issues early, when they are cheapest to fix, and to prevent known vulnerability classes from ever reaching production. For manufacturers of CRA-covered products, DevSecOps provides the technical infrastructure to operationalise the SDLC obligations required by Annex I without creating bottlenecks in release velocity.

A CRA-aligned DevSecOps pipeline should incorporate the following automated security controls:

• SAST (Static Application Security Testing): Analyses source code and binaries for known vulnerability patterns (CWE instances). Tools: Semgrep, CodeQL, Coverity, SonarQube.
• SCA (Software Composition Analysis): Identifies known CVEs in third-party dependencies and generates the SBOM. Tools: Dependency-Track, Snyk, FOSSA, Syft.
• Secret scanning: Detects hardcoded credentials, API keys, and cryptographic material committed to source code. Tools: Gitleaks, Trufflehog, GitHub Advanced Security.
• DAST (Dynamic Application Security Testing): Tests running applications for exploitable vulnerabilities through automated attack simulation. Tools: OWASP ZAP, Burp Suite (automated).
• Container scanning: Analyses container images for OS and application vulnerabilities. Tools: Trivy, Grype, Snyk Container.
• Infrastructure-as-code scanning: Detects misconfiguration in deployment infrastructure. Tools: Checkov, tfsec.

A practical DevSecOps architecture for a CRA-covered product manufacturer typically stages security controls through the pipeline:

Pre-commit (developer workstation): IDE plugins for SAST linting; secret scanning on git commit hooks.

CI pipeline (on every pull request): SAST scan of changed code; SCA scan with SBOM update; secret scanning; unit tests including security-relevant cases.

Build pipeline (on merge to main): Full SCA scan; container scanning; SBOM generation and signing; policy gate (fail build on new Critical findings without approved exception).

Release pipeline (on release candidate): DAST scan of integration environment; firmware binary analysis; SBOM publishing to Dependency-Track; security sign-off checkpoint.

Post-release monitoring: Dependency-Track continuous CVE monitoring; EPSS score monitoring for SBOM components; alert to PSIRT on new Critical findings.

DevSecOps is as much a cultural shift as a tooling change. The core principle is that security is everyone's responsibility — developers own the security of the code they write; security engineers provide tooling, guidance, and triage support; operations teams are responsible for secure deployment and monitoring. For CRA manufacturers, this means:

• Security training for all developers, not just a dedicated security team.
• Security champions in each development team who are the primary contact for security questions.
• Published secure coding guidelines specific to the technology stack.
• Blameless security retrospectives that treat security findings as learning opportunities.
• Metrics that track security debt (number of open vulnerabilities by severity) alongside feature velocity.

CRA compliance requires documentation that security was addressed throughout development. DevSecOps provides the pipeline artifacts — scan reports, SBOM records, policy gate outcomes — that constitute this evidence.