Secure development lifecycle (SSDLC): what it is and how to put it in place

What it actually is

A secure development lifecycle is not a phase bolted onto the end of a project. It is the idea that at every stretch of development there is a piece of security work that can only be done well in that stretch, and that doing it earlier or later goes badly or does not happen at all.

At design time the question is what could go wrong with this architecture. While code is being written, it is whether known classes of defect are going in. At integration, it is what is being pulled in from third parties. At release, it is whether somebody can really break it. And once it is in production, it is whether you would notice.

Put another way: an SSDLC does not add one gate at the end, it distributes several small gates along the way. That is the whole concept, and the rest is implementation detail.

Why a review at the end is not enough

Reviewing security just before going to production has two problems, and neither of them is fixed by reviewing better.

• What you find at the end is no longer cheap to change. An authorisation flaw that comes out of how permissions were modelled is not fixed with a patch: it is fixed by touching the model, and by then there is code, data and other functionality sitting on top of it. The conversation stops being technical and turns into a conversation about the calendar.
• It arrives when there is no room left to say no. If the report lands the week before launch, the pressure works against fixing it. Findings turn into accepted risks, not because anybody weighed them up, but because there was no slot.

You do not need a study to see the mechanism: the later a wrong design decision surfaces, the more has been built on top of it. What you will not find here is the usual figure for how many times more expensive it is to fix in production, because that figure circulates attributed to work we have not read, and this site does not publish numbers it cannot stand behind.

What happens in each phase

This is the split, in the order the work shows up. No phase needs to start by buying anything.

• Requirements. Writing down what data the system handles, who should be able to see it and what would happen if it leaked. It is the only phase where security can be expressed as a requirement instead of as a repair.
• Design. This is where threat modelling belongs: sitting in front of the diagram and asking where somebody would come in. It has the best ratio of effort to result on the whole list, and it is the one almost nobody does.
• Development. Static analysis of your own code with SAST, and control over credentials not slipping into the repository, which is what secrets management is about. As a shared reference for what to look for, the OWASP Top 10 is still the common vocabulary.
• Dependencies. Almost all the code in a modern application belongs to somebody else. Software composition analysis tells you what you are using and with which known vulnerabilities, and an SBOM puts that on record so you can answer quickly the day something comes out. That is the surface a software supply chain attack travels through.
• Testing. Dynamic analysis with DAST against the running application, and manual testing of business logic, which is what no tool understands.
• Production. Knowing which version is deployed, being able to patch it quickly, and keeping enough logs to reconstruct what happened. Without this, everything above expires on its own.

The tools are not the lifecycle

The most common mistake when putting this in place is buying three tools, plugging them into continuous integration and calling the project done. What happens next is predictable: the pipeline starts emitting hundreds of warnings, nobody has time to triage them, and within a few weeks the team learns to ignore the alert or simply switches it off. The organisation ends up worse than before, because now it also believes it is covered.

SAST, DAST and SCA produce inputs, not decisions. The lifecycle is what you do with those inputs: who looks at them, on what basis something is decided to block a release, and what happens to whatever is decided not to fix. A team with a spreadsheet and that criterion clear is safer than one with three dashboards and none.

If you have to choose where to put money, putting it into reducing the noise of what you already have pays off more than adding one more tool.

Where a pentest fits, and where it does not

It is worth not confusing two things that sound alike. A vulnerability assessment searches in breadth, with tools, and finds classes of defect that are already catalogued. A penetration test searches in depth, with a person, and finds what comes out of chaining two things that on their own were nothing, or of business logic allowing something nobody thought about.

That second category is the one nobody automates, and it is where the findings that really matter tend to be: permissions that can be escalated, flows that can be replayed, identifiers that can be guessed. If you want the detail of what that work looks like from the inside, it is in our pentesting methodology, and by target type in how a web application pentest works and how an API pentest works.

Inside an SSDLC, a pentest does not replace any of the above: it comes afterwards and checks whether the above worked. We run them against web applications and against APIs, and the deliverable is a reproducible proof of each finding together with what has to be done to close it, not a list of scanner warnings.

Where to start if you have nothing today

Putting the whole lifecycle in place at once does not work in any real team. This order does, and the first three things do not cost a licence:

• One threat modelling session on what you already have in production. Two hours, the diagram in front of you and the question of where somebody would come in. It usually produces the to-do list for the next six months.
• Knowing what dependencies you have. Before analysing anything, have the inventory. Plenty of teams discover here that they did not know what was deployed.
• Getting credentials out of the repository. It is the most repeated finding and the cheapest one to close.
• Then, and only then, automate. One tool at a time, with somebody responsible for tuning its noise before the next one goes in.

If at some point you want somebody from outside to look at what you have built and try to break it, that is a conversation we can have here.

A note on this article

This text describes a practice, not a specific standard, and that is why it does not cite numbered clauses from any of them: the numbering changes between revisions and a citation from memory ages badly. It also carries no statistics on the cost of fixing defects late, for the reason given above.

English edition published on 4 August 2026. The Spanish original was published on 3 August 2026.