INCIBE published a technical article on DevSecOps in October 2025. What stands out is not the technical content, which is solid, but the context: a public institution dedicated to cybersecurity in Spain is explicitly saying that security must be integrated from the code, not added as an afterthought.
When INCIBE says it, the problem is widespread enough to warrant official attention.
Fixing security late costs 6x more
The classic NIST data point: fixing a vulnerability in production costs up to 30 times more than fixing it during design. And up to 6 times more than fixing it during development.
Companies that add security as a final phase pay that premium on every release. Every new feature shipped without a security review accumulates technical debt that sooner or later has to be paid off. The longer you wait, the more expensive it gets.
This is not a budget problem. It is a matter of where you invest it.
What is DevSecOps (without the jargon)
DevSecOps is not a tool or a product. It is an approach where security is integrated into every phase of development.
This involves several concrete practices:
- Static Application Security Testing (SAST): reviews source code for vulnerable patterns before it reaches production.
- Software Composition Analysis (SCA): detects third-party libraries with known vulnerabilities.
- Dynamic Application Security Testing (DAST): simulates attacks against the running application.
- Configuration review: verifies that servers, containers and cloud services are securely configured.
- Secrets management: ensures API keys, passwords and certificates are not hardcoded or exposed in repositories.
You do not need a massive security team. You need every development decision to account for security as a requirement, not an afterthought.
SMEs write vulnerable code too
SMEs tend to think "we don't develop software, this doesn't apply to us." But they use third-party APIs, have web forms, integrate payment gateways, run WordPress plugins and connect cloud services.
Every integration is an attack surface.
Worth reflecting on: You don't need to develop an operating system to need DevSecOps. You need to have data worth protecting and code, yours or third-party, that processes it. If your company has a website, an API or a contact form, you have exposed code.
The most high-profile breaches of recent years did not come from complex internally developed software. They came from an outdated dependency, an unpatched plugin, a misconfigured API. Things that any company, regardless of size, has.
ISO 27001 already requires security in the software lifecycle
ISO 27001 control A.8.25 (secure development) requires organisations to establish rules for secure software development. Control A.8.26 requires security testing during development. Control A.8.28 calls for secure coding practices.
DevSecOps is not a trend: it is the operational way to comply with the security controls in development that ISO 27001 already mandates.
If your company is certifying or planning to certify against ISO 27001, you need DevSecOps. Not as a separate initiative, but as part of the information security management system the standard requires you to implement.
What we see in audits: The ISO 27001 controls that most companies fail are the ones related to secure development. Not because they are technically complex, but because development and security sit in separate departments that do not communicate. When the dev team and the security team do not share tools, processes or criteria, compliance with these controls is nearly impossible.
How to start without rebuilding everything
You do not need to rebuild everything. Three concrete steps can make a real difference:
Tools like SonarQube, Snyk or Semgrep integrate into CI/CD and detect vulnerabilities before merge. They do not replace human review, but they automate detection of known patterns. This is the investment with the highest immediate return.
Most recent breaches come from third-party libraries, not from your own code. A dependency scan tells you which libraries you use have known vulnerabilities and which are outdated. It can be configured in hours and may prevent an incident costing tens of thousands of euros.
They do not need to be cybersecurity experts. They need to know the most common vulnerability patterns (OWASP Top 10) and how to avoid them. A dev team that understands SQL injection, cross-site scripting or poor session management makes fewer mistakes and catches them earlier.
These three steps do not require restructuring anything. They plug into the workflow you already have. And if your company is going through ISO 27001 certification, they demonstrate maturity to the auditor on secure development controls.
Security assessment for your development
If you need to integrate security into your development cycle or are preparing for ISO 27001 certification, we can run an initial analysis of your pipeline and attack surface. No commitment.
Talk to an expertYour team needs secure AI training
The EU AI Act requires AI literacy for all staff from August 2026. Our courses cover compliance, AI agents and governance. FUNDAE can subsidise 100% of the cost.
