Secure SDLC (SSDLC): Where Pentesting Fits in Each Phase

A secure software development lifecycle (SSDLC, or secure SDLC) builds security work into every phase of how software is planned, designed, coded, built, released and maintained, instead of testing for it once at the end. In practice that means security requirements during planning, threat modeling during design, secure coding, code review and SAST during development, DAST and penetration testing before release, and vulnerability handling in production. NIST's Secure Software Development Framework (SSDF, SP 800-218) groups these practices into four areas you can map to any SDLC, and penetration testing fits wherever risk changes, not only once a year.

What Is a Secure SDLC (SSDLC)?

A secure SDLC is your normal software development lifecycle with defined security activities, owners and exit criteria added to each phase. It is not a separate process that runs beside development. The NIST SSDF describes its practices as a core set of high-level secure development practices that can be integrated into each SDLC implementation, which is the key idea: the SSDLC adapts to waterfall, agile, DevOps or any mix, because it defines what must happen, not how your team ships.

A working SSDLC has four properties:

• Security starts at requirements. Security and privacy requirements are written down with functional requirements, so designers and testers know what "secure enough" means for this application.
• Every phase has a gate. Each phase ends with a check, such as a reviewed threat model, a clean SAST run on high-severity rules or a passed pre-release pentest, that decides whether work moves on.
• Findings feed back. Vulnerabilities found in testing or production are fixed, traced to a root cause and turned into a new requirement, coding rule or test, so the same class of bug does not return.
• The effort scales with risk. A payment flow or multi-tenant API gets deeper review and testing than an internal dashboard.

SDLC vs SSDLC

SSDLC vs DevSecOps

The two terms overlap but are not the same. The SSDLC is the lifecycle model: which security activities happen in which phase and who owns them. DevSecOps is the culture and automation that runs many of those activities inside fast CI/CD pipelines. A DevOps team that adds SAST to its pipeline has started DevSecOps, but without threat modeling, security requirements and a vulnerability response process it does not yet have a full secure SDLC. For the pipeline side, see our guide to penetration testing for DevOps, which covers CI/CD security gates in detail.

Why a Secure SDLC Matters in 2026

Three pressures make a secure SDLC a business requirement rather than a best practice.

Attackers go after software flaws. The Verizon 2026 Data Breach Investigations Report found that 31% of breaches in its dataset (incidents from November 1, 2024 to October 31, 2025) started with the exploitation of software vulnerabilities, ahead of stolen credentials as the top way in. Every flaw an SSDLC prevents before release is one less entry point.

Buyers and governments expect evidence. CISA's Secure by Design guidance asks software manufacturers to document conformance to a secure SDLC framework, and names the NIST SSDF as the option to consider in the United States. In the European Union, the Cyber Resilience Act entered into force on December 10, 2024; manufacturers must report actively exploited vulnerabilities from September 11, 2026, and its main obligations, which cover the planning, design, development and maintenance of products with digital elements, apply from December 11, 2027.

US federal policy moved to risk-based assurance. On January 23, 2026, OMB memorandum M-26-05 rescinded M-22-18 and M-23-16, the memos that had required federal agencies to collect secure software development attestations. Agencies must still maintain software and hardware inventories and set assurance requirements that match their risk. They may still use the Secure Software Development Attestation Form, may require a software bill of materials (SBOM) by contract, and can reference NIST SP 800-218. In other words, the mandatory form is gone, but the SSDF remains the reference federal buyers point to.

The Secure SDLC Phase by Phase

The table below is the core of an SSDLC. Phase names vary between frameworks: IBM's explainer lists nine, Cobalt and HackerOne use six. The six phases here follow common practice; what matters is that each activity has an owner and each phase has an exit gate. The SSDF column uses practice IDs from NIST SP 800-218 Version 1.1.

Phase 1: Plan and requirements

Security starts before any design. Define security and privacy requirements alongside functional ones: authentication strength, authorization model, data classification, logging, encryption and regulatory needs. OWASP ASVS (version 5.0.0, published May 30, 2025) is a practical source of testable requirements, because the same items later become test cases.

Assign each application a risk tier so effort is proportional. A customer-facing payment service and an internal reporting tool should not get the same depth of review. This phase also covers the organization-level SSDF practices: PO.1 (define security requirements), PO.2 (roles, responsibilities and training), PO.3 (supporting toolchains) and PO.5 (secure development environments).

Where pentesting fits: not yet as a test, but plan for it. Budget time and scope for pre-release and periodic testing now, so testing is not cut when the release date gets tight.

Phase 2: Design

Design is where the most expensive flaws are prevented. SSDF practice PW.1.1 recommends forms of risk modeling, such as threat modeling, attack modeling or attack surface mapping, to assess the security risk of the software. A threat model asks what you are building, what can go wrong, what you will do about it and whether you did a good enough job. Our threat modeling guide covers STRIDE, PASTA and data flow diagrams step by step.

PW.2 then asks for a review of the design against the security requirements and risk information, by a qualified person who was not the designer. Design choices that remove whole classes of bugs belong here: parameterized queries through a vetted data layer, a central authorization service, memory-safe languages for new components and secure defaults (PW.9).

Where pentesting fits: for high-risk systems, an experienced tester can review the architecture and threat model before code exists, asking how an attacker would chain trust boundaries, roles and integrations. That is far cheaper than finding a broken authorization model after launch.

Phase 3: Develop

Developers write code to a secure coding standard (PW.5) and reuse well-secured components instead of writing their own crypto or parsers (PW.4). PW.7 covers reviewing and analyzing human-readable code: SSDF distinguishes code review, where a person reads the code, from code analysis, where tools do. Both have a place. Automated tools catch known patterns at scale; human reviewers catch logic and authorization flaws that tools cannot model. Our comparison of manual vs automated code review explains how to combine them.

Practical controls in this phase:

• SAST on every pull request, tuned to block only high-confidence, high-severity rules so developers trust the results.
• Secret scanning before code reaches the shared repository.
• SCA to flag vulnerable or abandoned open-source dependencies before they are merged. Our explainer on software supply chain attacks shows why dependency hygiene matters.
• Security-focused review of high-risk code paths: authentication, session handling, access checks, payment logic and file handling.

Where pentesting fits: not as a full test, but findings from earlier pentests should shape secure coding rules and review checklists here.

Phase 4: Build and verify

The build pipeline itself is an attack target. SSDF PS.1 asks you to protect all forms of code from unauthorized access and tampering, and PW.6 covers secure compiler, interpreter and build settings. Signed commits, protected branches, least-privilege CI runners and signed artifacts belong here. The SLSA framework gives graded levels for build integrity.

Verification moves from code to running software. PW.8 (test executable code) lists dynamic testing in automated suites, regression tests for previously reported vulnerabilities, fuzz testing and, in Example 6, using penetration testing "to simulate how an attacker might attempt to compromise the software in high-risk scenarios." DAST and API scanners cover known patterns quickly. For how SAST, DAST, IAST and RASP divide the work, see our SAST vs DAST vs IAST vs RASP guide.

Where pentesting fits: this is the main pre-release slot. A targeted manual pentest of new high-risk functionality, such as a new login flow, a payment feature, multi-tenant data access or a public API, finds business logic and access control flaws that scanners miss.

Phase 5: Release and deploy

Release is a decision point. SSDF PO.4 asks you to define criteria for security checks and track them through the SDLC, which is what a release gate does: no open critical findings, known residual risks accepted by an owner, and fixed findings retested. PS.2 and PS.3 cover release integrity and archiving: publish hashes or signatures so customers can verify releases, and keep the SBOM and provenance data for each release.

Deploy with secure configuration by default (PW.9). Configuration deserves the same scrutiny as code; common problems include debug modes left on, overly broad cloud permissions, default credentials and exposed admin interfaces.

Where pentesting fits: retest every finding fixed before release, and test the production-like configuration rather than only a developer environment.

Phase 6: Operate and respond

No SDLC prevents every flaw, so the last phase covers response. RV.1 asks you to identify and confirm vulnerabilities on an ongoing basis, including through a vulnerability disclosure program (RV.1.3) and a product security incident response team (PSIRT). RV.2 covers assessing, prioritizing and remediating, and RV.3 analyzing root causes so that whole classes of vulnerabilities are addressed rather than single instances. Our guide to vulnerability management covers prioritization and remediation timelines.

Where pentesting fits: periodic full-scope tests, tests after significant changes, and retests after fixes. Each confirmed finding should end in three outputs: a fix, a root cause recorded against the phase that should have caught it, and a regression test so it does not return.

An illustrative walk-through: one feature through the SSDLC

The example below is illustrative, not a client engagement. A SaaS team adds "share a report with an external user by link."

1. Plan: requirements state that links expire, can be revoked, never expose other tenants' data, and that every access is logged. The feature is tiered high risk because it crosses tenant boundaries.
2. Design: the threat model flags guessable link tokens, tenant confusion and missing revocation. Mitigations: long random tokens, a tenant check on every request, and a revocation table.
3. Develop: a reviewer checks the tenant check in the data layer; SAST passes; SCA flags an outdated token library, which is upgraded.
4. Build and verify: DAST runs against staging. A focused pentest of the sharing flow tries token reuse after revocation, cross-tenant access with a valid token and privilege changes on the shared object.
5. Release: the pentest found that revoked links still worked for cached exports. It is fixed, retested and added to the regression suite; the release gate passes.
6. Operate: a disclosure-program report later shows the same caching pattern in another export feature. Root-cause analysis adds a coding rule: every cached object must re-check authorization.

NIST SSDF (SP 800-218): The Four Practice Groups

The NIST Secure Software Development Framework, SP 800-218 Version 1.1, was published as final in February 2022. It is not a checklist or a mandated process; it is a set of outcome-based practices, each with tasks, notional implementation examples and references to other standards such as BSIMM, OWASP SAMM, Microsoft SDL and IEC 62443. Version 1.1 has 19 practices in four groups:

PW.3 does not appear because NIST merged it into PW.4 during the 2021 revision.

What is changing. On December 17, 2025, NIST released SP 800-218 Rev. 1, SSDF Version 1.2, as an initial public draft in response to Executive Order 14306. The comment period closed on January 30, 2026, and as of NIST's pages checked on November 4, 2026, Version 1.1 remains the final version. The draft's change log adds two practices, PO.6 (define and implement a continuous process improvement plan) and PS.4 (ensure software updates are robust and reliable, including tiered and staged roll-outs), and adds examples such as testing the functionality that uses third-party dependencies under PW.8.2.

AI development. NIST also published SP 800-218A in July 2024, an SSDF community profile that adds practices for developing generative AI and dual-use foundation models. Teams that train or fine-tune models should treat it as an extension of the same SSDLC rather than a separate program.

Is the SSDF mandatory? For most private companies, no. It is a voluntary NIST framework. US federal agencies may still reference it when they set software assurance requirements under M-26-05, and customers increasingly ask suppliers to show how they align with it.

Where Penetration Testing Fits in a Secure SDLC

Penetration testing is not a phase. It is a verification activity that the SSDF places under PW.8 (test executable code) and RV.1 (identify and confirm vulnerabilities), and it pays off most where risk changes. A single annual test leaves every change between tests unverified by a human attacker's view.

Compliance regimes set their own minimum cadence; for one example, see our PCI DSS penetration testing guide.

What pentests find that scanners miss

Automated tools are good at known patterns: injection signatures, missing headers, outdated components. A manual tester works from how the application is supposed to behave and looks for ways to make it do something else. Typical examples:

• A user in one tenant reads another tenant's records by changing an identifier that every scanner request treated as valid.
• A discount, refund or approval workflow is completed out of order, skipping a check.
• A low-privilege role reaches an administrative API that is hidden from the user interface but not protected on the server.
• Two low-severity issues, such as verbose errors and a predictable identifier, combine into account takeover.

These are design and logic flaws, which is why the earlier phases, especially threat modeling and security-focused code review, should feed the tester's scope.

Feeding pentest results back into the SSDLC

A pentest only improves the SDLC if its results travel backward. For each confirmed finding:

1. Fix and retest (RV.2). Close the specific issue and confirm the fix.
2. Find the root cause (RV.3). Ask which phase should have caught it: a missing requirement, a gap in the threat model, a coding rule, a review checklist item or an untuned SAST rule.
3. Add a regression test (PW.8). SSDF suggests incorporating tests for previously reported vulnerabilities into the test suite so errors are not reintroduced.
4. Update the standard. Add the pattern to the secure coding standard, the threat model template or the design review checklist.

A good penetration testing report makes this easier: reproducible steps, affected components and root-cause notes map directly to these four actions.

Threat Modeling, Code Review, SAST, DAST and Pentests: Who Finds What

Each activity sees a different slice of risk. None replaces the others.

For a deeper comparison of the last two rows, read penetration testing vs bug bounty. For how these methods fit together in a testing program, see software testing vs security testing.

Secure by Design: CISA's Principles and the SSDLC

The SSDF tells you which practices to run. CISA's Secure by Design initiative asks why and for whom: it argues that software manufacturers, not customers, should carry the burden of security. CISA's Secure by Design page describes it as prioritizing customer security as a core business requirement rather than a technical feature.

The joint guide Shifting the Balance of Cybersecurity Risk, first published in April 2023 and revised on October 25, 2023 with international partners, sets out three principles:

1. Take ownership of customer security outcomes.
2. Embrace radical transparency and accountability.
3. Lead from the top.

The guide defines "secure by default" as products that are resilient against prevalent exploitation techniques out of the box, without added charge. For the SSDLC it makes two concrete recommendations: document conformance to a secure SDLC framework (in the United States, consider the NIST SSDF), and move beyond patching single bugs toward data-driven analysis that eliminates entire classes of vulnerability.

On May 8, 2024, CISA announced that 68 software manufacturers had signed its voluntary Secure by Design Pledge, committing to work toward seven goals within a year:

The pledge is not legally binding, but its goals make a useful checklist: if your SSDLC cannot show progress on them, buyers who follow CISA guidance will notice.

A Secure SDLC Maturity Model

Most organizations do not move from "no SSDLC" to "fully measured" at once. The model below is a DeepStrike editorial model for self-assessment, not a NIST or OWASP standard. It borrows the idea of graded levels from OWASP SAMM, which defines three maturity levels for each of its 15 security practices across five business functions (governance, design, implementation, verification and operations). Score each dimension separately; it is normal to be at different levels.

Use the model to choose one step up per dimension for the next two quarters rather than trying to reach Level 4 everywhere.

Choosing a framework

Framework sites: OWASP SAMM, Microsoft SDL, OWASP ASVS and SLSA.

These frameworks map to each other; the SSDF itself references BSIMM, OWASP SAMM and Microsoft SDL for each practice. Pick one as your backbone and use the others for depth.

How to Start a Secure SDLC: A 90-Day Plan

This plan is a practical starting sequence, not a requirement from any framework.

Days 1 to 30: baseline

• Inventory applications and give each a risk tier.
• Score the six dimensions of the maturity model with engineering and security leads.
• Write a one-page secure development policy that names owners and the SSDF as your reference.
• Turn on secret scanning and SCA for all repositories; they are low-friction and high-value.

Days 31 to 60: put gates on the riskiest work

• Require a lightweight threat model for every high-risk feature.
• Add SAST to pull requests for high-risk applications, blocking only high-confidence, high-severity rules at first.
• Define release criteria (PO.4): what must be true before a high-risk change ships.
• Schedule a manual pentest of the most exposed application if it has not had one recently.

Days 61 to 90: close the loop

• Feed pentest findings back: root cause, regression test and coding rule for each.
• Publish a vulnerability disclosure policy and a single intake channel.
• Start measuring (see below) and pick next-quarter targets per dimension.

Metrics That Show Your SSDLC Works

Track a few measures that reflect outcomes, not tool activity:

• Escape rate: share of confirmed vulnerabilities found in production or by pentests that earlier phases should have caught.
• Recurrence: findings of the same class (for example, broken object-level authorization) appearing again after a root-cause fix.
• Time to remediate by severity, from confirmation to verified fix.
• Threat model coverage: share of high-risk changes with a reviewed threat model.
• Gate health: SAST and SCA findings blocked versus overridden, and the false positive rate developers report.
• Retest pass rate: share of fixes that pass the first retest.

Our DevSecOps statistics roundup collects industry benchmarks you can compare against, with their sources.

Common Secure SDLC Mistakes

• Buying tools instead of building a process. SAST without triage owners becomes noise that developers learn to ignore.
• Treating the annual pentest as the SSDLC. It verifies one moment; it does not prevent flaws in the eleven months of changes that follow.
• Threat modeling once. A threat model from the first release is wrong after the third major feature.
• Gates nobody can pass. Blocking every medium-severity finding stops delivery and leads to exceptions for everything.
• Fixing instances, not classes. If the same bug type keeps returning, the root cause is in design or standards, not in one line of code.
• No response plan. Without a disclosure policy and a PSIRT owner, external reports get lost.
• Ignoring the build pipeline. A secure codebase can still ship a tampered artifact from an exposed CI runner.

Frequently Asked Questions

What is SSDLC?

SSDLC stands for secure software development lifecycle. It is a software development lifecycle with defined security activities in every phase: security requirements in planning, threat modeling in design, secure coding and code analysis in development, dynamic and penetration testing before release, and vulnerability response in production.

What is the difference between SSDLC and SDLC?

The SDLC is the process for planning, building, releasing and maintaining software. The SSDLC is the same process with security built into each phase, with owners and exit gates, instead of one security test at the end. The secure version catches many flaws earlier, when they are cheaper to fix.

What are the phases of a secure SDLC?

A common model has six phases: plan and requirements, design, develop, build and verify, release and deploy, and operate and respond. Frameworks name and split them differently; the NIST SSDF avoids fixed phases and groups practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities.

What is the NIST SSDF?

The Secure Software Development Framework, NIST SP 800-218, is a set of outcome-based secure development practices that can be added to any SDLC. Version 1.1 (February 2022) has 19 practices in four groups. Version 1.2 was released as an initial public draft on December 17, 2025, and adds two practices.

Is NIST SSDF mandatory?

Not for most private companies. Federal attestation requirements tied to it were rescinded by OMB memorandum M-26-05 on January 23, 2026, but agencies may still reference SP 800-218 and use the attestation form when setting risk-based software assurance requirements, so suppliers to government and regulated buyers are often asked to show alignment.

Where does penetration testing fit in the SDLC?

Penetration testing belongs in verification and operations: before release for high-risk changes, periodically in production, after significant changes and as a retest after fixes. For high-risk systems, an offensive review of the architecture and threat model during design adds value before code exists.

How often should you pentest in a secure SDLC?

At least once a year for important applications, plus before releasing high-risk features and after significant changes. Teams that release frequently often move to continuous or per-sprint testing so new functionality is tested soon after it ships.

Why is SSDLC required in an organization?

Because exploitation of software vulnerabilities is a leading way attackers get in, and because customers, regulators such as the EU under the Cyber Resilience Act, and government buyers increasingly expect evidence of secure development. An SSDLC also lowers cost by catching flaws before release.

Is the SDLC outdated?

No. Agile and DevOps changed how fast teams move through the lifecycle, not the need for planning, design, development, testing, release and maintenance. A secure SDLC works with any delivery model, including DevSecOps pipelines that run many security checks automatically.

Next Step: Verify Your SDLC With a Human Attacker's View

A secure SDLC works when every phase has a security activity, an owner and a gate, and when findings travel back to the phase that should have caught them. Start by scoring your six maturity dimensions, adding threat modeling and pull request checks to your riskiest work, and scheduling a pentest where risk is changing right now.

DeepStrike's web application penetration testing puts that verification step in place: manual testing that simulates real attacks based on your application's logic, checks from multiple users' perspectives, findings validated through exploitation, fix recommendations, a technical presentation for your engineers and re-testing to confirm that fixes hold. For teams that release often, continuous penetration testing integrates manual security testing into the SDLC so changes are tested before they reach production. To discuss scope, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1 (February 2022)
• NIST SP 800-218 Rev. 1 (Initial Public Draft): SSDF Version 1.2 (December 17, 2025)
• NIST SP 800-218A: Secure Software Development Practices for Generative AI and Dual-Use Foundation Models
• NIST: Secure Software Development Framework project
• OMB Memorandum M-26-05: Adopting a Risk-based Approach to Software and Hardware Security (January 23, 2026)
• CISA: Secure Software Development Attestation Form
• CISA: Secure by Design
• CISA and partners: Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software (revised October 25, 2023)
• CISA: Secure by Design Pledge
• CISA: CISA Announces Secure by Design Commitments from Leading Technology Providers (May 8, 2024)
• European Commission: Cyber Resilience Act
• Verizon: 2026 Data Breach Investigations Report
• OWASP Software Assurance Maturity Model (SAMM)
• OWASP Application Security Verification Standard (ASVS)
• Microsoft Security Development Lifecycle practices
• SLSA: Supply-chain Levels for Software Artifacts