The two previous posts in this series looked at pieces of application security in isolation: attacking a vulnerable API to cover the impact of the OWASP API Security Top 10, and threat modelling to anticipate flaws before any code is written. Both are valuable, but each is a single practice. The wider question is how all of these fit together into something an organisation can actually run day to day — which is where a Secure Software Development Lifecycle comes in.
A Secure Software Development Lifecycle, or SSDLC, is broadly the set of activities performed to develop, maintain, and deliver a secure software solution. The key word is lifecycle: security isn’t a phase you bolt on before release, it’s something you need to consider at every step — a defence-in-breadth approach to sit alongside the more familiar defence-in-depth. Threat modelling lives in the design stage, penetration testing in verification, dependency management in the build, patching and log analysis in operations. The SSDLC is the framework that holds them in the right places and makes sure none are forgotten.
Use a framework
One of the reassuring aspects of building an SSDLC is that you don’t need to invent it. Several mature, well-documented frameworks already describe what “good” looks like, and it’s worth knowing the landscape:
- NIST Secure Software Development Framework (SSDF) — a concise set of secure-development practices, useful as a common vocabulary.
- ISO/IEC 27034 — the ISO standard dedicated specifically to application security.
- Building Security In Maturity Model (BSIMM) — a descriptive model built from observing what real organisations actually do.
- OWASP Software Assurance Maturity Model (SAMM) — a prescriptive, measurable model for assessing and improving a software assurance programme.
You don’t need all of them. A pragmatic approach is to establish a baseline against a standard you’re likely already working towards — ISO 27001 — and then mature beyond that baseline using OWASP SAMM.
Starting with ISO 27001
ISO/IEC 27001 is the international standard for managing information security, and if an organisation is pursuing or holds certification, it already imposes a set of secure-development expectations. In the 2013 edition these lived under A.14.2 — Security in Development and Support Processes; the 2022 revision reorganised them into the 8.25–8.28 controls (Secure development life cycle, Application security requirements, Secure system architecture and engineering principles, and Secure coding), with related controls covering change control, security testing, and the separation of development, test and production environments.
Stripped of the clause numbers, the standard asks you to think about a fairly sensible list of topics:
- the security of the development environment itself;
- documented guidance for security across the development lifecycle, including secure coding guidelines for each language in use;
- security requirements captured in the design phase, not retrofitted later;
- security checkpoints at project milestones;
- secure source repositories and secure version control;
- and developers who actually have the knowledge to avoid, find and fix vulnerabilities.
None of that is unusual, and much of it is satisfied with unglamorous hygiene. Enforce MFA on your source-control platform, keep secrets secured, keep your dependencies updated and more, run internal and external vulnerability scanning, secure the endpoints developers work on, and more.
Adopting a documented secure methodology and a secure-coding reference — the OWASP Security Knowledge Framework is a good starting point — so guidance isn’t tribal knowledge. Shift security requirements left into the design phase and give each stage a checklist. Put a formal change-control process around significant changes. And consider a Security Champions programme: developers embedded in teams who improve the flow of communication between engineering and security, promote good practice, and help shape standards from the inside.
Do all of that and you have a solid baseline. What ISO 27001 is less good at is going into further detail on application security or what to improve next. For that, you need something more focused.
Beyond the baseline: maturing with OWASP SAMM
Where ISO 27001 largely sets broad coverage, OWASP SAMM goes into more detail. It also gives you a way to measure maturity. Its structure is easy to remember as 5 / 3 / 2: five business functions, three security practices within each, and two streams within each practice.
The five business functions cover the whole lifecycle:
| Governance | Design | Implementation | Verification | Operations |
|---|---|---|---|---|
| Strategy & Metrics | Threat Assessment | Secure Build | Architecture Assessment | Incident Management |
| Policy & Compliance | Security Requirements | Secure Deployment | Requirements-driven Testing | Environment Management |
| Education & Guidance | Secure Architecture | Defect Management | Security Testing | Operational Management |
Each practice is scored against three maturity levels — roughly, Level 1 being ad-hoc or reactive, Level 2 structured and consistent, and Level 3 comprehensive, repeatable and verifiable. Crucially you don’t aim for Level 3 everywhere; you set target maturities appropriate to your risk, assess where you actually are, and close the gap deliberately.
That turns improvement into a repeatable cycle — assess, set a target, build a roadmap, implement — run in phases (three to twelve months is typical) rather than a one-off push. Phasing it matters: it avoids compliance drop-off and gives new processes time to embed before you pile more on top.
The SAMM lifecycle
Working through the five functions gives a feel for the breadth of an SSDLC, and shows where the earlier posts slot in:
- Governance. Define metrics to measure the effectiveness of the programme, adopt verification checklists such as the OWASP Application Security Verification Standard (ASVS), monitor compliance, and invest in shared security know-how. Governance is usually where the initial effort goes, because it sets the baseline everything else is measured against.
- Design. Consider security explicitly during requirements. Classify each application’s risk with a short set of questions, and reach for threat modelling on the higher-risk ones — keeping those models in the app’s repository and updating them as the design changes. Reinforce secure design principles and evaluate the security quality of the components you build on.
- Implementation. Actively avoid vulnerable dependencies (are they maintained, supported, correctly licensed?), set security baselines for builds, secure your secrets, and get disciplined about identifying and tracking security defects.
- Verification. This is where the reactive testing lives: architecture assessment to understand the overall posture, requirements-driven testing against something like ASVS, static analysis (SAST), dynamic analysis (DAST), and penetration testing at periodic intervals.
- Operations. The lifecycle doesn’t end at deployment. Analyse log data, keep incident-response playbooks current, establish and monitor configuration standards, patch consistently and proactively, understand the sensitivity of the data you process, and standardise how systems are decommissioned.
Pulling it together
The value of an SSDLC is that it takes the various good practices — the threat model here, the pen-test there, the dependency analysis somewhere else — and gives them a place as components in a coherent programme, with owners, checkpoints and a way to determine whether you’re improving. ISO 27001 gives you a good baseline, while OWASP SAMM turns that into something more in-depth, which you can measure and mature over time. Frameworks like NIST SSDF and BSIMM are also there to borrow from.
None of it makes software magically secure — there’s always residual risk — but building security into the whole lifecycle, deliberately and measurably, is how you stop paying full price to fix things late. It’s the difference between doing scattered application security practices and having a coherent application security programme.
