How to build OWASP controls, dependency scanning and code review into CI/CD without slowing the team down.
In short
DevSecOps means running security checks in the same pipeline as build, test and deployment, instead of as a separate review just before release. Start with a few automated gates, use the OWASP Top 10 as the shared list of risks, block only new, serious and fixable findings, and give every finding a named owner and a deadline.
This guide comes from Devies, a Gothenburg-based product and engineering consultancy, and is written for the people who run development organisations in Sweden and the Nordics. It covers where to start, what should stop a release, which tools do what, and how to tell whether the work pays off. The goal is not more tools. It is fewer vulnerabilities reaching production, and faster fixes for the ones that still get through.
DevSecOps is the practice of treating security as part of the delivery flow, owned by the teams who write and ship the code. Secure by design is the related principle that security decisions start in architecture and requirements, long before any scanner runs.
Which risks should DevSecOps controls catch?
The OWASP Top 10 is the most widely used shared list of the risks that automated and manual controls in web applications should catch. As of October 2026, the current edition is the OWASP Top 10:2025:
- A01 Broken Access Control
- A02 Security Misconfiguration
- A03 Software Supply Chain Failures
- A04 Cryptographic Failures
- A05 Injection
- A06 Insecure Design
- A07 Authentication Failures
- A08 Software or Data Integrity Failures
- A09 Security Logging and Alerting Failures
- A10 Mishandling of Exceptional Conditions
Two points matter when you plan your application security work. First, the software supply chain now has its own category (A03). Dependencies, build tools and package registries are part of the attack surface, not just the code your team writes. Second, several of the risks cannot be found by a scanner. Broken access control and insecure design (A01 and A06) need someone who understands what the application is supposed to allow, which is why threat modelling belongs early in the work.
Use the list as a common language, not as a complete requirement specification. For detailed, testable requirements, the OWASP Application Security Verification Standard (ASVS) is the better reference.
Pipeline gates: what should stop a release?
A release should be stopped by findings that are new, serious and fixable, while older findings go into a prioritised backlog with deadlines.
The most common mistake is switching every control to blocking on day one. The result is hundreds of findings, red builds and a team that learns to ignore warnings. Start instead with new controls in report-only mode, remove the noise, and then tighten the threshold step by step.
Checkpoint
What runs
Blocks the release?
Pull request
What runs
Secret scanning, SAST on changed code, check of newly added packages
Blocks the release?
Yes, for exposed secrets and critical new findings
Build
What runs
SCA on the full dependency tree, SBOM generation, artefact signing
Blocks the release?
Yes, for known critical vulnerabilities with an available fix
Test environment
What runs
DAST against the deployed application, checks of configuration and infrastructure as code
Blocks the release?
Usually a warning first, blocking once false positives are under control
Production
What runs
Continuous monitoring for new vulnerabilities in existing dependencies
Blocks the release?
No, but it creates tickets with deadlines
Treat the table as a starting point. Where the line goes depends on the product's risk level, how often you release and how mature your test automation is.
SAST, DAST and SCA: what does each one do?
SAST, DAST and SCA are three complementary scanning methods that examine source code, a running application and third-party dependencies respectively, and none of them replaces the others.
SAST: static analysis of source code
SAST is analysis of source code without executing it. It finds patterns such as injection, unsafe input handling and weak cryptography. It works best close to the developer, in the editor or the pull request, where a finding can be fixed straight away. Its weakness is false positives, so the rule set needs tuning.
DAST: dynamic testing of a running application
DAST is testing of a deployed application from the outside, roughly the way an attacker would approach it. It finds misconfiguration, missing security headers and some authentication flaws. It needs a stable test environment and takes longer to run, so it often fits better in a nightly or pre-release stage than in every commit.
SCA: analysis of dependencies
SCA is an inventory of third-party components matched against known vulnerabilities and licence terms. Because a large share of a modern application is open source, SCA often gives the most effect per hour invested. Combine it with an SBOM (Software Bill of Materials) so that you can answer "are we affected?" within minutes when a new vulnerability is published. Our planned guide on what an SBOM is and why the CRA requires it goes deeper.
Add secret scanning on top. It is cheap to introduce and catches one of the most common and costly mistakes: keys and passwords committed to version history.
Ownership: who fixes the findings?
The team that owns the code should own its security findings, while a central security function sets the rules and supports the teams.
Tools produce findings. Ownership decides whether anything happens. A few principles that tend to work:
- Deadlines per severity. Decide in advance how quickly critical, high and medium findings must be fixed, and who may approve an exception.
- Documented exceptions. An accepted finding needs a reason, an owner and an expiry date, not just an ignore flag in the tool.
- Security champions. One developer per team with some extra training often does more good than a central reviewer who sees the code last.
- Secure code review. Add a few security questions to the pull request checklist. Is authorisation checked on the server side? Is input validated? Are security events logged without sensitive data?
Ownership also matters for regulatory reasons. As of October 2026, the EU Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force since 10 December 2024. The manufacturer's obligation to report actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, and the main obligations, including vulnerability handling during the product's support period, apply from 11 December 2027. If you build products with digital elements for the EU market, a working pipeline with an SBOM and traceable vulnerability handling is a large part of the preparation. Whether your products are in scope needs its own assessment, which is what the Cyber Resilience Act alignment workshop is designed for.
How do you measure whether DevSecOps is working?
You know DevSecOps is working when fixes reach production faster and fewer serious vulnerabilities stay open over time, not when the number of tools goes up.
These five metrics are easy to produce and say a lot:
- Time to fix per severity, from the moment a finding is created to the fix being in production.
- Share of findings fixed within the deadline.
- Open critical and high vulnerabilities in production over time.
- Share of builds stopped by security controls, and how many of those stops were false positives. A high false positive rate is a signal to tune the rules, not to switch off the gate.
- Coverage: the share of repositories and services with SAST, SCA and secret scanning enabled.
Set a baseline and follow up every quarter. The trend matters more than the absolute number. If you want a framework to map your practices against, NIST's Secure Software Development Framework (SP 800-218) groups them into preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities.
A checklist for the first 90 days
- Inventory repositories and pipelines, and pick one or two products to start with.
- Turn on secret scanning and SCA, in report-only mode first.
- Generate an SBOM in the build.
- Add SAST to pull requests for changed code.
- Agree deadlines and an exception process with the product owners.
- Run a short threat modelling session for the most critical user flows.
- Switch on blocking for new critical findings once the noise is under control.
- Record a baseline for the metrics above.
Keep reading
From our work
Client Case: ZenseactHow Devies helped Zenseact make cybersecurity a natural part of developing safety-critical software for driver assistance and autonomous driving.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Will DevSecOps slow our team down?
In the short term you may see more stopped builds. If you start new controls in report-only mode, tune the rules and block only new, serious findings, the effect on lead time is usually small. At the same time, you avoid expensive findings late in the process, such as a vulnerability discovered by a customer or a penetration test the week before a major release.
Is following the OWASP Top 10 enough?
No. The OWASP Top 10 describes the most common and serious risks in web applications, but it is an awareness list, not a complete set of requirements. For testable requirements, use the OWASP Application Security Verification Standard (ASVS). Add threat modelling for the risks that are specific to your product, such as business logic flaws and access rules that no generic list can predict.
Do we need SAST, DAST and SCA from day one?
Not necessarily. Secret scanning and SCA usually give the most effect for the least effort, so they are good places to start. SAST and DAST can be added step by step once you have a process for triaging and fixing findings. Adding every scanner at once without clear ownership tends to produce a large backlog that nobody acts on.
What is the difference between DevSecOps and secure by design?
Secure by design is the principle that security is decided in architecture and requirements, for example through threat modelling and safe defaults. DevSecOps is the delivery practice that checks, continuously and automatically, that the code you ship still meets those decisions. You need both: design choices set the target, and pipeline controls catch the drift between the design and the code.
Sources
- OWASP Top 10:2025
- OWASP Application Security Verification Standard (ASVS)
- European Commission, Cyber Resilience Act
- NIST SP 800-218, Secure Software Development Framework (SSDF)
- Devies Cybersecurity+
- Devies, The Cyber Resilience Act: Alignment Workshop
