How PASTA Threat Modeling Supports Secure SDLC

Secure SDLC frameworks such as BSIMM and OWASP SAMM describe which security activities organizations perform, but say comparatively little about how to prioritize among findings once those activities are running. This paper examines whether PASTA (Process for Attack Simulation and Threat Analysis) threat modeling closes that gap across the full software development lifecycle, or primarily at the design phase where it is most commonly applied. We map PASTA’s seven stages against SDLC phases, examine current secure-development adoption data, and find the mapping is clean for early phases and considerably more aspirational for later ones. We also flag and decline to repeat a widely cited but unverifiable statistic about the cost of late-stage defect remediation, substituting a more defensible current source.

Introduction

Frameworks like BSIMM and OWASP SAMM are useful because they are descriptive: they document what security activities organizations actually perform, at what frequency, across which phases of development. What they generally do not provide is a mechanism for weighing one finding against another once an activity code review, architecture analysis, or penetration testing produces results. That prioritization problem is where a risk-centric threat modeling methodology like PASTA is typically positioned as complementary rather than competing.

This paper asks a specific question: does PASTA, as an analytical methodology, actually extend usefully across the entire secure SDLC requirements, design, development, testing, deployment, and maintenance or is its practical application concentrated at one or two of those phases, with the remaining phases supported only in theory? Section 2 addresses the economic argument for early-phase analysis and corrects a commonly miscited statistic in the process. Section 3 maps PASTA’s seven stages against SDLC phases directly. Section 4 examines where that mapping holds up against current adoption data and where it doesn’t. Section 5 states what actually closing the gap would require. Section 6 lists this paper’s limitations. Section 7 concludes.

The Economic Case for Early-Stage Analysis, and a Necessary Correction

The most commonly cited justification for shifting security analysis earlier in the SDLC is a claim, usually attributed to “the IBM Systems Sciences Institute,” that fixing a defect in production costs on the order of 100 times more than fixing the same defect during design. This figure appears, in various forms, across a large share of secure-development marketing and training material. It also appears to be untraceable: researchers who have attempted to locate the original IBM study behind the claim have not been able to find it, and the figure’s exact multipliers vary inconsistently across the sources that cite it, which is itself a signal of a statistic propagating by citation of citation rather than by anyone checking the original source. This paper does not repeat it as established fact.

A more defensible and current figure comes from the Consortium for Information & Software Quality’s most recent Cost of Poor Software Quality report, which estimated the total cost of poor software quality in the United States at $2.41 trillion annually, split roughly across operational failures ($1.56 trillion), technical debt ($1.52 trillion), and unsuccessful projects ($260 billion).

This figure supports a narrower and more defensible claim than the 100x multiplier: poor software quality, of which security defects are one significant contributor, carries a cost that concentrates in operational failure and accumulated technical debt rather than in the direct cost of a single late-stage fix. That is a real argument for early-phase risk analysis. It is a different, and more honest, argument than a specific, unverifiable multiplier suggests.

Mapping PASTA’s Seven Stages Against SDLC Phases

PASTA’s seven stages map onto SDLC phases with uneven cleanliness. The first three stages definition of objectives, definition of technical scope, and application decomposition align naturally with the requirements and design phases, since they require exactly the artifacts (business requirements, architecture diagrams, data flow definitions) that are produced during design and not yet available earlier or reliably available later.

The fourth and fifth stages, threat analysis and weakness and vulnerability analysis, sit awkwardly between design and development. Threat analysis, correlating adversary intelligence against the system’s decomposition, can begin during design but is only as accurate as the implementation choices it’s checked against, which means it properly belongs partly in development as well. Vulnerability analysis depends even more heavily on implementation detail and is difficult to perform meaningfully before code exists.

The sixth stage, attack modeling, aligns most naturally with the testing phase, particularly where testing includes adversarial validation such as penetration testing or red teaming rather than only functional and unit testing. The seventh stage, risk and impact analysis, is not phase-specific at all; it is meant to be revisited whenever new findings from any phase accumulate, which places it conceptually across deployment and maintenance as much as design.

Where the Mapping Holds Up, and Where It Doesn’t

The above mapping implies that PASTA, applied faithfully, should touch every SDLC phase. Current secure-development adoption data suggests most organizations’ actual practice concentrates much more heavily on the phases the mapping identifies as cleanest requirements and design.

Seezo’s 2026 analysis of the BSIMM16 report found that security design review, called security feature review in BSIMM’s terminology, is now observed in 80.2 percent of the 111 participating organizations, making it one of the most widely adopted security activities tracked by the framework. This is consistent with Section 3’s finding that PASTA’s early stages map cleanly onto design, since design review is exactly the point where an analysis resembling PASTA’s first three stages is easiest to insert into existing processes.

The practices growing fastest in the same report a roughly 30 percent increase in SBOM production, over 40 percent growth in streamlining responsible vulnerability disclosure, and more than a 50 percent surge in automated infrastructure security verification are concentrated in deployment and maintenance-adjacent activities driven substantially by regulatory pressure, such as the EU Cyber Resilience Act, rather than by risk-centric analysis extending forward from design. This is a meaningful gap: the SDLC phases growing fastest in adoption are not obviously the phases where PASTA’s later stages (attack modeling, ongoing risk and impact analysis) are being extended into, based on the available data. BSIMM does not track “continuous threat modeling” or “PASTA-specific attack modeling” as a distinctly labeled activity with its own adoption percentage, which is itself worth noting: the data available to test Section 3’s later-stage mapping is thinner than the data available for the design-phase mapping, not because the later stages don’t matter, but because the industry’s own measurement frameworks don’t yet isolate them cleanly.

What “Supporting the Secure SDLC” Actually Requires

Based on Sections 3 and 4, PASTA threat modeling supporting the full secure SDLC, rather than only the design phase, requires two things that are not automatic consequences of running a PASTA exercise once. First, the technical scope and decomposition from stages two and three need to be revisited as implementation and infrastructure change, rather than treated as accurate from a single design-phase session. Second, stages six and seven attack modeling and risk and impact analysis need a mechanism for staying current as new findings accumulate through testing and production monitoring, rather than being finalized once and archived alongside the original design documentation.

Continuous platforms built specifically to keep a threat model current as code and infrastructure change, such as Fork among them, are a direct structural response to this requirement. Whether an organization uses a continuous platform or a disciplined manual re-review cadence, the underlying requirement is the same: PASTA’s later stages only support the secure SDLC as a whole if something forces stages four through seven to be revisited on a cadence that matches how quickly the system actually changes, which for most modern applications is considerably faster than an annual or per-release schedule.

Limitations and Open Questions

This paper’s argument depends on a structural mapping exercise in Section 3 that has not been independently validated against outcome data. No dataset cited here measures whether organizations that extend PASTA-style analysis across all seven stages and every SDLC phase experience fewer incidents or lower remediation costs than organizations that apply it only at design. The claim that later-stage extension matters is inferred from the logic of the methodology and from the adoption-gap data in Section 4, not measured directly.

Second, the correction made in Section 2 is worth sitting with as a methodological point in its own right: a specific, precise-sounding statistic (the 100x multiplier) achieved wide circulation despite an apparently untraceable original source, while a real, attributable, and considerably less quotable finding (the CISQ cost breakdown) is cited far less often in the same secure-development literature. This suggests the field’s citation practices reward specificity and memorability over verifiability, a pattern this paper has tried explicitly not to repeat, though it cannot rule out having done so elsewhere.

Third, BSIMM is a descriptive model of what participating organizations do, not a representative sample of the software industry as a whole, and its participant pool skews toward organizations mature enough to take part in a BSIMM assessment in the first place. Adoption figures cited in Section 4 should be read as describing relatively security-mature organizations, not the median software-producing organization.

Conclusion

PASTA threat modeling maps cleanly onto the requirements and design phases of the secure SDLC, which is also where current adoption data shows the most widespread practice of comparable activities. Its later stages threat analysis carried into development, attack modeling aligned with adversarial testing, and risk and impact analysis revisited through deployment and maintenance are logically part of the same methodology but are supported by considerably thinner adoption data, partly because the industry’s own measurement frameworks do not yet track them as distinctly as they track design-phase activity. Supporting the full secure SDLC, rather than only its earliest phase, requires a mechanism for keeping PASTA’s later-stage analysis current as systems change, which is a requirement most organizations have not yet operationalized as consistently as they have operationalized design review.

References

1. Consortium for Information & Software Quality (CISQ). Cost of Poor Software Quality in the US (2022, most recent edition), authored by Herb Krasner.
2. Black Duck. BSIMM16 Report. January/February 2026.
3. Seezo. The Evolution of Security Design Review, analysis of BSIMM16 data, February 2026.
4. UcedaVélez, T., and Morana, M.M. Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis. Wiley, 2015.

Frequently Asked Questions