Skip to main content

The problem DevSecOps solves

Summary: in the classic model, security comes in at the end, as an audit, a few days before going to production. This model fails for structural reasons, not through lack of skill. This lesson details those reasons, quantifies the exponential cost of a late fix, and explains the true price of a data breach.


1. The classic scenario

The crucial point of this scenario, the one you really need to grasp: no one did a bad job. The developers delivered what was asked of them. The auditor did decent work. Management made a rational decision given the constraints.

The process is broken, not the people. Placing security after development mathematically guarantees that its conclusions will arrive too late to be applied.


2. The exponential cost of late fixes

The commonly cited orders of magnitude: a vulnerability fixed at design time costs 1. Fixed in development, about 5. In acceptance testing, about 15. In production, 30 to 100. After exploitation, the scale changes in nature entirely.

The practical conclusion: every day gained in detection reduces the cost in a non-linear way. This is the entire economic foundation of shift left, and it is the argument to present to management.


3. The six structural problems of the classic model

Problem 5 is the most underestimated, by far. Your code may not change for two years, but your exposure changes every day, because new vulnerabilities are constantly being published on the libraries you use. An annual audit is a snapshot; what you need is continuous monitoring.

Problem 6 explains why DevSecOps was born now and not twenty years ago. When software shipped twice a year, a three-week audit could be absorbed. With twenty deployments a day, it becomes mathematically impossible. It is CI/CD that made DevSecOps necessary.


4. The true cost of a data breach

Cost 5 is the one that hits the longest in the professional world. As soon as you sell to companies, every call for tenders includes a security questionnaire with the question "have you suffered a security incident in the last three years?". A positive answer eliminates you from certain markets, regardless of the quality of your product.

Frequently cited order of magnitude: the global average cost of a data breach sits around 4 to 5 million dollars according to annual industry studies — with considerable variation depending on organization size and sector, healthcare and finance being the most costly.


5. Why it's harder than before

Point 1 is the one that changes everything, and it is regularly ignored. You can write perfectly clean code and remain massively vulnerable, because 80% of what runs comes from libraries you have never examined. That is precisely why dependency analysis (SCA) often delivers more immediate value than analyzing your own code.

This is also what explains Log4Shell: a single logging library, used by millions of applications, and one critical flaw. The topic is covered in lesson 7.


6. What DevSecOps changes

Point 4 is the most powerful, and the least practiced. There is a huge difference between "flagging that a storage bucket is public" and "making it technically impossible to create a public storage bucket". The first approach produces a report someone will have to read; the second eliminates the entire class of problems.

This is the principle of the guardrail rather than the gatekeeper: instead of checking after the fact, you make the mistake impossible.


7. The usual objections, and how to answer them

Objection 3 deserves to be carefully dismantled, because it is the most widespread. The vast majority of attacks target no one in particular: bots continuously crawl the internet looking for known vulnerable versions, and exploit everything they find. A small unknown application with a public flaw will be found, often within a few hours of going online.


Remember in 30 seconds

  • Security at the end of the chain fails structurally: its conclusions arrive too late to be applied.
  • The cost of fixing grows exponentially: about 1 at design, 5 in development, 15 in acceptance testing, 30 to 100 in production.
  • Six structural problems: late information, bottleneck, adversarial security, no learning, untracked dependencies, incompatible with continuous delivery.
  • A data breach costs far beyond the technical side: regulatory (up to 4% of revenue under GDPR), reputation, and above all lost deals through security questionnaires.
  • More than 80% of the code that runs comes from dependencies you have never read. That is the major change.
  • It is CI/CD that made DevSecOps necessary — a three-week audit is impossible with twenty deployments per day.
  • Prefer the guardrail to the gatekeeper: make the mistake impossible rather than flagging it afterwards.
  • "Nobody is interested in us" is false: attacks are automated and untargeted.
  • The most cost-effective action: enable vulnerable dependency detection. Fifteen minutes.

Next: What is DevSecOps? Shift left and definitions →