Secure software development lifecycle (SSDLC): how to implement it in a software company
By Kike Gandia · Co-Founder & CEO, OSCP · Last updated:
A secure software development lifecycle, or SSDLC, is the set of practices that build security into every phase of development instead of leaving it for a test at the end. It does not require an in-house security team or halting feature delivery: it requires deciding what is checked in each phase, who does it and what evidence remains. This guide explains the phases, what to automate, where the pentest fits and which frameworks to use, with a small or mid-sized development company in mind.
Why it matters now
Fixing a security flaw in production costs far more than avoiding it at design time, and now someone is asking. Clients certified to ISO 27001 have to oversee the development they outsource, banks and insurers subject to DORA have to control their ICT providers, and Spain's public sector requires the National Security Framework (ENS), which includes specific measures for application development (mp.sw.1) and for acceptance and commissioning (mp.sw.2).
A documented SSDLC answers all of them: instead of improvising every questionnaire, you show a process.
The phases and what to do in each
| Phase | What is done | Evidence left |
|---|---|---|
| Requirements | Security requirements agreed with the client, for example an OWASP ASVS level | Requirements in the contract or the user stories |
| Design | Threat modelling of what is new: sensitive data, roles, integrations | Diagram and identified threats with their mitigation |
| Development | Secure coding guide, peer code review, secrets kept out of the repository | Reviewed pull requests and linter rules |
| Integration | Static analysis (SAST), dependency analysis (SCA) and secret scanning in the pipeline | Pipeline results and approved exceptions |
| Testing | Dynamic testing (DAST) and a pentest before major releases | Pentest report and retest |
| Deployment and maintenance | Secure configuration, dependency vulnerability management and incident response | Component inventory (SBOM) and patch log |
There is no need to implement everything at once. The best return at the start usually comes from clear requirements, code review with a checklist and dependency analysis in the pipeline.
What to automate and what not to
Automated tools are good at finding known patterns and very bad at understanding the business:
- Automate: analysis of dependencies with known vulnerabilities, secret detection, static analysis of dangerous patterns and basic dynamic scanning on each release.
- Do not automate: threat modelling, business logic review and validation of permissions between roles and between tenants. A scanner does not know that a user from one company should not see another company's invoices.
The usual mistake is to add a scanner to the pipeline, fill it with alerts and have the team learn to ignore them. Better a few rules that really block than many that nobody reads.
Where the pentest fits
The pentest does not replace the SSDLC: it checks it. It makes sense before the first delivery, before every release with major changes (a payments module, a new role, an integration) and at least once a year on what is in production.
For a company that delivers to clients, the key moment is before delivery: the pentest report and the retest are the easiest evidence to show, and findings arrive while they can still be fixed without rebuilding the project.
Which framework to follow
| Framework | What it is | What it is useful for |
|---|---|---|
| NIST SSDF (SP 800-218) | A list of secure development practices grouped into four blocks | Organizing the process and answering clients who cite it |
| OWASP SAMM | A maturity model with levels per practice | Measuring where you are and planning improvements in stages |
| OWASP ASVS | A list of verifiable application requirements, in three levels | Agreeing with the client which security level is delivered, and testing it |
| ISO 27001:2022, controls 8.25 to 8.29 | Annex A secure development controls | What the auditor will ask if you or your client are certified |
For a small company, the practical route is ASVS for requirements and testing, and SSDF or SAMM to organize the process. If an ISO 27001 certification is at stake, the process must cover what its controls ask for.
An agile SSDLC that does not slow sprints down
In a team working in sprints, the SSDLC fits into what already exists:
- Definition of done: a story is not finished unless it has passed code review and the pipeline without critical alerts.
- Refinement: stories that touch authentication, permissions, payments or personal data carry a threat note.
- Per release, not per sprint: the pentest is planned for major releases, not for every sprint.
- A point of contact: you do not need a security team, but you do need someone in the team who is the contact and keeps the checklist up to date.
FAQ
What is the difference between SDLC and SSDLC?
The SDLC is the software development lifecycle: requirements, design, development, testing, deployment and maintenance. The SSDLC is the same cycle with security activities in every phase, instead of a security review at the end.
Do I need a security team to implement an SSDLC?
No. In a small company a point of contact within the team is enough, together with a few automated rules in the pipeline, code review with a checklist and an external pentest on major releases.
Which tools do I need to start?
A dependency analyzer, a secret detector and a static analyzer integrated into the pipeline. There are open-source options for all three. More important than the tool is deciding which alerts block a release and who reviews the exceptions.
Does an SSDLC help with ISO 27001 or the ENS?
Yes, if it is documented and leaves evidence. ISO 27001:2022 devotes controls 8.25 to 8.29 to secure development, and the ENS has specific measures for application development (mp.sw.1) and acceptance and commissioning (mp.sw.2). The auditor will want to see the process and proof that it is applied.
How often should a pentest be done?
Before the first delivery, before every release with major changes and at least once a year on what is in production. In between, the automated tests in the pipeline cover the most repetitive work.
Related service
cybersecurity for software development companies
Related content
- ISO 27001 control 8.25: what the auditor asks
- DevSecOps: offensive security in the pipeline
- Source code audit
- Web application pentesting