DEVSECOPS AND SECURE SDLC

What DevSecOps is, and why the CRA requires it without naming it

DevSecOps is neither a tool nor a role. It is a way of organising work in which security checks are part of the same delivery process as build and deployment: they run automatically, they run on every change, and their result has an owner who does something about it. The alternative is the model most companies are used to — security as a one-off gate before release, usually a penetration test and a report that development receives a week before the deadline.

The word DevSecOps appears nowhere in the Cyber Resilience Act (CRA), Regulation (EU) 2024/2847. The regulation is technology-neutral and prescribes no particular tool. What it does prescribe are activities that have to be repeated, and that is precisely the part a single pre-release check cannot cover.

This is clearest in the cybersecurity risk assessment. Under Art. 13(2) the manufacturer carries it out and takes its outcome into account in the planning, design, development, production, delivery and maintenance phases of the product; under Art. 13(3) it is documented and updated throughout the support period. A document written a week before an inspection will not evidence that — it has to be visible that it grew over time.

The same goes for Annex I Part II as a whole. It does not impose properties of the product, it imposes processes of the manufacturer. And processes cannot be evidenced with a template.

• A software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies of the product (Annex I Part II point 1). To be of any use it has to be produced on every build, not once a year.
• Addressing and remediating vulnerabilities without delay, including by providing security updates (point 2) — which means a queue of findings, triage, and someone who decides on them.
• Regular testing and review of the security of the product (point 3). The word “regular” is there on purpose.
• A coordinated vulnerability disclosure policy and a contact address for reporting (points 5 and 6) — an inbound channel that someone reads and answers.
• Secure distribution of updates, automatic where applicable (point 7), and their dissemination without delay and free of charge, accompanied by an advisory message (point 8).
• Due diligence on third-party components including open source (Art. 13(5)) and the duty to report a vulnerability found in a component to whoever maintains it (Art. 13(6)).
• Reporting actively exploited vulnerabilities and severe incidents within 24 hours, 72 hours and 14 days (Art. 14, applicable from 11 September 2026). This is a purely operational capability — a team either has it or does not.

There is one more requirement that reads like a detail and yet presupposes a working process: the product is made available on the market without known exploitable vulnerabilities (Annex I Part I point 2(a)). You can only make that claim about your product if you know what it is made of and check it regularly against current data. The remaining Annex I requirements are summarised in the guide to the regulation.

Shift-left: why security is settled in design, not before release

Shift-left means moving security decisions as close as possible to the moment they are made — into requirements, design and writing code. The reason is mundane: the later a flaw is found, the more has been built on top of it. A fix in design is a change to a diagram. A fix after release is a code change, regression tests, a new version, a notice to customers and their own rollout plan.

The multipliers that circulate in slide decks — ten times more expensive in testing, a hundred times in production — come from studies that are old and methodologically shaky, and we are not going to repeat them here. The direction is beyond dispute, the number is not. The direction is enough to decide by.

More to the point, a number of the requirements in the regulation are properties of the design, not scanner findings. A secure by default configuration, minimising the data processed, limiting attack surfaces, the ability to securely remove and transfer data — those are architectural decisions (Annex I Part I point 2(b), (g), (j) and (m)). A scanner will find SQL injection. It will not find that the product ships with the same default administrator password for every installation, because technically that is working as intended.

Shift-left is sometimes read as “everything gets tested on the developer machine”. That is a misunderstanding. Some checks cannot be moved because they need a running application or a real environment — dynamic testing, configuration testing, a penetration test. Shift-left changes the order and the frequency, not the scope.

• Requirements — security requirements are written alongside the functional ones. Who gets authenticated, what they have access to, what is logged, how long data is kept.
• Design — threat model, trust boundaries, choice of cryptography and update mechanism. This is where most of what cannot be changed cheaply later gets decided.
• Code — checks in the editor and over the diff in the pull request, code review with a security angle, no secrets in the repository.
• Build — dependency analysis, SBOM generation, image scanning, artefact signing, reproducible builds.
• Before release — dynamic testing, configuration testing, a check that the product carries no known exploitable vulnerabilities.
• After release — monitoring components against current vulnerability data, receiving reports from outside, distributing fixes.

In practice the cheapest intervention in the design is the one that happens before the team starts writing. That is why we run threat modelling as a workshop over the real architecture of the product, not as a document written after the fact — its output can then serve as input to the risk assessment under Art. 13.

Tool categories and what each one actually does

There are a lot of acronyms and marketing material uses them loosely. Below, each category comes with three things: what it finds, what it does not find, and when it is worth having. The last item on the list — threat modelling — is not a tool but a discipline, and it is here deliberately: without it, the rest of the list only produces findings with no context.

The structure follows the way categories are split in the OWASP DevSecOps Guideline, which is a good starting point if you want to form your own view.

• SCA (software composition analysis) — analyses dependencies: the libraries you pulled in and their transitive dependencies. It finds known vulnerabilities in third-party components, licence risks and outdated versions; the same run usually produces the SBOM as well. It will not find a flaw in your own code, and by default it mostly does not answer whether the vulnerable function is reachable from your code at all — which is why a share of the findings carries no real risk. For the CRA this is the most direct link of them all: the bill of materials under Annex I Part II point 1 and the due diligence on components under Art. 13(5) both rest on exactly this inventory.
• SAST (static analysis) — reads your source code without running it. It finds injection, unsafe use of cryptography, hard-coded credentials, flaws in input handling. It is blind to runtime: it does not know the configuration, the deployment or the flaws in authorisation logic, because it never starts the application. The share of false positives is the most sensitive point on this whole list. It works best over the diff in a pull request, not as a nightly scan of the entire repository.
• DAST (dynamic testing) — tests the running application from the outside, with no knowledge of the code. It finds configuration errors, missing headers, exposed endpoints, authentication and authorisation problems, that is, the things static analysis cannot see by design. It will not find what it cannot reach — coverage is limited by where the scanner gets to, and for APIs without an interface description it tends to be poor. It needs a running environment, so it belongs in a nightly job against staging, not in every commit.
• IAST and RASP — both rely on instrumentation inside the running application. IAST correlates execution with the place in the code, so its findings carry a markedly lower share of false positives than SAST. IAST only sees what your tests exercise, though, and it needs support for the given language and runtime. RASP is not testing but runtime protection — it blocks the attack inside the application. It makes sense as a temporary compensating control where a fix takes time, not as a substitute for the fix.
• Secrets scanning — looks for keys, tokens and passwords in the repository and across the whole git history. The ratio of benefit to effort is good here and the share of false positives low, especially for tokens with a recognisable shape. The essential part is understanding what a finding means: once a secret has made it into history, it is compromised and has to be rotated. Rewriting history does not solve that, it only hides it. The check belongs in two places — a pre-commit hook on the developer side and the server side, because a hook can be switched off.
• Container image and IaC scanning — for images it finds vulnerable base image packages, unnecessary tooling in the resulting image and processes running as root; that is a layer application dependency analysis usually misses. For infrastructure as code (Terraform, Kubernetes manifests, Helm) it finds open security groups, public buckets, privileged pods, missing encryption. Neither will tell you whether a finding is exploitable in your environment — you supply the context.
• Threat modelling — the only discipline on the list that is not a tool. Over a diagram of data flows and trust boundaries you ask what an attacker might want, how they would get to it and what fails first. It will not find a specific vulnerability on a specific line, but it will find the missing control that no scanner reports, because it is not a flaw in the code. For the CRA it has practical value: a documented threat model output is usable input to the risk assessment under Art. 13(3).
• Fuzzing — generates malformed inputs and looks for a crash or an unhandled state. It pays off for parsers, protocol implementations, file format handling and native code in general, where the consequences of memory handling bugs are harshest. For an ordinary enterprise web application over a database the ratio of benefit to effort is poor. For a library you ship to others it makes sense to run it continuously rather than once.

None of the categories covers another. SCA does not know your code, SAST does not know runtime, DAST does not know the structure, and a threat model will not find a typo. So it is worth introducing them gradually and in the order of what hurts most in your product — the order that comes out of our projects is in the timeline at the end of this page.

False positives: the main reason a rollout dies

This is the part tool vendors are not keen to mention, and it decides whether the whole rollout succeeds. The typical scenario looks like this: a company buys a platform, turns everything on, the first scan of an established codebase returns hundreds or thousands of findings, the team starts working through them, after two weeks realises that most of them are not exploitable in its context, and stops reading them. From that moment the security check in the pipeline is just a source of noise, and the first real finding disappears into it.

A false positive is not necessarily a fault of the tool. Often it is a correct finding without context — a vulnerability in a library whose affected function is never called in your product; a weak random number generator used for something that is not security-sensitive; a missing header on an endpoint that is not public. The tool has no way of knowing that. You do — and that decision has to be recorded somewhere so it does not have to be made again on every run.

The other half of the truth: false negatives exist too. A clean pipeline is not proof that the product is secure — it is proof that this particular set of checks found nothing. A team that never says that out loud will sooner or later base its release decisions on a green tick.

• Freeze the current state (baseline) — historical findings are recorded and worked through to a plan, but the pipeline only fails on new ones. Without this step a new check cannot be switched on for an established product.
• Trim the rule set — the default set is built so that nothing slips through, not so that it is usable. Rules that systematically produce noise in your language and framework are switched off deliberately and with the reason written down.
• Record decisions in machine-readable form — for components that is VEX (see the next section), for code a suppression with a justification and an expiry. A decision without a justification is useless six months later.
• Reachability analysis where your SCA offers it — it cuts the volume of findings by an order of magnitude, because it separates out vulnerabilities in code that never runs in your product.
• One owner per queue of findings and deadlines by severity. A finding that belongs to everyone belongs to no one.
• Measure the noise, not just the number of findings — what share of findings ends up as “does not apply to us”. If it stays above half, the problem is in the configuration, not in the team.

In practical terms this means the first months after a tool is switched on are not about finding vulnerabilities but about tuning. Skip that phase and the team learns to ignore the checks — and getting that trust back takes far longer than the original rollout.

SBOM in practice: formats, when it is generated, and the link to VEX

A software bill of materials is a formal record of the components in the software elements of a product and of their supply chain relationships (Art. 3 point 39). The regulation asks two things of it: that it be in a commonly used, machine-readable format and that it cover at least the top-level dependencies of the product (Annex I Part II point 1). It prescribes no specific format; the Commission may specify the elements and the format by implementing act (Art. 13(24)), which as of 8 August 2026 has not happened.

In practice there are two formats. CycloneDX came out of OWASP; the current specification is version 1.7 of 21 October 2025 and it is standardised as ECMA-424 (2nd edition, December 2025). SPDX is maintained by the Linux Foundation; the current release is 3.0.1 from December 2024, while ISO/IEC 5962:2021 still recognises the older version 2.2.1 and the revision to the 3.0 line is at draft stage in ISO. Both formats satisfy the Annex I requirement and can be converted between, though not without loss.

More important than the choice of format is when the bill of materials is generated. It should be produced during the build, from what actually ended up in the artefact, and stored next to the artefact and with its version. A bill of materials assembled afterwards by scanning the repository is a different thing: it will not capture what the build added, what was resolved from the lock file and what sits inside the container base image.

And then there is the question of what to do with it. On its own a bill of materials is an inventory that goes stale the moment a new vulnerability is published. It only becomes useful once it is continuously matched against current vulnerability data — that is what turns “does this affect us?” into a question answered in hours rather than days. A bill of materials without that connection is a file, not a process.

• You do not have to publish the SBOM. It is provided to a market surveillance authority upon reasoned request where necessary to check compliance (Annex VII point 8). It is made available to the user only if the manufacturer decides to do so (Annex II point 9).
• One bill of materials per artefact version. A bill of materials with no link to a specific build is useless for answering which release is affected.
• Depth of the record. The regulation asks for at least the top-level dependencies; practice is moving towards the transitive tree, because the exploitable component is usually the dependency three levels below the one you picked.
• VEX (Vulnerability Exploitability eXchange) is the other half. The bill of materials says what is in the product; VEX says whether a given vulnerability actually affects it — with statuses such as not affected, affected, fixed and under investigation, together with a justification.
• There are three VEX formats and they differ in how the document is delivered: CSAF as a standalone security advisory profile, CycloneDX embedded directly in the bill of materials, and OpenVEX as a minimal standalone document. CISA has described the minimum elements in a separate document.
• The practical benefit of VEX is twofold: internally it removes repeated manual decisions about the same finding, externally it stops forty customers sending forty identical questions the moment a vulnerability lands in a widely used library.

Watch out for a confusion that comes up often around the bill of materials: an SBOM is not compliance with the duty to handle vulnerabilities. It is an input to it. The duty to address and remediate vulnerabilities without delay stands on its own in Annex I Part II point 2 and the bill of materials does not replace it — the difference between the two regimes is covered in the guide section on SBOM and vulnerability handling.

Gates in CI/CD: what to block and what to merely report

A gate is a point in the pipeline where the run stops because a check found something that must not go further. Deciding what will be a gate and what will only be a report is the most political part of the whole rollout, and it determines whether the team adopts the checks or starts working around them.

A hard gate on everything from day one has a predictable ending. Developers have a deadline, the gate stands between them and deployment, so a way around it appears: a flag that skips the check, an “exception” label that stops being removed, or moving the check into a job where failure is allowed. Formally the check still runs; in fact it guards nothing — and that is a worse starting position than no check at all, because nobody knows about it.

A workable rule is simple: block where the share of false positives is low and the consequence of letting something through is high. Report everything else first, measure it, and only then tighten if needed. And there does not have to be a single gate — a pull request is judged differently from a merge into the main branch, and both differently from a release, because only at release does it have to hold that the product goes to market without known exploitable vulnerabilities (Annex I Part I point 2(a)).

• Block in practically every case — a secret found in a commit, an artefact without a valid signature, a build from an unknown or non-auditable source, a failed dependency integrity check (a lock file change with no corresponding change in the code).
• Block at release — a high severity vulnerability in a directly used component for which a fix exists; a component with an actively exploited vulnerability; an image with unpatched base image vulnerabilities for which a patch has been released.
• Report only, at least to begin with — static analysis findings over established code, vulnerabilities in transitive dependencies with no demonstrated reachability, dynamic testing findings, infrastructure configuration recommendations.
• Never block on a score alone — CVSS measures severity in the general case, not risk in your deployment. A gate built on “anything above 7.0” produces stoppages that teach the team to route around it.
• An exception path has to exist and be recorded — who approves it, how long it lasts and what happens when it expires. An exception with no expiry turns within a year into a permanent state nobody knows about.
• Speed is a security parameter. A check that takes twenty minutes in a pull request will sooner or later be moved elsewhere. Only what finishes in single-digit minutes belongs in the PR, the rest goes into the nightly run.

The pipeline itself is an asset that belongs in the scope of protection. The environment in which artefacts shipped to customers are built and signed is a classic supply chain target — and its compromise is exactly the case of a severe incident having an impact on the security of the product that has to be reported under Art. 14(3) from 11 September 2026 (details in the guide).

Vulnerability management after release: KEV, EPSS and CRA reporting

Release is not the end of the work; under the CRA it is where the longest-running part begins — the support period is at least five years, and issued security updates have to remain available for at least ten years from their issuance (Art. 13(8) and (9)). For that whole time the loop has to work: monitor, assess, fix, distribute, inform.

The hardest decision in that loop is whether a vulnerability is actively exploited. The definition in the regulation is stricter than everyday usage: it is a vulnerability for which there is reliable evidence that an actor executed malicious code on a system without the permission of the system owner (Art. 3 point 42). That is not the same as exploitable. The existence of a working proof of concept does not trigger the reporting duty by itself.

Two public sources are used for this decision and it helps to know what each of them means. The KEV catalogue run by the US agency CISA lists vulnerabilities with an assigned CVE for which there is evidence of active exploitation and a known remediation. It is a strong external signal, but by its nature it is delayed, incomplete and oriented towards the US environment — absence from KEV is not evidence that a vulnerability is not being exploited.

EPSS from FIRST is something entirely different: a statistical model that estimates daily the probability that a published vulnerability will be exploited in the wild within the next 30 days. The current model is version 4 from March 2025. EPSS is a prediction, not an observation — excellent for ordering the remediation queue and unusable as the trigger for the 24-hour deadline under Art. 14. That deadline is triggered by knowledge of a fact, not by a probability.

In practice the first evidence is usually something of your own: telemetry from the product, a customer report, a finding from incident response, or a message arriving at the contact address for reporting vulnerabilities under Annex I Part II point 6. Which is exactly why that address should not be just a line on a website.

• Daily matching of the bill of materials against vulnerability data sources, with a ticket opened automatically on a match. Manual checking does not survive across dozens of products.
• Triage with two outputs — whether it affects us (and a VEX record if it does not) and how urgent it is. Ordering by a combination of severity, reachability in your product and EPSS gives a better queue than any of those figures on its own.
• A separate signal for active exploitation — KEV monitoring, advisories from component suppliers, your own telemetry. This signal carries a different urgency from the ordinary fix queue, because a deadline follows from it.
• Authority to decide, and availability outside working hours. The 24-hour deadline runs from the moment the manufacturer becomes aware, not from Monday morning. It has to be clear in advance who decides and who files the notification.
• Security fixes separated from functional changes where technically feasible (Annex I Part II point 2) — a customer who has to accept new functionality along with a security fix will deploy it later.
• An advisory message with each released fix describing the vulnerability, the impact, the severity and the remediation (Annex I Part II points 4 and 8). Publication may be delayed in justified cases until users have had the chance to deploy the fix.

Reporting under Art. 14 becomes an operational duty on 11 September 2026, with deadlines of 24 hours, 72 hours and 14 days, and one month for incidents. What exactly goes into each report, who it is submitted to and when each deadline starts is covered in the guide section on reporting. This is not a process a team should be running for the first time for real.

Secure SDLC as a framework: where it meets the standards

DevSecOps is the operational half of the matter — what runs, when and with what result. Secure SDLC is the other half: the framework that says which activities exist in the lifecycle at all, who owns them and how you tell they are being done well. Without the framework you get a collection of tools you cannot evidence to anyone; without the operations you get documentation that does not match reality.

There are several frameworks and they are not competitors — each answers a different question. Below are the four most used in the European and industrial context, briefly, and with what each is good for.

One thing holds for all of them and is worth knowing in advance: none of these frameworks creates a presumption of conformity with the CRA. That arises solely from applying a harmonised standard whose reference has been published in the Official Journal (Art. 27(1)), and as of 8 August 2026 no such standard exists for the CRA. A certificate is a good foundation and evidence of established processes, not a substitute for conformity assessment.

• NIST SSDF (SP 800-218) — four groups of practices: prepare the organisation (PO), protect the software (PS), produce well-secured software (PW) and respond to vulnerabilities (RV). The last group maps almost one to one onto what Annex I Part II requires of the manufacturer. The current version is 1.1 from February 2022; version 1.2 was released on 17 December 2025 as the initial public draft of SP 800-218r1, the comment period closed on 30 January 2026 and as of 8 August 2026 it is not final.
• OWASP SAMM — a maturity model, not a checklist. Five business functions (Governance, Design, Implementation, Verification, Operations), fifteen practices and three maturity levels. It is good for what frameworks like SSDF are not: working out where you stand today and having a measurable difference against where you stand a year later.
• IEC 62443-4-1 — a secure product development lifecycle for industrial automation: eight groups of practices from security management through requirements definition, design and verification to defect and update management, with four maturity levels. Of the existing standards it is the closest in substance to what Annex I Part II asks of the manufacturer, and for industrial products it is usually a sensible starting point.
• ISO/IEC 27001:2022 — an information security management system, meaning the organisation, not the product. Development is touched by the Annex A controls from 8.25 (secure development lifecycle) through 8.28 (secure coding) to 8.29 (security testing in development and acceptance). It covers the process side and change management; it will not replace the product-level risk assessment, the bill of materials or the technical documentation under Annex VII.

A practical recommendation: choose the framework not by which one is “right” but by whom you will be evidencing what to. IEC 62443-4-1 for an industrial customer, SSDF for a US buyer, and for CRA surveillance your own risk assessment and technical documentation. The relationship between standards and regulation is covered in the guide to standards, and the standing of certificates under the CRA in the CRA FAQ.

How we can help with this

The previous sections describe what gets done. This one describes what we do with clients and in what format. The offering is split into separate parts on purpose — most companies do not need all of it, they need the two or three pieces that are missing.

We work with what you already have. If a tool in the pipeline makes sense, we tune it instead of replacing it. We have no partnership or commission arrangement with vendors, so our recommendations are neutral and follow your environment, and we have no reason to push you towards any particular tool; we can supply and resell a licence, but that is not our target business — we do not rule it out, we simply do not build on it. Nor do we replace your development team — in the end the checks and processes have to be run by the people who build the product, otherwise they last about a quarter after we leave.

• Consultation — a one-off session over your product and your development. We go through what runs today, which of the CRA requirements it covers and what is missing. The output is a list of steps in order and with an effort estimate, not a quote.
• Assessment of the existing pipeline — what actually runs in CI/CD, what each check covers, where the blind spots are, how much noise it produces and whether the gates are in fact being bypassed. The output is a ranked list of findings and a recommended order of remediation.
• Product threat modelling — a workshop with the development team over the real architecture. Trust boundaries, data flows, attack scenarios, missing controls. The output is written so that it can be used as input to the risk assessment under Art. 13.
• Secure SDLC rollout — activities, owners, decision points and the exception path, mapped onto the chosen framework (SSDF, IEC 62443-4-1) and onto the Annex I requirements. Including what has to be evidenced and with what.
• Setting up gates in CI/CD — selecting the checks and wiring them into your CI, freezing the current state, tuning the rules, the gate policy and its gradual tightening. The goal is a state in which the team trusts the checks.
• SBOM and VEX — generating the bill of materials during the build, storing and versioning it, matching it continuously against vulnerability data, and a process in which the “does not affect us” decision is recorded once and in machine-readable form.
• Vulnerability management and reporting under Art. 14 — triage, roles, availability outside working hours, the content of each report and a dry run, so that the real 24-hour deadline is not being worked out for the first time during a real event.

There are two formats of cooperation: a bounded assessment with a deliverable and a deadline, or a longer engagement with regular capacity when you want to run the rollout gradually and with someone on hand. What each of them involves is described on the Security Assessment page; scope and price depend on how many products and teams it has to cover.

The rollout order that works for us

This is not a requirement of the regulation, nor a standard. It is our estimate from projects — roughly a product team of 5 to 15 people with one main product and an existing CI. The durations are rough, the steps overlap and the order shifts depending on what you already have in place. The point of the list is different: to show that this is introduced piece by piece, and what should follow what.

Official sources

The subject-matter claims about obligations and dates on this page are based on the following sources, as of 8 August 2026. This page does not replace the text of the legislation.