Software Factory Security Framework (SF²)

Demand for security work grows faster than your team's capacity to deliver it, and there is a day when the two cross. SF² is a strategic response. Instead of racing to hire, it asks where your organization actually stands, then sequences the security work that compounds from there.

The framework rests on two ideas. Five Universal Security Conditions that every software-producing organization owes: Supply Chain first because it degrades fastest, then Third-Party, Process, Runtime, and Adaptive Capacity. And four strategic positions, set by your Blast Radius and Operational Readiness, that decide what to fund first and how fast to move.

Start with the Executive Summary, then assess your strategic position.

Executive Summary

The Security Scaling Challenge

Run a security org long enough and the math catches up with you. Demand for security work grows faster than your team's capacity to deliver it, and there's a day when the two cross. You're managing more security reviews, compliance requests, and incident responses while the organization demands faster innovation and delivery.

The traditional response, hiring more security professionals, provides temporary relief but becomes increasingly difficult to sustain. This framework presents a different approach: strategic resource allocation that enables sustainable security scaling while improving business outcomes.

The Strategic Opportunity

Organizations that work through this well solve more than a scaling problem. They build competitive advantages: faster time-to-market, higher developer productivity, and more robust security postures at the same time. The shift requires understanding that security scaling is a strategic and organizational challenge before it's a technical one.

Framework Overview

The Software Factory Security Framework (SF²) provides security leaders with:

Universal Security Conditions

Five Universal Security Conditions that apply to every software-producing organization:

1. Supply Chain (#1 Priority): Managing security risks from all external dependencies
2. Third-Party: Managing risks from integrated services and platforms
3. Process: Embedding security throughout the development lifecycle
4. Runtime: Maintaining security of systems in production
5. Adaptive Capacity: Whether the system as a whole can absorb a surprise it was not designed for and keep working

Learn more about the Universal Security Conditions

Strategic Positioning Tool

Two-axis framework for understanding your organization's current state:

• Blast Radius (How far a failure can reach): Small reach → Large reach
• Operational Readiness (How you operate): Lower → Higher

This creates four strategic positions: Studio, Lean, Craft, and Mass.

Assess your position

Investment Portfolio Approach

Systematic method for balancing security investments:

• BAU Activities (Constrain): Manual work that scales with growth
• Scaling Investments (Prioritize): Capabilities that reduce manual effort
• Platform Effects (Multiply): Benefits that deliver internal and external value

Explore investment strategy

Contextual Adaptation Guide

Eight modifiers that influence your implementation approach:

1. Attack Landscape Maturity
2. Supply Chain Complexity
3. Regulatory Constraints
4. Crisis Events
5. Change Capacity
6. Relationship Health
7. AI Saturation
8. PQC Exposure

Understand your context

Strategic Context: Adversary Evolution

Critical Shift in Adversary Capabilities

In recent years, attackers have shifted from targeted reconnaissance to automated discovery at internet scale, sweeping billions of assets to find vulnerabilities.

Organizations using manual security processes face a fundamental capability gap: attackers can discover unknown systems faster than defenders can catalog them.

Understanding these adversary evolution patterns helps security leaders prioritize investments that shift economic advantage away from attackers.

How This Framework Works

This framework works alongside existing security methodologies (NIST SSDF, OWASP SAMM, BSIMM) by addressing the strategic resource allocation and organizational change questions they don't answer.

Your Question	SF² Answer
How do I sustainably invest in security as we scale?	Investment Portfolio Framework
How do I adapt security approaches to my org?	Strategic Positioning + Contextual Modifiers
How do I align security with business outcomes?	Platform Effects + Evaluation Criteria

Executive Insight

Quote

Hiring alone doesn't solve security scaling. It takes strategic investment in capabilities that reduce manual effort, and that is what lets security effectiveness and delivery speed rise together instead of trading off against each other.

Getting Started

Three Steps to Apply This Framework

1. Assess Your Position: Use the Two-Axis Model to understand your current state
2. Evaluate Context: Review Contextual Modifiers that influence your approach
3. Implement Strategically: Follow your Implementation Guide for actionable next steps: Studio, Lean, Craft, or Mass

---

Applying the framework starts with assessing your position, as the three steps above lay out. To read the underlying concepts in sequence, continue to Foundation: Software Factory Definition.

Continue to Foundation

Foundation

Foundation: Software Factory Definition

The Universal Challenge

Whether you're leading security for a three-person startup or a multinational corporation, you face the same fundamental question: How do you maintain security accountability for code-based systems that deliver value to end users?

This responsibility spans your entire value delivery chain, from internal development through third-party dependencies to production operations.

What is a Software Factory?

Definition

A Software Factory is whoever bears operational responsibility for deploying, maintaining, and evolving code-based systems that deliver value to end users, including systematic risk stewardship across all components in their value delivery chain, whether directly controlled or third-party.

This definition encompasses:

• Scale Agnostic: From single-developer startups to enterprise organizations
• Technology Agnostic: Any tech stack, deployment model, or infrastructure approach
• Responsibility Focused: Emphasis on operational accountability rather than just code ownership
• Third-Party Inclusive: Recognition that modern software depends extensively on external components

Key Characteristics

Operational Responsibility

Software Factories are accountable for how code reaches end users and impacts their experience, regardless of whether every component is built in-house.

Value Delivery Chain

The entire pipeline from code creation through production deployment and ongoing operations.

Risk Stewardship

Ongoing responsibility for understanding, assessing, and responding to security risks across the complete software stack.

Systematic Processes

Repeatable, improvable approaches to software creation and deployment rather than ad-hoc development.

Why This Definition Matters

Understanding your organization as a Software Factory helps clarify:

1. Scope of Responsibility: You're accountable for security across the entire value delivery chain, beyond the code you write
2. Third-Party Dependencies: External components are part of your security responsibility
3. Operational Focus: Security accountability extends through production operations
4. Universal Applicability: The same framework applies regardless of organization size or technology choices

How This Framework Complements Existing Security Standards

SF² addresses strategic questions that existing frameworks don't answer:

• Resource Allocation Strategy: How do you sustainably invest in security as your organization scales?
• Contextual Implementation: How do you adapt security approaches to your specific organizational reality?
• Business Integration: How do you align security investments with business outcomes and competitive advantage?

Framework Relationships

Framework	Primary Focus	SF² Relationship	When to Use Together
NIST SSDF	Secure development lifecycle practices	SF² addresses sustainable resourcing of SSDF practices at scale	Use SSDF for development security practices, SF² for sustainable implementation strategy
OWASP SAMM	Security practice maturity progression	SF² contextualizes SAMM implementation based on organizational readiness	Implementation speed and scope vary by organizational complexity and readiness level
BSIMM	Security activity measurement and benchmarking	SF² determines investment priorities for BSIMM activities based on organizational positioning	Use SF² assessment to guide BSIMM implementation scope and sequencing
OWASP ASVS	Security verification requirements	SF² helps sequence ASVS implementation within scaling investment strategy	Use SF² to determine risk-based ASVS subset vs. comprehensive implementation

The four frameworks in the table are today's instance of the baseline rather than the baseline itself. SF² overlays whatever the prevailing practice baseline is, and right now that is a set of human-pace maturity models: SSDF, SAMM, BSIMM, ASVS. That baseline is already broadening. As more software gets built and shipped by machines, a new layer is emerging alongside the maturity models: attestation and capability standards. Two examples point the way. Verifiable provenance for what was built is the direction SLSA points, and scoped identity for what an agent may do is what SPIFFE provides. The roster of the baseline will grow; SF²'s job will not. It sequences the investment, decides what to fund first for your context, and aims it at the thing the baseline is ultimately trying to protect: a capability boundary that limits what any part of the system can do. That boundary is the floor. When the baseline grows a new wing, SF² sequences it the way it sequenced the old. The durable commitment is to that floor, set out in Boundary Enforcement, rather than to the four names that express it today.

Examples of Software Factories

To illustrate the universal nature of this definition:

Startup Software Factory

• Team: 5 developers
• Product: SaaS application
• Value Chain: Cloud infrastructure (AWS), development tools (GitHub), monitoring (Datadog), dozens of open-source dependencies
• Security Responsibility: Entire stack, despite building ~5% of code themselves

Enterprise Software Factory

• Team: 500+ developers across multiple teams
• Products: Multiple applications and services
• Value Chain: Multi-cloud infrastructure, extensive third-party integrations, internal platform services, hundreds of dependencies
• Security Responsibility: Complex ecosystem with multiple ownership boundaries but unified accountability to end users

Platform Software Factory

• Team: 50 platform engineers
• Product: Internal developer platform
• Value Chain: Kubernetes infrastructure, CI/CD pipelines, security tooling, compliance automation
• Security Responsibility: Enabling other teams while maintaining platform security posture

Common Thread

In each case, security responsibility extends far beyond code directly written by the organization. The Software Factory definition emphasizes this operational accountability across the complete value delivery chain.

This raises a gap the rest of the framework has to close. You are accountable for far more than you can personally read, and as generation outpaces comprehension the gap widens: the volume of code, dependencies, and agent actions you answer for grows faster than anyone's capacity to inspect it. Accountability does not shrink to match. You discharge it by bounding what the system was ever able to do, rather than by comprehending everything that happened. Comprehending everything is no longer possible at scale. That is what boundary enforcement and the three-layer model provide: a way to answer for a system you cannot fully read. The same logic governs what you delegate rather than build: as Third-Party stewardship puts it, a contract can move a capped slice of the cost, never the responsibility.

---

Next Steps

Now that you understand what constitutes a Software Factory, the next section explores the five Universal Security Conditions that every Software Factory must address.

Continue to Universal Security Conditions Back to Executive Summary

The Atelier and the Factory

Foundation · The atelier and the factory

This chapter extends: Software Factory Definition. Scope: the steelmanned case that AI and flat orgs have dissolved the professional software factory, from vibe coding to the artist colony, and why SF² plus Coadaptive Security answers the movement rather than any single voice.

Not everyone who builds software believes they work in a factory, and the ranks of the unbelievers are growing. One current says the tools have democratized creation: describe what you want to an AI and working software falls out, so building value no longer belongs to professional engineers. An older current says the org was always the wrong picture, that titles and reporting lines are scaffolding the work does not need. Shyam Sankar, Palantir's CTO, gives the second its sharpest form, calling software production an artist colony where position and portfolio decouple and the artist and the work are the only durable units. The two currents arrive at the same verdict: the software factory is a dead metaphor. A framework called Software Factory Security owes that verdict a real answer rather than a dismissal. The answer is that both currents describe something true about the surface of the work, and both miss the factory that makes their version of it possible.

The case against the factory, steelmanned

The strongest version arrives in two registers. The first is about the tools. Andrej Karpathy, who named the practice vibe coding, argues that prompting your way to working software while you "forget that the code even exists" has opened building to anyone and released a wave of creativity. Jensen Huang tells audiences that everyone is a programmer now, that you just have to say something to the computer. Snowflake's Sridhar Ramaswamy describes salespeople who ship their own dashboards because all they do is describe what they want in English. The proof points are concrete: a British GP with no coding background built and shipped a working patient app for his clinic in four days, after agencies had quoted the job at £75,000. Replit's founder, Amjad Masad, frames that as the whole point, a platform he is building for a billion people rather than for professional engineers. The claim runs deeper than easier tooling. Taken to its limit, it is that producing software has stopped being a profession, a conclusion the movement points toward more than any single voice states outright.

The second register is about the shape of the org rather than the power of the tools, and Sankar states it most cleanly. In Position and Portfolio he argues that titles and org charts are scaffolding the work does not need: "There is only the artist and the work." Roles are fluid, ownership stays with the person who made the thing, and opportunity gets seized without waiting for a box on a chart to authorize it. He put it more plainly to the Financial Times in 2021: "We at Palantir, we're an artist colony, extraordinarily and exquisitely flat."

This is not generational posturing, and it names something real. A generation of engineers reads software as craft, where the person and the artifact are inseparable and the value lives in judgment rather than in process. Anyone who has watched one strong engineer outproduce a carefully managed team of ten has felt the pull of the argument. The atelier framing is a real cultural force, and a framework that pretends otherwise gets ignored by exactly the people it most needs to reach.

Why "Software Factory" is the right term anyway

The factory framing survives the critique because it answers a different question. The atelier describes how creative work feels and how talent arranges itself. The factory describes who is accountable when ten thousand deployments a day have to ship safely. Those are not competing claims about the same thing. The term names operational responsibility for delivery at scale, and that responsibility does not dissolve because the people doing the work think of themselves as artists. Someone still owns the blast radius when the artist's brilliant, unreviewed change reaches production.

Call the work a factory and the objection writes itself: an assembly line, the opposite of craft, the very image the democratized-creation crowd wants to leave behind. But a software factory optimizes something other than the throughput of identical parts: the time it takes for value to reach a customer, and for that customer's response to travel back to the people making it, so each version improves on the one before. The model for that is Toyota's line, where quality is built in at the source and anyone can pull the andon cord to halt production the instant a defect appears. Automate that discipline and the line catches its own defects while still answering to a human who can stop it, and the people it frees move up to deciding what to build while the machine handles how it ships.

That is what the democratization story gets right and stops short of. Describing software and delivering it are different acts, and the second one is the factory. The GP who shipped a patient app in four days never built a factory, but he ran on one: Replit carried the pipeline, the dependencies, the runtime, and the blast radius that four days of prompting could not. The wider building spreads, the more delivery rides on platforms like it. The factory outlived the org. It moved under the builder, into the platform.

This is the part the critique gets closest to and still misses. The org chart is not what makes someone responsible. But accountability follows the work to wherever the factory now runs, whether the org has flattened or the builder works alone. The GP still answers for patient data, and so does the platform underneath him. HIPAA does not care how many people were in the room. The AI era hands you a factory you did not build, and asks who owns it.

That platform is a real company with its own security function, often a better one than a lone builder could staff, and buying that function does not take the responsibility off the builder. A contract shifts a capped slice of the cost onto the platform and the duty to answer for what ships stays with whoever put the software in front of a user, the ground Third-Party stewardship already works.

The term is industrial-lineage vocabulary with a fifty-year paper trail.

Term provenance

The history predates the current debate by decades:

• Bob Bemer, 1968: the GE paper often credited as the earliest "software factory" proposal.
• Cusumano, Michael, 1991: Japan's Software Factories: A Challenge to U.S. Management. Oxford University Press.
• Greenfield, Jack and Keith Short, 2004: Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley.
• U.S. Department of Defense: 20+ accredited Software Factories operating today (Platform One, Kessel Run, Kobayashi Maru, Black Pearl, others).

The Defense Department runs more than twenty accredited software factories right now. The word carries operational and regulatory weight in the one ecosystem where getting delivery wrong gets people killed. That is provenance rather than proof that every shop should think in factory terms; it shows the word is real and regulated where delivery is life-and-death. It is the right word for what SF² governs.

SF² + Coadaptive as the synthesis

Both framings are load-bearing, and the synthesis is naming the layer where each one holds.

The factory framing is right at the layer of operational accountability. Foundation and the Universal Security Conditions live here: who owns the supply chain, who answers for what runs in production, how delivery stays safe as it scales. The atelier framing, and the democratization argument with it, is right at the layer of the creative act and how roles get arranged inside a team. SF² never claimed that layer and does not want it. How you organize your artists is your business.

Coadaptive Security extends the picture to a third layer neither metaphor anticipated: the unit of operation in the AI era. That unit is most often a person working with agents, and it resembles a paired-intelligence cell more than a factory worker or a lone craftsman. Chapter 03, The Unit of Defense, takes that up. The synthesis names the layer at which each framing earns its keep, so no one has to choose between them.

The AI-era production-model question

The movement surfaces a harder question than the one it answers, and the synthesis has to sit with it honestly. If the unit of production is shifting from a team of humans to a human working with agents, neither metaphor maps. A factory is a human assembly line. An atelier is a lone craftsman with tools. A paired-intelligence cell is neither. The tools in this case reason, act, and occasionally get things wrong on their own initiative.

Foundation does not resolve that question. It names it and hands it forward to Coadaptive Security Chapter 03, where the unit of operation and the property that defends it get worked out.

See also

• Software Factory Definition: the base definition this chapter engages
• Coadaptive Security · 03 The Unit of Defense: where the AI-era production-model question is taken up
• Coadaptive Security · Overview: the AI-era layer that absorbs the production-model shift

Universal Security Conditions

Universal Security Conditions

Conditions versus controls

A control is something you check off. It passes or it fails, it lives as a line in a spreadsheet, and half the energy around it goes into arguing the spirit of the control rather than the state of the system. A condition is a different kind of object. It is something you cultivate and keep alive, and it has no passing grade. The security posture of a Software Factory is a set of conditions you tend. Like anything living, they start to degrade the moment you stop tending them.

Your strategic position tells you how to tend them. A Craft shop and a Lean enterprise cultivate the same conditions with very different tools, budgets, and timelines. The conditions themselves do not move with size, stack, or industry. They are what every Software Factory has to keep alive regardless of where it sits on the map, which is why this section comes before the positioning work and not after it.

There are four conditions you can hand to a team, and one you cannot.

Four conditions you can name, staff, and put on an org chart, plus Adaptive Capacity, the resilience of the whole system, running across all four. You assess the fifth; you cannot hand it to a team.

The four you can staff

Condition	Kind	The question it asks	The lever
Supply Chain (#1)	Domain	Do I know what is inside what I shipped?	Comprehension: SBOM, provenance, signing, pinning
Third-Party	Domain	Do I know what I handed off, and who holds the bag when it fails?	Containment: blast-radius limits, shared-responsibility clarity, failover
Process	Mechanism	Does the way we build produce security, or bolt it on afterward?	Feedback: security arriving while the work happens, ahead of the end-of-cycle review
Runtime	Domain	Can we sense what production is doing right now and respond before a user does?	Observability: detection, response, recovery

These four map to functions you can name, staff, and put on an org chart. That is deliberate. A condition you cannot assign to anyone is a condition nobody tends.

The four are not the same kind of thing. Supply Chain, Third-Party, and Runtime are domains, a scope of risk you can point to: the code you pulled in, the services you handed off, the system running now. Process is a mechanism: the way those domains get built, which is why a pipeline that emits provenance tends Supply Chain for free. Adaptive Capacity, further down, is a third kind entirely: a property of the whole system, not a domain or a mechanism. The numbers label three different kinds of thing on one list, and tempo is the only ranking the list carries, which is why Supply Chain leads. A domain, a mechanism, and a system property do not belong on the same maturity scale, so read the column before you build a scorecard.

Supply Chain and Third-Party are not the same condition

They look like one thing. They are not, and the line between them is where a lot of programs quietly fail.

Supply Chain is what you pull in: third-party libraries, base images, sidecars, the code you embed and then ship as if it were your own. Once you embed it, the liability is yours. You can also do something about it, because the artifact is in your hands. You can read it, generate an SBOM, sign it, pin it, rebuild it. Supply Chain is soil: you can amend it. The way it fails is that you did not look.

Third-Party is what you hand off: the payments processor, the data warehouse, the identity-verification provider, the cloud, the SIEM. Some of these are infrastructure; others are core to how your product delivers value at all. You delegate the function, and a shared-responsibility model splits the work. A contract can shift the legal liability to them; it cannot shift the responsibility, and no certificate hands it back. Compliance is a market-access key: a vendor earns FedRAMP to unlock the federal market, and its attestation retires none of your risk. You still have to do your part and trust they are doing theirs. You cannot directly inspect or observe what they run. Third-Party is weather: you cannot change it, you can only prepare for it. The way it fails is that they got breached and you inherited it anyway.

Lumping both under "supply chain" because the word has stretched to cover everything external is the move that hides the seam. The two conditions take different muscles. One is a comprehension problem: you embedded something and never read it. The other is an opacity problem: you delegated something you cannot directly inspect, and no contract or certificate changes that. Keep them apart on the page so they stay apart in the work.

Supply Chain is what you pull in and can amend, a comprehension problem. Third-Party is what you hand off and can only prepare for, an opacity problem. Lump them together and you hide the seam.

Supply Chain is still the loudest

Of the four, Supply Chain has been the one to watch for years, roughly since 2017, when adversaries moved discovery to automation at internet scale and started finding vulnerable dependencies faster than defenders could inventory them. This is a matter of tempo. Supply Chain does not matter more than the rest; it degrades faster and gets exploited sooner, so it earns first call on attention and budget. Treat it as the default #1 and argue yourself down from there if your context warrants.

The one you cannot staff: Adaptive Capacity

The fifth condition does not get a team, and that is the point.

Adaptive Capacity is whether the system as a whole can absorb a surprise it was not designed for and keep working. It is the old Continuous Learning idea, finally named for what it actually is. The other four conditions each map to a function you can put on an org chart. This one does not. It is closer to the resilience of an ecosystem than to anything you could install or assign. The capacity of a living system to take a shock, a drought or a new predator, and reorganize without collapsing is spread across the whole web rather than held in any single species or place. It is never finished, because the system and the things stressing it keep changing against each other. You assess whether the system has this capacity. You cannot hand it to a team.

It runs across the other four rather than beside them. A healthy Adaptive Capacity shows up as blameless post-incident review that changes something, as feedback loops that shorten, as the organization sensing a shift in the threat landscape and adjusting before it gets hit rather than after. When it is missing, the other four can each look fine on a maturity chart while the system stays brittle, because nothing is teaching it to bend.

This is the condition that carries the framework's resilience thinking, and it is the seam where this base framework meets the Coadaptive Security layer. The idea comes from ecology. A system survives shocks when it can reorganize as new ones arrive, and that capacity lives in the whole web rather than in any single part. Security works the same way. Certify a system once and trust it to hold, and it falls behind, because the things trying to break it keep changing while it stands still. Adaptive Capacity measures whether the whole system is still adapting faster than its adversaries. That is the question worth asking.

How the conditions hold each other up

The conditions are coupled, and the coupling is where leverage hides:

• A weak Supply Chain condition rarely announces itself in Supply Chain. It surfaces at Runtime, as the incident you trace back to a dependency you never inventoried.
• Process is where the other conditions either get cultivated or get skipped. A build pipeline that produces provenance is tending Supply Chain for free.
• Third-Party failures are bounded by Runtime containment. The vendor breach you survive is the one whose blast radius you limited in advance.
• Adaptive Capacity is how all four improve at all. Without it, you are just repainting the same four walls on a fixed cadence.

Adaptive Capacity is a different kind of thing from the other four: the resilience of the whole system, which you assess but cannot staff.

Invest where a single move strengthens more than one condition at once. Those are the moves worth sequencing first.

Universal conditions, local implementation

The conditions are universal. How you cultivate them varies.

A three-person Craft shop and a five-thousand-person Lean enterprise both have to tend Supply Chain, but one does it with a single well-chosen managed scanner and the other with a platform team and a paved road. The Strategic Positioning section is how you decide which version of "tending" your organization can actually sustain. Read the conditions here as the what. Read positioning as the how.

Naming note (v0.5 → v0.6)

In v0.5 this section was "Universal Risk Stewardship Responsibilities," organized as five areas you steward. v0.6 reframes them as conditions you cultivate, splits the old Supply Chain area along the embedded/delegated line, and recasts Continuous Learning as the cross-cutting Adaptive Capacity condition. The migration crosswalk maps every old name to its v0.6 home.

Next Steps

Start with the condition that degrades fastest:

Supply Chain (#1) Third-Party Adaptive Capacity

---

Back to Foundation

Supply Chain

Supply Chain is the condition that asks one question: do you know what is inside what you shipped? Every modern build pulls in code you did not write, the third-party libraries, base images, sidecars, and a transitive dependency four levels down that you have never once opened. Once you embed it, you ship it as if it were your own, and the liability is yours from that moment on.

The question now reaches past code. A modern build also ships model weights you did not train, datasets you did not assemble, and the pieces an agent pulls in to do its work: the skills it loads, the tools it calls, the MCP servers it connects to. Each one you embed and then ship as your own, the same as any library, and the liability arrives with it. These resist inventory harder than code does. An agent's tools tend to self-install, self-update, and connect at runtime, often outside whatever software intake process you thought you had. And a model weight arrives as an opaque blob you cannot read or rebuild from source, whose origins you take on trust. The surface widened faster than the practice did. The discipline does not change: know what is inside, and refuse to ship what you cannot account for.

Some of what you embed does not sit still. An agent's tools and MCP servers reach out at runtime to dependencies of their own, pulled in past whatever intake you thought you had, so the thing you shipped is operating sub-dependencies you never reviewed. That is the operator beneath the operator seen from the supply side: a delegated dependency, embedded.

This is the condition you can do the most about, because the artifact is in your hands. You can read it, generate an SBOM, sign it, pin it, rebuild it from source. Supply Chain is soil. You can amend it. The way it fails is almost always the same: you did not look.

Why it is the loudest of the four

Supply Chain has been the one to watch for years, roughly since 2017, when adversaries moved discovery to automation at internet scale and began finding vulnerable dependencies faster than defenders could inventory them. The asymmetry is the whole problem. An attacker runs continuous, internet-wide scans for a known-vulnerable package. A defender who inventories dependencies once a quarter is answering last quarter's question.

This is a matter of tempo. Supply Chain does not matter more than the rest; it degrades faster and gets exploited sooner, so it earns first call on attention and budget. Treat it as the default #1 and argue yourself down from there if your context warrants.

The asymmetry that earns it the slot is that adversaries scan faster than defenders inventory. If build-generated inventory ever becomes universal and continuous, that gap narrows and the call would have to be re-argued. Abandonment is the part that would survive the change, because knowing which orphaned package you depend on does not make it maintained.

What cultivating it looks like

Tending Supply Chain is the practice of comprehension: closing the gap between what you shipped and what you actually understand about it. That gap is widening on its own, as more of the code entering your artifacts is generated faster than anyone reads it. The Coadaptive Security layer takes up that pressure directly. Here it is enough to say the lever is comprehension, and the work is refusing to ship what you have not understood.

• Inventory, continuously. A complete, current picture of direct and transitive dependencies, generated by the build rather than maintained by hand. The SBOM is the artifact; the comprehension is the point.
• Establish provenance and sign. Know where each artifact came from and that it arrived unaltered. Verified provenance turns "we think this is the library we meant" into something you can check.
• Pin and rebuild. Pin versions so a dependency cannot change under you silently. Rebuild from source where the supply matters enough to warrant it.
• Catch the supply-specific attacks. Dependency confusion, typosquatting, a compromised maintainer pushing a poisoned release, and now a poisoned MCP server or a tool whose description carries instructions the model will follow. They are attacks on your trust rather than bugs in your code, which is why your own tests never catch them.
• Weigh survivability alongside security. A dependency's future is part of its risk. Take it on partly on whether the project is alive and whether you could carry it if the upstream stopped.

None of this is a control you install once. A dependency you vetted last year is a dependency that has shipped forty releases since. Comprehension is a standing practice or it is nothing.

When no one is left to tend it

The practices so far assume the thing you embedded keeps shipping. You inventory it, sign it, pin it, and wait for the next release to patch. But a dependency can fail in a way none of that touches: it can simply stop. The maintainer walks away, the project is archived, the company behind it folds or sells and the buyer turns it off. The code still sits in your tree doing its job, until the day a vulnerability lands in it and no fix is ever coming.

This is a different failure from a breach. A poisoned release is an attack on your trust; an abandoned dependency is the absence of anyone to trust. None of the breach-facing controls reach it. An SBOM tells you that you depend on the orphaned package; it says nothing about keeping it alive. A signature proves the last release was genuine and promises nothing about the next. Against a vendor that no longer exists, an indemnity is a claim on an empty estate.

core-js sits in a large share of the web, downloaded billions of times, and is maintained by one person who has said the money to keep it going has collapsed and that he is ready to walk. Nothing was breached. The risk is that a load-bearing dependency rests on a single human, and the bus factor upstream is one.

With open source you always have the right to fork. What you rarely have is the capacity to maintain what you forked. Forking core-js means owning a polyfill library you did not write and cannot staff. So the real question is your own bus factor on a dependency whose upstream bus factor is one, and you answer it before the abandonment, while there is still time. Vendor the source so you can patch it yourself when no one upstream will. Weigh how alive a project is before you take it on: the release cadence, the number of hands, whether a foundation stands behind it or one tired person does. Funding the maintainer can buy time, but it buys goodwill rather than a control.

That is the embedded version. A delegated vendor can die the same way, on a deadline or in a bankruptcy, and because that is Third-Party the continuity plan for it is built there.

Containment does not save you from abandonment. This is a continuity problem rather than a blast-radius one, carried by source escrow, the contractual right to fork or self-host, and your own capacity to take the code over, planned before you need it rather than improvised the week the upstream goes quiet.

How tending differs by position

The condition is the same everywhere; the way you can sustain it is not. A Craft shop tends Supply Chain with a single well-chosen managed scanner and a short list of vetted dependencies. A Lean enterprise tends it with a platform team, a dependency proxy, and a paved road that makes the secure choice the default choice. The Craft shop that reaches for the Lean enterprise's toolchain will drown in alerts it cannot triage. Match the practice to what your position can actually keep alive.

Where it shows up

A weak Supply Chain condition rarely announces itself in Supply Chain. It surfaces at Runtime, as the incident you trace back to a dependency you never inventoried. And it is cultivated, or skipped, in Process: a build pipeline that emits provenance and an SBOM as a byproduct is tending Supply Chain for free.

---

Next Steps

Third-Party Back to Universal Security Conditions

Third-Party

Third-Party asks a harder question than Supply Chain: do you know what you handed off, and who holds the bag when it fails? This is the function you delegated rather than the code you embedded. The payments processor, the data warehouse, the identity-verification provider, the cloud, the SIEM. Some of these are infrastructure. Others are core to how your product delivers value at all. Either way, you do not run them, and you cannot see inside them.

That is the defining trait of this condition: opacity. You will never inspect your cloud provider's hypervisor or audit your SIEM vendor's internal controls directly. Third-Party is weather. You cannot change it. You can only prepare for it. The way it fails is that they got breached, and you inherited the consequence anyway.

Liability moves; responsibility does not

A shared-responsibility model splits the work, and a contract can move a capped slice of the financial loss to the vendor through indemnities, a security super-cap, and a matched cyber policy. That money moves only after the failure, and only the part you could put a number on. It does not move the work of preventing the failure, or the duty to answer for it. Liability shifts; responsibility never leaves you. Regulators treat it the same way: a board stays responsible for an outsourced function as if it ran in-house. When your identity provider leaks your users' credentials, your users do not call the vendor. They call you.

This is where compliance gets misread. Compliance is a market-access key. A vendor earns FedRAMP to unlock the federal market; the attestation expands their addressable market and retires none of your risk. Read a SOC 2 or a FedRAMP authorization as evidence that a vendor cleared a bar, never as a transfer of the responsibility that stays with you.

This is the Foundation accountability premise narrowed to the functions you delegate. No law lets you transfer the responsibility itself, only a capped slice of its cost, and that is why it cannot be argued away.

Operating is not delegating

The agent era splits the vendor relationship in two. A provider ships the model or tool; you take it on the same terms as any other opaque dependency, and everything above applies. An operator runs an agent in its own environment, wired to its own credentials, data, and systems. Most organizations running AI agents are operators, and operating is not delegating. You did not build the model and cannot see how it reasons, but the authority it acts with is something you assembled: the token it carries, the systems it can reach, the actions it can take.

When you delegate a function you hand off the work, and a contract can move a capped slice of the cost back. When you operate an agent you keep the work, and usually carry the cost alone. How it goes wrong depends on what feeds it. Exposed to input you do not control, the agent is the confused-deputy case. Kept to internal, trusted inputs, the risk runs through a compromised account, an insider, or its own error. Either way the agent widens the reach of each. Either way it acts with the authority you gave it, and that reach is yours to bound.

But you can only bound it as finely as the platforms beneath it allow: some reach you scope, some the platform sets for you. Your agent needs to read one project and the platform's token reads them all. To post a comment, it has to hold a scope that also lets it delete the repository. You did not choose that breadth and you often cannot remove it. The provider defines what is expressible in the authorization vocabulary; you stay accountable for what you express, and for choosing that substrate at all. The residual is yours to answer for twice over. A capability limit is only as fine as the platform's model allows; boundary enforcement is where you attenuate within that floor. Bound what you can at the layers you control, compensate at runtime for what the substrate cannot express, and count coarse primitives as a real cost when you choose what to build on.

Regulators are drawing the same line. The EU AI Act separates the provider that builds and places a system from the deployer, the operator in this chapter's terms, that uses it under its own authority, and it shifts a deployer toward provider obligations precisely as it modifies and repurposes the system. The more you wire an agent into your operation, the more of it lands on you.

The operator beneath the operator

The chain rarely stops at one link. A provider you operate is often itself an operator, running a service or an agent wired to sub-providers you never contracted: a native integration, an OEM model under the vendor's label, a sub-processor three hops back. The vendor's AI feature turns out to be someone else's model, and your data is routed to a party whose name is on no contract you signed.

Three things compound down that chain. Opacity deepens: you could not see inside your direct provider, and you can see less inside the provider it leans on. Reach widens: the access the composition can exercise does not stop where your contract does, and it lands at a layer where you hold no controls and no recourse. And the liability cap reaches only the link you signed, so the matched cyber policy answers for your direct vendor, never for the sub-operator that actually leaked your data.

You cannot inventory what you cannot see, and here you cannot see in advance two layers down. That is the case that shows most cleanly why the answer is containment rather than inspection. You do not certify the sub-dependency; you bound what the whole composition can reach and spend, so a failure at a link you never contracted spends only the authority you granted at the boundary. What the boundary cannot do is claw back data the sub-operator already holds and leaks; that residual is carried by contingency and contract, beyond what the boundary covers. Boundary enforcement is built for exactly the dependency you cannot inventory.

When a vendor dies

A breach is the failure you rehearse for most, but it is not the only way a vendor leaves you holding the bag. A vendor can also simply end: it goes bankrupt, it sunsets the product, an acquirer buys it and turns it off. The outage you fail over from is temporary; this one is permanent. When Facebook shut down Parse, roughly six hundred thousand apps had a year to migrate or go dark. That sunset ended softly, because Facebook open-sourced the server so dependents could host it themselves, which is what source escrow is meant to deliver. Most do not end that softly. The preparation has the same shape as the breach plan and is rarely written beside it: know which vendors are load-bearing, what your product does the day one is gone for good, and what continuity you secured while the vendor still existed to sign it. That continuity is the concrete part: source escrow, a self-host right, a wind-down clause.

What cultivating it looks like

Because you cannot inspect the vendor, you cultivate this condition by preparing for the day it fails.

• Contain the blast radius before you need to. Scope what each vendor can reach to the minimum the function requires. The vendor breach you survive is the one whose reach you bounded in advance.
• Assume the breach and rehearse it. Know which vendors are load-bearing, what happens to your product when one goes dark, for a day or for good, or goes hostile, and how you fail over. A contingency plan you have never tested is a hope.
• Make the shared-responsibility line explicit. The third-party incidents that hurt tend to trace to a boundary nobody owned, because each side assumed the other had it. Write down who secures what, then check the assumption against reality.
• Monitor the surface you can see. You cannot watch their internals, but you can watch what they expose to you: the access they hold, the data crossing the boundary, the certifications lapsing.

How tending differs by position

A Craft shop tends Third-Party with a short list of critical vendors and a tested plan for the two or three it cannot live without. A Lean enterprise tends it with vendor risk scoring, pre-approved integration patterns, and failover rehearsed as a matter of course. Both are doing the same thing: bounding what an opaque dependency can do to them.

Where it shows up

Third-Party failures are bounded by Runtime containment, which is why the two conditions are read together. And the line between Third-Party and Supply Chain is the line between what you delegated and what you embedded. Keep them apart on the page so they stay apart in the work: one is an opacity problem you prepare for, the other a comprehension problem you can fix.

---

Next Steps

Process Back to Supply Chain

Process

Process asks whether the way you build produces security, or bolts it on afterward. The other three conditions are mostly about things: dependencies, vendors, running systems. This one is about the machine that makes the things. A build pipeline either emits security as a byproduct of how it works, or it leaves security to a review at the end that everyone has learned to route around.

The lever is feedback. Security that arrives while the work is happening gets fixed while the work is happening. Security that arrives in a gate three days later arrives as an interruption, and interruptions get bypassed.

Security as a property of the build

The aim is a build that makes the insecure version harder to ship than the secure one, rather than simply adding more checks. When provenance, dependency inventory, secret scanning, and policy checks run as part of the pipeline rather than alongside it, they stop being security activities at all and become properties of how code moves to production.

This is also where the other conditions get cultivated for free. A pipeline that emits an SBOM is tending Supply Chain. A pipeline that refuses a hardcoded secret closes a Runtime exposure before it exists. Process is the leverage point because a single change to the build strengthens more than one condition at once.

What cultivating it looks like

• Put the feedback where the work is. Checks that run in minutes, inside the pull request, with a clear path to the fix. A scan that takes two hours to return runs once and then gets disabled.
• Make secrets structurally hard to leak. Secrets that never enter source control, scanning that catches the ones that try, short-lived credentials over long-lived ones. The goal is a pipeline where leaking a secret takes effort.
• Codify the secure default. Paved roads, vetted templates, configurations that are safe before anyone tunes them. The secure path should be the path of least resistance.
• Watch for the bypass. A rising rate of skipped checks is the signal that the process has become friction instead of feedback. Measure it, and treat a bypass as a defect in the process rather than in the developer.

When the checks pass and catch nothing

Process fails in the quietest way of the four. Nothing breaks. The build keeps shipping, the pipeline stays green, every check reports success. What stops, silently, is the security those checks were installed to produce. A control does not have to be removed to fail; it only has to keep running after it has stopped meaning anything, while no one is watching the pipeline itself.

Equifax is the case study. In March 2017 a patch for a known Apache Struts vulnerability went out, and the process meant to apply it never reached the server that needed it. That gap alone was the way in. But the detail that turns a missed patch into a story about drift is what the attackers walked past on the way out: the tool meant to inspect encrypted traffic for exactly this kind of exfiltration had been running on a certificate that expired in January 2016, and no one had noticed for 19 months. The scanner was installed, funded, and green. It was also blind. The breach was found the day someone renewed the certificate and the tool, restored to sight, immediately lit up with the activity it had been missing the whole time. Data on 148 million people left over 76 days, past a guard that had been asleep since before anyone thought to check.

This is what drift looks like: a control that was bought and installed, then quietly stopped working while every dashboard stayed green. The patch queue that no longer reaches production, the scanner whose rules last updated two years ago, the gate that has been auto-approving since a config change no one logged. None of it announces itself, because a broken check and a passing check produce the same green until the day you need the difference.

So the discipline Process demands is not more checks; it is watching the checks. Treat the pipeline itself as a system that decays and must be tended. Verify that a control still does what its green light claims, on a cadence, the way you would test a smoke detector you are betting the building on. A check no one audits is a check that has already started to drift.

How tending differs by position

A Craft shop tends Process with a handful of checks wired into one pipeline. A Studio shop, simple but operationally ready, can automate from the start rather than building manual steps it will replace within a year. A Lean enterprise tends it with a platform team whose product is the paved road itself. The trap is the Mass pattern: heavy process that produces ceremony instead of security, gates that delay releases without reducing risk.

Where it shows up

A Process failure rarely announces itself as a Process failure. It surfaces as the Supply Chain dependency that shipped without an SBOM, or the Runtime incident that traces back to a secret the pipeline should have caught. Process is the leverage point precisely because it sits upstream of the others; when it drifts, they drift with it, one quiet green build at a time.

---

Next Steps

Runtime Back to Third-Party

Runtime

Runtime asks whether you can sense what production is doing right now and respond before a user does. Everything upstream of here is preparation. Runtime is where the system meets real adversaries, real load, and real consequence, and where the question stops being whether you built it well and becomes whether you can tell what it is doing.

The lever is observability in the full sense: seeing what happens, and seeing it in time to act. Detection that arrives after the customer has already noticed is just confirmation.

Sense and respond

A healthy Runtime condition is a short loop. Something anomalous happens, you see it quickly, you contain it, you recover, and the system keeps serving everyone it was already serving. The three intervals that matter are time to detect, time to contain, and time to recover. Each one measures how tight the loop is rather than a grade you pass.

When the alarm goes unanswered

The failure Runtime rehearses for is the missed detection, the intrusion you never saw. It has a second failure that is worse, because it happens after everything worked: you saw it, and nothing followed.

In late 2013 Target was running a $1.6 million malware-detection system, watched around the clock by a security team in Bangalore. When the attackers loaded their exfiltration tool, the system caught it and fired, on November 30 and again on December 2. Bangalore saw the alerts and escalated them to the response team in Minneapolis. The detection did its job: the signal was real, and it was early. Then no one acted on it, and forty million card numbers left over the following two weeks.

This is the failure noise produces. The signal was not missing; it arrived in a stream that had trained everyone to look past it. A surface that emits a thousand low-value alerts a day does not fail loudly on the one that matters. It fails quietly, by being ignored on schedule. Detection you do not act on is not detection. It is a log of the breach you could have stopped, written in advance.

So the condition is a loop, and the loop is only as fast as its slowest human link. Coverage no one can read buys nothing. One high-fidelity signal wired to a response someone is accountable to answer beats total visibility no one is watching. It is why Runtime is won in the response: time to contain is the interval that decides the condition, and the seeing was rarely the hard part.

What cultivating it looks like

• Detect on behavior, beyond signatures. Know what normal looks like for your system so the abnormal stands out. Static rules catch yesterday's attack; a sense of baseline catches the one you have not seen.
• Rehearse the response. A playbook no one has run is only a document. The teams that contain incidents quickly are the ones that have practiced containing them.
• Protect the data at the boundary. The breaches that land here rarely turn on an exotic exploit. Year after year, the path that gets used is a stolen credential or a misconfiguration. Least privilege, encrypted data, and audited access close it.
• Design for graceful failure. Systems that degrade rather than collapse under pressure buy you the minutes response needs. Recovery is part of the condition rather than a separate discipline.

How tending differs by position

A Craft shop tends Runtime with the monitoring its cloud provider gives it and a plan for the incidents it can actually foresee. A Lean enterprise tends it with correlated observability, automated response for known patterns, and threat hunting for the unknown ones. Both run the same loop of sense and respond, at different radii.

Where it shows up

Runtime is where the other conditions come to be judged. The uninventoried dependency from Supply Chain, the vendor breach from Third-Party, the gap a drifting Process stopped catching: each of them, if it is going to hurt you, hurts you here. A strong Runtime condition is the last containment when an upstream condition was weak. It does not substitute for tending them.

---

Next Steps

Adaptive Capacity Back to Process

Adaptive Capacity

Adaptive Capacity is whether the system as a whole can absorb a surprise it was not designed for and keep working. It is the condition that used to be called Continuous Learning, named now for what it actually is. The other four conditions each map to a function you can put on an org chart. This one does not. You assess whether the system has it. You cannot hand it to a team.

The idea comes from ecology

In 1973 the ecologist C.S. Holling drew a line between two things people had been treating as one. Stability is how fast a system returns to where it was after a small disturbance. Resilience is something else: how much a system can absorb and reorganize around before it becomes a different system altogether. A forest that burns and regrows is not stable while it burns; it is resilient. The capacity lives in the whole web rather than in any single tree, and it is never finished, because the system and the things stressing it keep changing against each other.

Security works the same way. A field of practice grew up carrying Holling's insight out of ecosystems and into engineered ones: Erik Hollnagel reframed safety as the presence of adaptive capacity rather than the absence of failure, David Woods described resilience as graceful extensibility at the brittle edges of a system, Richard Cook catalogued how complex systems fail and keep running anyway, and Kelly Shortridge made the case for treating security as ecology rather than enforcement. The full citations are in the references. The throughline is one claim: certify a system once and trust it to hold, and it is already falling behind, because the things trying to break it keep changing while it stands still.

That throughline is a bet, and it is worth saying what would make it wrong. Adaptive Capacity earns its place only in a world where the threats keep moving. If the landscape ever froze, a system you certified once would hold, and this whole condition would be dead weight. The wager SF² makes is that it does not freeze: adversaries pick up the same automation defenders do, and the pace of change is itself the thing being defended against. Treat that as the assumption to check rather than a law of nature.

The sturdier half of this needs no adversary at all. Your own system does not hold still: it grows, and as it grows it outruns the people who understand it, so the picture you hold of your own attack surface goes stale on its own. That alone would keep you tending, even against an enemy that never improved. The threat side only adds to it, and in more ways than the obvious one. Attackers do not have to get smarter for the landscape to change. There can simply be more attackers, because the same automation that helps you lowers the cost of attacking you, and old tools recombine into attacks no one had to invent. The mechanism does not rest on attackers getting cleverer. It rests on two things that move on their own: a system you cannot fully hold, and a threat surface that widens even when no single attacker sharpens.

What it looks like, present and absent

You cannot install Adaptive Capacity, but you can see it. It shows up as a blameless post-incident review that actually changes something, instead of a document filed and forgotten. It shows up as feedback loops that shorten over time, and as the organization sensing a shift in the threat landscape and adjusting before it gets hit rather than after. It is the difference between learning from an incident and merely surviving it.

When it is missing, the other four conditions can each look fine on a maturity chart while the system stays brittle, because nothing is teaching it to bend. The reviews happen but nothing changes. The same class of incident recurs under a different name. The program is busy and not adapting. Without it, you are just repainting the same four walls on a fixed cadence.

Why it runs across the other four

Adaptive Capacity is how all four of the other conditions improve at all. It is the health of all four at once rather than a fifth lane staffed beside them, the question of whether Supply Chain, Third-Party, Process, and Runtime are getting better faster than their failure modes are. A maturity chart can tell you whether each condition is filled in. Only Adaptive Capacity tells you whether the system is still adapting faster than the things trying to break it, and that is the question worth asking.

The seam to the Coadaptive layer

This is where the base framework meets the Coadaptive Security layer. The contest between a system that keeps changing and adversaries who keep changing in response is the same predator-and-prey pressure that runs through any living system, and it sharpens once the system includes AI that writes, decides, and acts. Adaptive Capacity is the condition that carries the base framework up into that layer. It is the reason SF² treats security as something a system keeps doing rather than a state a system reaches.

This chapter says security is never finished. The Coadaptive layer says something that sounds like the opposite: you can prove a hard limit on what one component is allowed to do, and that limit holds without tending. Both are true, because they describe different things. You can prove a part. You cannot finish the whole. A single component has a fixed job, so you can bound it and trust the bound. The system those components add up to keeps meeting new surprises, and they land at the seams between the parts, where no single proof reaches. So you prove each piece and you tend the system. Neither move does the other's job.

---

Next Steps

You have now worked through the five universal security conditions. The next section is how you decide which version of tending each one your organization can actually sustain.

Continue to Strategic Positioning Back to Runtime

Strategic Positioning

Two-Axis Positioning Model

Understanding Your Strategic Starting Point

Rather than using traditional maturity models that assume linear progression, this framework positions software factories on two independent dimensions that determine your optimal security approach.

Why Not Maturity Models?

Traditional security maturity models imply everyone should follow the same path. SF² recognizes that a 10-person startup with modern cloud infrastructure shouldn't implement security the same way as a 5,000-person enterprise with legacy systems, even if both need strong security.

This is contingency theory applied to security: organizational research has held for decades that there is no single best way to organize, only the structure that fits an organization's environment, scale, and technology (Donaldson 2001; Horne, Maynard & Ahmad 2017). SF² carries that finding into security program design: your position, rather than your rung on a ladder everyone is told to climb, sets your strategy.

The Strategic Positioning Framework

Organizations can be assessed along two critical axes:

Blast Radius Axis (What a Failure Can Reach)

The horizontal axis is inherent blast radius: how far a failure could reach if containment fails, given everything your systems are allowed to do. It is set by the authority you have handed your automation and agents, rather than by how many people you employ. Headcount and team count were the old stand-in, and the stand-in held while a bigger system meant more people to run it. AI broke that correlation. A fifteen-person shop running fifty agents with broad tool access has the reach of an enterprise and the headcount of a studio, and a security strategy keyed to headcount cannot see the reach. So the axis names the reach directly.

Small reach: automation that touches one bounded surface, authority scoped per task, a worst-case failure contained to a single blast cell.

Large reach: automation that crosses trust boundaries (production, data, and identity at once), standing authority broad enough that one misused credential is an enterprise event, a worst-case failure that cascades across the estate.

Headcount survives here as a legacy proxy: it used to predict reach, and where a small team still holds small authority it still does. AI is what severs headcount from reach, and the axis follows the reach.

This is inherent reach, measured as if containment failed. What you build to stop a failure reaching that far, the boundary enforcement that holds a compromised component to the authority it was granted, is the other axis: readiness. Keeping the two apart is what keeps the model honest. Your reach is mostly what you have decided to let your systems do; your readiness is what you build to contain it. The containment floor that bounds the blast is the same boundary enforcement the coadaptive layer specifies at the substrate: this chapter names the position, that chapter builds the floor.

This runs asymmetrically, and the asymmetry is the point. A small shop can leap to large reach by granting fifty agents broad authority, but a large enterprise cannot shrink below its own surface area: inherent reach is the sum of every authority you have granted, and a big estate has granted a great deal. Past a certain scale that sum is simply large, and the horizontal axis stops telling enterprises apart. So the two ends of the model play different games. Small shops fight to stay on the left, one over-scoped agent fleet away from teleporting to Mass. Large enterprises take their reach as given and fight the vertical: the whole move is proving containment and climbing to Lean.

A test keeps the two axes from blurring. Place yourself in two sentences: a reach sentence using only the verbs of authority (what the automation can reach, is granted, is allowed to touch) and a readiness sentence using only the verbs of control (what is contained, caught, reviewed, segmented). If a containment word is carrying your reach claim, you have measured the wrong axis.

Operational Readiness Axis (How You Operate)

Lower Readiness:

• Manual processes
• Legacy infrastructure
• Limited automation
• Tribal knowledge
• Reactive operations

Higher Readiness:

• Automated pipelines
• Modern infrastructure
• API-driven operations
• Documented processes
• Proactive operations

The Four Strategic Positions

These two axes create four distinct strategic positions, each with different security approaches:

The horizontal axis is inherent blast radius (reach if containment fails); the vertical axis is operational readiness, repeatability and proven containment rising. Mass is Lean's large reach without Lean's floor: ungoverned scale rather than big batch.

Reading the two axes

The horizontal axis is blast radius: the inherent reach of a failure if containment fails, set by what authority your automation holds. The vertical axis is operational readiness: moving up means the work becomes more repeatable and a failure provably stays contained. The goal is the top row, the floor built, and it is one goal at two addresses: Studio if your reach is small, Lean if it is large. You do not choose your reach; the authority you have already granted sets it. The assessment below places you.

The names are production modes, about flow and containment

The four names map to production modes, and the analogy is about flow and containment rather than volume. Lean is the cleanest fit: Toyota's line stops the instant a defect appears so it cannot propagate, which is large flow contained by construction, exactly large reach with the floor built. Craft is the artisan touching one or two things by hand. Studio is the small, bounded, modern shop. Mass is Lean's large reach without Lean's floor: ungoverned scale rather than big batch. Under the reach axis the border that matters is against Lean rather than against Ford's assembly line.

Each position is drawn out in full on Four Strategic Positions: its characteristics, security approach, investment priorities, and common pitfalls. In short: Studio is small reach with the floor built, Lean is large reach with the floor built, Craft is small reach done by hand, and Mass is large reach with no floor under it. The top row is the goal at either reach; Craft and Mass are those same two reaches without the floor.

Assessing Your Position

Use these questions to determine your organization's position:

Blast Radius Assessment (inherent reach)

Question	Small reach	Large reach
Reach of most-capable automation: the largest set of systems any one automated actor (pipeline, agent, service account) can touch without a human in the loop?	One bounded surface (single service/datastore)	Crosses trust boundaries (prod + data + identity); org-wide
Worst-case propagation: if your single most-privileged non-human identity were fully compromised now, how far does damage reach before something not also compromised stops it?	Contained to one blast cell	Cascades across the estate
Autonomy depth: how much can automation do rather than merely read, without a human checkpoint (open and merge code, move money, grant access, drop data)?	Read or propose only; humans commit consequential actions	Acts and commits consequential actions unattended
Authority concentration: does any single credential, role, or agent hold standing authority broad enough that its misuse is an enterprise event?	No; authority attenuated per task	Yes; broad standing authority exists

If the answers are split

Reach is a sum, so it tips on the strongest answer. If any row above lands in the Large reach column, especially worst-case propagation or authority concentration, treat your reach as large. One broad grant is enough to put the whole estate in the blast.

Operational Readiness Assessment

Question	Lower Readiness	Higher Readiness
Containment verifiability: can you prove (not assert) that a compromised component cannot exceed the authority you granted it?	No; you rely on it behaving	Yes; enforced at the boundary
Deployment process?	Manual	Fully automated
Infrastructure?	Legacy/on-prem	Cloud-native/hybrid
Documentation?	Tribal knowledge	Comprehensive docs
Observability?	Limited/reactive	Comprehensive/proactive
Change velocity?	Weeks/months	Hours/days

Why This Matters for Security

Position is a sequencing and funding diagnostic rather than an architecture one. It does not decide whether you adopt the containment floor; every quadrant owes the same one. It decides how fast you reach it and what you fund first. Within that, your position determines:

1. Funding order: Which security investments to make first, and which to defer
2. Rollout pace: How fast you can stand up capabilities without outrunning the organization
3. Timeline expectations: How long transformation realistically takes
4. Mechanism fit: Which implementation meets the containment floor at your scale
5. Success metrics: What good looks like at your stage

Common Mistake

Implementing Lean-level security programs in a Mass or Craft organization often leads to:

• Failed tooling implementations
• Frustrated security and development teams
• Wasted budget on capabilities you never put to use
• Security becoming a bottleneck instead of enabler

Strategic Movement Paths

Most organizations are working upward: building the floor under the reach they already hold. Small reach lands that climb in Studio; large reach lands it in Lean. The route depends on where they start. Every move, with its investments, timeline, and likelihood, is laid out on Strategic Movement Paths, which lays all six out in a summary table. The one worth naming here: Craft → Mass is drift rather than a strategy, reach that outran the floor. It is the move to guard against.

Using Position to Guide Security Strategy

The lists below are four sequences toward the same containment, each with tooling fit to its scale. Every quadrant owes deny-by-default limits on the authority review cannot police at scale; what changes below is the order of investment and the tooling that fits the operational reality. Each list is a funding order for your scale rather than the security you end up with.

For Studio:

• Use cloud-native security services
• Implement policy-as-code from inception
• Build security into platform capabilities
• Enable developer self-service

For Lean:

• Orchestrate enterprise security architecture
• Build internal security platforms
• Optimize at scale with automation
• Continuous security improvement programs

For Craft:

• Focus on foundational security capabilities
• Manual but systematic approaches
• Gradual capability building
• Use managed security services

For Mass:

• Pragmatic hybrid security approaches
• Risk-based prioritization (critical systems first)
• Incremental modernization
• Balance legacy and modern security capabilities

---

Next Steps

Now that you understand strategic positioning, explore the specific characteristics and recommended approaches for each position:

Explore Strategic Positions in Detail Learn About Movement Paths

---

Naming note (v0.5 → v0.6)

These four positions were named Visionaries, Leaders, Niche Players, and Challengers in v0.5. They are now Studio, Lean, Craft, and Mass. See the quadrant rename mapping for the full crosswalk and the reasoning behind the change.

---

Back to Universal Security Conditions

Four Strategic Positions

Understanding Where You Are Determines What You Should Do

The two-axis positioning model creates four distinct strategic positions. Each position faces different security challenges and requires different sequencing and pace to scale security capabilities. What it does not change is what the program must ultimately contain.

Critical Insight: Your position changes almost everything about your security program. It does not change what the program is for. Every quadrant owes the same containment: deny-by-default limits on authority. Code review and human comprehension were never able to police that authority at the scale enterprises already run. That containment is the floor. How you enforce it fits your scale: a small shop on a single workload contains it with host isolation and tight access scoping; a large mesh contains it with workload identity. Same floor, mechanism fit to scale. What your position decides is how fast you reach that containment, what you fund first, and what pace the rest of the program can sustain. A Studio organization that funds security like a Lean enterprise creates coordination overhead it does not need; a Mass organization that promises Studio timelines will miss them.

---

The Four Strategic Positions

Studio: Small reach + Higher Readiness

Who You Are:

• Narrow granted authority: no automated actor crosses trust boundaries (a small team is the usual correlate rather than the cause)
• Cloud-native infrastructure from inception
• Automated CI/CD pipelines and modern DevOps practices
• API-driven operations and infrastructure-as-code
• Minimal legacy technical debt

Your Security Approach: Enable security through modern tooling and self-service capabilities. Use your technology advantages rather than building processes that assume operational constraints you don't have.

Strategic Focus: Build security automation from day one. Don't create manual processes you'll need to replace in 18 months. Your higher operational readiness makes automation achievable now, and your small reach means there's little cross-boundary authority to coordinate and govern.

Key Investment Priorities:

1. Automated Supply Chain Security: Dependency scanning and update automation with minimal manual intervention
2. Pipeline-Native Security: Security checks integrated directly into CI/CD with immediate developer feedback
3. Self-Service Security Capabilities: Cloud platform security features that "just work" without security team involvement
4. Observability-First Runtime Security: Cloud-native monitoring with automated alerting and incident response

Common Pitfalls to Avoid:

Don't Build for Future Complexity

Risk: Implementing enterprise-scale security architecture "because we'll need it eventually"

Symptoms: Multi-week security design reviews, approval workflows for two-person teams, committee decision-making

Solution: Build for your current reality. Add governance weight only when your reach actually widens.

Success Indicators:

• 6 Months: Automated dependency scanning covers 95%+ of codebases, security checks integrated in all pipelines with <5 minute feedback loops
• 12 Months: Zero manual security reviews for standard deployments, developers resolve 80%+ security issues without security team involvement
• 24 Months: Security automation enables 3-5x growth without proportional security team expansion

Movement Path: As you grow, you'll naturally grant more authority and widen your reach. Your challenge is keeping containment ahead of that reach: transition to Lean rather than falling into the Mass trap of widening reach faster than you can contain it.

See Studio Implementation Guide

---

Lean: Large reach + Higher Readiness

Who You Are:

• Broad granted authority across the estate, held with the floor built (large scale is the correlate; reach is set by authority rather than headcount)
• Sophisticated DevOps and platform engineering practices
• Comprehensive observability and automation across the enterprise
• Mature change management and incident response processes
• Strong engineering culture with continuous learning focus

Your Security Approach: Orchestrate enterprise security architecture with integrated learning culture. Enable security at scale through platform engineering and federated champions who configure the boundaries the platform enforces.

Strategic Focus: Optimize security operations at enterprise scale while maintaining innovation velocity. Your advantage is operational sophistication. Use it to embed security into engineering platforms rather than building centralized security bottlenecks.

Key Investment Priorities:

1. Security Platform Engineering: Self-service security capabilities available across all teams and products
2. Federated Security Champions: Engineers inside each team who set the team-level boundaries the platform then enforces: capability scopes, deny-by-default grants, the guardrails their team ships inside. The platform team authors the paved road; champions set the boundaries within it and feed the threat models that shape it. The leverage is configuration rather than inspection, so enforcement scales without a human in the path of every change. The boundary-setting is itself threat modeling and risk judgment rather than a config chore: the enforcement is delegated to the platform, the judgment is not.
3. Enterprise Architecture Integration: Security embedded in platform decisions and organizational standards
4. Continuous Security Intelligence: Automated threat detection with predictive insights and proactive response
5. Cultural Scaling Mechanisms: Learning from incidents and scaling security knowledge across the organization

Common Pitfalls to Avoid:

The Coordination Overhead Trap

Risk: Security program becomes a bottleneck due to enterprise coordination requirements

Symptoms: Multi-week security architecture reviews, declining developer satisfaction, increasing workarounds

Solution: Federate security decision-making to engineering teams with clear guardrails. Centralize platform capabilities rather than every security decision.

Success Indicators:

• 6 Months: Security platform adoption across 70%+ of teams, measurable reduction in security review wait times
• 12 Months: Security champions program active in all major teams, 60%+ of security issues resolved without central team involvement
• 24 Months: Security capabilities scale automatically with organizational growth, security becomes competitive advantage

Movement Path: Stay in Lean by continuously evolving security capabilities to match organizational scale. Falling into Mass happens when readiness can't keep pace with widening reach, so maintain platform investment velocity.

See Lean Implementation Guide

---

Craft: Small reach + Lower Readiness

Who You Are:

• Narrow granted authority, held by hand rather than by a proven floor
• Legacy systems or manual deployment processes
• Limited automation and observability
• Straightforward product or service offering
• Often resource-constrained or bootstrapped

Your Security Approach: Focus on operational readiness foundations while maintaining essential security capabilities. Accept manual security processes initially, but invest strategically in readiness improvements that enable future automation.

Strategic Focus: Build operational capabilities systematically while maintaining security coverage. Your small reach means a failure stays contained even when caught by hand, so you can afford some manual processes temporarily. Use this breathing room to invest in readiness infrastructure.

Key Investment Priorities:

1. Critical Supply Chain Controls: Basic dependency scanning and critical vulnerability management
2. Foundational Readiness Infrastructure: CI/CD basics, infrastructure documentation, change management fundamentals
3. Essential Runtime Monitoring: Basic production monitoring and incident response capabilities
4. Process Documentation: Record what works to enable eventual automation and knowledge transfer

Common Pitfalls to Avoid:

The Permanent Manual Process Trap

Risk: Treating manual processes as acceptable long-term state rather than temporary necessity

Symptoms: "This is how we've always done it," no automation roadmap, resistance to process changes

Solution: Be explicit that manual processes are temporary. Document current state as foundation for future automation. Invest consistently in readiness improvements.

Success Indicators:

• 6 Months: Critical dependencies monitored, basic CI/CD pipeline operational, documented security processes
• 12 Months: 30-50% automation of security checks, measurable reduction in manual security work
• 18-24 Months: Operational readiness sufficient to support automation investments, movement toward Studio position

Movement Path: Move toward Studio by investing in operational readiness. This single-axis movement is achievable. Prioritize cloud migration, DevOps tooling, and automation infrastructure over widening your reach.

See Craft Implementation Guide

---

Mass: Large reach + Lower Readiness

Who You Are:

• Broad granted authority accumulated across a legacy estate, with no proven floor under it
• Significant technical debt and mixed infrastructure (legacy + modern)
• Manual processes coexist with automated systems
• Complex compliance and regulatory requirements
• Multiple organizational changes or acquisitions

Your Security Approach: Pragmatic security within constraints while enabling gradual modernization. Accept that full transformation takes 3-5 years. Don't promise 12-month miracles.

Strategic Focus: Balance current operational demands with strategic modernization investments. The reach you already hold prevents rapid transformation, but your scale justifies investment in foundational improvements.

Key Investment Priorities:

1. Pragmatic Supply Chain Controls: Risk-based approach given limitations; focus on critical paths and crown jewels
2. Hybrid Security Architecture: Solutions that work across legacy and modern systems without requiring full modernization
3. Strategic Technical Debt Reduction: Systematic elimination of highest-risk legacy constraints enabling future automation
4. Change Management and Communication: Organizational alignment on multi-year transformation reality and sequencing
5. Quick Wins for Credibility: Visible improvements that build organizational confidence in long-term transformation

Common Pitfalls to Avoid:

The Diagonal Transformation Trap

Risk: Attempting to shrink reach AND build containment at the same time, the highest failure risk

Symptoms: Aggressive transformation timelines, simultaneous re-platforming and process overhauls, widespread disruption

Solution: Sequence changes carefully. Typically, build the containment floor first (the Mass → Lean climb) to enable automation at scale. Accept 36-60 month timeline.

Success Indicators:

• 12 Months: Hybrid security solutions operational, critical technical debt reduction projects started, transformation roadmap with executive buy-in
• 24 Months: Measurable automation improvements in high-value areas, improved operational readiness metrics, cultural momentum toward transformation
• 36-60 Months: Substantial progress toward Lean position, security increasingly enabling business rather than constraining it

Movement Path: Most Mass should move toward Lean by investing in operational readiness while managing existing complexity. This is difficult but achievable with sustained executive support and realistic timelines. Attempting to simplify operations (Mass → Craft) rarely succeeds. It requires major business restructuring.

See Mass Implementation Guide

---

Confirm Your Position

Confirm which quadrant you are in with the position assessment on the Two-Axis Model page. It walks you through the same reach and readiness questions that define the axes.

Strategic Position and Investment Strategy

Your strategic position determines your optimal approach to the investment portfolio, including how you constrain business-as-usual work and where you invest instead:

Position	BAU Approach	Constraint Mechanism	Scaling Investment Focus	Timeline to ROI
Studio	Minimal BAU burden initially	Avoid creating manual processes to begin with	Automation-first from inception	6-12 months
Lean	Systematic BAU constraint	Self-service platform + clear escalation paths	Platform capabilities at scale	12-18 months
Craft	Manageable manual BAU	Keep manual scope small; document while building readiness	Foundational readiness infrastructure	18-24 months
Mass	High BAU burden requiring constraint	Triage system + strategic automation pilots	Strategic debt reduction + readiness	24-48 months

---

Common Position Misidentification

Startup Founder Self-Assessment: "We're obviously Craft, we're small and scrappy!"

Reality Check: If you're cloud-native with automated deployments, you're Studio. Your reach is small because no automated actor holds broad authority, rather than because the team is small, and your modern stack is high readiness. Don't build manual processes just because you're small.

---

Established Enterprise Self-Assessment: "We're Lean, we have mature security programs!"

Reality Check: If you're running significant legacy infrastructure with manual deployments, you're Mass regardless of security team size. Your reach is large, but operational readiness is constrained by technical debt.

---

High-Growth Startup Self-Assessment: "We're Studio scaling successfully!"

Reality Check: If you're widening reach faster than you can contain it, you're moving toward Mass (large reach, lower readiness). Maintain containment investments or you'll face the diagonal transformation trap.

---

Next Steps

1. Confirm your quadrant: Use the position assessment on the Two-Axis Model page
2. Review Movement Paths: Understand how to transition strategically
3. Read Your Implementation Guide: Apply position-specific guidance from 06-implementation/
4. Evaluate Contextual Modifiers: Understand how your specific situation affects implementation

---

Back to Two-Axis Model Continue to Movement Paths

Edit this page

Strategic Movement Paths

How Organizations Transition Between Positions

Understanding your current strategic position is only the first step. Most organizations benefit from moving up, building the floor under the reach they already hold (Studio at small reach, Lean at large), but the path you take determines your likelihood of success.

The Transformation Reality

Quadrant transitions are organizational transformations rather than technology projects. The tractable moves change one axis at a time. But one axis is not automatically quick: widening reach is fast and cheap (you just grant the authority), while building the containment floor under reach you already hold is slow. Climbing from Mass to Lean is a single-axis move on paper and still takes 36-60 months, because the floor has to cover the whole estate. The moves that fail most often are the ones that widen reach and build containment at the same time.

That gap between fast and slow is the install clock against the absorb clock: how fast you can stand a change up versus how fast the organization actually runs on it. Granting authority installs in a day, building the floor the organization runs on takes quarters (the two clocks get their full treatment in Change Capacity). And the reason doing both at once fails most is that they draw on one shared absorption budget rather than two. The same people, sponsor, and approval path carry both, so each absorbs worse. Sequence the heavy moves; do not stack them.

---

The Strategic Movement Framework

The Goal: The Floor Built at Your Reach

One goal, two addresses: the floor built, higher readiness proven at whatever reach your business already holds. A small-reach organization reaches that goal at Studio; a large-reach organization reaches it at Lean. Higher readiness is always the move; only the reach it lands at changes.

What the top row buys you (Studio and Lean both):

• Security capabilities that scale automatically with organizational growth
• Developer experience improvements that increase velocity
• Platform approaches that enable innovation while holding security
• Cultural integration where security is a competitive advantage

Reality Check: Lean is the goal only for large-reach organizations. If your reach is small, your end state is Studio, and it stays Studio for as long as your reach stays small. When the business widens your reach, build the floor first, so you pass through Studio rather than Mass.

---

Six Strategic Movement Paths

From → To	Movement Type	Timeline	Success Probability	Strategic Guidance
Craft → Studio	Single-axis (Readiness ↑)	12-18 months	High ⭐⭐⭐⭐	Operational Readiness Path
Craft → Mass	Drift	18-24 months (unplanned)	Not a goal	The drift to guard against
Studio → Lean	Single-axis (Reach ↑)	24-36 months	High ⭐⭐⭐⭐	Enterprise Scaling Path
Mass → Craft	Single-axis (Reach ↓)	18-30 months	Low ⭐	Simplification Path
Mass → Lean	Single-axis (Readiness ↑, large reach)	36-60 months	Moderate ⭐⭐	The Containment Climb
Studio/Lean → same	Position Maintenance	Ongoing	High ⭐⭐⭐⭐	Sustaining a Top-Row Position

The timelines above are install-and-build floors. A move is not done until it is absorbed, and two major moves that run through the same quarters draw on one absorption budget rather than two. Sequence by that budget rather than by what your calendar can install (see Change Capacity).

These ranges and likelihood ratings are practitioner estimates synthesized from transformation experience rather than measured outcomes. SF² treats them as hypotheses to validate rather than findings, and refining them against real transformations is part of the framework's research agenda.

The three tractable moves change one axis at a time. The dashed path is drift to guard against; the crossed diagonal is the two-axis move that fails most often. The top row is the goal at either reach: Studio for small, Lean for large.

---

Path 1: Craft → Studio (Operational Readiness)

Movement Type: Single-axis (Increasing Operational Readiness)

Timeline: 12-18 months

Success Probability: High ⭐⭐⭐⭐

When to Choose This Path

Yes, if:

• Your business remains relatively simple (single team or product focus)
• You have budget/appetite for infrastructure modernization
• Legacy technical debt is constraining your business velocity
• You want to enable future automation before your reach widens

No, if:

• You're simultaneously scaling teams and organizational complexity rapidly
• Legacy systems have significant customer dependencies requiring careful migration
• Business model requires immediate complexity scaling

Key Investment Priorities

1. Cloud Migration: Move from on-premises or manual infrastructure to cloud platforms
2. CI/CD Implementation: Automated build, test, and deployment pipelines
3. Infrastructure as Code: Terraform, CloudFormation, or similar tooling
4. Observability Foundation: Centralized logging, metrics, and monitoring
5. Security Automation: Dependency scanning, SAST/DAST integration into pipelines

Sequencing Strategy

Months 1-6: Foundation

• [ ] Cloud platform selection and initial migration planning
• [ ] Basic CI/CD pipeline for new services or non-critical systems
• [ ] Observability platform implementation with critical system coverage
• [ ] Team training on cloud-native practices and DevOps principles

Months 7-12: Acceleration

• [ ] Expand CI/CD coverage to 70%+ of systems
• [ ] Infrastructure as Code for new deployments
• [ ] Security tooling integrated into pipelines with automated feedback
• [ ] Legacy system migration planning with risk assessment

Months 13-18: Completion

• [ ] 90%+ systems on modern infrastructure
• [ ] Automated security scanning comprehensive
• [ ] Manual deployment processes eliminated for standard changes
• [ ] Team operating with cloud-native mindset and capabilities

Success Indicators

• Technical: Deployment frequency increases 5-10x, infrastructure provisioning time reduced from days to minutes
• Security: Vulnerability detection moves from quarterly to continuous, dependency management automated
• Cultural: Team enthusiasm for new capabilities, reduced resistance to process changes

Common Pitfalls

The 'Lift and Shift' Trap

Risk: Moving legacy systems to cloud without architectural modernization. You get cloud bills without operational readiness benefits

Solution: Modernize incrementally. Start with new services cloud-native, migrate legacy strategically with re-architecture where beneficial

---

Path 2: Craft → Mass (the drift to guard against)

Movement type: Reach widening, usually involuntary

Drift speed: 18-24 months from Craft to Mass once reach starts outrunning the floor

Recovery cost: 36-60 months for the Mass → Lean containment climb afterward

This is the one move on the map you do not make on purpose. Craft → Mass is what happens when you grant automation and agents more authority faster than you build the containment to hold it: a new integration here, broader tool access there, another autonomous actor in the pipeline. Reach widens and the floor does not. One day a failure's blast radius is enterprise-scale and nothing proves a compromised component stays inside its grant. You arrived at Mass by drift rather than by decision.

Sometimes it is a bet rather than an accident

Occasionally the reach is taken on knowingly: the business needs enterprise features or a new market before it can fund readiness, and you grant the authority with your eyes open. That is defensible exactly once, when you book the debt. Name a containment-funding date, put it in writing, and treat the position as temporary Mass you are already climbing out of. Undated, "we chose this" is not a strategy. It is the rationalization this warning exists to puncture. Either way you are in Mass, managing reach that outran its floor. A conscious tradeoff changes the motive rather than your coordinates.

Recognition signs

• Authority is granted to automation and agents faster than you can scope or review the grants
• "We will add the containment later" has been said more than once
• For a given agent or credential, you cannot say what it can reach if it misbehaves

What prevents it

The move you actually choose is Craft → Studio: raise readiness and build the floor before you widen reach. If reach is already widening for real business reasons, pair every authority grant with the containment that bounds it, per-credential scoping, human review on consequential actions, and blast-radius limits, so you land in Studio on the way to Lean rather than in Mass.

If you are already in Mass

Plan the Mass → Lean containment climb and start it. Do not settle in. Mass is unsustainable: 36-60 months to build the floor under reach you already hold, and every month you wait is a month the blast radius stays uncontained.

---

Path 3: Studio → Lean (Enterprise Scaling)

Movement Type: Single-axis (Increasing Reach)

Timeline: 24-36 months

Success Probability: High ⭐⭐⭐⭐

When to Choose This Path

Optimal scenario for sustainable growth: You're widening reach while maintaining operational readiness, so containment scales with the reach. This is the high-success transformation path.

Key Investment Priorities

1. Platform Engineering: Self-service security capabilities for multiple teams
2. Federated Security Model: Security champions program with central guidance
3. Enterprise Architecture: Standardized patterns and reusable security components
4. Organizational Design: Matrix management, cross-functional coordination
5. Cultural Scaling: Learning culture that scales with organizational growth

Sequencing Strategy

Months 1-12: Platform Foundation

• [ ] Security platform vision and initial capabilities
• [ ] Security champions program launch in 2-3 pilot teams
• [ ] Enterprise architecture patterns documented
• [ ] Cross-team coordination mechanisms established

Months 13-24: Scaling

• [ ] Platform capabilities covering 50%+ of common security needs
• [ ] Security champions in all major teams
• [ ] Federated decision-making with clear guardrails
• [ ] Organizational structure supporting scale

Months 25-36: Optimization

• [ ] Platform capabilities comprehensive and self-service
• [ ] Security embedded in engineering culture
• [ ] Continuous improvement processes mature
• [ ] Security as competitive advantage realized

Success Indicators

• Platform Adoption: 70%+ of teams using self-service security capabilities
• Developer Satisfaction: Measurable improvement in security experience scores
• Security Outcomes: Capabilities scale automatically with team growth
• Cultural: Security champions viewed as career development opportunities

---

Path 4: Mass → Craft (Simplification)

Movement Type: Single-axis (Reducing Reach)

Timeline: 18-30 months

Success Probability: Low ⭐

Strategic Reality Check

This is the hardest path and rarely succeeds. Shrinking inherent reach means clawing back authority you have already granted across the estate, and a large enterprise cannot easily shrink below its own surface area. It typically requires:

• Major business restructuring or product simplification
• Customer migration from complex to simple offerings
• Organizational downsizing or significant reorganization
• Market repositioning from enterprise to SMB or niche focus

When This Might Be Necessary

• Business pivot from enterprise to SMB market
• Divestiture or spin-off creating smaller organization
• Post-acquisition rationalization eliminating complexity
• Strategic decision to focus on core simplified offering

Why This Usually Fails

• Customer Commitments: Existing customers expect continued enterprise capabilities
• Revenue Dependency: Complex offerings often generate significant revenue
• Organizational Resistance: Teams resist simplification seen as "scaling back"
• Market Perception: Simplification can be viewed as retreat or failure

Alternative: Consider Mass → Lean Instead

Most Mass should invest in operational readiness rather than attempting to shrink reach. The Mass → Lean path is difficult but more achievable than clawing back granted authority across the estate.

---

Path 5: Mass → Lean (The Containment Climb)

Movement Type: Single-axis (Increasing Readiness under fixed large reach)

Timeline: 36-60 months

Success Probability: Moderate ⭐⭐

When to Choose This Path

Reality: Most Mass organizations must take this path. You can't shrink reach you've already granted across the estate, so you must build containment under it.

The Challenge

You're simultaneously:

• Holding large inherent reach (broad automation authority across legacy and modern systems, enterprise requirements)
• Improving operational readiness (automation, cloud migration, technical debt reduction)

This requires sustained executive support, significant investment, and realistic timeline expectations.

Critical Success Factors

1. Executive Sponsorship: Sustained leadership commitment over 3-5 years
2. Realistic Timelines: Accept 36-60 months; don't promise 12-month miracles
3. Hybrid Solutions: Technology that works with legacy AND modern systems
4. Strategic Debt Reduction: Systematic elimination of highest-risk constraints
5. Quick Wins: Visible improvements that maintain organizational momentum

Sequencing Strategy

Phase 1 (Months 1-12): Stabilize and Plan

• [ ] Comprehensive assessment of current state and transformation requirements
• [ ] Hybrid security architecture supporting legacy and modern systems
• [ ] Quick wins demonstrating transformation value and building confidence
• [ ] Executive alignment on 36-60 month realistic timeline
• [ ] Transformation roadmap with clear milestones and success metrics

Phase 2 (Months 13-24): Foundation Building

• [ ] Critical technical debt reduction enabling future automation
• [ ] Modern platforms deployed alongside legacy systems
• [ ] Automation pilots in high-value areas demonstrating ROI
• [ ] Cultural initiatives building transformation momentum
• [ ] Change management reducing organizational resistance

Phase 3 (Months 25-36): Acceleration

• [ ] Significant automation coverage with measurable benefits
• [ ] Legacy system migration or modernization showing progress
• [ ] Platform capabilities emerging enabling self-service
• [ ] Organizational capability development sustaining transformation

Phase 4 (Months 37-48): Optimization

• [ ] Lean-level capabilities operational across organization
• [ ] Legacy constraints substantially eliminated or managed
• [ ] Security automation enabling business velocity
• [ ] Competitive advantage realization from transformation

Common Pitfalls

The Aggressive Timeline Trap

Risk: Promising 12-18 month transformation when 36-60 months is realistic

Symptoms: Burnout, partial implementations abandoned, organizational skepticism about security competence

Solution: Be honest about timelines. Under-promise and over-deliver. Secure executive commitment for realistic multi-year transformation.

Success Indicators

• 12 Months: Hybrid solutions operational, transformation roadmap with executive buy-in, visible quick wins
• 24 Months: Measurable automation improvements, improved readiness metrics, cultural momentum
• 36-60 Months: Substantial Lean-level capabilities, security enabling rather than constraining business

---

Path 6: Maintaining a Top-Row Position (Studio or Lean)

Movement Type: Position Maintenance and Continuous Evolution

Timeline: Ongoing

Success Probability: High ⭐⭐⭐⭐ (with continued investment)

The Challenge

You're not done. Studio and Lean are both finished end states, and holding either requires continuous investment as:

• Organizational complexity continues evolving
• Technology platforms change and require adaptation
• Threat landscape shifts requiring capability updates
• Competitive pressure demands ongoing innovation

Key Investment Priorities

1. Platform Evolution: Continuous improvement of security self-service capabilities
2. Cultural Sustainment: Learning culture maintenance and psychological safety preservation
3. Innovation Integration: Incorporating new technologies and security practices
4. Competitive Advantage: Translating security capabilities into market differentiation
5. Talent Development: Growing security and engineering capability across organization

Common Pitfall: Complacency

The 'We've Arrived' Trap

Risk: Treating a top-row position as a finish line that needs no upkeep

Symptoms: Platform investment declining, manual processes creeping back, cultural erosion

Solution: Continuous investment in capabilities matching organizational evolution. Lean falls to Mass when containment can't keep pace with widening reach; Studio falls to Craft when readiness erodes, or to Mass if reach widens without the floor.

---

Movement Path Selection Guide

Decision Framework

Use these questions to select your optimal path:

1. What is your current position?

• Accurately assess using the position assessment on the Two-Axis Model page

2. What is your business trajectory?

• Remaining small in reach vs widening reach
• Revenue growth supporting transformation investment
• Market pressures requiring rapid change

3. What is your organizational change capacity?

• Executive sponsorship sustainability over multi-year timeline
• Team capacity for transformation alongside operational demands
• Cultural readiness for significant change

4. What are your critical constraints?

• Budget availability for transformation investment
• Technical debt severity limiting automation potential
• Regulatory requirements affecting technology choices

Your answers point back into the summary table above: your current position fixes the starting row, and your trajectory, change capacity, and constraints pick between the moves open from it.

---

Next Steps

1. Confirm Your Current Position: Use the position assessment on the Two-Axis Model page
2. Select Your Target Path: Based on business trajectory and change capacity
3. Review Contextual Modifiers: Understand how your specific constraints affect timeline
4. Read Your Implementation Guide: Position-specific guidance in 06-implementation/
5. Develop Transformation Roadmap: Use sequencing strategies above to create your plan

---

Back to Strategic Positions Continue to Investment Portfolio

Edit this page

Investment Portfolio

Investment Portfolio Framework

The Scaling Challenge

Picture this scenario: Your development teams want faster security reviews. Customer success needs immediate responses to security questionnaires. Compliance requires detailed audit preparations. Meanwhile, a critical vulnerability just dropped, and your CEO is asking about your incident response plan.

Sound familiar? You've hit the scaling crisis, the inevitable moment when demand for security services grows exponentially while your team capacity grows linearly.

The Inflection Point

Most security leaders respond to scaling challenges by hiring more people and working longer hours. While this provides temporary relief, it becomes increasingly difficult to sustain long-term and doesn't address the fundamental capability gap.

A Different Approach

Past a certain point, the solution is deliberately constraining some activities while investing in capabilities that reduce future manual effort rather than simply doing more security work. This section shows you how to make this strategic shift while maintaining security outcomes.

The BAU Scaling Crisis

The Capability Gap Reality

The BAU scaling crisis is a capability mismatch rather than a resource problem. When adversaries automate attacks at internet scale while defenders remain manual, no amount of hiring closes the gap.

The Structural Mismatch:

• Manual defender processes: Quarterly vulnerability scans, manual asset discovery, individual security reviews
• Scaled adversary automation: Continuous probing, automated reconnaissance, industrial-scale exploitation

This structural mismatch, manual defender processes versus scaled adversary automation, makes the crisis inevitable.

Demand Outpaces Capacity

As software factories grow, traditional security activities face a mathematical scaling challenge:

• Security reviews increase with feature velocity
• Threat modeling requests scale with system complexity
• Customer security inquiries grow with customer base expansion
• Incident response requirements increase with system surface area
• Compliance activities expand with regulatory scope

Meanwhile, security team capacity grows linearly at best. Hiring requires time and creates temporary productivity reduction during onboarding. Communication overhead increases with team size.

A word on exponential: that growth rests on AI capability continuing to compound, and the pre-training mechanism behind it may be slowing, with the public-text supply it runs on exhausting this decade. It matters less than it sounds. The demand here tracks how much code ships and how much authority automation holds, both of which keep rising on deployment alone, and the comprehension gap above is already booked. A plateau buys more time rather than a different answer. The BAU vs Scaling chapter works this through.

The Inflection Point

Organizations reach a point where demand for BAU security services exceeds sustainable capacity, creating constraints on both security effectiveness and business velocity.

Strategic Choice Point

Organizations approaching this inflection point can choose between different resource allocation strategies:

Traditional Scaling Approach

• Hire additional security personnel for manual work
• Attempt to maintain current service levels across all requests
• Build custom solutions for individual use cases
• Maintain primarily reactive security posture

Result: Temporary relief followed by recurring capacity crises

Strategic Scaling Approach

• Deliberately constrain capacity for some BAU activities
• Develop automation and self-service capabilities
• Create standardized approaches for common security needs
• Shift toward proactive, scalable security architecture

Result: Sustainable security that improves with scale

Investment Portfolio Categories

These three categories rank by the shape of their return. BAU is linear-effort work whose return is bounded by the hours spent and stops when the spending stops; Scaling investments keep paying after the spend ends (BAU vs Scaling works that economics in full). Platform Effects pay across more than one factory at once, but only where you have more than one factory to serve. Usually that means factories you do not run: a product your customers build on, an open-source tool the field adopts. A large enterprise running many factories of its own can reach the same multiplication internally. An organization that serves a single factory tops out at Scaling, which is the right ceiling for it. The ranking by return shape is the durable claim. Which rungs are open to you is a matter of context.

The payback windows below are a 2026 baseline, calibrated to today's tooling and a typical rate of adoption. They will age. The ordering they sit under does not move on the same clock.

The three categories ranked by return shape. BAU returns nothing once the spend stops; Scaling keeps compounding after it; Platform multiplies across more than one factory, where you have more than one to serve. The ordering is durable; the payback windows are a 2026 baseline that ages.

How fast any of this returns is set by absorption capacity: how fast the organization adopts a paved road, retires the manual work it replaces, and keeps a working understanding of what changed. Absorption has a measurable cost. DORA's 2024 State of DevOps research found that standing up a platform first cost roughly an eight percent dip in delivery throughput before the platform matured: the gain arrived after a temporary dip, paced by how fast teams absorbed the change rather than by the rollout date.

One thing the return-shape ranking does not say on its own: the category it tells you to prioritize, compounding scaling investment, is also the most discretionary line on the budget, which makes it the first one a downturn cuts. The 2023 round of security budget cuts landed hardest on exactly this kind of future-facing spend. That year, HackerOne found 63 percent of organizations cut their security budgets, and 39 percent cut headcount. Two instructions follow, and both are about sequencing rather than reassurance. If you are funding in an up-cycle, pre-fund the compounding capability now, because it is the line that vanishes when the cycle turns. Whatever the cycle, bias the portfolio toward capability-based controls that keep enforcing with fewer hands, because that is the spend whose value does not leave with the headcount. What a cut cannot repossess is the durable enforcement that keeps running with fewer hands, which is the Lean guide's subject. This paragraph is about what to fund first. A plateau may give you more time on the demand side; a downturn gives you less on the funding side, so build for the clock that runs out first.

BAU Activities (Constrain)

Characteristics:

• Manual work that scales with growth
• Security reviews, threat modeling, incident response
• Customer security questionnaires
• Individual risk assessments

Evaluation Criteria:

• Operational necessity
• Customer impact
• Constraint sustainability

Resource Allocation: Deliberately limited capacity post-crisis

Expected ROI: Immediate but unsustainable scaling

Constraining BAU Strategically

Constraint doesn't mean abandonment. It means providing self-service alternatives, automation, and clear prioritization criteria.

Scaling Investments (Prioritize)

Characteristics:

• Capabilities that reduce manual effort exponentially
• Automation platforms, self-service capabilities, policy-as-code
• Developer security platforms
• Continuous security validation

Evaluation Criteria:

• Manual effort reduction potential
• Developer experience improvement
• Time to value
• Cultural alignment
• Organizational change requirements
• Adversary economics

Resource Allocation: Primary investment focus past crisis point

Expected ROI: 6-18 months with compound returns (2026 baseline, modeled; paced by absorption capacity rather than a fixed calendar)

Scaling Investment Examples

• Paved Roads: Secure templates that eliminate security review needs
• Self-Service Platforms: Automated environments with security baked in
• Policy-as-Code: Automated compliance validation
• Automated Dependency Management: Continuous monitoring without manual effort

Platform Effects (Multiply)

Characteristics:

• Benefits both internal and customer software factories
• Security capabilities that create multiplicative value
• Open-source security tools
• Security-as-a-service offerings

Evaluation Criteria:

• Internal business case + multiplicative customer value
• Competitive differentiation
• Market amplification potential

Resource Allocation: Enhancement to scaling investments

Expected ROI: 12-24 months with market amplification (2026 baseline, modeled; same caveat as above)

Investment Evaluation Framework

When evaluating security investments, consider these criteria:

Criteria	Description	Why It Matters
Manual Effort Reduction	Will this eliminate repetitive work permanently?	Primary driver of sustainable scaling
Developer Experience Impact	Does this reduce security friction or create new complexity?	Critical for organizational adoption
Time to Value	How quickly will benefits become measurable?	Affects organizational confidence
Cultural Alignment	Does this support learning culture and psychological safety?	Determines long-term sustainability
Organizational Change Requirements	What adoption challenges should we anticipate?	Affects implementation success probability
Adversary Economics	Does this close the surface it claims, or only raise the cost on paths already covered?	Coverage is the test. Cost-raising counts on top of a boundary that contains the breach, not instead of it.

Designing Security Capabilities That Compound

The "Catch and Store" Principle

The most sustainable security investments do more than solve immediate problems. They capture organizational effort and store it in reusable capabilities that serve future needs without additional manual work.

Renewable Energy Analogy

Like renewable energy systems that provide ongoing value after initial investment, effective scaling investments become self-sustaining and increasingly valuable over time.

Examples of Compound Capabilities:

Paved Roads:

• Secure templates and baselines that engineers reuse without security review
• Each use provides security value without marginal security team effort
• Templates improve based on lessons learned

Self-Service Platforms:

• Automated environments and policy-as-code
• Eliminates recurring security review requests
• Scales to thousands of deployments without proportional security team growth

Automated Dependency Management:

• Continuous monitoring without manual scanning
• Automated vulnerability detection and remediation
• Improves security posture while reducing security team workload

Security-Quality Integration:

• Process improvements that serve both goals simultaneously
• Single investment, dual benefits
• Reinforcing improvements over time

Avoid Energy-Consuming Tools

Some security tools create new maintenance burdens without proportional value. Favor investments that become more valuable and less demanding over time, capabilities that store energy rather than consume it.

BAU Constraint Strategy by Organizational Stage

Organizational Stage	BAU Constraint Approach	Communication Strategy	Alternative Provision
Pre-Crisis	Maintain current service levels	"We're investing in better capabilities"	Gradual self-service introduction
Crisis Point	Strategic capacity limits	"We're shifting to sustainable scaling"	Clear self-service alternatives
Post-Crisis	Systematic constraint with alternatives	"Improved capabilities now available"	Comprehensive self-service platform

Financial Model Considerations

Security leaders must work within inherited financial constraints while building toward more strategic integration:

Cost Center Context

Reality: Security viewed as overhead to minimize

Strategy: Focus on compliance cost avoidance and operational efficiency

Communication: Emphasize business risk reduction and efficiency gains

Investment Opportunities: Crisis events create windows for scaling investment approval

Shared Services Context

Reality: Security funded through chargeback model

Strategy: Develop strong business cases emphasizing internal customer satisfaction

Communication: Highlight operational improvements that reduce business friction

Investment Opportunities: Service level improvements and efficiency gains

R&D Integration Context

Reality: Security integrated into product development budget

Strategy: Frame security investments as competitive advantages

Communication: Measure success through business outcomes rather than security-specific metrics

Investment Opportunities: Product security capabilities that differentiate in market

Strategic Conversation Template

When proposing the shift from traditional to strategic scaling:

Executive Communication

"We've identified that our current security approach may become a business constraint as we continue to scale. Rather than only adding capacity through hiring, which provides temporary relief, we recommend investing in capabilities that reduce manual effort requirements permanently.

This approach can improve both security outcomes and business velocity over time. The initial investment will create capabilities that compound: each use provides security value without proportional security team effort.

We'll measure success through developer satisfaction, security coverage, and time-to-market improvements, demonstrating that security enables rather than constrains business growth."

Implementation Roadmap

Run it in this order: assess, pilot, constrain, expand. The quarter labels are a 2026 baseline cadence. An organization with high absorption capacity may move through it in two quarters; one stabilizing heavy BAU debt may need a year. Pace the moves to what the organization can absorb rather than to the calendar.

Quarter 1: Assessment and Planning

• Measure current BAU demand and capacity
• Identify scaling investment opportunities
• Assess developer pain points
• Build business case for strategic shift

Quarter 2: Pilot Scaling Investments

• Select highest-impact scaling investment
• Implement pilot with small team
• Measure manual effort reduction
• Collect developer feedback

Quarter 3: Constrain BAU + Scale Alternatives

• Introduce strategic BAU constraints
• Provide self-service alternatives
• Communicate clearly about transition
• Monitor adoption and satisfaction

Quarter 4: Iterate and Expand

• Review pilot results and iterate
• Expand successful scaling investments
• Build compound capabilities
• Demonstrate ROI to stakeholders

---

Next Steps

Explore specific aspects of the investment portfolio framework:

BAU vs Scaling Investments Platform Effects Evaluation Criteria

---

Back to Strategic Positioning

BAU vs Scaling Investments

The Inevitable Choice

When demand outruns the team, the instinct is to read the constraint as capacity: not enough reviewers, not enough hours. Several things do bind a scaling security program, but the one thing more headcount cannot buy is comprehension bandwidth, the rate at which your people can actually understand what your factory ships. This is a race between two exponentials rather than a structural gap where a linear line loses to an exponential one and you manage the decline: how fast the factory produces, and how much of that output your people can actually secure and understand. Which curve you fund is the inflection point.

One honest caveat on the word exponential. The demand curve climbs as long as the factory ships more code and hands automation more authority, and that has compounded because AI capability has compounded. That engine is not guaranteed. Most people, when they say the models keep getting better, mean pre-training scaling. That mechanism is showing diminishing returns, and the public human text it trains on is being used up sometime this decade. Ilya Sutskever, who led much of that scaling, told NeurIPS in 2024 that "pre-training as we know it will end." A slowdown in that one mechanism is a real possibility rather than a tail risk.

It changes less than it looks like it should, for three reasons in rising order of certainty. The least certain first: the mechanism people will point to, pre-training, may stall. Next, and surer: even if it does, the demand this framework tracks is the volume of code shipped and the breadth of authority handed to automation rather than model cleverness, and both keep climbing on deployment alone, through test-time reasoning, agent fleets, and wider rollout, with no new scaling breakthrough required. Surest of all: the comprehension debt and the automated adversary are already here, since a plateau does not un-ship the code your people already cannot read, or call off the scanners already probing you. The destination is the same. What a plateau buys is time on the clock rather than a turn in the road.

Production climbs faster than comprehension; the widening gap is the share of output no one can secure or understand. Which curve you fund is the inflection point. A plateau slows demand but does not change the destination.

The investment portfolio model sorts security spending into three categories ranked by the shape of their return; this page is the execution deep dive on the hardest move in it: shifting from linear business-as-usual work to compounding scaling investment.

---

The Capability Gap

The gap runs deeper than volume: a capability mismatch between manual defenders and automated adversaries.

The Adversary Capability Shift: Since roughly 2017, adversaries evolved from targeted reconnaissance to automated discovery at internet scale. Using techniques inspired by bug bounty programs and internet-wide scanning, attackers can now:

• Discover unknown assets (forgotten servers, shadow IT, unmanaged dependencies) faster than organizations can inventory them
• Exploit known vulnerabilities within hours or days of disclosure
• Conduct credential stuffing at scale against thousands of targets simultaneously
• Probe continuously while defenders scan quarterly

One Break, Two Bottlenecks: Organizations conducting quarterly vulnerability scans face adversaries who probe continuously. Manual asset discovery can't keep pace with automated reconnaissance. Underneath both sits one break showing up in two places. On the attacker's side, automation outran a human-bound defensive process, so manual throughput loses the speed race. On the production side, automation now outruns people too: code and systems are generated faster than anyone can understand them, so manual comprehension loses the understanding race. One root cause, two human bottlenecks, neither closed by hiring alone.

Critical Insight: Supply Chain as #1 Priority

Supply chain security became the #1 priority because adversary capability evolved rather than because dependencies increased. When attackers can discover your unknown assets faster than you can catalog them, supply chain security becomes existential regardless of your other security investments.

Once a program has enough repeated work to amortize, the dollar that makes the secure path the easy path, by automating a step or packaging it into a guardrail engineers plug into, buys more than the dollar that adds one more linear reviewer, including the dollar that pays the engineer who builds it.

---

What Compounds and What Doesn't

Scaling Investments compound in two different ways, and the difference decides what each one buys. Automation takes a human out of a repeated step, so the work runs hands-free and throughput stops being bound by hours. Composable guardrails keep the human but change what they have to understand: instead of reviewing N bespoke implementations of mTLS, base images, scoped roles, or secure pub/sub, your people understand one packaged path that teams plug into. The comprehension does not disappear. It concentrates into one durable review, amortized across every team that adopts the path, which is a real economy only on the traffic that actually takes it. A guardrail also does what automation does not: because it is a boundary, it limits what goes wrong when something slips through, beyond what your reviewers have to read. Two benefits from one artifact.

The Compound Interest Principle

Just as financial investments generate compound returns, security scaling investments compound. An automation capability used 100 times costs the same to build as one used once; the build cost amortizes toward zero per use while the value keeps accruing. Manual security work never amortizes. Each review costs the same effort as the last.

What to Avoid: Tools That Create Maintenance Burden

The Maintenance Burden Trap

Some security tools create ongoing maintenance costs that exceed their security value. Avoid investments that:

• Require continuous manual tuning to remain effective
• Generate high false-positive rates demanding constant triage
• Need specialized expertise that creates key-person dependencies
• Don't integrate with existing development workflows
• Create new manual processes rather than automating existing ones

Favor investments that:

• Become more valuable and less demanding over time
• Store organizational knowledge in reusable form
• Enable self-service without security team involvement
• Integrate seamlessly into existing workflows
• Improve developer experience while improving security

---

Constraint Strategy by Position

The Strategic Position and Investment Strategy table maps each quadrant's business-as-usual load to its scaling focus. The first-year balance between the two looks very different by position:

Year-one effort split per quadrant. The more readiness you hold, the more goes to scaling rather than constraining BAU. Craft and Mass spend most on BAU for opposite reasons: Craft by intentional simplicity, Mass because legacy eats the budget.

---

BAU Constraint Communication Strategy

Constraining BAU activities requires clear communication to maintain organizational support and developer relationships.

Communication by Organizational Stage

Pre-Crisis (Building Alternatives):

Message: "We're investing in improved capabilities that will provide faster, more consistent security support."

Actions:

• Maintain current service levels while building alternatives
• Gradual introduction of self-service options
• Measure baseline metrics for later comparison
• Build organizational confidence in new approaches

---

Crisis Point (Implementing Constraints):

Message: "We've reached a scaling inflection point. To ensure sustainable security support, we're shifting from manual processes to self-service capabilities. Here's what's changing, here are the alternatives, and here's the timeline for improved capabilities."

Actions:

• Set explicit capacity limits with clear justification
• Provide immediate self-service alternatives (even if basic)
• Establish escalation paths for critical needs
• Regular updates on scaling investment progress

Example Communication:

"Our security review process has reached capacity constraints. Starting next quarter, we're implementing a self-service security baseline that will enable most teams to deploy securely without security review wait times. For projects outside this baseline, we'll use a triage process prioritizing business-critical initiatives. We expect this transition to take 6 months, after which your experience will significantly improve."

---

Post-Crisis (Systematic Operations):

Message: "Improved self-service capabilities are now available. Most teams can now [specific capability] without security team involvement, and we've measured [specific improvement metric]."

Actions:

• Demonstrate ROI realization from scaling investments
• Showcase developer experience improvements
• Adjust capacity constraints based on capability maturity
• Continuous improvement of self-service platforms

---

Success Metrics for Investment Shifts

Track these metrics to validate your BAU constraint and scaling investment strategy:

Leading Indicators (Early Signals)

• Scaling investment velocity: Projects started, adoption rates, developer feedback
• Alternative capability usage: Self-service adoption rates, platform utilization
• Developer satisfaction trends: Survey scores, friction reports, voluntary participation
• Investment pipeline health: Approved projects, executive support, resource allocation

Lagging Indicators (Results)

• Manual effort reduction: Hours saved per activity type, capacity freed for strategic work
• ROI realization: Measurable benefits vs investment costs, compound return evidence
• Security outcomes: Vulnerability detection rates, incident response times, risk posture improvements
• Business velocity: Time-to-market improvements, deployment frequency increases, developer productivity gains

---

Next Steps

1. Assess Your Position: Are you pre-crisis, at crisis point, or post-crisis in your scaling journey?
2. Evaluate Current Portfolio: Catalog BAU activities and identify scaling investment opportunities
3. Review Evaluation Criteria: Systematic framework for prioritizing investments
4. Understand Platform Effects: Additional considerations for platform companies
5. Develop Communication Strategy: Prepare stakeholder messaging for investment shifts

---

Back to Portfolio Framework Continue to Platform Effects

Edit this page

Platform Effects

Multiplicative Value for Platform Companies

Platform companies, organizations that provide capabilities to other software factories, have unique opportunities to create value that extends beyond their immediate organization. However, these opportunities come with important constraints and strategic considerations.

Critical Principle: Platform effects should serve as investment multipliers rather than primary drivers. The internal business case must work first.

---

Who This Section Is For

This guidance applies specifically to:

Platform Companies: Organizations whose products serve other software factories

• Cloud platforms (AWS, Azure, GCP, etc.)
• Development tools and CI/CD platforms (GitLab, GitHub, CircleCI, etc.)
• Security platforms and tools (vulnerability scanners, SIEM, etc.)
• Developer productivity platforms (observability, monitoring, etc.)
• Infrastructure and container platforms (Kubernetes, Docker, etc.)

Where it applies: anywhere you serve more than one software factory. Usually that means factories you do not run yourself, like a product your customers build on or an open-source tool the field adopts. A large enterprise running many internal factories can reach the same multiplication across them.

Where it does not: any org that serves a single factory. A one-factory company (even a large end-user application company) or an internal platform team serving one internal org tops out at Scaling, which is the right ceiling for it. Security vendors selling traditional enterprise software sit here too, unless the product is itself a factory platform.

If you serve only one factory, focus on BAU vs Scaling and Evaluation Criteria instead.

---

The Platform Effects Principle

Primary Responsibility: Solve Your Own Problems First

Non-Negotiable Foundation: Security investments must first make business sense for your direct needs. Platform effects are enhancement factors rather than justifications.

Why This Matters:

• Your security team's primary responsibility is securing your software factory
• Platform features that don't solve your internal problems create maintenance burden
• Customer value without internal value is unsustainable
• Failed internal implementations can't become successful external products

The Platform Distraction Trap

Risk: Building security features for customers that your own organization doesn't use or value

Symptoms: Platform features your internal teams avoid, customer requests driving roadmap over internal needs, security theater for market positioning

Solution: Eat your own dog food. If your security team won't use it internally, don't build it for customers.

---

Multiplicative Opportunity: When Internal and Customer Value Align

The Strategic Multiplier: When security investments that solve your internal problems also benefit customer software factories, this creates additional value justifying:

• Higher investment levels than internal-only business case supports
• Faster implementation timelines with cross-functional priority
• Different prioritization relative to competing initiatives
• Market differentiation and competitive advantage opportunities

Example: Automated dependency scanning

• Internal value: Reduces your security team's manual effort, improves your supply chain security posture
• Customer value: Enables your customers to secure their supply chains using your platform
• Platform effect: every customer who adopts the feature multiplies the security value beyond your internal use; the multiple tracks adoption rather than your headcount
• Competitive advantage: Security capability differentiating your platform from competitors

---

Platform Investment Prioritization Framework

Use this systematic framework to evaluate security investments when you're a platform company:

Evaluation Dimensions

Dimension	Assessment Criteria	Weight	Strategic Implication
Direct Security Benefit	Does this solve our internal security problems?	Primary	Business case foundation, must pass threshold independently
Multiplicative Customer Value	Does this create additional customer value?	Enhancement	Multiplier on internal business case, breaks ties between competing investments
Competitive Differentiation	Does this create defensible advantages?	Strategic	Market positioning, pricing power, customer acquisition/retention
Industry Influence	Does this position us as thought leaders?	Market	Long-term market development, standard adoption, ecosystem benefits

---

Decision Matrix

Strong Internal + Strong Customer Value (Highest Priority):

• Example: Automated vulnerability management solving your supply chain problems that customers can use
• Priority: Accelerate implementation, allocate cross-functional resources, market aggressively
• Timeline Impact: May justify materially faster implementation than an internal-only business case (calibrate to your org)
• Investment Level: Can justify materially higher investment than internal-only features (calibrate to your org)

Strong Internal + Weak Customer Value (Standard Priority):

• Example: Internal compliance automation specific to your regulatory environment
• Priority: Standard internal security investment evaluation using evaluation criteria
• Timeline Impact: Normal implementation sequencing
• Investment Level: Internal business case justification required

Weak Internal + Strong Customer Value (Avoid):

• Example: Security features customers request but your team doesn't use
• Priority: Decline or deprioritize, likely maintenance burden without sustainability
• Warning: High risk of poor execution, customer disappointment, wasted investment

Weak Internal + Weak Customer Value (Reject):

• Example: Security theater features for marketing purposes
• Priority: Hard reject, diverts resources from valuable work
• Risk: Damages credibility with both internal teams and customers

Priority is carried by the rank numerals and labels rather than color. The internal business case must pass on its own; customer value is the multiplier, never the justification.

---

Customer Zero Insights and Strategic Weighting

The "Customer Zero" Advantage

Platform companies often serve as sophisticated users of their own products, providing unique insights into security challenges and solutions. Your internal security pain often represents market opportunities.

Adversary Evolution Insights: When your platform company experiences security challenges that mirror broader industry shifts, these Customer Zero insights carry additional strategic weight.

Example: Modern Supply Chain Security

Your platform company discovers that:

• Automated dependency scanning significantly reduces your manual security effort
• Your security team's productivity improves 3x with automated vulnerability management
• Unknown dependency discovery becomes systematic rather than reactive

Strategic Insight: If this internal pain point reflects modern adversary capabilities (automated discovery at scale), it likely represents a market opportunity affecting thousands of customer software factories facing the same capability gap.

---

Customer Zero Cost Impact Assessment

When evaluating internal security pain points, weight them by total organizational impact including the Customer Zero amplification factor:

Cost Category	Internal Cost Assessment	Customer Zero Multiplier (illustrative)	Strategic Priority
Direct Incident Costs	Breach response, system downtime, recovery efforts	1x (internal impact)	High
Security Research/Bug Bounty	External researcher rewards, program costs	2x (customer trust impact)	Medium
Vulnerability Management	Discovery, assessment, patching cycles	1.5x (operational efficiency)	High
Business Disruption	Customer communication, support escalation, sales impact	3x (customer experience amplification)	High
Engineering Cycles	Feature development diverted to security firefighting	2x (opportunity cost amplification)	Medium
Customer Trust Erosion	Churn risk, sales pipeline impact, competitive disadvantage	5x (platform company trust multiplier)	Critical

These multipliers are judgment anchors for ranking pain points rather than measured coefficients. Calibrate them to your own incident data before attaching dollar weights.

Strategic Application: If a security issue category costs your organization $5M annually across these factors, and Customer Zero insights suggest this affects thousands of customers similarly, the platform investment justification becomes compelling:

• Internal problem: $5M annual cost
• Customer impact: Thousands of factories facing similar issues
• Platform solution value: Addresses market need while solving internal problem
• Competitive differentiation: Security capability competitors may lack

---

Implementation Prioritization for Platform Companies

When you've identified a security investment with both internal and customer value, use this sequencing approach:

Phase 1: Internal Implementation and Validation (Critical)

Objective: Solve your own problem first, learn from real usage

Activities:

• Implement security capability solving your internal team's pain
• Use internally with realistic production workloads
• Measure actual impact on your security team's effectiveness
• Iterate based on internal feedback and usage patterns

Success Criteria:

• Your security team actively uses and values the capability
• Measurable improvement in internal security metrics
• Positive feedback from internal stakeholders
• Sustainable operational model established

Timeline: 3-6 months typically

---

Phase 2: Customer Zero Learnings Integration

Objective: Refine based on internal experience before customer exposure

Activities:

• Document lessons learned from internal implementation
• Identify operational challenges and edge cases discovered
• Develop customer-facing documentation based on internal experience
• Create support and troubleshooting guidance from real issues

Success Criteria:

• Clear understanding of capability limitations and tradeoffs
• Documented internal patterns from usage
• Realistic customer expectations established
• Support burden manageable based on internal experience

Timeline: 1-2 months typically

---

Phase 3: Limited Customer Beta (If Customer Value Validated)

Objective: Validate customer value hypothesis with friendly customers

Activities:

• Select 3-5 sophisticated customers for beta program
• Provide hands-on support during initial adoption
• Measure customer outcomes and gather detailed feedback
• Validate that customer experience matches your internal experience

Success Criteria:

• Customers achieve measurable security improvements
• Feedback validates value hypothesis
• Support burden matches predictions
• Customers actively use the capability rather than only enabling it

Timeline: 3-6 months typically

---

Phase 4: General Availability (Only If Beta Succeeds)

Objective: Scale capability to broader customer base

Activities:

• Polish customer experience based on beta feedback
• Scale support infrastructure for broader adoption
• Market capability emphasizing customer outcomes
• Monitor adoption and iterate based on usage patterns

Success Criteria:

• Adoption rates meet targets
• Customer satisfaction scores strong
• Support burden sustainable
• Competitive differentiation realized

---

Security as Competitive Advantage

Market Differentiation Questions

Evaluate whether security investments create defensible competitive advantages:

1. Does this capability create defensible competitive advantages?

• Is this difficult for competitors to replicate?
• Does this build on unique platform strengths?
• Can this become customer-facing product value driving adoption?

2. Does this enable market expansion?

• Does improved security enable entry into regulated industries?
• Can this support enterprise customer requirements?
• Does this address blockers in sales pipeline?

3. How does this compare to competitor security offerings?

• Do competitors offer similar capabilities?
• Is your implementation meaningfully better?
• Can customers easily switch to competitors?

4. What is the thought leadership opportunity?

• Can this position you as security innovation leader?
• Does this enable industry standard or best practice development?
• Will this attract top security talent to your organization?

---

Communication Strategy for Platform Companies

Critical Balance: Platform companies must clearly communicate that platform security capabilities serve dual purposes, protecting the platform while enabling customer security, without creating unrealistic expectations about security responsibility transfer.

The Shared Responsibility Clarity Requirement

Platform security features enhance customer capabilities but don't transfer security accountability. Customers remain responsible for their security decisions and implementations.

Good Communication Example:

"Our automated dependency scanning capability protects our platform and is available to help you secure your software factory. This tool provides vulnerability detection and remediation guidance, but you remain responsible for reviewing findings and making security decisions appropriate to your risk tolerance and operational context."

Bad Communication Example (Avoid):

"Our platform handles your security, so you don't need to worry about vulnerabilities." [Implies accountability transfer]

---

Platform Effect Measurement

Track these metrics to validate platform effects investment strategy:

Internal Metrics (Primary)

• Internal security improvement: Your team's security posture improvements
• Internal operational efficiency: Reduced manual effort, faster incident response
• Internal developer satisfaction: Your engineers' experience with security capabilities

Customer Metrics (Secondary)

• Customer adoption rates: Percentage of customers using platform security capabilities
• Customer security outcomes: Measurable improvements in customer security postures
• Customer satisfaction scores: NPS or similar for security features
• Customer retention impact: Reduced churn attributable to security capabilities

Competitive Metrics (Strategic)

• Market differentiation: Customer acquisition attributable to security capabilities
• Thought leadership indicators: Conference talks, standards adoption, media coverage
• Talent attraction: Security engineer recruiting success, employer brand strength

---

Common Platform Company Pitfalls

Pitfall 1: Building for Customers Before Internal Validation

Symptom: Platform features your own security team doesn't use

Consequence: Poor quality, unsustainable support burden, customer disappointment

Solution: Always implement internally first, validate value, then consider customer availability

---

Pitfall 2: Overselling Security Responsibility Transfer

Symptom: Marketing language implying customers can "let platform handle security"

Consequence: Customer misunderstanding, blame when security issues occur, legal/liability concerns

Solution: Clear shared responsibility communication, explicit customer accountability

---

Pitfall 3: Platform Effect as Primary Driver

Symptom: Investments justified by customer value without internal business case

Consequence: Unsustainable features, internal team resistance, maintenance burden

Solution: Require internal business case independence, use customer value as multiplier only

---

Pitfall 4: Ignoring Customer Zero Insights

Symptom: Internal security pain dismissed as "just our problem"

Consequence: Missed market opportunities, competitive disadvantage

Solution: Systematic assessment whether internal pain represents broader market need

---

Next Steps

1. Assess Platform Company Status: Confirm whether platform effects guidance applies to your organization
2. Evaluate Current Investments: Review security investments through platform effects lens
3. Prioritize Internal Value: Ensure internal business cases are solid before considering customer value
4. Review Evaluation Criteria: Systematic framework works for all security investments
5. Consider Customer Zero Insights: Identify internal pain representing market opportunities

---

Back to BAU vs Scaling Continue to Evaluation Criteria

Edit this page

Investment Evaluation Criteria

Systematic Framework for Prioritizing Security Investments

Security leaders face overwhelming numbers of potential investments: automation projects, tooling purchases, process improvements, platform capabilities. Without systematic evaluation criteria, investment decisions become reactive or driven by whoever shouts loudest.

This framework provides objective criteria for evaluating and prioritizing scaling investments.

---

When to Use This Framework

Appropriate for:

• Scaling investments (automation, self-service, platform capabilities)
• Tool and technology selection decisions
• Process improvement prioritization
• Resource allocation across competing security initiatives

Not designed for:

• Emergency incident response (requires immediate action)
• Regulatory compliance requirements (non-discretionary)
• Executive-mandated initiatives (political reality)
• BAU activity triage (different evaluation model)

---

The Six Evaluation Criteria

Use these criteria to score and compare potential security investments systematically:

1. Manual Effort Reduction

The Question: Will this eliminate repetitive work permanently?

Why Primary: Manual effort reduction is the fundamental driver of sustainable scaling. Investments that don't reduce manual work don't solve the scaling crisis. They may improve security outcomes but won't enable organizational growth without proportional security team expansion.

Hours saved is a proxy for value rather than the value itself. This criterion counts the work an investment displaces, never the work it creates downstream: the generated code someone still has to understand, the dependencies it adds, the authority it now holds, the maintenance it needs. Credit a high score here only net of that cost. The risk is structural rather than careless. Once hours saved carries a 2x weight it becomes a target, and a measure under target pressure stops tracking the value it once stood for. An investment that saves hours while widening what can go wrong has not reduced effort. It has moved the effort somewhere this number cannot see.

Assessment Framework:

Score	Manual Effort Reduction	Annual Hours Saved	Example
5 - Exceptional	Eliminates entire category of manual work	2,000+ hours annually	Automated dependency scanning replacing manual reviews
4 - High	Reduces 70-90% of manual effort in domain	1,000-2,000 hours	Self-service environment provisioning
3 - Moderate	Reduces 40-70% of manual effort	500-1,000 hours	Automated security questionnaire responses
2 - Low	Reduces 10-40% of manual effort	100-500 hours	Partial process automation
1 - Minimal	Reduces <10% of manual effort	<100 hours	Security tool with high manual overhead

Assessment Questions:

• What manual security work does this eliminate completely?
• How many person-hours per month does this category consume currently?
• Will benefits compound as the organization scales?
• Does this create capacity for strategic work, or just shift manual effort?
• What new authority, attack surface, or maintenance burden does this automation create, and is that cost already netted in your Adversary Economics score?

Red Flags:

• "This tool will help us work more efficiently" (without specific hour reduction)
• Automation that requires extensive manual tuning or maintenance
• Solutions that create new categories of manual work

---

2. Developer Experience Impact

The Question: Does this reduce security friction or create new complexity?

Why Critical: Scaling investments require developer adoption to deliver value. Security capabilities that degrade developer experience face resistance, workarounds, or abandonment regardless of security benefits. Developer experience is not a "nice to have." It determines adoption success.

Assessment Framework:

Score	Developer Experience	Time Impact	Adoption Likelihood
5 - Exceptional	Dramatically improves developer workflow	Saves developers 5+ hours/week	Enthusiastic adoption, voluntary expansion
4 - High	Noticeably improves workflow	Saves 2-5 hours/week	Willing adoption, positive feedback
3 - Neutral	Minimal workflow change	±30 minutes/week	Passive acceptance, follow guidelines
2 - Moderate Friction	Some workflow disruption	Costs 1-2 hours/week	Resistance, some workarounds
1 - High Friction	Significant workflow disruption	Costs 5+ hours/week	Active resistance, widespread workarounds

Assessment Questions:

• Does this integrate seamlessly into existing development workflows?
• How much additional time or effort does this require from developers?
• Do developers see personal benefit, or only security team benefit?
• What happens when developers encounter edge cases or issues?
• Is this faster/easier than current alternatives (including workarounds)?

Developer Experience Testing:

• Pilot with friendly team before broad rollout
• Measure time-to-first-value (how long until developers see benefits)
• Track voluntary vs mandated adoption
• Monitor for workaround creation or process avoidance

---

3. Time to Value

The Question: How quickly will benefits become measurable?

Why Important: Time to value affects organizational confidence in scaling investment strategy. Long-running projects with delayed benefits create skepticism, while quick wins build momentum and executive support. This doesn't mean always choosing the fastest options, but timeline awareness is critical for communication and sequencing.

Assessment Framework:

Score	Time to Value	Measurable Benefits	Organizational Impact
5 - Immediate	<3 months to measurable impact	Quick win visible to stakeholders	Builds confidence quickly, enables next investments
4 - Fast	3-6 months to measurable impact	Benefits emerging, metrics improving	Sustains momentum, validates strategy
3 - Moderate	6-12 months to measurable impact	Significant effort before payoff	Requires sustained commitment, regular updates
2 - Slow	12-18 months to measurable impact	Long investment before returns	Requires strong executive support, milestone communication
1 - Delayed	18+ months to measurable impact	Benefits uncertain or far future	High risk of abandonment, requires exceptional justification

Assessment Questions:

• What is the minimum viable implementation that delivers measurable value?
• Can we phase this to deliver incremental benefits?
• What metrics will demonstrate value, and when can we measure them?
• How do we communicate progress during implementation?

Sequencing Strategy:

• Start investment portfolio with high time-to-value projects (score 4-5)
• Build organizational confidence before tackling longer-term investments
• Mix quick wins with strategic long-term capabilities
• Communicate realistic timelines; don't over-promise to get approval

---

4. Cultural Alignment

The Question: Does this support learning culture and psychological safety?

Why Critical: Security investments succeed or fail based on organizational culture. Capabilities that punish developers, create blame dynamics, or undermine psychological safety will be resisted or circumvented regardless of security benefits. Cultural alignment is a hard requirement for adoption success.

Assessment Framework:

Score	Cultural Alignment	Psychological Safety Impact	Learning Culture Support
5 - Exceptional	Actively builds learning culture	Enhances safety, enables experimentation	Facilitates continuous improvement, knowledge sharing
4 - High	Supports existing culture	Maintains safety, no blame creation	Enables learning opportunities
3 - Neutral	Culturally compatible	Doesn't affect safety dynamics	Neither helps nor hinders learning
2 - Friction	Cultural resistance likely	May create defensive behavior	Could limit experimentation
1 - Damaging	Undermines culture	Reduces safety, creates blame	Inhibits learning, creates fear

Assessment Questions:

• Does this create opportunities for learning and improvement?
• Will this tool/process be used to blame individuals for security issues?
• Does this support experimentation and innovation, or constrain it?
• How does this affect trust between security and engineering teams?
• Does this enable self-service and autonomy, or create dependencies and gatekeeping?

Cultural Red Flags:

• Tools that "catch" developers making mistakes (blame framing)
• Processes that require security approval for experimentation
• Metrics that rank individuals or teams on security "scores"
• Automation that blocks without explanation or education
• Systems that feel like surveillance rather than enablement

---

5. Organizational Change Requirements

The Question: What adoption challenges should we anticipate?

Why Important: Even technically excellent capabilities fail if organizational change requirements exceed capacity. Understanding change burden helps with sequencing (tackle easier wins first), resource planning (what support is needed), and communication strategy (how to frame the change).

Assessment Framework:

Score	Change Requirements	Adoption Difficulty	Success Requirements
5 - Minimal	Works with existing processes	Easy adoption, minimal training	Basic communication, standard rollout
4 - Low	Minor workflow adjustments	Some training required	Clear documentation, support availability
3 - Moderate	Significant workflow changes	Moderate training, practice needed	Change management, pilot programs, champions
2 - High	Major process transformation	Extensive training, culture shift	Sustained executive support, dedicated change resources
1 - Extreme	Organizational restructuring	Fundamental way-of-working change	Multi-year transformation, may require external help

Assessment Questions:

• How much does this change existing ways of working?
• What training or skill development does this require?
• Do we have change management resources to support adoption?
• What is the organizational appetite for change right now?
• Are there competing changes creating change saturation?

Change Management Success Factors:

• Start with willing early adopters rather than mandates
• Provide hands-on support during initial adoption
• Celebrate early successes and share learnings
• Address failures constructively, iterate based on feedback
• Ensure executive visible support throughout adoption

---

6. Adversary Economics

The Question: Does this close the surface it claims, or only raise the cost on paths already covered?

Why Important: Adversary economics is real, but it is easy to measure the wrong part of it. An attacker does not pay the average cost of attacking you. They pay for the cheapest way in that still works. Harden nine of an attacker's ten ways in and leave the tenth open, and that tenth path still costs what it always did. Your average goes up. The real cost to breach you does not move. This is why the breaches that hurt so often trace back to one dull thing: a storage bucket left public behind a well-run security program, an aging server no one re-checked. The damage hides in the seams between the parts you hardened, rather than in the parts themselves. So the test is coverage rather than price. Does this capability actually close the surface it claims, or does it just raise the toll on paths that were already covered? Cost-raising still earns its place, but on top of a boundary that contains the breach when one gets through, never in place of one. An expensive attack that slips through an open seam owns you just as completely as a cheap one.

One kind of cost-imposition earns full credit on its own: friction that comes with an alarm you can act on. Plant something that has no real use and watch who touches it. A fake admin login, a decoy database, a credential that should never be used. The moment anyone uses it, you know, because no legitimate person ever would. That is not raising the average toll. It is closing the blind spot where an intruder moves unseen. So the rule is simple: cost-imposition counts when it comes with a signal and a way to contain whatever trips it. Friction with nothing watching does not, because the attacker just reroutes to the next cheapest path and you never find out.

Deception is the clearest case

Honeypots, canary tokens, and honeytokens are the standard tools (the discipline MITRE Engage organizes). A common real version: drop a fake cloud access key into a private repository. It does nothing, so the instant it shows up in your logs you have a true alarm and a rough location for the intruder, with almost no false positives. Deception works because of that signal rather than the friction. It closes the detection surface while covering no prevention surface, which is also why Bejtlich's Intruder's Dilemma ("the defender only needs to detect one indicator") is really a detection argument rather than a cost one.

Assessment Framework:

Score	Adversary Impact	Attack Economics Change	Strategic Security Value
5 - Exceptional	Forces adversary pivot to different vector	Makes current attacks infeasible	Closes entire attack category
4 - High	Significantly increases attack cost/time	Requires sophisticated adversary capability	Substantially raises bar for successful attacks
3 - Moderate	Moderately increases attack difficulty	Deters opportunistic attackers	Reduces risk from common threat actors
2 - Low	Slightly increases attack effort	Minimal impact on determined adversaries	Limited practical security improvement
1 - Minimal	No meaningful adversary impact	Attacks remain economical	Compliance theater, negligible risk reduction

Assessment Questions:

• Does this eliminate an attack vector completely, or just make it harder?
• Do attackers need to develop new capabilities to succeed?
• Does this protect against automated/scaled attacks, or only targeted efforts?
• Will adversaries simply move to easier targets or different techniques?
• Does this address current adversary capabilities, or historical threats?

Adversary Evolution Context:

Adversaries evolved from targeted reconnaissance to automated discovery at internet scale. Investments that address this capability gap have exceptional adversary economics impact:

• Automated asset discovery (defenders find assets before attackers)
• Continuous vulnerability management (close windows of exposure)
• Supply chain automation (detect unknown dependencies)
• Real-time threat detection (match adversary speed)

Community-Level Success: Once in a while a whole field closes a path for good, and attackers leave it because it stops paying. Software has done this once already, at the transport layer. The web moved to encryption by default, with free certificates and browsers warning on plain HTTP, and the old trick of sniffing someone's login over open Wi-Fi mostly died. Attackers did not keep trying it. They moved on.

At the level of the code itself, software has not done this yet. The best attempt so far is the shift to memory-safe languages. When you write in a language that makes an entire class of memory bugs impossible, those bugs stop appearing at all, instead of being found and patched one at a time. The early numbers are real: as Android moved new code to memory-safe languages, the share of its vulnerabilities that were memory-safety bugs fell from about three-quarters to under a quarter in six years.

That is the shape of the highest form of security success: a whole attack method deleted from every target at once, beyond the average cost of attack merely rising. It is rare, it is slow, and at the code level it is still a direction more than a destination. And even when a field finishes the job, it never closes your own seams for you. The industry can retire a path for everyone, and one team with a forgotten gap still loses through it.

---

Investment Scoring and Prioritization

Scoring Method

For each potential investment, score across all six criteria (1-5 scale):

1. Manual Effort Reduction (weight: 2x)
2. Developer Experience (weight: 1.5x)
3. Time to Value (weight: 1x)
4. Cultural Alignment (weight: 1.5x)
5. Organizational Change (weight: 1x)
6. Adversary Economics (weight: 2x)

Total Score Calculation:

Total = (Manual Effort × 2) + (Developer Experience × 1.5) + (Time to Value × 1) +
        (Cultural Alignment × 1.5) + (Organizational Change × 1) + (Adversary Economics × 2)

Maximum Possible Score: 45
Minimum Possible Score: 9

---

Priority Thresholds

Total Score	Priority	Action
36-45	Must Do	Implement immediately, highest resource priority
27-35.5	Should Do	Strong business case, sequence strategically
18-26.5	Consider	Evaluate context, may be valuable in specific situations
9-17.5	Avoid	Poor fit, likely low ROI or high failure risk

---

The Risk Override

One rule sits on top of the score. A high Manual Effort Reduction score cannot by itself lift an investment past Should Do when Adversary Economics is low. Effort saved is not risk retired, and the spine of this framework is risk rather than activity. An investment that reduces real toil but closes no surface and contains no breach is a productivity buy rather than a security one, and it should rank as the productivity buy it is.

The override has a second clause, for the failure the first cannot see. An automation can score high on effort saved and honestly high on Adversary Economics while still introducing a new credential, a new trust boundary, or a delegation path that nothing has accounted for. A score gates on a threshold. It never subtracts. So when the assessment question above surfaces a new authority or surface that is not already netted in Adversary Economics, that investment does not clear Should Do on effort alone, whatever the total reads. The override keeps the arithmetic honest to the spine: risk-realization decides the tier rather than toil-realization.

The spend-side companion to this override is Defender cost economics: once the cost of the next control exceeds the risk it retires, you accept and sign the residual rather than keep adding controls.

---

Example Investment Evaluation

Proposed Investment: Automated dependency scanning with auto-remediation

Scoring:

• Manual Effort Reduction: 5 (eliminates 2,000+ hours of manual reviews annually)
• Developer Experience: 4 (automatic security fixes reduce developer toil)
• Time to Value: 5 (measurable benefits within 8 weeks of deployment)
• Cultural Alignment: 4 (enables learning, no blame dynamics)
• Organizational Change: 4 (low change requirement, integrates with existing CI/CD)
• Adversary Economics: 5 (addresses modern adversary capabilities, closes supply chain gaps)

Total Score: (5×2) + (4×1.5) + (5×1) + (4×1.5) + (4×1) + (5×2) = 10 + 6 + 5 + 6 + 4 + 10 = 41

Priority: Must Do (Score 41/45)

Justification: Exceptional score across all criteria. Addresses fundamental scaling challenge while improving developer experience and closing critical security gaps created by adversary evolution.

---

Position-Specific Evaluation Adjustments

Your strategic position affects criteria weighting:

Studio (Small reach + Higher Readiness)

Adjust weights:

• Increase Time to Value weight (rapid iteration preferred)
• Increase Developer Experience weight (preserve innovation culture)
• Decrease Organizational Change concern (high change capacity)

Prioritize: Quick-win automation, developer-centric tools, modern platform capabilities

---

Lean (Large reach + Higher Readiness)

Adjust weights:

• Increase Adversary Economics weight (sophisticated threat model)
• Increase Cultural Alignment weight (learning culture critical at scale)
• Maintain balanced approach across all criteria

Prioritize: Platform capabilities, federated solutions, cultural scaling mechanisms

---

Craft (Small reach + Lower Readiness)

Adjust weights:

• Increase Organizational Change sensitivity (limited change capacity)
• Prioritize readiness-building over automation breadth
• Focus on foundational capabilities enabling future investments

Prioritize: Readiness infrastructure, documentation, basic automation proving value

---

Mass (Large reach + Lower Readiness)

Adjust weights:

• Dramatically increase Organizational Change sensitivity (change saturation risk)
• Increase Time to Value weight (need quick wins for credibility)
• Focus on hybrid solutions working with legacy constraints

Prioritize: Strategic debt reduction, hybrid architecture, visible quick wins building momentum

---

Comparative Investment Analysis

Use this framework to compare competing investments:

Example Scenario: Choose between three automation investments with limited budget

Investment	Manual Effort	Dev Experience	Time to Value	Cultural	Org Change	Adversary Econ	Total Score	Priority
Dependency Scanning	5	4	5	4	4	5	41	Must Do
Security Review Automation	4	3	3	3	3	3	29	Should Do
Compliance Documentation	2	2	4	3	4	1	21.5	Consider

Decision: Prioritize dependency scanning: highest total score, addresses adversary evolution, exceptional ROI.

---

Common Evaluation Mistakes

Mistake 1: Optimizing for Single Criterion

Problem: Choosing investments based solely on one factor (usually cost or vendor relationship)

Consequence: Miss investments with exceptional overall value but moderate cost

Solution: Systematic multi-criteria evaluation, weighted scoring

---

Mistake 2: Ignoring Developer Experience

Problem: Selecting security tools security team loves but developers hate

Consequence: Poor adoption, workarounds, wasted investment

Solution: Pilot with developers first, weight developer experience appropriately

---

Mistake 3: Underweighting Cultural Alignment

Problem: Treating culture as "soft" factor, prioritizing technical capabilities

Consequence: Technically excellent solutions that fail organizationally

Solution: Recognize cultural alignment as a hard requirement rather than a nice-to-have

---

Mistake 4: Chasing Vendor Hype

Problem: Investing based on vendor marketing rather than internal evaluation

Consequence: Tools solving problems you don't have, creating new maintenance burden

Solution: Start with your pain points, evaluate vendors against your criteria

---

Next Steps

1. Catalog Potential Investments: List scaling investments under consideration
2. Score Systematically: Evaluate each using six criteria framework
3. Prioritize by Position: Apply position-specific weighting adjustments
4. Sequence Strategically: Consider BAU vs Scaling investment timing
5. Review Platform Effects: Additional considerations if you're a platform company

---

Back to Platform Effects Continue to Contextual Modifiers

Edit this page

Contextual Modifiers

Contextual Modifiers

Adapting Your Strategy to Organizational Reality

The core framework applies universally, but organizational reality bends how you implement it. Contextual modifiers are the factors that do the bending: the reasons two organizations in the same strategic position need different implementation approaches.

The method for working with modifiers is permanent: assess each one's impact, read how they compound or offset, adjust your sequence. The recognized set of modifiers is not fixed. Eight factors earn a place today. If your organization faces a contextual reality these eight miss, the method is built to absorb it: apply the same logic and add it.

Context Matters

Two organizations in the same strategic position (e.g., both in the Mass quadrant) may need different implementation approaches based on their contextual modifiers. These factors help you customize the universal framework to your reality.

The Eight Modifiers (The Recognized Set)

These eight are the recognized set: the factors that meet the test below and weigh most on a software factory's security strategy right now. The set grows when reality reveals a factor the others cannot hold, and it sheds one when a factor stops telling organizations apart.

Modifier	Impact on Implementation	Assessment Questions
Attack Landscape Maturity	Accelerates need for automation; manual processes become existential vulnerabilities	Do attackers discover our assets before we do? Are we seeing automated reconnaissance?
Supply Chain Complexity	May require Lean-level tools regardless of base quadrant	How many dependency tiers? Critical single vendors? Geopolitical constraints?
Regulatory Constraints	Cuts both ways: a BAU drag that can delay progression, but also a forcing function and a market-access lever that make security easier to fund	Audit frequency? Technology constraints? Compliance violation risk?
Crisis Events	Can rapidly accelerate quadrant movement through organizational change	Recent major incidents? Lasting organizational changes?
Change Capacity	Affects transition speed and scaling investment success probability	Tool rollout timelines? Process disruption tolerance?
Relationship Health	Directly affects adoption velocity and scaling investment success	Proactive consultation frequency? Voluntary participation rates?
AI Saturation	Shifts the binding constraint from writing code to understanding it; pushes review toward automated guardrails and authorization toward per-request scope	What share of code, review, and ops runs through AI and agents? Is review keeping pace with generation?
PQC Exposure	Front-loads crypto-agility and migration sequencing for long-confidentiality data; the work scales with how hard your primitives are to rotate	How long must your data stay secret? Can you rotate a cryptographic primitive, or is it welded into firmware?

How Modifiers Work

Impact Levels

Each modifier has three impact levels that influence your implementation:

Low Impact: Minor adjustments to base quadrant approach

Moderate Impact: Significant customization needed; may advance or delay certain investments

High Impact: May require capabilities from a different quadrant or fundamentally alter implementation timeline

Modifier Interaction

Contextual modifiers can compound or offset each other:

Compounding Effects:

• High attack landscape maturity + high supply chain complexity = Supply chain becomes urgent regardless of quadrant
• Low change capacity + poor relationship health = Scaling investments will face significant adoption challenges

Offsetting Effects:

• High regulatory constraints (slows down) + crisis events (speeds up) = May create windows for change during crisis response
• Low change capacity + strong relationship health = Adoption challenges mitigated by trust and collaboration

Why These Eight

The eight aren't arbitrary, and the count isn't permanent. A contextual modifier is a factor that meets three tests:

1. It doesn't fix your position. Two organizations in the same strategic position can sit at opposite ends of it. A factor that only restates your position is not a modifier. Correlation is fine: regulatory exposure often tracks with position, but two regulated firms in the same quadrant can still carry very different compliance loads.
2. It shifts implementation. It changes the pace, sequence, or investment of how you implement, rather than which position you occupy.
3. It isn't already covered. No modifier already in the set captures the implementation shift it drives. Partial overlap is fine. A factor fails only when an existing modifier already does its work.

These three tests are why the set holds where it does, and they are the gate for adding the next one.

Adding a Modifier

When a real factor passes all three tests, give it three impact levels (Low / Moderate / High) with questions a security leader can answer, and state how each level shifts implementation. Every modifier chapter already follows that assessment shape. A new one slots into the same matrix and the same compounding-and-offsetting logic, with no change to the method. This is the move the framework makes wherever a fixed list could harden into dogma: name the rule that generates the set rather than only the set.

The seventh modifier is the proof. AI Saturation entered the set when AI moved from the margins of the pipeline to its center. It doesn't fix your position: a Craft shop and a Mass enterprise can each be barely touched or saturated. It shifts implementation: when AI writes code faster than people can read it, the binding constraint moves from writing to reviewing, and the investment moves from manual review toward automated guardrails and scoped agent identity. And it isn't already covered: supply chain measures what you pull in, attack landscape measures the adversary outside your boundary, while saturation measures how much of your own pipeline now runs faster than your people can comprehend it. It passed the gate, so it was recognized as the seventh. PQC Exposure is the eighth, recognized the same way: nothing in the set touched cryptography, and the quantum-migration clock made the gap impossible to fold into another factor.

Every modifier must also be falsifiable. State it as a testable prediction, not an assertion. Most modifiers take the standing-exposure shape. Score an organization's level on the factor before an outcome. Organizations that scored high and did not act should then face a specific, costlier implementation difference than organizations that scored low and also did not act. If the two face the same cost, the factor is falsified. A few take an accelerant shape instead: the factor is present or it is not, and its presence should produce a specific, faster or larger movement than its matched absence at equal intent, with equal movement falsifying it. Crisis Events is the accelerant case; the rest are standing exposures. A modifier that cannot be written as one of these two sentences is a vocabulary word, not a risk-reducing distinction, and does not enter the set. Each modifier chapter carries its own version.

When the Map Stops Fitting

Two activities are easy to confuse: rating where you sit, and changing the set itself. They run at different speeds. Assessing where you sit on each modifier is ongoing, per-organization work: your position on AI Saturation or Regulatory Constraints drifts as your world changes, and re-rating it belongs on a cadence. Changing the recognized set itself is rare and evidence-driven. It is not something you schedule.

The modifiers are a map of your organization's reality, and like any map they hold until the terrain moves. You will not learn the set is behind from a calendar. You learn it when you catch yourself stretching a modifier to cover something it was never shaped to hold, forcing a new kind of risk into the closest old category because that category is what's on the slide. That stretch is the signal.

The stretch nominates; it does not decide. It is a prompt to run the three tests above, not proof a factor is missing. Sometimes the honest answer is that the modifier is broad and should hold the new factor, which is what the third test protects. A stretch that fails the gate confirms the set already covers the ground. A stretch that clears it means the territory grew a region the map did not have, and the factor is recognized. AI was that case: practitioners kept filing it under Supply Chain Complexity or Attack Landscape Maturity, it fit neither, and AI Saturation became the seventh.

So schedule the thing that drifts rather than the thing that doesn't. Re-rate your position across the modifiers on a cadence, faster for the volatile ones. Revisit the recognized set itself only when the stretch keeps recurring, when reality has outgrown the map. A periodic look is a backstop for the drift you missed rather than a reason to add.

Retiring a Modifier

Adding is only half the discipline. A modifier earns its place by discriminating, by separating two organizations in the same position. When it stops, it has to go. A factor retires when scoring it no longer changes anyone's implementation sequence: it has saturated to a baseline every organization shares, so it no longer tells two same-position orgs apart. The practical signal is the mirror of the addition test: you catch yourself scoring it and changing nothing you'd fund. Attack Landscape Maturity is the likeliest first candidate. If automated adversaries become a universal baseline, how mature the threat is against you stops separating anyone, and the factor folds into the assumed conditions of building software at all. Retiring is as evidence-driven and unscheduled as adding. You do not retire a modifier on a calendar; you retire it when it has lost its variance.

When a Folded Factor Earns Its Own Seat

The set sheds and grows by the same gate. A factor folded into a broader modifier today is not folded forever. When a parent modifier saturates, when AI Saturation, say, becomes a universal baseline, that is the trigger to re-run the three tests on the facets folded inside it. A facet graduates to its own seat only if it then independently passes all three against the new set. Parent-saturation triggers the test; it is not itself the promotion. This is how the set stays honest while it grows: a folded factor waits, named and visible, until it can clear the gate on its own. Calling something a facet is never a quiet way to keep it.

Using Modifiers Strategically

Assessment Process

1. Evaluate Each Modifier: Use the assessment questions to determine impact level (Low/Moderate/High)
2. Identify Compounding Factors: Look for modifiers that reinforce each other
3. Spot Constraints: Understand which modifiers limit your options
4. Find Opportunities: Identify modifiers that could accelerate transformation

Implementation Adjustments

For Positive Modifiers (High relationship health, strong change capacity):

• Accelerate transformation timelines
• Take on more ambitious scaling investments
• Experiment with advanced capabilities earlier

For Constraining Modifiers (High regulatory constraints, low change capacity):

• Extend timelines and add checkpoints
• Start with smaller pilots before broad rollout
• Invest in change management and stakeholder alignment
• Choose less disruptive implementation paths

For Crisis Modifiers (High attack landscape maturity, recent crisis events):

• Prioritize security investments that address immediate threats
• Use urgency to accelerate approvals and adoption
• Balance rapid response with sustainable transformation

Contextual Modifier Matrix

Use this matrix to assess your organization:

In this matrix, a factor's level runs Low to High by magnitude rather than good-to-bad. For most modifiers a higher level constrains you; for a few (change capacity, relationship health) a higher level accelerates you. See Implementation Adjustments for how direction is handled.

Modifier	Low Impact	Moderate Impact	High Impact	Your Assessment
Attack Landscape	Primarily targeted attacks	Automated attacks on common vulnerabilities	Adversaries discovering assets faster than your inventory	?
Supply Chain	Standard dependencies, known vendors	Multi-tier dependencies, critical SaaS integrations	National security implications, highly regulated vendors	?
Regulatory	Standard business compliance (GDPR, privacy)	Industry-specific requirements (HIPAA, PCI-DSS, SOX)	Government/defense requirements (FedRAMP, financial regulations)	?
Crisis Events	Minor operational issues	Security incidents, compliance failures	Major breaches, business disruption	?
Change Capacity	Risk-averse culture, slow adoption	Selective pilots, gradual rollouts	Innovation culture, rapid experimentation	?
Relationship Health	Damaged security-R&D relationships	Functional but transactional	Strategic partnership collaboration	?
AI Saturation	AI on the margins, human-reviewed	AI in the workflow, review straining	AI the default author, generation decoupled from comprehension	?
PQC Exposure	Short-lived secrets, agile crypto	Mixed data lifetimes, partial agility	Decade-long data behind primitives hard to rotate	?

Strategic Examples

Example 1: Studio with High Attack Landscape Maturity

Base Position: Studio (Small reach + Higher Readiness)

Modifier Impact: High attack landscape maturity means automated adversaries despite small scale

Adjustment: Prioritize supply chain automation and continuous monitoring even earlier than typical Studio roadmap. The capability gap created by automated adversaries requires immediate automation response.

Example 2: Mass with Strong Relationship Health

Base Position: Mass (Large reach + Lower Readiness)

Modifier Impact: Strong relationship health enables faster adoption despite operational constraints

Adjustment: Use that trust to implement hybrid solutions more aggressively. Good relationships reduce friction of transformation, allowing faster progress than typical Mass timeline.

Example 3: Lean with High Regulatory Constraints

Base Position: Lean (Large reach + Higher Readiness)

Modifier Impact: Heavy regulatory burden increases BAU workload despite strong operational capabilities

Adjustment: Factor compliance operational overhead into capacity planning. May need dedicated compliance automation investments before other scaling capabilities.

Example 4: Lean with High AI Saturation

Base Position: Lean (Large reach + Higher Readiness)

Modifier Impact: Most code and much of review now run through AI; generation has outpaced human comprehension

Adjustment: Move the security investment from manual review to automated guardrails, and from static authorization to per-request agent identity. A Lean team's scale advantages hold only if review is automated, and saturation exposes manual gates first.

Next Steps

Explore each contextual modifier in detail to understand how it affects your implementation:

Attack Landscape Maturity Supply Chain Complexity Regulatory Constraints Crisis Events Change Capacity Relationship Health AI Saturation PQC Exposure

---

Back to Investment Portfolio

Attack Landscape Maturity

The Critical Shift: From Targeted to Automated

Around 2017, the attack landscape fundamentally changed. Adversaries evolved from targeted reconnaissance against specific organizations to automated discovery at internet scale, sweeping billions of assets to find exploitable weaknesses.

The Automation Advantage

High attack landscape maturity means adversaries can discover your unknown assets (forgotten servers, shadow IT, unmanaged dependencies) faster than you can inventory them. This creates an existential capability gap regardless of your strategic position.

Maturity Levels

Low Maturity: Targeted Attacks

Characteristics:

• Attacks require specific knowledge of your systems
• Manual reconnaissance against known targets
• Attacker invests time in individual organizations
• Exploitation requires customization

Defender Advantage:

• Manual security processes can keep pace
• Quarterly assessments may be sufficient
• Asset discovery matches attacker reconnaissance speed

Implementation Impact: Manual security processes remain viable

Moderate Maturity: Automated Common Vulnerabilities

Characteristics:

• Automated scanning for known vulnerabilities
• Some internet-scale reconnaissance
• Exploitation of common misconfigurations
• Credential stuffing at scale

Defender Challenge:

• Manual processes start falling behind
• Need for continuous monitoring increases
• Asset inventory must be more frequent

Implementation Impact: Automation becomes important but not yet existential

High Maturity: Industrial-Scale Automation

Characteristics:

• Bug bounty techniques applied at internet scale
• Adversaries discover assets before defenders catalog them
• Rapid exploitation of disclosed vulnerabilities
• Automated reconnaissance of entire attack surfaces
• Real-time vulnerability weaponization

Defender Crisis:

• Manual defender processes versus scaled adversary automation
• Quarterly asset inventories face adversaries with continuous discovery
• Unknown assets become critical vulnerabilities
• Speed of response becomes existential

Implementation Impact: Manual security processes become existential vulnerabilities

The Capability Gap

Organizations relying on quarterly asset inventories face adversaries who discover vulnerabilities continuously at internet scale. No amount of hiring closes this gap. Only automation can match automated adversaries.

Assessment Questions

Use these questions to determine your attack landscape maturity:

Question	Low Maturity	Moderate Maturity	High Maturity
Discovery Speed	We discover assets before attackers	Roughly equal	Attackers discover before us
Attack Automation	Targeted manual attacks	Some automated scans	Industrial-scale automation
Exploitation Speed	Days to weeks	Hours to days	Minutes to hours after disclosure
Reconnaissance Scale	Targeted orgs	Industry sectors	Internet-wide sweeps
Unknown Asset Risk	Low concern	Moderate concern	Critical vulnerability

Impact on Strategy

For All Quadrants

High attack landscape maturity accelerates the need for automation regardless of your strategic position:

Studio: Implement continuous monitoring and automated security from inception; manual processes won't hold even at small scale

Lean: Advanced threat detection and response automation become critical; scale advantages only work with automation

Craft: Must prioritize basic automation earlier than typical roadmap; manual processes create existential risk

Mass: Automation becomes urgent even with limited operational readiness; hybrid manual/automated approaches are insufficient

Investment Priorities

Low Maturity Context:

• Manual security processes remain viable
• Gradual automation roadmap acceptable
• Focus on process maturity before automation

Moderate Maturity Context:

• Begin prioritizing automation investments
• Accelerate continuous monitoring capabilities
• Balance manual and automated approaches

High Maturity Context:

• Automation becomes existential priority
• Supply chain continuous monitoring critical
• Asset discovery automation required
• Real-time vulnerability detection essential
• Rapid response automation necessary

Real-World Indicators

You're facing high attack landscape maturity when:

• Attackers are exploiting vulnerabilities within hours of disclosure
• You're discovering unauthorized systems during incident response
• External parties notify you of assets you didn't know existed
• Automated scanning attempts occur continuously
• Credential stuffing attacks happen at scale
• Supply chain attacks target your dependencies systematically

Strategic Response

Short-Term (0-6 months)

1. Asset Discovery Automation: Implement continuous asset inventory
2. Vulnerability Scanning: Move from quarterly to continuous scanning
3. Threat Intelligence: Subscribe to real-time threat feeds
4. Incident Detection: Deploy automated monitoring for critical systems

Medium-Term (6-18 months)

1. Security Orchestration: Automate response to common attacks
2. Supply Chain Monitoring: Continuous dependency vulnerability tracking
3. Attack Surface Management: Automated external attack surface discovery
4. Threat Hunting: Proactive automated threat detection

Long-Term (18+ months)

1. AI-Powered Detection: Machine learning for anomaly detection
2. Autonomous Response: Self-healing systems for common attacks
3. Predictive Security: Anticipate attacks before they occur
4. Security-as-Code: Complete automation of security capabilities

Connection to Supply Chain Stewardship

High attack landscape maturity makes Supply Chain Stewardship the #1 priority because:

• Adversaries discover supply chain vulnerabilities at scale
• Dependency confusion attacks happen automatically
• Compromised packages are detected through industrial scanning
• Manual dependency tracking can't keep pace

This is why supply chain became the #1 priority when the attack landscape matured to industrial-scale automation.

Is This Modifier Earning Its Place?

Score an organization's attack-landscape maturity before a year of operation. High-scorers who kept manual processes will absorb materially more automated-discovery damage than low-scorers who kept them. Equal damage falsifies this modifier.

---

Next Steps

Continue to Supply Chain Complexity Back to Contextual Modifiers Overview

Supply Chain Complexity

Beyond Volume: Complexity as Risk Multiplier

Supply chain complexity is less about the number of dependencies than about the interconnected risk created by multi-tier dependencies, critical single vendors, and geopolitical constraints.

Volume is easy to count and mostly beside the point. A thousand well-maintained, widely used dependencies with clear provenance carry less risk than a handful you cannot see past the first tier. The three drivers below each break the count-and-relax instinct in a different way. Multi-tier depth hides your real exposure two or three levels down, where you have no direct relationship and often no visibility. A critical single vendor concentrates continuity risk in a node whose failure you cannot absorb. Geopolitical constraint removes options you assumed were fungible. Each is a different shape of one fact: what you depend on matters more than how much.

May Require Lean-Level Tools

High supply chain complexity may require Lean-level supply chain tools regardless of your base quadrant position. Organizations with critical supply chains should prioritize supply chain stewardship investments early.

Complexity Levels

Simple Supply Chain

Characteristics:

• Standard dependencies with known vendors
• Direct relationships (minimal tiers)
• Straightforward compliance
• Geographic simplicity
• Minimal single points of failure

Implementation: Standard supply chain stewardship from your quadrant

Complex Supply Chain

Characteristics:

• Multi-tier dependencies (2-3 levels deep)
• Critical SaaS integrations
• Multiple geographic regions
• Some vendor concentration risk
• Industry-standard security requirements

Implementation: Enhanced supply chain visibility and management

Critical Supply Chain

Characteristics:

• National security implications
• Highly regulated vendors (defense, finance)
• Geopolitical constraints and restrictions
• Bloc bifurcation: the same primitive available in one technology bloc, unavailable or untrusted in another
• Critical single vendors (business-critical dependencies)
• Supply chain attacks as existential risk

Implementation: Enterprise-grade supply chain security regardless of position

Assessment Questions

Question	Simple	Complex	Critical
Dependency tiers?	1-2 levels	2-3 levels	3+ levels with unknowns
Single vendor risk?	Multiple alternatives	Some concentration	Critical dependencies
Geopolitical concerns?	Minimal	Moderate	Significant constraints
Regulatory requirements?	Standard	Industry-specific	Government/defense
Supply chain attack impact?	Recoverable	Significant	Existential
Vendor/dependency survivability?	Vendors stable, deps actively maintained	Some single-maintainer or aging deps	Load-bearing dep on one maintainer or a vendor that could vanish

Impact on Strategic Position

Complexity behaves differently from the other modifiers. Most of them tune how fast or how carefully you implement your quadrant's approach. Complexity can override the quadrant outright: a Craft organization with a critical supply chain needs capabilities its position would not otherwise justify, because the risk does not scale with your size, it scales with what you depend on. The higher the complexity, the harder the supply chain condition pulls investment up regardless of where you sit.

Simple Supply Chain

Follow standard quadrant approach for supply chain stewardship

Complex Supply Chain

• Enhanced SBOM capabilities required
• Multi-tier dependency tracking
• Vendor relationship management program
• Supply chain risk scoring

Critical Supply Chain

Requires Lean-level capabilities even in other quadrants:

Craft with Critical Supply Chain:

• Implement enterprise SBOM tools early
• Comprehensive vendor security program
• May need dedicated supply chain security role

Mass with Critical Supply Chain:

• Prioritize supply chain modernization
• Hybrid approaches with enhanced visibility
• Balance legacy and modern supply chain security

Studio with Critical Supply Chain:

• Use advanced supply chain automation
• Policy-as-code for supply chain governance
• AI-powered supply chain risk analysis

When a Single Vendor Is Load-Bearing

The complexity levels measure how tangled your supply chain is. They do not measure what happens when one load-bearing node stops existing. A critical single vendor is two risks wearing one label. Concentration risk is the ordinary one: too much rides on a single supplier, so a bad quarter or a breach on their side ripples straight into yours. Continuity risk is the sharper one: the supplier is simply gone, and the question stops being how well it performs and becomes whether it exists next year.

Vendors vanish for reasons that have nothing to do with their security posture. An acquirer buys the product and sunsets it. The company runs out of money. A license or pricing change prices you out overnight. An export restriction cuts off a supplier you were using legally yesterday. The sole maintainer of an open-source package deep in your tree stops answering. None of these surface in a vulnerability scan.

The work is to name the dependencies whose loss stops the business rather than merely slows it, and for each one hold an answer to the plain question: what do we do the week it is gone. The instruments are known and cheap to stage ahead of need. Qualify a second source before you are forced to. Hold source escrow for proprietary code you cannot live without. Keep an exit runbook current. Build enough abstraction that swapping a vendor is a project, not a rebuild. You cannot do this for everything, so rank by blast radius and fund continuity only where the loss is existential. The rest you carry, with your eyes open.

When the Stack Bifurcates

There is a second case the levels cannot see: the same primitive is available in one technology bloc and unavailable or untrusted in another. When a cloud, a chip, a model, or a cryptographic standard splits along geopolitical lines, "use the best tool" stops being one global decision and becomes one decision per bloc. You dual-source primitives you would rather buy once, duplicate build and deployment pipelines to keep each bloc supplied, and sequence roadmap work around export controls and entity lists that can redraw the available set with little warning.

This is the source-and-build half of sovereignty: what you can buy, run, and ship. The legal half, which regimes you must answer to, lives in Regulatory Constraints under jurisdiction plurality. Same geopolitics, two different questions, and they usually arrive together. Treat a welded-in single-bloc dependency the way PQC Exposure treats a cryptographic primitive that is hard to rotate: the exposure is less that you use it and more that you could not change it in time if you had to. Know which of your primitives are single-bloc: a foundry or chip family, a frontier model and its API, a hardware security module or the cryptographic library it implements, a hyperscaler region you cannot replicate elsewhere. Know the fallback for each, and budget the duplication as a standing cost of operating across blocs rather than a migration you will someday finish.

Is This Modifier Earning Its Place?

Score an organization's supply-chain complexity before a third-party failure. High-scorers without enhanced visibility will absorb a materially larger blast radius than low-scorers without it. Equal blast radius falsifies this modifier.

Next Steps

Continue to Regulatory Constraints Back to Attack Landscape

Regulatory Constraints

Regulation Cuts Both Ways

Regulation is both a drag and a driver. Most security strategies see only the drag.

As a drag, regulation increases BAU workload, constrains technology choices, and can delay transformation. As a driver, it does two things, and both come down to what security can get funded to build. It is a forcing function: a mandate dissolves the "why now, who pays" friction that stalls security investment in a normal budget cycle, the same way a crisis does, except on a schedule you can plan against. And it opens markets: clearing a regulatory bar makes you eligible to compete where you were shut out, and once cleared, that same bar raises the cost of entry for competitors who have not cleared it. Neither is revenue the security function delivers; both make the investment easier to fund.

Both driver effects carry the same caveat. Compliance is not security. Clearing the bar makes you eligible and easier to fund; it does not hand you a safer system. The capability still has to be built.

How much the caveat bites depends on your operational readiness. In lower-readiness organizations, the mandate often does pull real security forward; it supplies discipline the organization has not yet built on its own. Higher-readiness organizations have already cleared these bars, so compliance and real security come apart, and running the program to the mandate can quietly cost you posture. Standards move slower than the security knowledge underneath them. A re-validation cycle can keep a flawed cryptographic module in place long after the flaw is found, because re-certifying takes far longer than patching. A control can also outlive its evidence: mandated periodic password rotation stayed in standards until the field showed it drives people toward weaker, predictable secrets. When the mandate is the program, you inherit its lag.

This lag changes direction over time. Early on, a regulation is a gate: it limits your technology choices and sets the pace of what you can change, and that gate is real. Given enough time, it inverts. The rule was written to match what the field knew that year; the field moves on, the rule does not, and the same mandate that once pushed you forward starts holding your posture below where it would otherwise sit. The password-rotation and validated-module cases above are small versions of that flip. This lag is structural, not a failure of any one regulator: rules are set on slow cycles by bodies that do not track the frontier in real time. Closing it would take coadaptive regulation, written to evolve as the field does, and that does not exist at scale today. If it ever emerges and a rule's requirements track the frontier within a single revision cycle, the lag has closed for that rule. Watch for it; do not budget on it.

Constraint Levels

Minimal Regulatory

Standard business compliance (GDPR, basic privacy)

• Flexible implementation choices
• Standard commercial tools acceptable
• Regular but manageable audit cycles

Implementation Impact: Minimal external constraint, and minimal external forcing function. With no mandate to lean on, security investment has to win the internal budget fight on its own merits. That is the fight it most often loses. And minimal is a position rather than a permanent property.

Regulation telegraphs. CIRCIA was law four years before its reporting rule landed; the EU's Cyber Resilience Act and AI Act each signaled years of obligations before the first one bound anyone. In a lightly regulated domain the signal is usually there to read well ahead of the rule; whether you act on it depends on where your organization operates today and where it aspires to operate. A domain you already score high on, AI Saturation or Supply Chain Complexity, is where regulation tends to move first; when it does, an organization that built no capacity under light regulation absorbs a high-stakes mandate from a standing start.

Minimal can change

If you intend to sell into a regulated market, the bar is already visible. Build toward it before it becomes a deadline, while it is still cheaper than compliance under a clock.

Sector-Specific

Industry requirements (HIPAA, PCI-DSS, SOX)

• Constrained technology choices
• Regular audit cycles with documentation burden
• Industry-specific security controls
• Compliance-driven BAU workload

Implementation Impact: Increases BAU burden; factor into capacity planning

High-Stakes Regulatory

Government/defense (FedRAMP, financial regulations)

• Severely limited technology options
• Continuous compliance monitoring
• Extensive documentation requirements
• Compliance as gating factor for changes

Implementation Impact: May extend transformation timelines; compliance becomes primary constraint

When It Lands Faster Than You Can Build

Everything above is the regulation you can see coming. Telegraphed rules give you years. CIRCIA, the CRA, and the AI Act all signaled their demands long before they bound anyone, and the move is to build toward the visible bar early. The harder case is the one you cannot see coming. An event, a breach wave, a safety failure, a political shift, sets off new regulation on a short clock: the compliance deadline arrives before you could realistically build the security capability the rule requires. The AI Act is the live example: a field went from barely regulated to a binding, tiered law in about two years. An organization running heavy on AI with no governance in place had to meet that bar from a standing start. A crisis is the usual trigger, so this pairs with Crisis Events: the incident creates the mandate, and the mandate sets the clock.

What helps is less prediction than the things that make any new rule cheaper to absorb whenever it lands. The first is partnership with the functions that usually meet compliance before security does. Sales, go-to-market, and legal carry the real skin in the compliance game. They read the market-access pressure and the regulatory signal early, and a security team close to them gets advance warning and a shared business case when capacity has to be funded fast. The second is a compliance cross-walk: a standing map from the controls you already run to the frameworks you might have to meet. Most frameworks are versions of each other, overlapping heavily in what they actually require, so an organization that has crosswalked its controls absorbs a new mandate as the delta it adds rather than as a build from zero.

The window is rarely truly zero. Regulators usually phase enforcement or open a grace period, and what they reward in it is a credible, good-faith program you can show early rather than a finished one. A team that has done the cross-walk shows that fast. A team that has not pulls people off the roadmap, pays consultants a premium, and takes the efficiency hit of a scramble. The cross-walk is cheap to build ahead of need and expensive to build under a clock.

When Many Rules Apply at Once

The levels above measure how deep a single regulation cuts. They say nothing about how many apply at once. Depth and breadth are different problems, and you can have either without the other. One firm clears a single hard bar, FedRAMP High, and runs routine everywhere else. Another answers to a dozen lighter rules at the same time, no single one of them severe, and pays more in total than the first. That second cost is jurisdiction plurality, and the depth scale above cannot see it.

The cost compounds because each rule comes with its own evidence, its own data-residency requirement, its own reporting clock, and its own auditor, and the work does not merge. Some rules genuinely cannot both hold. Keep EU personal data beyond the reach of US lawful-access demands and you cannot also store it where a US provider can be compelled to hand it over; honor a GDPR erasure request and you cannot also preserve that record under a US litigation hold. Others do not contradict so much as fragment: the EU AI Act and the US state patchwork can both be met, but only with different settings in each place.

Either way, no one build serves everyone, so you split the work to stay legal: separate data environments and customer-held keys where residency and access collide, separate builds or feature gates where one jurisdiction forbids what another requires, and duplicated audits and evidence on top. Few architectures are compliant everywhere at once. That is the legal twin of the stack bifurcation in Supply Chain Complexity, and the budget line a CFO grasps fastest. A cross-walk collapses the overlap most frameworks share; genuine conflict is the residue it cannot, and that residue is what forces the split.

This is the paperwork half of sovereignty. Which laws you must answer to lives here; what technology you can buy, run, and ship under bloc bifurcation lives in Supply Chain Complexity. Same geopolitics, two different questions. They usually arrive together, and you score, fund, and sequence them apart.

Assessment Questions

Question	Minimal	Sector-Specific	High-Stakes
Audit frequency?	Annual	Quarterly	Continuous
Technology constraints?	Minimal	Moderate	Severe
Documentation burden?	Standard	Significant	Extensive
Compliance violation risk?	Manageable	Serious	Existential
Regulatory surge rate?	Telegraphed, years of lead	Occasional new rules, plannable	Event-driven, deadline shorter than build
Jurisdiction plurality?	One set of rules	A few, broadly aligned	Many, some in conflict

Strategic Implications

Factor compliance overhead into: Capacity planning, Timeline estimates, Tool selection, Change management

Opportunities during compliance: Crisis events, Audit findings, Regulatory changes

Is This Modifier Earning Its Place?

Score an organization's regulatory load, including how many separate rules apply and whether any conflict, before a scaling push. High-scorers who budgeted no compliance overhead will overrun capacity materially more than low-scorers who budgeted none. Equal overrun falsifies this modifier.

Surge is the second test, and a rarer one. Score, before new regulation hits a domain and never after, whether an organization has crosswalked its existing controls and partners closely with the functions that usually see compliance pressure first. At the same regulatory load, the one that has should absorb the hit at materially lower cost than the one that has not. Equal cost falsifies surge as a separate dimension from load. True surges are rare, so this is the chapter's hardest prediction to run, and the honest one to keep.

Next Steps

Continue to Crisis Events Back to Supply Chain Complexity

Crisis Events

Strategic Opportunity Through Disruption

Crisis events create unique windows for organizational change. Security incidents, compliance failures, and business disruptions can rapidly accelerate quadrant movement by shifting organizational priorities and unlocking resources.

Crisis as Catalyst

A crisis dissolves the friction that normally slows reallocation: priorities clear, budget frees, approvals that took quarters take days. It funds none of that on its own; the freed resources flow to whoever already holds a ready roadmap. The work is to stay staged so the window finds you ready.

Types of Crisis Events

Security Incidents

• Data breaches
• Ransomware attacks
• Supply chain compromises
• System compromises
• Customer data exposure

Compliance Failures

• Audit failures
• Regulatory violations
• Certification losses
• Customer security requirement failures

Business Disruptions

• Service outages from security issues
• Customer impact from security gaps
• Revenue loss from security incidents
• Market reputation damage

Impact on Transformation

Pre-Crisis

Normal state: Gradual change, competing priorities, incremental budgets

Security position: Requested but not urgent

During Crisis

Heightened urgency: Security becomes top priority, resources unlock, decisions accelerate

Window of opportunity: A finite stretch of elevated priority and funding. Practitioners often plan for one to two quarters; treat that as a rule of thumb rather than a measured figure. Plan for it to close sooner than you expect.

Post-Crisis

Two possible outcomes:

1. Sustained Change: Crisis leads to lasting organizational transformation and continued investment
2. Return to Normal: Initial momentum fades, priorities revert, limited lasting impact

Strategic Response to Crisis

Immediate Response (Days)

• Contain and resolve crisis
• Communicate transparently
• Document lessons learned
• Begin root cause analysis

Short-Term Exploitation (Weeks-Months)

• Present strategic security roadmap
• Secure funding for scaling investments
• Fast-track approved initiatives
• Build momentum for transformation

Long-Term Transformation (Months-Years)

• Implement sustained security improvements
• Build on crisis-driven approvals
• Maintain executive attention
• Demonstrate measurable progress

Assessment Questions

Question	Minor	Moderate	Major
Recent incidents?	Operational issues	Security incidents	Major breaches
Business impact?	Minimal	Significant	Existential
Organizational changes?	None	Some adjustments	Fundamental transformation
Lasting effects?	Temporary	Moderate duration	Permanent changes

Using Crisis Strategically

Stay Staged: A crisis arrives on its own schedule, and the window closes on its own schedule, so a roadmap written once and parked is stale by the time it is needed. Staying staged starts with knowing your top systemic risks as a software producer, named concretely enough to hold a plan against each. What sits at the top is yours, not a standard list: for one org it is workstation access into production, for another a missing artifact server or no hardened base-image service, for another a supply chain it cannot see into. Stage the highest-priority one or two, and add the rest as your change capacity allows. When one of those risks lands, the staged roadmap is most of the answer already. Contain the incident, run the retro, and let what it teaches sharpen the staged roadmap before you launch it inside the window. If the budget was not there before, use the now-visible risk to build the case the organization was not ready to hear.

• Keep a response plan for your highest-priority risks (one or two for a thin team)
• Rebaseline those plans on a cadence
• Refresh business cases against current numbers
• Know the organizational blockers, and which a crisis removes

Act Quickly:

• Present solutions during crisis
• Secure commitments while urgent
• Fast-track initiatives
• Build irreversible momentum

Sustain Changes:

• Deliver quick wins
• Demonstrate measurable improvement
• Maintain executive visibility
• Build lasting capabilities

When No Window Ever Opens

Everything above assumes the crisis arrives. Some of the most consequential security work never gets a moment, and a reader who takes "stay staged so the window finds you ready" as universal will stage a roadmap for a window that never comes. Post-quantum exposure and comprehension debt build like a rising tide, not a lightning strike: no breach alert, no outage, no board email. What you get instead is a silent clock, running against a deadline you either set yourself or never see. These are chronic exposures, the kind that build with no triggering crisis, and PQC exposure and AI saturation already score them as standing factors, which is the right way to size them. But sizing a risk does not fund the work to retire it. This chapter relies on one mechanism: a crisis that forces budget loose. For a chronic exposure it never fires, because no crisis arrives to trigger it.

Three moves fund the work anyway.

An acute incident spikes and opens a finite funding window a staged roadmap can ride. A chronic exposure runs as a silent clock that never spikes, so three moves fund it without a crisis: make it legible, piggyback a real window, or couple it to funded work.

Make the silent clock legible. A crisis frees budget by making a latent risk visible and urgent to every decision-maker at once. That shared sight ends the argument before the usual vetoes reassemble. You can produce the same shared sight without the harm, by turning a silent risk into one the budget-holders can read. Two instruments do that:

• a cryptographic bill of materials that puts your long-lived data, the primitives protecting it, and the deprecation deadline on a single page (PQC exposure);
• a queryable model of how your systems behave, which surfaces the questions about your own estate that no one can currently answer (AI saturation).

A peer's incident of the same class supplies the urgency the instruments cannot: organizations change course on a demonstrated exposure even when it lands on someone else (vicarious and near-miss learning). Put the inventory, the deadline, and the precedent in front of the people who hold the budget, in their own terms of expected loss. The legitimacy line is firm. Show something real, and close with a specific ask and a date. Spend the move sparingly. A warning that does not pan out gets discounted by the third telling, and the credibility you spent is gone.

Piggyback on the next real window. When an acute incident does open a window, bundle the chronic work onto it, but only when the two share a root cause. Brittle key handling exposed by a breach is the moment to fund crypto-agility, because it is one problem fixed once. A post-quantum migration bolted onto an unrelated ransomware response is scope creep, and the executive who smells padding cuts the whole package back. A window holds only so much change at once (change capacity): spend it on the acute fix first, and let the chronic work ride the slipstream. Never let the added scope slow the containment the window was opened to fund.

Couple it to work that is already funded. Not every chronic fix needs its own budget line. When a broader product or engineering initiative is already moving, with money and a deadline behind it, make the security work a true dependency of it. The teams have to clear it to reach their own goal, so the shared objective carries it across the line. Each coupling also earns the standing that makes the next ask easier.

Coupling funds whatever the moving initiative happens to need, which will not always be your highest risk. Take it anyway, but keep the discipline where it counts. Spend your legibility and your crisis windows on the top risks, where the gain is largest. Use coupling for the lower-ranked work that would otherwise sit at zero. Coupling earns timing and cost on work that already deserves funding; it is never a reason to fund work you otherwise would not. The day momentum picks your roadmap instead of risk, the discipline has snapped. A ranked plan only retires the risks that actually get funded, so a lower one that ships beats a higher one that never does. What counts is realized risk reduction, not the order of the list.

All three moves get more urgent when money is tight. When the broader capital environment is already contracting, an acute incident stops freeing fresh budget: the purse was clamped before the crisis landed. The funded initiatives you might couple onto grow scarce too. The chronic clocks keep running regardless. So build these plays before the squeeze arrives (funding under pressure).

Common Pitfalls

Crisis Anti-Patterns

Reactive-Only: Fixing immediate issue without strategic improvements

Over-Promising: Commitments that can't be sustained post-crisis

Wasted Window: Missing opportunity while crisis urgency exists

Return to Normal: Allowing organizational attention to fade

Is This Modifier Earning Its Place?

Crisis Events is an accelerant rather than a standing exposure, so it falsifies in the accelerant shape. Score whether an organization has had a recent crisis before measuring strategic movement. Orgs with crisis events will show faster quadrant change than matched orgs without, at equal intent. Equal movement falsifies this modifier.

The chronic case, an exposure that builds with no triggering crisis, carries its own test, because it claims you can move such an exposure without a crisis of its own: by making it legible to budget-holders, by piggybacking a real crisis window, or by coupling it to funded work. Chronic exposures worked through one of those moves should move measurably faster than matched exposures left alone. If the worked exposures move no faster than the untouched ones, the claim is false and the moves were theater.

Next Steps

Continue to Change Capacity Back to Regulatory Constraints

Change Capacity

Organizational Ability to Absorb Transformation

Change capacity determines how quickly you can implement security transformations. It affects transition speed, scaling investment success probability, and overall transformation timeline.

Change capacity is really a clock, and it is the slow one. Every transformation runs on two. The install clock is how fast you can stand the change up: buy the tool, flip the config, grant the authority, light up the pipeline. The absorb clock is how fast the organization actually runs on it: people change how they work, the new path becomes the default, the old one shuts off. Change capacity is the absorb clock.

The two are not equally visible, and that is where the money leaks. The install date has an invoice and a deploy log; the absorb date has nothing, unless you build it. So leaders manage the clock they can see. They price the move on the install date, call it done when the tool is live, and are surprised two quarters later when the numbers have not moved, because no one's behavior has. A tool installed but not absorbed is shelfware with a green light.

The error is testable. Projects dated and closed on the install date should show lower sustained adoption two quarters out than otherwise-matched projects tracked to an absorb milestone. If they adopt just as well, the pricing error is not real and this is only relabeling.

You cannot price a clock you cannot read, so make the absorb clock legible first. Before you start, name the absorb milestone the way you would a ship date: the share of work running on the new path, the date the old path is switched off, the point where the change is the default rather than the option. Price the move on that.

The install clock is short and visible; the absorb clock runs longer and stays invisible unless you build a way to read it. The gap between them is where the spend leaks. Schedule by the absorb budget rather than the install date.

Capacity Levels

Risk-Averse / Slow Adoption

• Conservative culture
• Lengthy approval processes
• Resistance to new tools
• Gradual rollout requirements
• Change fatigue from previous initiatives

Implementation Impact: Extend timelines, increase change management investment, pilot-first approaches

Selective / Gradual Rollouts

• Measured approach to change
• Pilot programs before broad adoption
• Structured change management
• Balanced innovation and stability

Implementation Impact: Standard transformation timelines with appropriate checkpoints

Innovation Culture / Rapid Experimentation

• Embrace of change
• Fast decision-making
• Tolerance for experimentation
• Quick adoption of new tools
• Learning-oriented culture

Implementation Impact: Accelerate transformation timelines, reduce change management overhead

Assessment Questions

Question	Low Capacity	Moderate Capacity	High Capacity
Tool rollout timeline?	12+ months	6-12 months	3-6 months
Process disruption tolerance?	Very low	Moderate	High
Change management resources?	Limited	Adequate	Strong
Recent change success?	Mixed/negative	Generally positive	Consistently successful
Cultural innovation orientation?	Risk-averse	Balanced	Innovation-focused
Concurrent change overlap (top two initiatives)?	Share two or more of	Share one	Share none

Strategic Implications

Low change capacity requires:

• Longer transformation timelines
• More extensive pilots and proofs-of-concept
• Significant change management investment
• Incremental rather than transformative changes
• Strong executive sponsorship

High change capacity enables:

• Compressed transformation timelines
• Bold strategic investments
• Rapid experimentation and iteration
• Transformative rather than incremental changes

Absorption Is a Shared Budget

Change capacity is one budget, not one allowance per project. Every change in flight draws on the same store: the same people's attention, the same tolerance for disruption before fatigue sets in. The change-saturation research is consistent that this tolerance is finite, and that piling concurrent change on the same people degrades all of it. So two big moves in the same quarter do not run in parallel. They contend, and overdrawing the budget makes each absorb worse than it would alone.

How much two changes contend comes down to how much they share. Four overlaps decide it: the same people doing the absorbing, the same approval body in the path, the same sponsor spending political capital to defend each one, the same system or pipeline being touched. The more of these two changes share, the harder they pull against each other. Score the overlap before the quarter starts, while you can still resequence. A diagonal transformation and a high-exposure PQC migration that run through the same people, the same review board, and the same exec are three overlaps deep, and stacking them means both absorb badly. Sequence them instead.

This is what turns change capacity from a description into a sequencing tool. You schedule by the absorb budget, not by what you can install: you can stand up four tools at once, you cannot absorb four changes at once. Sequencing your actual transformation paths by this budget is where the movement paths come in.

The honest default is contend rather than parallelize. Real initiatives almost always share at least one of the four surfaces, so running both this year usually costs you on absorption even when the install schedules fit. Genuine independence across all four, separate people and approval and sponsor and system, does happen, and then you can run them together. But it is rarer than optimism assumes. Make clean separation something you have to prove before you bank on it.

Is This Modifier Earning Its Place?

Score an organization's change capacity from its prior track record (slack, governance, how past rollouts went) before a new one. High-scorers will complete adoption materially faster than low-scorers running the same rollout. Equal timelines falsify this modifier.

The budget claim carries its own test, and it must be scored before the fact, never after. Before a quarter, rate two concurrent major changes on the four overlaps (shared people, approval body, sponsor, system). Pairs that share several should absorb materially worse than the same pair run one after the other; pairs that share none should absorb no worse than sequential. If a high-overlap pair absorbs as cleanly as sequential, or a no-overlap pair absorbs worse, the budget model is falsified. Overlap scored after you see the result does not count.

Next Steps

Continue to Relationship Health Back to Crisis Events

Relationship Health

Adoption Velocity Is the Binding Constraint

A scaling investment pays off only when the organization takes it up. The capability you ship sets a ceiling; how fast it gets adopted decides whether you ever reach it. That makes adoption velocity the binding constraint on this modifier once the capability exists. Relationship health is the strongest lever on it while the people doing the adopting are human: strong relationships speed adoption, damaged ones turn every rollout into a negotiation.

Relationship Levels

Damaged Relationships

• Security seen as blocker
• Minimal communication
• Adversarial interactions
• Security bypassed when possible
• Mutual distrust

Implementation Impact: Significant adoption challenges; must rebuild trust before transformation

Functional but Transactional

• Working relationship exists
• Reactive consultations
• Compliance-focused interactions
• Limited collaboration
• Professional but not strategic

Implementation Impact: Standard adoption patterns; some friction expected

Strategic Partnership

• Security as enabler
• Proactive collaboration
• Shared objectives
• Voluntary participation
• Mutual trust and respect

Implementation Impact: Accelerated adoption; reduced friction; innovation opportunities

Assessment Questions

Question	Damaged	Functional	Strategic
Proactive consultation frequency?	Rare	Occasional	Regular
Voluntary participation in security initiatives?	Low	Moderate	High
Security seen as?	Blocker	Necessary function	Partner/enabler
Collaborative incident response?	Blamed	Coordinated	Blameless
Developer satisfaction with security?	Low	Neutral	Positive

Building Strong Relationships

For Damaged Relationships:

1. Listen and acknowledge past friction
2. Focus on quick wins that reduce developer pain
3. Be transparent about constraints
4. Deliver on commitments consistently
5. Measure and improve developer experience

For Functional Relationships:

1. Increase proactive engagement
2. Collaborate on shared objectives
3. Invest in developer-friendly security tools
4. Celebrate joint successes
5. Build security champions program

For Strategic Partnerships:

1. Maintain momentum through continuous improvement
2. Co-design security capabilities
3. Share ownership of security outcomes
4. Innovate together on security solutions
5. Expand collaboration across organization

Impact on Transformation

Strong relationships enable:

• Faster adoption of scaling investments
• Higher adoption through low-friction, often voluntary, participation
• Better feedback and iteration
• Innovation opportunities
• Sustainable transformation

Weak relationships require:

• Extended relationship-building before transformation
• A shift to low-friction defaults rather than more mandates
• Slower rollouts with more resistance
• Limited innovation opportunities
• Higher risk of transformation failure

The reflex when relationships are weak is to make more controls mandatory and accept the resistance. That reads the tradeoff as mandatory against voluntary, when the axis that governs adoption is friction. A secure default built into the paved road is mandatory and low-friction at once: dependency scanning that runs in the pipeline and blocks only on a critical finding gets full adoption because no one has to choose it. The mandatory-versus-voluntary frame misses that whole quadrant. When trust is thin, the move that protects adoption velocity is to lower friction, to make the secure path the default path, so the capability lands even before the relationship does.

Friction governs adoption, the mandate does not. The paved road is mandatory and low-friction at once, the cell the mandatory-versus-voluntary frame misses.

---

When the Counterparty Is an Agent

Everything above assumes a person is doing the adopting. Relationship health is a property of people. An agent does not adopt through trust; it is governed by what it is allowed to do. As more of the work shifts to agents, the weight of this modifier shifts with it: the lever stops being the relationship and becomes the capability boundary. You do not build trust with an agent. You bind what it can do.

But that boundary still has to be built, and someone with authority chooses to build it. A capability boundary is a decision before it is a control; the paved road does not pave itself. That decision runs on a relationship: security on one side, and on the other whoever owns the platform investment. Usually that is engineering leadership. Sometimes it is a platform org, or whoever holds the roadmap tradeoff. So relationship health survives the shift to agents; it moves up a tier. At the line, the lever is the boundary. At the top, the lever is whether there is a boundary at all. DORA finds the same shape for leadership: leaders move performance indirectly, by enabling the practices teams adopt, not by adopting for them.

Scope the claim honestly, because the relationship is rarely what opens the wallet. The funding usually comes from outside it: a breach, a regulator, a customer's security questionnaire, a budget cycle with room left in it. The relationship governs the contested middle instead: the boundaries not yet obviously good platform engineering, and not yet ordered from above. It also governs what happens after the money lands, whether the boundary survives the next reorg and the next complaint that it slows people down. A leader on bad terms with engineering can still issue a mandate; issuing costs nothing. What the relationship buys is the boundary that is still funded and running a year later. The one that ships underfunded and gets switched off in the pipeline is the shelfware the relationship was supposed to prevent. The same research is blunt on the limit: even the strongest leaders cannot reach high performance on their own. Read this as a multiplier on the forcing function rather than a replacement for it.

What remains after all that automation is itself on a clock. The mechanics of building and ordering the boundary are already automating. The rules that build and enforce the paved road increasingly run as code, and budget will follow. What does not delegate is who answers for the reach of a failure. When an agent's blast radius goes wide, a board or a court looks for the human who chose that authority envelope, not the policy engine that approved its own rule. Blast radius is set by granted authority, and a human grants it. So the residue shrinks the same way the boundary does, down to one irreducible act. A named human ratifies the authority an agent runs under, and owns what it can reach.

Is This Modifier Earning Its Place?

Score security-and-engineering relationship health before a scaling investment. High-health orgs will see materially higher voluntary adoption than low-health orgs deploying the same capability. Equal adoption falsifies this modifier.

Score it again, separately, before a boundary-funding decision. Holding org size, budget, and regulatory mandate equal, high-health pairs get the boundary funded, mandated, and still running a year later more often than low-health pairs at equal threat. Equal funded-and-durable outcomes falsify the residue.

Next Steps

Continue to AI Saturation and PQC Exposure, the two newest modifiers:

Continue to AI Saturation Back to Contextual Modifiers Overview

AI Saturation

How Much of Your Pipeline Runs Through AI

AI saturation measures how much of an organization's software work, from code generation to code review to operations, now runs through AI tools and autonomous agents. It is the newest contextual modifier, and in the current landscape it moves faster than any other. Two organizations in the same strategic position can sit at opposite ends of it: one barely touched by AI, the other generating, reviewing, and shipping most of its code through it.

Saturation is not the risk from any single AI tool. It is a measure of proportion. As that proportion climbs, the binding constraint on security shifts from writing code to understanding it, and the work of security shifts with it.

The Comprehension Gap

At high saturation, code is generated faster than people can read it. The constraint stops being how fast you ship and becomes how fast you can understand what you shipped. No amount of hiring closes a gap that scales with machine output. See the comprehension crisis.

As saturation climbs, generation pulls away from review and the shaded gap, comprehension debt, widens. Hiring cannot close a gap that scales with machine output, and newer models test no safer. The response is structural rather than patient.

Saturation Levels

Low Saturation: AI on the Margins

Characteristics:

• AI assists individual developers; adoption is uneven
• Most code is human-written and human-reviewed
• Few or no autonomous agents in the pipeline
• AI output reviewed at the same pace as human output

Implementation Impact: Existing review and authorization models hold. Standard roadmap.

Moderate Saturation: AI in the Workflow

Characteristics:

• AI generates a meaningful share of committed code
• Humans still originate most non-trivial code
• Review volume rising faster than review capacity
• Agents handling discrete tasks (tests, refactors, ops runbooks)
• First MCP servers and tool integrations in production

Implementation Impact: Manual review starts to strain. Begin shifting toward automated guardrails and scoped agent identity.

High Saturation: AI as the Default Author

Characteristics:

• Most code, and much of review and operations, runs through AI
• The human's default role shifts to reviewing and approving AI-originated code
• Autonomous agents act across the repo, CI, and infrastructure
• One operator now spawns a fan-out of many agents, so the blast radius of a single instruction is the union of what every spawned agent can reach
• Authority propagates across agent-to-agent delegation chains, one hop past where it was scoped
• Tool grants and non-human identities multiply faster than they are inventoried
• Generation speed has decoupled from human comprehension

Implementation Impact: Manual review is no longer the control. Guardrails, policy-as-code, and per-request authorization become the binding investments. And a fleet you cannot see is a fleet you cannot bound: a registry, a delegation policy, and a tested kill-switch make the population governable, while boundary enforcement contains what any one agent can reach.

Better Models Do Not Close the Gap

In a 2025 study spanning more than 100 models, asked to write code for security-sensitive tasks, the models produced insecure code nearly half the time, and newer, more capable models did not test meaningfully safer. You cannot wait for the next model to solve this. The response is structural rather than patient.

Assessment Questions

Question	Low Saturation	Moderate Saturation	High Saturation
Share of committed code AI-generated?	Small	Substantial	Majority
Review capacity vs generation speed?	Review keeps pace	Review is the visible queue	AI code ships without deep review
Autonomous agents in the pipeline?	None	Discrete tasks	Acting across systems
Non-human identities and tool grants?	Few, scoped, inventoried	Growing, partly tracked	Many, broad, unaudited
Where does the bottleneck sit?	Writing code	Shifting to review	Understanding what shipped

Impact on Strategy

For All Quadrants

High saturation changes the security investment regardless of position. The constraint it creates is comprehension that cannot scale with generation, and that constraint does not care where you sit.

Studio: Build guardrails in from the start. At small scale the comprehension gap is survivable, but the habits you set now decide whether you can absorb saturation later. For a high-craft team the risk shows up as trust: code no one fully read, shipped because it looked right.

Lean: Your scale advantages only hold if review is automated. Manual gates become the bottleneck saturation exposes first.

Craft: Prioritize automated guardrails earlier than a pre-AI roadmap would. Manual review of AI-generated code at volume is the trap you walk into without noticing.

Mass: Saturation arrives on its own schedule rather than when your operations are ready for it. At high volume and low touch it lands as a cost-and-scale problem: more code, more agents, more grants, all faster than inventory. Sequence guardrails and agent identity ahead of other scaling work.

Investment Priorities

Low Saturation:

• Existing review models remain viable
• Establish baseline policy-as-code before volume arrives

Moderate Saturation:

• Shift review effort from line-by-line inspection to automated guardrails
• Begin scoped, short-lived identity for agents and tools
• Inventory non-human identities and MCP servers

High Saturation:

• Automated guardrails become the primary control rather than a supplement
• Scoped, short-lived agent identity (necessary) plus per-request attenuation, which is what identity alone cannot provide
• Continuous inventory of tool grants and agent identities
• Comprehension treated as an asset: an authoritative, queryable model of system behavior, continuously reconciled rather than tribal memory

Real-World Indicators

You're facing high saturation when:

• Pull request volume has outrun your reviewers' capacity to understand each change
• More of your code is read first by a model than by a person
• Agents are opening PRs, running CI steps, or touching infrastructure on their own
• You are discovering MCP servers and tool grants you did not know were in production
• Non-human identities outnumber human ones and most carry more access than they use

Strategic Response

Short-Term (0-6 months)

1. Guardrails over gates: move security checks into the pipeline as automated policy rather than manual review steps
2. Identity inventory: enumerate agents, service accounts, and tool grants; revoke standing access that isn't used
3. Secrets discipline: more code committed faster, with less human review, means more chances to commit a secret; continuous scanning and short-lived secrets

Medium-Term (6-18 months)

1. Scoped agent identity: per-request, just-in-time grants for agents and tools. Scoped identity is necessary; per-request attenuation is what identity alone cannot provide, because no static scope statement can narrow a general agent
2. Comprehension capacity: build an authoritative, queryable model of system behavior that survives the people who built it
3. Supply chain for AI: bring model weights, training data, and MCP servers under the same inventory discipline as code dependencies

Long-Term (18+ months)

1. Two floors, both required: boundary enforcement contains what cannot be fully understood; comprehension is the floor under the decisions themselves. Neither alone is the answer
2. Policy-as-code as the default: security expressed as constraints the pipeline enforces rather than advice reviewers remember
3. Continuous reconciliation: keep the model of behavior current as generation outpaces documentation

Connection to Supply Chain and Comprehension

AI saturation touches two areas the framework already treats as central, but it is not a restatement of either. Supply Chain Stewardship measures what you pull in; saturation measures how much of your own pipeline now runs through AI. The comprehension crisis names the gap saturation creates: generation outruns understanding, and the response is to contain and to model behavior rather than to read faster.

The closest seam is supply chain, so name it plainly. Saturation measures how much of your pipeline you route through AI, an upstream allocation decision. Supply chain measures the risk profile of what flows in, including AI output. Same artifact, two different questions.

Its effects reach the supply chain (model weights, MCP servers, tool grants) and the attack surface (more agents, more autonomous reasoning). What saturation isolates, and what the other modifiers do not see, is internal: the proportion of your work that now moves faster than your people can comprehend it.

Is This Modifier Earning Its Place?

Score an organization's AI saturation before measuring review load. High-saturation orgs that kept manual review will hit a comprehension bottleneck materially sooner than low-saturation orgs that kept it. Equal bottlenecks falsify this modifier.

---

Next Steps

Continue to PQC Exposure Back to Contextual Modifiers Overview

PQC Exposure

How Exposed Is Your Cryptography to the Quantum Transition

PQC exposure measures how much of your cryptography the quantum transition puts at risk, and how hard that risk is to retire. It is not a measure of how close quantum computers are. It is a measure of your own footprint: how long your data has to stay secret, and how hard it is to swap the math protecting it. Two organizations in the same strategic position can sit at opposite ends of it. A fintech that signs firmware lasting a decade and holds records that must stay confidential for years carries deep exposure. A media startup whose secrets are stale in a week barely registers, from the same quadrant.

What makes this its own modifier rather than a crisis waiting to happen is that the loss is silent and already underway. An adversary does not need a quantum computer today to take your data today. Harvest now, decrypt later: capture the ciphertext, store it, wait for the machine that reads it. There is no breach alert for data copied and shelved. So exposure has to be scored now, as a standing factor, instead of handled the week it becomes news. By the time it is news, the data is already gone.

The Clock Already Started

Harvest-now-decrypt-later means the attack does not wait for a quantum computer. Anything an adversary can record today and needs to read in ten years is exposed now, on today's encryption. NIST finalized the replacement algorithms (FIPS 203/204/205, August 2024) and set the deprecation clock: quantum-vulnerable public-key cryptography like RSA and ECC is deprecated by 2030 and disallowed in NIST standards by 2035 (NIST IR 8547). The migration is years of work against a fixed deadline, which is why exposure belongs on your standing roadmap rather than your incident plan.

NIST set the deprecation clock; harvest-now-decrypt-later runs above it. Data captured today is exposed now, on today's encryption, with no breach alert to announce it.

Exposure Levels

Low Exposure: Short-Lived Secrets, Agile Crypto

Characteristics:

• Confidential data loses value in days or weeks; little or nothing needs decade-long secrecy
• Cryptography runs through managed, updatable libraries and services you can patch centrally
• Few or no long-lived signed artifacts (firmware, certificates, code-signing roots)
• Primitives can be rotated without touching products already in the field

Implementation Impact: Track the standards; no front-loading required. Inventory can wait behind higher-impact modifiers.

Moderate Exposure: Mixed Lifetimes, Partial Agility

Characteristics:

• Some data carries multi-year confidentiality requirements
• Crypto-agility is uneven: some systems swap primitives easily, others are pinned to versions
• Dependence on TLS, managed key stores, and third parties whose PQC timelines you do not control
• A first cryptographic inventory exists but is incomplete

Implementation Impact: Begin a cryptographic bill of materials. Prioritize agility in the systems that protect the longest-lived data.

High Exposure: Long Confidentiality, Pinned Primitives

Characteristics:

• Data that must stay confidential for a decade or more (health, financial, defense, intellectual property)
• Long-lived trust anchors: firmware signing, device certificates, code-signing roots with multi-year validity, living in products you cannot easily update
• Cryptography embedded where it is hard to rotate: hardware, IoT, key-management modules, protocol assumptions, vendor black boxes
• A binding migration deadline (for national-security systems, CNSA 2.0)

Implementation Impact: Front-load crypto-agility and migration sequencing now. This is the exposure the deadline turns into an emergency if deferred.

Crypto-Agility Is the Capability, Not the Algorithm

The investment that matters is not picking one approved algorithm over another. It is the ability to swap a primitive at all without re-architecting. An organization that rotates cryptography by configuration sits at low exposure almost regardless of its data. An organization with primitives welded into firmware sits at high exposure almost regardless of the algorithm. Build the swap path first.

Assessment Questions

Question	Low Exposure	Moderate Exposure	High Exposure
How long must your data stay confidential?	Days to weeks	Months to a few years	A decade or more
Can you rotate a cryptographic primitive?	By configuration	With effort, some systems	Welded into firmware or hardware
Long-lived signed artifacts in the field?	Few or none	Some, updatable	Many, hard to update
Do you have a cryptographic inventory?	Not yet needed	Partial	Required and in progress
Is a migration deadline binding on you?	No	Market-driven, soft	Regulatory and dated
Who controls your crypto timeline?	You, centrally	Mixed with vendors	Largely upstream or embedded

Impact on Strategy

Studio: Your footprint is small, which makes now the cheap moment to build the habit. Require primitive-rotation by configuration in every new system. Retrofit it after you scale and it costs you a rebuild.

Lean: Scale means the same primitive sits in many places, so agility is a scaling investment rather than a one-time project. Bake primitive-rotation into the platform every team builds on and the migration becomes a config change. Leave it to each team and you inherit a hand-search.

Craft: Your risk concentrates where long-lived data sits behind cryptography you hand-rolled or pinned years ago. Inventory first. The high-craft trap is confidence that the crypto is fine because it has always been fine, which is the exact assumption the deadline retires.

Mass: Legacy and embedded primitives are where the deadline lands hardest, because rotation is hardest there. Firmware you cannot recall, devices in the field, vendor black boxes: sequence these first, since they take the longest and you control them least.

Investment Priorities

Low Exposure:

• Track NIST and NSA guidance
• Require crypto-agility in new designs as a default

Moderate Exposure:

• Build the cryptographic bill of materials
• Pilot hybrid key establishment (classical plus post-quantum) on the longest-lived data path
• Pin vendor PQC roadmaps to contracts

High Exposure:

• Treat migration as a dated program: inventory, then prioritize by data lifetime, then hybrid deployment, then rotate trust anchors
• Sequence ahead of discretionary scaling work

Real-World Indicators

You're facing high exposure when:

• You hold data whose confidentiality must outlive 2035
• You sign firmware or issue certificates with multi-year validity into devices you cannot recall
• You cannot answer "what algorithm protects this?" for a critical system without a code dig
• A regulator has handed you a dated migration mandate
• Your crypto lives in a vendor or hardware boundary you do not control

Strategic Response

Short-Term (0-12 months)

1. Inventory your cryptography: build a cryptographic bill of materials so you know what protects what
2. Agility by default: require new systems to rotate primitives by configuration
3. Find the long tail: identify your longest-confidentiality data and what protects it

Medium-Term (1-3 years)

1. Hybrid on the worst paths: deploy classical-plus-post-quantum key establishment on the highest-exposure data first
2. Contract the timeline: pin vendor PQC commitments in writing
3. Rotate the anchors: begin replacing the trust anchors with the longest field life

Long-Term (3+ years)

1. Beat the disallow line: complete migration of quantum-vulnerable public-key crypto ahead of 2035
2. Keep the capability: primitive-rotation outlives this migration; keep it standing for the next crypto transition, because there will be one

How This Differs From the Modifiers Near It

This sits close to three modifiers without being any of them. Supply Chain Complexity measures what you pull in rather than whether your own primitives can rotate. Crisis Events accelerate movement after an incident, and PQC's defining property is that there is no incident: the loss is silent. Regulatory Constraints can drive your urgency through a mandate like CNSA 2.0, but the mandate is not the exposure. An unregulated company sitting on a decade of confidential data has maximal exposure and no one telling it so. Different dial from each.

Is This Modifier Earning Its Place?

Score an organization's PQC exposure (data-confidentiality lifetime times primitive-rotation difficulty) before 2030. High-scorers who deferred crypto-agility will face materially costlier, deadline-compressed emergency migration than low-scorers who deferred. If high and low scorers face equal migration cost, this modifier is falsified.

Next Steps

Continue to Implementation Guides Back to Contextual Modifiers Overview

Implementation Guides

Implementation Guide: Studio

This guide is for organizations in the Studio quadrant: small Blast Radius (how far a failure could reach if containment fails, set by the authority granted to automation) and higher Operational Readiness (how mature your delivery and automation are). If you have not yet placed yourself among the four quadrants, Studio, Lean, Craft, and Mass, start with the two-axis model and strategic positions. Throughout, this guide refers to constraining BAU (business-as-usual security work) and investing in the five Universal Security Conditions, Supply Chain first.

Position Characteristics

Studio organizations occupy the Small reach + Higher Readiness quadrant:

• Small inherent reach (authority scoped per task; typically 10-200 engineers)
• Modern infrastructure (cloud-native, infrastructure-as-code)
• Strong automation foundation (CI/CD, automated testing)
• Fast decision-making (minimal bureaucracy)
• Innovation culture (experimentation encouraged)

Strategic Priorities

1. Maintain Velocity While Building Security

Your advantage is speed. Security should accelerate rather than slow down.

Investment Focus:

• Automated security scanning integrated into CI/CD
• Secure templates and paved roads for common patterns
• Self-service security capabilities for developers
• Policy-as-code from the start

Avoid:

• Manual security review bottlenecks
• Process for process's sake
• Premature complexity (don't build Lean-level tools yet)

2. Embed Security in Modern Infrastructure

You're building on cloud-native foundations. Embed security from inception.

Investment Focus:

• Infrastructure security automation (cloud posture management)
• Container and Kubernetes security guardrails
• Automated compliance validation
• Supply chain security from day one (SBOM, dependency scanning)

Avoid:

• Bolting security on after architecture decisions
• Manual cloud configuration review
• Treating security as separate from infrastructure

3. Build Foundations for Scale

You're positioned to scale efficiently. Build the right foundations now.

Investment Focus:

• Security platforms over point solutions
• Reusable security capabilities (not one-off solutions)
• Documentation and self-service patterns
• Metrics that matter (outcomes rather than activity)

Avoid:

• Tool sprawl without integration
• Heroic manual efforts that can't scale
• Missing the inflection point before scaling crisis

Quick Start Checklist

Week 1: Assessment

• [ ] Map current blast radius and readiness level
• [ ] Identify manual security bottlenecks
• [ ] Assess relationship health with engineering teams
• [ ] Review current security tool coverage

Month 1: Foundation

• [ ] Deploy automated security scanning (SAST, dependency scanning, container scanning)
• [ ] Create secure templates for 3 most common patterns
• [ ] Establish security documentation hub
• [ ] Define security review triage criteria (what needs manual review vs. automated)

Quarter 1: Automation

• [ ] Implement CI/CD security gate automation
• [ ] Create self-service security documentation
• [ ] Deploy policy-as-code for infrastructure
• [ ] Establish security metrics dashboard

Quarter 2: Scaling

• [ ] Reduce manual security reviews by 50% through automation
• [ ] Launch security champions pilot program
• [ ] Implement runtime security monitoring
• [ ] Build feedback loops for continuous improvement

Investment Roadmap

Studio runs the BAU-versus-Scaling portfolio model at its cleanest: high readiness lets you constrain BAU hard and pour the freed capacity into scaling investments from the first year.

Year 1: Build Scaling Foundations

BAU to Constrain (30% effort):

• Manual security reviews for novel architectures only
• Critical incident response
• Compliance validation (automate where possible)

Scaling Investments (70% effort):

• Automated security scanning platform
• Secure templates and paved roads
• Self-service capabilities
• Policy-as-code infrastructure

Expected Outcomes:

• 70% reduction in manual security review time
• Higher deployment frequency without a rise in security incidents (set your own baseline target)
• Security embedded in default paths

Year 2: Optimize and Extend

BAU to Constrain (20% effort):

• Maintain only truly unique security reviews
• Automated incident response where possible

Scaling Investments (80% effort):

• Advanced security automation (threat modeling as code)
• Supply chain security platform
• Runtime security with automated response
• Security product capabilities (if customer-facing software factory)

Expected Outcomes:

• Sub-hour security review for 90% of changes
• Proactive vulnerability detection before exploitation
• Security as competitive advantage

Common Pitfalls

Premature Complexity

Risk: Building Lean-level tooling before you need it

Symptoms:

• Creating complex security platforms for simple needs
• Over-engineering automation
• Analysis paralysis on tool selection

Solution: Start simple, add complexity as operations scale

Missing the Scaling Crisis

Risk: Not recognizing when manual processes are failing

Symptoms:

• Security reviews taking weeks instead of hours
• Security team overwhelmed with ticket backlog
• Engineering teams bypassing security to meet deadlines

Solution: Proactively constrain BAU before crisis hits

Process Over Outcomes

Risk: Importing heavyweight processes that slow innovation

Symptoms:

• Security reviews requiring extensive documentation for simple changes
• Multiple approval layers for standard patterns
• Compliance theater instead of actual risk reduction

Solution: Focus on secure defaults and automation rather than manual gates

Success Indicators

6 Months

• [ ] Manual security review time reduced 50% (from baseline)
• [ ] Automated scanning detecting 80%+ of security issues before human review
• [ ] Secure templates used for 60%+ of new services
• [ ] Developer satisfaction with security improved (measured via survey)

12 Months

• [ ] Manual security review time reduced 70% (from baseline)
• [ ] Security review SLA: 90% completed within 2 hours for standard patterns
• [ ] Zero critical security incidents from standard patterns
• [ ] Security champions program launched with 5+ active participants

24 Months

• [ ] Manual security review time reduced 80% (from baseline)
• [ ] Security embedded in default engineering workflows (no separate security step)
• [ ] Proactive vulnerability detection before external disclosure
• [ ] Security as competitive advantage (measurable customer trust improvement)

Movement Paths

Maintaining Position: Staying Studio

As your organization grows, your inherent reach will naturally widen. To maintain the Studio position:

Strategy: Continuously optimize processes and automation as you scale

Key Investments:

• Automation that scales with team growth
• Self-service capabilities to maintain velocity
• Strong onboarding for security patterns
• Avoid complexity creep

Timeline: Ongoing; requires continuous attention

If Your Reach Widens

Studio is a finished end state for as long as your reach stays small. Lean becomes your end state only when the business widens your reach (more automation authority, broader scope; often 100+ engineers, multiple products). When that happens:

Strategy: Thoughtful complexity management while maintaining readiness

Key Investments:

• Platform security capabilities
• Advanced automation for complex scenarios
• Policy-as-code at organizational scale
• Security product capabilities

Timeline: 24-36 months as reach naturally increases

Critical Success Factor: Don't let increased complexity degrade operational readiness

---

Next Steps

If your reach widens: Lean Implementation Back to Contextual Modifiers

Edit this page

Implementation Guide: Lean

This guide is for organizations in the Lean quadrant: large Blast Radius (how far a failure could reach if containment fails, set by the authority granted to automation) and higher Operational Readiness (how mature your delivery and automation are). If you have not yet placed yourself among the four quadrants, Studio, Lean, Craft, and Mass, start with the two-axis model and strategic positions. Throughout, this guide refers to constraining BAU (business-as-usual security work) and investing in the five Universal Security Conditions, Supply Chain first.

Position Characteristics

Lean organizations occupy the Large reach + Higher Readiness quadrant:

• Large inherent reach (broad authority across the estate; typically 200+ engineers, multiple products/services)
• Mature infrastructure (sophisticated cloud platforms, advanced automation)
• Strong security foundations (established security programs, proven capabilities)
• Platform-oriented (internal platforms serving multiple teams)
• Optimization focus (refining what works, eliminating waste)

Strategic Priorities

1. Optimize What Works, Eliminate What Doesn't

You have established security capabilities. Focus on optimization and continuous improvement.

Investment Focus:

• Data-driven optimization of existing security platforms
• Eliminate security theater (activities that don't reduce risk)
• Advanced automation to replace remaining manual processes
• Security engineering productivity tools

Avoid:

• Complacency (maintaining status quo)
• Adding capabilities without retiring old ones (tool sprawl)
• Activity metrics over outcome metrics

2. Scale Security Through Platform Effects

Your complexity requires platform thinking. Build capabilities that serve multiple teams.

Investment Focus:

• Security platforms with self-service capabilities
• Policy-as-code at organizational scale
• Federated security models (champions who set boundaries rather than gate changes)
• Reusable security components and libraries

Avoid:

• Centralized bottlenecks (security as single point of failure)
• One-size-fits-all solutions (enable teams to customize within guardrails)
• Platform features without adoption focus

3. Innovate for Competitive Advantage

Security should be a differentiator rather than a cost center.

Investment Focus:

• Security product capabilities (if customer-facing software factory)
• Advanced threat detection and response
• Supply chain security leadership
• Security research and thought leadership

Avoid:

• Innovation for innovation's sake
• Pursuing cutting-edge at expense of fundamentals
• Building capabilities that don't align with business strategy

Quick Start Checklist

Month 1: Assessment

• [ ] Conduct comprehensive capability assessment across all Universal Security Conditions
• [ ] Identify high-effort, low-impact security activities (candidates for elimination)
• [ ] Map platform adoption rates and satisfaction
• [ ] Review outcome metrics rather than activity metrics

Quarter 1: Optimization

• [ ] Eliminate or automate 3 low-value security activities
• [ ] Implement data-driven optimization for top security platform
• [ ] Establish federated security model (champions set team boundaries, platform enforces)
• [ ] Define clear outcome metrics for each stewardship area

Quarter 2: Innovation

• [ ] Launch advanced automation pilot (threat modeling as code, automated remediation)
• [ ] Implement cross-team security capability sharing
• [ ] Deploy advanced supply chain security capabilities
• [ ] Establish security research program

Quarter 3-4: Scale

• [ ] Expand successful pilots across organization
• [ ] Build security product capabilities (if applicable)
• [ ] Establish industry thought leadership presence
• [ ] Continuously optimize based on metrics

Investment Roadmap

Lean runs the BAU-versus-Scaling portfolio model at its most aggressive: readiness and scale push constrained BAU toward the single digits, so nearly all effort compounds as scaling investment.

Year 1: Optimize and Scale

BAU to Constrain (10-15% effort):

• Truly unique security challenges requiring expert review
• Strategic incident response (automated where possible)
• Critical compliance audits (automate evidence collection)

Scaling Investments (85-90% effort):

• Platform optimization and adoption improvement
• Advanced automation (threat modeling, automated remediation)
• Federated security models
• Security product capabilities
• Tool consolidation and retirement

Expected Outcomes:

• 50% reduction in manual security work through optimization
• 90%+ of teams using security platforms voluntarily
• Security capabilities as competitive advantage
• Industry recognition for security leadership

Year 2: Lead the Industry

BAU to Constrain (5-10% effort):

• Only truly novel security challenges
• Strategic advisory for critical decisions

Scaling Investments (90-95% effort):

• Advanced security research and innovation
• Open source security leadership
• Industry standard contribution
• Security product innovation
• AI-powered security capabilities

Expected Outcomes:

• Security as measurable competitive advantage
• Industry thought leadership
• Attracting top security talent through reputation
• Security capabilities ahead of adversary evolution

Common Pitfalls

Complacency

Risk: Resting on past success while adversaries evolve

Symptoms:

• "We've always done it this way" mentality
• Declining participation in security programs
• Missing emerging threats (supply chain, AI security)
• Slow response to industry changes

Solution: Continuous innovation and experimentation culture

Tool Sprawl Without Retirement

Risk: Accumulating security tools without sunsetting old ones

Symptoms:

• 20+ security tools with overlapping capabilities
• Low adoption rates across multiple tools
• Alert fatigue from redundant tooling
• High operational overhead maintaining tools

Solution: Regular capability assessment with intentional retirement

Optimization Over Innovation

Risk: Focusing on incremental improvements while missing strategic shifts

Symptoms:

• All security investments are optimizations of existing capabilities
• No exploration of emerging security paradigms
• Falling behind on supply chain, AI, cloud-native security
• Inability to attract innovative security talent

Solution: Balance 70% optimization with 30% innovation

Platform Without Adoption

Risk: Building sophisticated platforms nobody uses

Symptoms:

• Low voluntary adoption of security platforms
• Teams building workarounds instead of using platforms
• Platform teams focused on features rather than user experience
• Disconnect between platform capabilities and team needs

Solution: Product management approach to security platforms with adoption metrics

Success Indicators

6 Months

• [ ] Manual security effort reduced 30% through optimization
• [ ] Security platform adoption >80% for primary platforms
• [ ] 3+ low-value activities eliminated or fully automated
• [ ] Outcome metrics defined and baseline established for all Universal Security Conditions

12 Months

• [ ] Manual security effort reduced 50% (from baseline)
• [ ] Security platform voluntary adoption >90%
• [ ] Advanced automation deployed (threat modeling as code, automated remediation)
• [ ] Measurable security competitive advantage (customer trust metrics, compliance differentiators)

24 Months

• [ ] Security almost entirely self-service (sub-5% manual effort)
• [ ] Industry thought leadership established (conference talks, research publications)
• [ ] Security product capabilities providing customer value
• [ ] Attracting top security talent through reputation and innovation

Movement Paths

Maintaining Position: Staying Lean

Continuous effort required to maintain leadership position:

Strategy: Continuous innovation and optimization to stay ahead

Key Investments:

• Ongoing platform optimization
• Cutting-edge security research
• Industry collaboration and standards contribution
• Attract and retain top security talent

Timeline: Ongoing; leadership requires constant investment

Critical Success Factor: Balance innovation with operational excellence

Risk: Regressing to Mass

There is a faster way to lose Lean than gradual creep, and it is worth naming plainly. Lean runs on 85 to 90 percent of effort going to scaling investment, the discretionary, future-facing spend a downturn cuts first. In 2023, HackerOne found 63 percent of security organizations had their budgets cut and 39 percent cut headcount in a single year, with two-thirds reporting it degraded their ability to operate. A capex shock does not let Lean drift back to Mass over quarters; it drops you there in a budget cycle. What the shock cannot touch is the floor: the containment built into the substrate, the boundaries a compromised component cannot cross whatever the budget. That floor is built once. No one a downturn lays off is staffing it. A downturn repossesses the position your spending rented; it cannot repossess the floor your design built. Spend buys position; design buys the floor. Fund the thing the downturn cannot repossess.

Without continuous investment, large reach outruns the readiness that was containing it:

Warning Signs:

• Manual processes creeping back in
• Platform adoption declining
• Security becoming bottleneck again
• Team morale declining

Prevention:

• Maintain 85%+ effort on scaling investments
• Ruthlessly eliminate low-value activities
• Continuous improvement culture
• Regular capability reassessment

Advanced Capabilities

Threat Modeling as Code

Automated threat modeling integrated into development workflow:

• Infrastructure-as-code scanning for security patterns
• Automated risk assessment based on component composition
• Self-service threat model generation

Automated Remediation

Moving beyond detection to automated response:

• Auto-patching for approved vulnerability classes
• Automated security configuration drift correction
• Self-healing security capabilities

Security Product Capabilities

If you operate a customer-facing software factory:

• Security features as product differentiators
• Compliance certifications as competitive advantage
• Security transparency as trust builder

Supply Chain Security Leadership

Advanced supply chain security:

• Complete SBOM across all products
• Continuous supply chain monitoring
• Vendor security posture management
• Proactive vulnerability intelligence

---

Next Steps

Continue to Craft Implementation Back to Studio Implementation

Edit this page

Implementation Guide: Craft

This guide is for organizations in the Craft quadrant: small Blast Radius (how far a failure could reach if containment fails, set by the authority granted to automation) and lower Operational Readiness (how mature your delivery and automation are). If you have not yet placed yourself among the four quadrants, Studio, Lean, Craft, and Mass, start with the two-axis model and strategic positions. Throughout, this guide refers to constraining BAU (business-as-usual security work) and investing in the five Universal Security Conditions, Supply Chain first.

Craft is a method, not a price tag

Craft names a method: non-repeatable hand-work, a snowflake per build. It is not a statement about quality, premium positioning, or boutique branding. A Craft organization can do excellent security work; it just does it by hand each time, which is exactly the low-readiness condition this guide addresses.

Position Characteristics

Craft organizations occupy the Small reach + Lower Readiness quadrant:

• Small inherent reach (little authority granted; typically <50 engineers, single product/service)
• Legacy or basic infrastructure (manual processes, limited automation)
• Resource constraints (small teams, limited budget)
• Pragmatic focus (solving immediate problems rather than building for scale)
• Critical decision point (modernize strategically or stay intentionally simple)

Strategic Priorities

1. Determine Your Strategic Path

The most important decision: intentional simplicity or prepare for growth?

Option A: Intentional Simplicity (Remain Craft)

• Small team, focused product, sustainable operations
• Security through simplicity (small attack surface)
• Selective modernization only where it reduces operational burden
• Appropriate for: Lifestyle businesses, internal tools, specialized services

Option B: Prepare for Growth (Move toward Studio)

• Anticipate operational growth
• Invest in infrastructure modernization now
• Build foundations that will scale
• Appropriate for: Funded startups, expanding services, growth trajectory

Critical: Choose intentionally. Don't accidentally drift into the wrong model.

2. Security Through Simplicity

Your advantage is small scale. Use it.

Investment Focus:

• Managed security services (SaaS over self-hosted)
• Secure defaults over complex configuration
• Cloud provider security features (don't build your own)
• Essential security only (supply chain, patching, basic monitoring)

Avoid:

• Building complex security infrastructure
• Manual processes that don't scale (if growth expected)
• Premature optimization
• Enterprise security frameworks designed for complexity

3. Strategic Modernization Choices

If preparing for growth, modernize strategically to build Studio foundations.

Investment Focus:

• Cloud migration (if still on-premises)
• CI/CD basics (automated deployment)
• Infrastructure-as-code foundations
• Automated security scanning (managed services)

Avoid:

• "Lift and shift" cloud migration (recreating legacy in cloud)
• Over-engineering for hypothetical scale
• Modernization without clear business value
• Modernization debt (half-finished migrations)

Quick Start Checklist

Week 1: Strategic Decision

• [ ] Determine strategic path: Intentional simplicity or prepare for growth?
• [ ] Assess current security posture against critical risks
• [ ] Identify biggest security pain points
• [ ] Define realistic security goals given resources

Month 1: Essential Security

• [ ] Implement automated dependency scanning (managed service)
• [ ] Establish basic vulnerability patching process
• [ ] Deploy managed security monitoring (cloud provider features)
• [ ] Document critical systems and dependencies

Quarter 1: Foundation (If Preparing for Growth)

• [ ] Begin cloud migration planning (if on-premises)
• [ ] Implement basic CI/CD pipeline
• [ ] Establish infrastructure-as-code for new systems
• [ ] Deploy automated security scanning in CI/CD

Quarter 2: Modernization (If Preparing for Growth)

• [ ] Complete cloud migration for priority systems
• [ ] Expand automation to cover deployment process
• [ ] Implement security guardrails in infrastructure
• [ ] Begin tracking operational readiness metrics

Investment Roadmap

Both paths run on the same BAU-versus-Scaling logic as the higher-readiness quadrants, tuned for low readiness and a small budget. Managed services are how Craft constrains BAU: they carry the operational security load so your limited capacity is free for the one or two scaling investments that lower future burden. Path A keeps most effort in that constrained-BAU floor; Path B tilts toward scaling investment from year one to make readiness climb.

Path A: Intentional Simplicity (Remain Craft)

Year 1 Focus:

• Maintain essential security through managed services (80% effort)
• Selective modernization only where it reduces burden (20% effort)

Security Approach:

• Managed security services (SaaS tools, cloud provider features)
• Supply chain security (dependency scanning, SBOM)
• Basic vulnerability management (automated patching)
• Essential monitoring (security logs, basic alerting)

Expected Outcomes:

• Appropriate security without operational burden
• Low total cost of ownership
• Sustainable operations at current scale

Path B: Prepare for Growth (Move toward Studio)

Year 1: Infrastructure Modernization (70% effort on modernization)

• Cloud migration (if on-premises)
• CI/CD automation
• Infrastructure-as-code
• Automated security in pipeline

Year 2: Security Automation (50% modernization, 50% security automation)

• Expanded security scanning
• Security guardrails in infrastructure
• Self-service secure templates
• Monitoring and response capabilities

Expected Outcomes:

• Studio quadrant positioning after 18-24 months
• Security embedded in modern infrastructure
• Ready to scale with business growth
• Avoided technical debt from premature scaling

Common Pitfalls

Accidental Path Drift

Risk: Unintentionally growing complexity without increasing readiness

Symptoms:

• Adding features without modernizing infrastructure
• Team growing but still manual processes
• Increasing operational burden without automation
• "Technical debt" accumulating

Solution: Make intentional strategic choice and revisit quarterly

Premature Optimization

Risk: Building for scale you may never reach

Symptoms:

• Complex security infrastructure for 10-person team
• Self-hosting tools that could be SaaS
• Extensive automation for rare scenarios
• More time on security infrastructure than product

Solution: Security should be appropriate to scale and risk

Wrong Modernization Sequence

Risk: Modernizing in wrong order creates more problems

Symptoms:

• Lift-and-shift cloud migration (legacy architecture in cloud)
• Adding automation to broken processes
• Infrastructure-as-code for unstable architecture
• Security tools before foundational security

Solution: Modernize infrastructure foundations first, then add security

Resource Exhaustion

Risk: Attempting Studio/Lean approaches with Craft resources

Symptoms:

• Security team overwhelmed trying to build platforms
• Half-finished modernization projects
• Burnout from unsustainable manual work
• Critical systems neglected for aspirational projects

Solution: Right-size security investments to actual resources

Success Indicators

Path A: Intentional Simplicity

6 Months:

• [ ] Essential security implemented (dependency scanning, patching, basic monitoring)
• [ ] Managed services handling 80%+ of security (minimal operational burden)
• [ ] Security incidents responded to within 24 hours
• [ ] Sustainable security operations (not requiring heroic effort)

12 Months:

• [ ] No known critical vulnerability unpatched beyond a 14-day SLA (through automated scanning and patching)
• [ ] Security integrated into development workflow (not separate process)
• [ ] Quarterly security reviews (confirming approach still appropriate)
• [ ] Team satisfaction with security approach (not excessive burden)

Path B: Prepare for Growth

6 Months:

• [ ] Cloud migration plan finalized (if applicable) or basic CI/CD operational
• [ ] Automated security scanning deployed
• [ ] Infrastructure-as-code for 30%+ of systems
• [ ] Operational readiness metrics tracked

12 Months:

• [ ] Cloud migration 80% complete (if applicable)
• [ ] CI/CD automation covering all deployments
• [ ] Infrastructure-as-code for 70%+ of systems
• [ ] Security embedded in deployment pipeline

18-24 Months:

• [ ] Studio quadrant positioning achieved
• [ ] Security automation at Studio level (see Studio guide)
• [ ] Ready to scale with business growth
• [ ] Technical debt minimal

Movement Paths

Staying Intentionally Simple (Maintain Craft)

This is a valid, sustainable choice for many organizations:

When Appropriate:

• Stable team size (<20 people)
• Single focused product/service
• Not venture-funded or seeking rapid growth
• Strong product-market fit at current scale

Strategy:

• Use managed services for security
• Security through simplicity (small attack surface)
• Quarterly reassessment of strategic choice
• Prepared to pivot if growth trajectory changes

Timeline: Ongoing; sustainable at this scale

Moving to Studio (Small reach + Higher Readiness)

Preparing infrastructure for growth:

Strategy: Single-axis movement (increase operational readiness)

Key Investments:

• Cloud infrastructure (if not already cloud-native)
• CI/CD automation
• Infrastructure-as-code
• Automated security scanning

Timeline: 18-24 months for complete transformation

Success Probability: High (single-axis movement is achievable)

Critical Success Factors:

• Clear business case for modernization
• Adequate resources (time, money, expertise)
• Avoid half-finished modernization
• Security embedded during modernization (not bolted on after)

Risk: Accidental Drift to Mass

Growing complexity without increasing readiness:

Warning Signs:

• Team growing but processes still manual
• Multiple products but no platform thinking
• Increasing operational burden without automation
• Security becoming bottleneck

Prevention:

• Intentional strategic choice reviewed quarterly
• If growing complexity, invest in operational readiness
• If not investing in readiness, constrain complexity
• Never accidentally drift between quadrants

---

Decision Framework

Use this to determine your strategic path:

Question	Intentional Simplicity	Prepare for Growth
Expected team growth?	Stable (<20)	Growing (20-200+)
Funding model?	Sustainable revenue	Venture-funded
Product strategy?	Single focused product	Platform/multiple products
Market position?	Craft/specialized	Expansion/growth
Risk tolerance?	Conservative	Growth-oriented
Infrastructure age?	Legacy OK if working	Must modernize

---

Next Steps

Continue to Mass Implementation Back to Lean Implementation

Edit this page

Implementation Guide: Mass

This guide is for organizations in the Mass quadrant: large Blast Radius (how far a failure could reach if containment fails, set by the authority granted to automation) and lower Operational Readiness (how mature your delivery and automation are). If you have not yet placed yourself among the four quadrants, Studio, Lean, Craft, and Mass, start with the two-axis model and strategic positions. Throughout, this guide refers to constraining BAU (business-as-usual security work) and investing in the five Universal Security Conditions, Supply Chain first.

Mass is Lean's reach without Lean's floor

Mass is Lean's large reach without Lean's floor: ungoverned scale rather than big batch. Your automation can already reach far; what it cannot yet do is prove a failure stays contained. The border that matters is against Lean rather than against Ford's assembly line, and this guide is about building the floor.

Position Characteristics

Mass organizations occupy the Large reach + Lower Readiness quadrant:

• Large inherent reach (broad authority granted; typically 100+ engineers, multiple products/services)
• Legacy infrastructure (manual processes, limited automation, technical debt)
• Resource constraints (security team stretched thin, competing priorities)
• Transformation imperative (current state unsustainable at scale)
• Highest transformation risk (containment climb under fixed large reach)

The Mass Reality

This is the most difficult transformation journey. You must simultaneously:

• Reduce operational burden (can't maintain current manual load)
• Increase automation (while systems resist automation)
• Maintain operations (can't stop to renovate)
• Work through organizational resistance (change is hard)

Critical Truth: This is the containment climb. Your reach is already large and you can't shrink it, so the whole job is building the floor beneath it while operations continue. That single-axis climb still has high failure risk; success requires strategic sequencing, executive support, and realistic timelines.

Strategic Priorities

1. Stabilize Before Transforming

Don't attempt transformation while drowning in operational work.

First Priority: Achieve operational stability

• Constrain BAU growth (say no to low-value work)
• Automate or eliminate highest-burden activities
• Build breathing room for strategic work
• Secure executive support for transformation

Investment Focus:

• Quick automation wins (eliminate repetitive manual work)
• Tool consolidation (reduce operational overhead)
• Relationship building with engineering (you'll need their help)
• Documentation of current state (know what you're transforming from)

Timeline: 6-12 months before major transformation begins

2. Choose Your Transformation Path

Almost every Mass organization takes the same path: build the floor under the reach it already holds, knowing that is a 3-to-5-year climb most attempts do not finish. The other path shrinks reach, and that is the exception.

The default: Build the Floor (Mass → Lean, the Containment Climb)

• Strategy: Increase readiness through gradual modernization while large reach stays in place
• Examples: Hybrid approaches, phased rollouts, incremental automation
• Advantages: Preserves the business as-is (operations and revenue continue)
• Challenges: Longest timeline, highest failure risk, requires sustained investment
• Timeline: 36-60 months to Lean (realistically)

Critical Decision Factors (for committing to the climb):

• Executive support and patience (a 3-5 year commitment)
• Resource availability (significant sustained investment)
• Business model (can you sustain operations through a long climb?)
• Organizational change capacity (high tolerance for disruption)

The exception: Reduce Reach (Mass → Craft, Simplification)

• Strategy: Simplify operations while modernizing what remains
• Examples: Consolidate products, retire legacy systems, reduce scope
• Advantages: Easier transformation, clearer focus, faster progress
• Challenges: Requires difficult business decisions, potential revenue impact
• Timeline: 18-30 months to Craft, then 18-24 months to Studio

Reducing reach works only when a divestiture, an SMB pivot, or a product consolidation already supports it. Without that, you cannot claw back authority you have already granted across the estate. See Movement Paths.

3. Execute Hybrid Transformation

Regardless of path, you'll need hybrid approaches:

Modern + Legacy Coexistence:

• Modern security for new systems (cloud-native, automated)
• Pragmatic controls for legacy systems (appropriate to modernization timeline)
• Gradual migration (not big-bang transformation)
• Clear criteria for what gets modernized when

Investment Focus:

• Security automation for new systems (don't recreate manual processes)
• Managed services for legacy (reduce operational burden)
• Platform capabilities that serve both (unified monitoring, identity)
• Clear boundaries between modern and legacy

Quick Start Checklist

Month 1-3: Stabilization

• [ ] Document current state: operational burden, manual processes, pain points
• [ ] Identify 3 highest-burden manual activities for elimination/automation
• [ ] Assess relationship health with engineering teams
• [ ] Secure executive sponsor for transformation (critical for success)
• [ ] Map which systems are candidates for modernization vs. retirement

Month 4-6: Quick Wins

• [ ] Eliminate or automate at least 1 high-burden manual activity
• [ ] Implement managed security service for at least 1 capability
• [ ] Launch relationship-building initiative with engineering
• [ ] Define transformation path (reduce reach or increase readiness)
• [ ] Create high-level transformation roadmap with executive sponsor

Month 7-12: Foundation

• [ ] Establish modern security for new systems (break legacy pattern)
• [ ] Deploy automated security scanning for active development
• [ ] Begin infrastructure modernization pilot
• [ ] Measure and track operational burden reduction
• [ ] Communicate transformation progress to stakeholders

Year 2: Transformation Launch

• [ ] Execute on chosen path (reach reduction or readiness increase)
• [ ] Establish success metrics and track progress
• [ ] Regular executive updates on transformation progress
• [ ] Course-correct based on what's working/not working

Investment Roadmap

The percentages below are phased across years, but they track the same BAU-versus-Scaling split the other guides use. Stabilization is BAU being constrained: reducing the operational burden that legacy reach imposes. Modern security for new systems and platform capabilities are the scaling investments that compound. Mass simply carries a larger, longer BAU tax than the higher-readiness quadrants, which is why the shift takes years rather than quarters.

The Default: Build the Floor (→ Lean)

Year 1: Stabilize + Hybrid Foundation

• Stabilization (40% effort): Quick wins, operational burden reduction
• Modern Security for New (40% effort): Break legacy patterns for new systems
• Hybrid Strategy (20% effort): Define modern vs. legacy approach

Year 2-3: Gradual Modernization

• New Systems (40% effort): Lean-level capabilities for modern infrastructure
• Legacy Pragmatism (30% effort): Managed services, appropriate controls
• Platform Capabilities (30% effort): Unified capabilities serving both

Year 4-5: Complete Modernization

• Legacy Migration (40% effort): Migrate remaining systems to modern platform
• Lean Capabilities (40% effort): Advanced automation, platform effects
• Legacy Retirement (20% effort): Sunset old infrastructure

Expected Outcome: Lean positioning after 4-5 years (optimistic)

The Exception: Reduce Reach (→ Craft → Studio)

Year 1: Stabilize + Plan Reach Reduction

• Stabilization (50% effort): Quick automation wins, operational burden reduction
• Scope Assessment (30% effort): What can be simplified, consolidated, retired?
• Modern Security for New (20% effort): Stop recreating legacy patterns

Year 2-3: Simplification + Modernization

• Simplification (40% effort): Product consolidation, system retirement, scope reduction
• Modernization (40% effort): Cloud migration, CI/CD, infrastructure-as-code
• Essential Security (20% effort): Maintain security during transformation

Year 3-4: Complete Transformation to Studio

• Security Automation (60% effort): Build Studio-level capabilities
• Legacy Retirement (30% effort): Complete sunset of old systems
• Optimization (10% effort): Refine and improve

Expected Outcome: Studio positioning after 3-4 years

Common Pitfalls

Attempting the Containment Climb Too Fast

Risk: Transformation failure from moving too aggressively

Symptoms:

• Multiple simultaneous transformation initiatives
• Team burnout from change overload
• Incomplete migrations and half-finished modernization
• Regression to old patterns under pressure

Solution: Sequence transformation: stabilize first, then build the containment floor in stages rather than attempting the whole climb at once

Underestimating Timeline and Resources

Risk: Transformation stalls from insufficient investment

Symptoms:

• Transformation "initiatives" without dedicated resources
• Security team expected to transform while maintaining BAU
• Projects perpetually delayed for operational work
• Executive frustration with "slow progress"

Solution: Realistic timelines (years rather than months), dedicated resources, executive understanding

Recreating Legacy in Modern Infrastructure

Risk: Cloud migration without modernization

Symptoms:

• "Lift and shift" cloud migration
• Manual processes recreated in cloud environment
• Complex security reviews for cloud deployments
• Same problems, higher cloud costs

Solution: Modernize during migration, automate from start, break old patterns

Transformation Without Relationship Building

Risk: Security transformation fails from engineering resistance

Symptoms:

• Security initiatives mandated without buy-in
• Engineering teams bypassing security controls
• Low adoption of security platforms
• Adversarial relationships between security and engineering

Solution: Invest heavily in relationship building, demonstrate value, collaborative approach

Missing the Crisis Window

Risk: Transformation loses momentum without executive support

Symptoms:

• Transformation deprioritized for short-term needs
• Resources pulled for other initiatives
• "Transformation fatigue" setting in
• Reverting to old patterns

Solution: Use crisis events to secure sustained executive commitment

One more failure mode belongs here, because it is the one outside your control. Every path in this guide assumes the funding holds for the years it takes. A capex shock mid-transformation does more than slow you; it strands you, half off legacy and not yet on the modern platform, carrying both. The 2023 round of security budget cuts, 63 percent of organizations in a single year, landed on exactly these multi-year programs first. The hedge is the one Lean rests on: build the containment floor into the substrate early, because the floor is the part a budget cut cannot repossess. Spend buys position; design buys the floor.

Success Indicators

Year 1 (Stabilization)

• [ ] Operational burden reduced 20% through automation/elimination
• [ ] Executive sponsor actively engaged (monthly transformation reviews)
• [ ] Modern security deployed for new systems (not recreating legacy)
• [ ] Relationship health improving (measured via engineering satisfaction)
• [ ] Transformation roadmap approved with committed resources

Year 2 (Early Transformation)

• [ ] Operational burden reduced 40% from baseline
• [ ] Clear separation between modern and legacy security approaches
• [ ] Measurable progress on reach reduction or modernization
• [ ] Team morale stable or improving (not burnout from change)
• [ ] Regular executive updates demonstrating progress

Year 3-5 (Transformation Progress)

• [ ] Operational burden reduced 60-80% from baseline
• [ ] Majority of systems on modern infrastructure (or reach significantly reduced)
• [ ] Security automation at Studio or Lean level for modern systems
• [ ] Sustainable operations (not requiring heroic effort)
• [ ] Position movement toward Craft, Studio, or Lean

Transformation Success Factors

Critical Requirements

1. Executive sponsorship - CEO, CTO, or COO level champion
2. Realistic timeline - 3-5 years for complete transformation
3. Dedicated resources - Can't be "side of desk" project
4. Relationship health - Engineering as partners rather than adversaries
5. Strategic patience - Resist pressure for premature timelines

Helpful Enablers

• Crisis event creating transformation window
• High change capacity in organization
• Strong engineering partnership willing to help
• Financial resources for tools, cloud migration, hiring
• Business support for reach reduction (if applicable)

Red Flags for Failure

• "Transform in 12 months" expectations
• Security team expected to transform without additional resources
• No executive sponsor or inactive sponsor
• Damaged relationships with engineering
• Attempting transformation during other major changes (M&A, reorgs)

Movement Paths

Mass is a position you move through rather than one you hold. Studio, Lean, and Craft each have a stable "maintain position" path; Mass does not, because large reach with low readiness is where the scaling crisis bites hardest. The strategy is always transformation. Two routes lead out, detailed in the Investment Roadmap above:

• The Default: raise readiness (Mass → Lean). Build the containment floor and modernize while holding your reach. The long road, 4 to 5 years on an optimistic clock, but it keeps the business you already serve.
• The Exception: reduce reach (Mass → Craft → Studio). Cut blast radius by consolidating, retiring, and simplifying, then raise readiness from a smaller base. Faster where the reach is genuinely sheddable.

Use the Decision Framework below to choose between them.

Decision Framework

Can You Commit to the Containment Climb (Mass → Lean)?

This is the question for almost every Mass organization. It is the default path.

Realistic if:

• Strong executive commitment (CEO level) to a 4-5 year timeline
• Significant resources available (budget, headcount, time)
• High organizational change capacity
• Excellent relationship health with engineering
• Recent crisis event creating transformation window

Unrealistic if:

• Expecting results in 1-2 years
• Security team must transform while maintaining full BAU
• Damaged relationships with engineering
• Low change capacity or change fatigue
• No crisis event or executive urgency

If the climb looks unrealistic, the answer is rarely to shrink reach instead. That path stalls without a real business driver, and it can strand you mid-transformation carrying both old and new. The answer is to make the climb realistic: stabilize first, sequence the work in stages, and secure sustained executive sponsorship before committing.

Should You Reduce Reach Instead (Mass → Craft)?

Only when a real business reason already supports it.

Yes, if:

• You have products/services that could be consolidated or retired
• Business model supports scope reduction
• Executive support for the difficult decisions involved
• A divestiture, SMB pivot, or product consolidation is already underway

No, if:

• Business model requires the current reach
• Revenue tied to all current products
• No viable consolidation or retirement options
• Must maintain all current operations

---

Next Steps

Continue to Framework Relationships Back to Craft Implementation

Edit this page

Framework Relationships

SF² and NIST SSDF Integration

Framework Overview

NIST SSDF (Secure Software Development Framework)

• Focus: Secure development lifecycle practices
• Website: https://csrc.nist.gov/Projects/ssdf
• Purpose: High-level guidance for integrating security into software development

Relationship to SF²

NIST SSDF tells you WHAT security practices to implement in your software development lifecycle.

SF² tells you HOW to sustainably resource and scale those practices based on your organizational position.

SF² sequences a practice baseline, and SSDF's practice groups are one expression of that baseline rather than a fixed endpoint. As that baseline broadens toward attestation standards for agent-built software, SF²'s role holds: it decides which practices to fund first for your context, and it keeps the work pointed at bounding what the system can do.

New to SF²? This page maps NIST SSDF onto SF²'s strategic model, which leans on a few SF² terms. SF² positions an organization on two axes: Blast Radius (how far a failure could reach if containment fails, set by the authority you have granted your automation and agents, not by headcount) and Operational Readiness (how repeatably you operate and how well you can prove a failure stays contained). The two axes form four positions: Studio (small reach, higher readiness), Lean (large reach, higher readiness), Craft (small reach, lower readiness), and Mass (large reach, lower readiness); see Positioning. BAU (business as usual) is the recurring manual security work you constrain to free capacity for scaling investments. Contextual modifiers are the eight situational factors that tune the strategy (Context); Universal Security Conditions are the five universal priorities every organization owes regardless of position, led by Supply Chain.

Other frameworks provide the practices. SF² is the strategic overlay that sequences them: which to fund first, when, and how fast. Integration over replacement.

Key Insight

NIST SSDF is a practice catalog rather than an implementation sequence. It tells you which secure-development practices exist rather than which to fund first or how fast to adopt them.

Your SF² quadrant position determines:

• Which SSDF practices warrant investment first
• Whether to implement a practice through automation or accept manual work at current scale
• The pace of SSDF adoption, so the rollout does not outrun your capacity
• Which practices to hold at a baseline rather than deepen beyond actual risk

Integration Approach

SSDF Provides the Practices

NIST SSDF defines four practice groups (SP 800-218 v1.1, 2022):

1. Prepare the Organization (PO) - Ready your people, processes, and technology for secure development
2. Protect the Software (PS) - Protect all software components from tampering and unauthorized access
3. Produce Well-Secured Software (PW) - Secure design, coding, review, and testing to minimize released vulnerabilities
4. Respond to Vulnerabilities (RV) - Identify and remediate residual vulnerabilities, and prevent their recurrence

SF² Provides the Implementation Strategy

SF² helps you:

• Determine which SSDF practices to implement first based on your quadrant position
• Choose between manual and automated implementation based on operational readiness
• Sequence SSDF practice adoption to avoid overwhelming your organization
• Scale SSDF practices sustainably without linear growth in security headcount

Implementation by Quadrant

Studio (Small reach + Higher Readiness)

SSDF Implementation Approach: Automated from the start

Priority SSDF Practices:

1. PS (Protect the Software) - Automated build security, supply chain verification
2. PW (Produce Well-Secured Software) - Automated security testing, secure templates
3. RV (Respond to Vulnerabilities) - Automated dependency scanning and patching
4. PO (Prepare the Organization) - Self-service security documentation

Implementation Strategy:

• Automate SSDF practices in CI/CD pipeline from inception
• Policy-as-code for SSDF requirements
• Self-service SSDF capabilities (developers implement without security review)
• Metrics on SSDF practice adoption and effectiveness

Timeline: 6-12 months for comprehensive automated SSDF implementation

Lean (Large reach + Higher Readiness)

SSDF Implementation Approach: Platform-scale automation

Priority SSDF Practices:

1. All SSDF practices at organizational scale with platform effects
2. Advanced automation for complex SSDF requirements
3. Federated SSDF ownership (security champions, guild structure)
4. Continuous SSDF improvement based on metrics

Implementation Strategy:

• SSDF practices embedded in internal platforms
• Automated evidence collection for SSDF compliance
• Organization-wide SSDF metrics and optimization
• Industry leadership in SSDF practice innovation

Timeline: Ongoing optimization of established SSDF capabilities

Craft (Small reach + Lower Readiness)

SSDF Implementation Approach: Essential practices, pragmatic implementation

Priority SSDF Practices:

1. RV (Respond to Vulnerabilities) - Basic vulnerability management (highest risk)
2. PS (Protect the Software) - Essential build security (supply chain #1 priority)
3. PW (Produce Well-Secured Software) - Secure coding guidelines
4. PO (Prepare the Organization) - Basic security awareness

Implementation Strategy:

• Focus on highest-risk SSDF practices first
• Use managed services for SSDF capabilities where possible
• Manual implementation acceptable at current scale
• Avoid over-implementing SSDF practices beyond actual risk

Timeline: 6-12 months for essential SSDF practices

Mass (Large reach + Lower Readiness)

SSDF Implementation Approach: Hybrid (automated for new, pragmatic for legacy)

Priority SSDF Practices:

1. RV (Respond to Vulnerabilities) - Vulnerability management across complex systems
2. PS (Protect the Software) - Build security for active development
3. Automated SSDF for new systems - Break legacy patterns
4. Pragmatic SSDF for legacy - Risk-based implementation

Implementation Strategy:

• Implement automated SSDF for new/modernizing systems
• Risk-based SSDF for legacy systems (not full implementation)
• Gradual SSDF improvement as systems modernize
• Avoid attempting comprehensive SSDF across all systems simultaneously

Timeline: 3-5 years for comprehensive SSDF as systems modernize

Contextual Modifiers and SSDF

High Attack Landscape Maturity

Impact: Accelerates SSDF RV (Respond to Vulnerabilities) priority

• Automated vulnerability scanning becomes critical
• Supply chain security (PS) moves to top priority
• Manual response processes become existential vulnerability

High Regulatory Constraints

Impact: Requires SSDF practice documentation and evidence

• Automated evidence collection essential
• SSDF compliance reporting becomes significant BAU burden
• May require comprehensive SSDF implementation regardless of risk

Crisis Events

Impact: Creates window for rapid SSDF adoption

• Use incident as catalyst for automated SSDF implementation
• "Never waste a good crisis" for securing SSDF resources
• Demonstrates clear ROI for SSDF investment

Practical Integration Example

The example below is a composite illustration rather than a case study. The numbers and timelines show the shape of an outcome rather than measured results.

Scenario: Series B Startup (Studio Position)

Current State:

• Manual security reviews blocking releases
• Basic SSDF practices implemented manually
• Growing too fast for manual SSDF

SF² Guidance:

1. Assess Position: Studio (Small reach + Higher Readiness)
2. Identify Scaling Crisis: Manual SSDF practices not sustainable
3. Constrain BAU: Manual security reviews for novel architectures only
4. Scaling Investment: Automate SSDF practices in CI/CD

SSDF Implementation:

• PS (Protect the Software): Automated build security, supply chain scanning
• PW (Produce Well-Secured Software): Automated SAST/DAST, secure templates
• RV (Respond to Vulnerabilities): Automated dependency scanning, patch automation
• PO (Prepare the Organization): Self-service security documentation

Outcome: SSDF practices fully automated, security reviews reduced 70%

SSDF Practice Decision Matrix

Your SF² Position	Priority SSDF Practices	Implementation Approach	Timeline
Studio	PS, PW, RV first; PO self-service	Automated from the start	6-12 mo
Lean	All four groups at platform scale	Platform-scale automation	Ongoing optimization
Craft	RV and PS first (highest risk, supply chain)	Essential only, managed services	6-12 mo (essentials)
Mass	RV, PS; automated for new systems	Hybrid (automated new, risk-based legacy)	3-5 yr as systems modernize

Key Takeaways

Use NIST SSDF for:

• Comprehensive security practice catalog
• Practice descriptions and outcomes
• Regulatory compliance requirements
• Industry standard terminology

Use SF² for:

• Determining which SSDF practices to implement first
• Choosing implementation approach (manual vs automated)
• Sequencing SSDF adoption based on your position
• Scaling SSDF sustainably without linear headcount growth

Together:

• SSDF provides the practices
• SF² provides the sustainable implementation strategy
• Result: Effective security practices at appropriate scale

---

Next Steps

Continue to OWASP SAMM Relationship Back to Implementation Guides

Edit this page

SF² and OWASP SAMM Integration

Framework Overview

OWASP SAMM (Software Assurance Maturity Model)

• Focus: Security practice maturity progression
• Website: https://owaspsamm.org/
• Purpose: Assess and improve software security maturity through structured levels

Relationship to SF²

OWASP SAMM defines maturity levels (0-3) for security practices across five business functions.

SF² helps determine which maturity levels to pursue and how fast to progress based on your organizational position and readiness.

SF² sequences a practice baseline, and SAMM's maturity levels are one expression of that baseline rather than a ladder to climb for its own sake. As that baseline broadens toward capability and attestation standards, SF²'s role holds: it decides which levels are worth the investment for your context, and it sequences them toward containing what the system can do.

New to SF²? This page maps OWASP SAMM onto SF²'s strategic model, which leans on a few SF² terms. SF² positions an organization on two axes: Blast Radius (how far a failure could reach if containment fails, set by the authority you have granted your automation and agents, not by headcount) and Operational Readiness (how repeatably you operate and how well you can prove a failure stays contained). The two axes form four positions: Studio (small reach, higher readiness), Lean (large reach, higher readiness), Craft (small reach, lower readiness), and Mass (large reach, lower readiness); see Positioning. BAU (business as usual) is the recurring manual security work you constrain to free capacity for scaling investments. Contextual modifiers are the eight situational factors that tune the strategy (Context); Universal Security Conditions are the five universal priorities every organization owes regardless of position, led by Supply Chain.

Key Insight

Not every organization should pursue SAMM Level 3 maturity in every practice.

Your SF² quadrant position determines:

• Which SAMM practices warrant higher maturity investment
• Which practices can remain at lower maturity levels
• Speed of maturity progression appropriate for your organization
• Whether to pursue breadth (many practices at low maturity) or depth (few practices at high maturity)

SAMM Business Functions

OWASP SAMM (v2) organizes security practices into five business functions:

1. Governance - Strategy, metrics, compliance, education
2. Design - Threat assessment, security requirements, architecture
3. Implementation - Secure build, deployment, defect management
4. Verification - Architecture assessment, requirements testing, security testing
5. Operations - Incident management, environment management, operational management

Each business function holds three security practices, so fifteen across the five functions, and each practice is assessed along two activity streams. Maturity runs from level 0 (not performed) through level 3 (optimized/strategic).

SF² Maturity Strategy by Quadrant

Studio (Small reach + Higher Readiness)

SAMM Maturity Approach: High maturity through automation

Target Maturity Levels:

• Implementation: Level 3 (fully automated secure build and deployment)
• Verification: Level 3 (automated security testing at scale)
• Design: Level 2 (automated threat modeling, security requirements)
• Operations: Level 2-3 (automated operational security)
• Governance: Level 2 (metrics-driven, appropriate documentation)

Maturity Progression Speed: Fast (12-18 months to target state)

Strategy: Automate practices to achieve high maturity quickly

• Skip manual maturity levels where possible
• Use automation to jump directly to Level 2-3 maturity
• Avoid building manual processes that won't scale

Lean (Large reach + Higher Readiness)

SAMM Maturity Approach: Comprehensive high maturity across all functions

Target Maturity Levels:

• All practices: Level 2-3 (comprehensive maturity at organizational scale)
• Strategic practices: Level 3 with innovation beyond SAMM
• Platform effects: Capabilities serving multiple teams

Maturity Progression Speed: Optimization focus (not progression, but refinement)

Strategy: Maintain and optimize high maturity

• Continuous improvement of Level 3 practices
• Industry leadership in select practices
• Efficient maturity maintenance through platform effects
• Eliminate practices that don't reduce risk (even if mature)

Craft (Small reach + Lower Readiness)

SAMM Maturity Approach: Essential practices at appropriate maturity

Target Maturity Levels:

• Implementation: Level 1-2 (basic secure build, essential deployment security)
• Verification: Level 1 (basic security testing)
• Operations: Level 1 (essential incident response, basic monitoring)
• Design: Level 1 (security requirements for high-risk features)
• Governance: Level 1 (basic security awareness, minimal documentation)

Maturity Progression Speed: Slow and selective (focus on essentials)

Strategy: Appropriate maturity for scale and risk

• Level 1 maturity sufficient for many practices
• Invest in higher maturity only for highest-risk areas
• Avoid pursuing comprehensive SAMM maturity
• Use managed services to achieve maturity without building capability

Mass (Large reach + Lower Readiness)

SAMM Maturity Approach: Hybrid maturity (high for new, pragmatic for legacy)

Target Maturity Levels by System Type:

New/Modern Systems:

• Implementation: Level 2-3 (automated secure build and deployment)
• Verification: Level 2 (automated security testing)
• Operations: Level 2 (automated operational security)

Legacy Systems:

• All practices: Level 1 (basic coverage, risk-based)
• Accept lower maturity for systems being retired
• Avoid investing in high maturity for legacy

Maturity Progression Speed: Very slow (3-5 years to target state)

Strategy: Build high maturity for future while maintaining basics for legacy

• Pursue Level 2-3 maturity for new systems only
• Accept Level 0-1 maturity for legacy (pragmatic risk management)
• Gradual maturity improvement as systems modernize

Contextual Modifiers and SAMM

High Attack Landscape Maturity

Impact: Accelerates need for verification and operations maturity

• Verification practices must reach Level 2+ (automated security testing)
• Operations incident management becomes critical
• Manual security testing (Level 1) becomes existential vulnerability

High Regulatory Constraints

Impact: Forces governance maturity regardless of risk

• Governance practices must reach Level 2 (documentation, metrics, evidence)
• Compliance evidence collection becomes significant burden
• May require maturity investments that don't align with risk

Low Relationship Health

Impact: Slows maturity progression significantly

• Difficult to achieve Level 2+ maturity (requires collaboration)
• Must invest in relationship building before maturity progression
• Forced to rely on Level 1 controls (they don't require engineering cooperation)

Practical Integration Examples

The examples below are composite illustrations rather than case studies. The numbers and timelines show the shape of an outcome rather than measured results.

Example 1: Studio Pursuing SAMM Implementation Maturity

Scenario: Series B startup wants to improve secure build practices

Traditional SAMM Approach (Level progression):

1. Level 1: Manual security reviews before builds
2. Level 2: Security requirements documented and reviewed
3. Level 3: Automated security verification in build

SF²-Informed Approach (Skip to automation):

1. Start with Level 3: Implement automated security in CI/CD from the beginning
2. Skip manual levels: Don't build Level 1-2 manual processes
3. Outcome: Level 3 maturity achieved in 6 months vs 18+ months

Example 2: Mass Pursuing SAMM Verification Maturity

Scenario: Large enterprise with mixed legacy and modern systems

Traditional SAMM Approach (Organization-wide):

• Attempt Level 2 verification maturity across all systems
• Requires significant investment in legacy system testing
• Likely to fail or stall

SF²-Informed Approach (Hybrid):

• New systems: Pursue Level 2-3 verification (automated testing)
• Active legacy: Level 1 verification (basic testing, risk-based)
• Retiring legacy: Level 0-1 (accept risk until retirement)
• Outcome: Achievable maturity with realistic resources

Example 3: Lean Optimizing SAMM Governance

Scenario: Large tech company with Level 2 governance across the board

Traditional SAMM Approach:

• Pursue Level 3 governance for all practices

SF²-Informed Approach (Selective optimization):

• Eliminate low-value governance (even if mature)
• Optimize high-value governance to Level 3
• Automate governance evidence collection (platform effects)
• Outcome: Higher governance effectiveness with less effort

SAMM Maturity Decision Matrix

Your SF² Position	SAMM Breadth vs Depth	Target Maturity	Progression Speed
Studio	Depth (high maturity in essential practices)	L2-3 for core	Fast (12-18 mo)
Lean	Comprehensive depth	L2-3 across board	Optimization
Craft	Breadth (basic coverage)	L1 sufficient	Slow (essentials only)
Mass	Hybrid (depth for new, breadth for legacy)	L0-1 legacy, L2-3 new	Very slow (3-5 yr)

Key Takeaways

Use OWASP SAMM for:

• Comprehensive security practice catalog
• Maturity level definitions and assessment
• Structured improvement roadmaps
• Industry benchmarking

Use SF² for:

• Determining which SAMM practices warrant investment
• Choosing target maturity levels based on position
• Sequencing maturity progression appropriately
• Avoiding "maturity for maturity's sake"

Together:

• SAMM provides the maturity framework
• SF² provides the strategic context for maturity investment
• Result: Appropriate maturity for your organizational reality

Critical Insight: Level 3 maturity is not always the goal. SF² helps you determine appropriate maturity levels based on organizational position, operational readiness, and actual risk.

---

Next Steps

Continue to BSIMM Relationship Back to NIST SSDF Relationship

Edit this page

SF² and BSIMM Integration

Framework Overview

BSIMM (Building Security In Maturity Model)

• Focus: Security activity measurement and benchmarking
• Website: https://www.bsimm.com/
• Purpose: Describe what real organizations actually do for software security

Relationship to SF²

BSIMM describes 128 security activities that organizations perform, organized into 12 practices across 4 domains (as of BSIMM16, 2026).

SF² helps determine which BSIMM activities to implement and in what sequence based on your organizational positioning and investment strategy.

BSIMM is a descriptive census of what programs already do. SF² sequences a practice baseline, and that census is one snapshot of it rather than a fixed target. As that baseline broadens toward attestation and capability standards, SF²'s role holds: it turns the census into priorities for your context, and it aims them at limiting what the system can do.

New to SF²? This page maps BSIMM onto SF²'s strategic model, which leans on a few SF² terms. SF² positions an organization on two axes: Blast Radius (how far a failure could reach if containment fails, set by the authority you have granted your automation and agents, not by headcount) and Operational Readiness (how repeatably you operate and how well you can prove a failure stays contained). The two axes form four positions: Studio (small reach, higher readiness), Lean (large reach, higher readiness), Craft (small reach, lower readiness), and Mass (large reach, lower readiness); see Positioning. BAU (business as usual) is the recurring manual security work you constrain to free capacity for scaling investments. Contextual modifiers are the eight situational factors that tune the strategy (Context); Universal Security Conditions are the five universal priorities every organization owes regardless of position, led by Supply Chain.

Key Insight

BSIMM is descriptive rather than prescriptive. It shows what organizations do rather than what they should do.

SF² provides the strategic framework to:

• Prioritize BSIMM activities based on your quadrant position
• Sequence BSIMM activity implementation based on investment strategy
• Determine which BSIMM activities to skip entirely
• Identify when BSIMM activities should be automated vs manual

BSIMM Domains and Practices

BSIMM organizes these activities into 4 domains:

Governance

• Strategy & Metrics (SM)
• Compliance & Policy (CP)
• Training (T)

Intelligence

• Attack Models (AM)
• Security Features & Design (SFD)
• Standards & Requirements (SR)

SSDL Touchpoints

• Architecture Analysis (AA)
• Code Review (CR)
• Security Testing (ST)

Deployment

• Penetration Testing (PT)
• Software Environment (SE)
• Configuration Management & Vulnerability Management (CMVM)

SF² Investment Strategy and BSIMM

Studio (Small reach + Higher Readiness)

BSIMM Activity Selection: Automation-friendly activities that scale

Priority BSIMM Activities:

1. CMVM (Configuration Management & Vulnerability Management)
2. Automated dependency scanning
3. Automated vulnerability remediation
4. Supply chain security automation
5. ST (Security Testing)
6. Automated SAST/DAST in CI/CD
7. Security test automation
8. SE (Software Environment)
9. Automated secure build
10. Infrastructure-as-code security
11. SFD (Security Features & Design)
12. Secure templates and paved roads
13. Automated security patterns

Skip or Minimize:

• Manual architecture analysis (AA)
• Manual code review (CR)
• Extensive governance documentation (CP)
• Time-intensive training programs (T) - prefer self-service documentation

Implementation Approach: Automate BSIMM activities from the start

Lean (Large reach + Higher Readiness)

BSIMM Activity Selection: Comprehensive coverage with platform effects

Priority BSIMM Activities:

1. All 12 practices with high activity coverage
2. Platform-scale implementation of BSIMM activities
3. Advanced (BSIMM Level 3) activities appropriate for complexity
4. Federated execution of BSIMM activities (security champions, guilds)

Optimization Focus:

• Automate evidence collection for BSIMM activities
• Platform capabilities enabling BSIMM activities org-wide
• Eliminate low-value BSIMM activities (even if industry performs them)
• Industry leadership in select BSIMM practices

Implementation Approach: Comprehensive BSIMM with efficiency focus

Craft (Small reach + Lower Readiness)

BSIMM Activity Selection: Essential activities only

Priority BSIMM Activities:

1. CMVM (Configuration Management & Vulnerability Management)
2. Basic dependency scanning
3. Vulnerability patching process
4. SR (Standards & Requirements)
5. Essential security requirements
6. ST (Security Testing)
7. Basic security testing
8. SE (Software Environment)
9. Essential build security

Skip Entirely:

• Advanced governance activities (SM, CP)
• Sophisticated attack modeling (AM)
• Manual architecture analysis (AA)
• Manual code review (CR)
• Penetration testing (PT) - not cost-effective at this scale

Implementation Approach: Minimal BSIMM coverage, managed services where possible

Mass (Large reach + Lower Readiness)

BSIMM Activity Selection: Hybrid (comprehensive for new, essential for legacy)

Priority BSIMM Activities by System:

New/Modern Systems:

• Full BSIMM practice coverage
• Automated implementation where possible
• Build Lean-level capabilities for future

Legacy Systems:

• CMVM (vulnerability management) only
• Essential security testing (ST)
• Risk-based approach (not comprehensive)

Skip for Legacy:

• Architecture analysis (AA) - legacy is what it is
• Code review (CR) - not changing legacy code significantly
• Sophisticated attack modeling (AM) - pragmatic risk assessment only

Implementation Approach: Build comprehensive BSIMM for new systems over 3-5 years

BSIMM Activity Prioritization Framework

High-Value Activities (Implement First)

These BSIMM activities provide highest ROI across all quadrants:

1. CMVM - Supply chain security and vulnerability management
2. Highest risk area (Supply Chain #1 priority)
3. Automatable at all scales

4. Clear business value

5. ST - Automated security testing

6. Scales with automation
7. Catches issues early (cheaper to fix)

8. Reduces manual review burden

9. SE - Secure build environment

10. Foundation for other activities
11. Prevents supply chain attacks
12. Enables automation

Moderate-Value Activities (Implement Selectively)

These BSIMM activities have value but require careful sequencing:

1. SFD - Security features and design
2. High value for Studio (secure templates)

3. Moderate value for others

4. SR - Standards and requirements

5. Essential for regulated environments

6. Lower priority otherwise

7. SM - Strategy and metrics

8. Critical for Lean (optimization)
9. Basic for Studio
10. Minimal for Craft

Lower-Value Activities for Small-Reach Positions (Implement Last or Skip)

At Craft and Studio, these activities often don't justify their cost when run as manual practices. A Lean org at platform scale runs the same activities differently, automated and federated, and keeps them (see the Lean selection above). Scope the call to your position:

1. AA - Architecture analysis
2. Manual and doesn't scale

3. Consider skipping for automation instead

4. CR - Code review

5. Manual and expensive

6. Consider automated alternatives (SAST)

7. T - Training programs

8. Extensive training doesn't scale

9. Consider self-service documentation instead

10. PT - Penetration testing

    • Expensive and point-in-time
    • Consider continuous automated testing instead

Contextual Modifiers and BSIMM

High Attack Landscape Maturity

Impact: Prioritizes defensive BSIMM activities

• CMVM becomes top priority (automated vulnerability management)
• ST must be automated (manual testing too slow)
• PT less valuable (adversaries find issues faster than annual pentests)

High Regulatory Constraints

Impact: Forces governance BSIMM activities

• CP (Compliance & Policy) becomes mandatory
• SM (Strategy & Metrics) needed for evidence
• T (Training) required for compliance
• May require activities that don't reduce actual risk

Low Relationship Health

Impact: Limits collaborative BSIMM activities

• AA, CR, PT difficult (require engineering cooperation)
• Must focus on automated activities (CMVM, ST, SE)
• Relationship building becomes prerequisite for manual BSIMM activities

Practical Integration Example

The example below is a composite illustration rather than a case study. The numbers and timelines show the shape of an outcome rather than measured results.

Scenario: Mass Position Enterprise

Current State:

• Attempting comprehensive BSIMM implementation
• Following industry BSIMM scores
• Overwhelming security team with 128 activities

Traditional BSIMM Approach:

• Implement all activities where industry shows high adoption
• Progress through BSIMM levels systematically
• Benchmark against similar organizations

SF²-Informed Approach:

Year 1: Stabilization

• CMVM automation (Supply Chain #1)
• SE for new systems (secure build)
• Basic ST (automated security testing)
• Skip: AA, CR, PT, extensive T programs

Year 2-3: Hybrid Build-out

• New systems: Comprehensive BSIMM (automation-focused)
• Legacy: CMVM only (vulnerability management)
• Relationship building: Enable collaborative activities (AA, CR) over time

Year 4-5: Comprehensive Coverage

• Full BSIMM for modernized systems
• Retire legacy activities as systems sunset
• Optimize: Eliminate low-value activities

Outcome: Achievable BSIMM implementation aligned with transformation timeline

BSIMM Activity Decision Matrix

Your SF² Position	BSIMM Activity Count	Implementation Focus	Automation Level
Studio	30-40 activities	Automation-friendly activities	Very high
Lean	60-80 activities	Comprehensive with efficiency	High
Craft	15-25 activities	Essential only	Managed services
Mass	30-40 (new systems only)	Hybrid approach	Mixed

Note: These are guidelines rather than targets. More BSIMM activities doesn't necessarily mean better security.

Key Takeaways

Use BSIMM for:

• Comprehensive catalog of security activities
• Understanding what other organizations do
• Benchmarking your security program
• Identifying potential activity gaps

Use SF² for:

• Prioritizing which BSIMM activities to implement
• Sequencing BSIMM activity adoption
• Determining automation vs manual implementation
• Deciding which BSIMM activities to skip entirely

Together:

• BSIMM provides the activity catalog
• SF² provides the strategic prioritization framework
• Result: Focused security program aligned with organizational reality

Critical Insight: More BSIMM activities doesn't equal better security. SF² helps you implement the right BSIMM activities for your organization rather than the most activities.

---

Next Steps

Continue to OWASP ASVS Relationship Back to OWASP SAMM Relationship

Edit this page

SF² and OWASP ASVS Integration

Framework Overview

OWASP ASVS (Application Security Verification Standard)

• Focus: Security verification requirements for applications
• Website: https://owasp.org/www-project-application-security-verification-standard/
• Purpose: Comprehensive security requirements for testing web applications

Relationship to SF²

OWASP ASVS provides comprehensive security verification requirements organized into 17 chapters across three verification levels (ASVS 5.0, 2025).

SF² helps determine which ASVS level to target, which requirements to prioritize, and how to implement verification based on organizational position and risk.

SF² sequences a practice baseline, and ASVS's verification levels are one expression of that baseline rather than a fixed endpoint. As that baseline broadens toward attestation and capability standards, SF²'s role holds: it picks the right subset for your context, and it ties the verification back to what the system is allowed to do.

New to SF²? This page maps OWASP ASVS onto SF²'s strategic model, which leans on a few SF² terms. SF² positions an organization on two axes: Blast Radius (how far a failure could reach if containment fails, set by the authority you have granted your automation and agents, not by headcount) and Operational Readiness (how repeatably you operate and how well you can prove a failure stays contained). The two axes form four positions: Studio (small reach, higher readiness), Lean (large reach, higher readiness), Craft (small reach, lower readiness), and Mass (large reach, lower readiness); see Positioning. BAU (business as usual) is the recurring manual security work you constrain to free capacity for scaling investments. Contextual modifiers are the eight situational factors that tune the strategy (Context); Universal Security Conditions are the five universal priorities every organization owes regardless of position, led by Supply Chain.

Key Insight

ASVS provides three verification levels (each a superset of the one below):

• Level 1: Baseline security and the first step into ASVS, for lower-risk applications
• Level 2: The recommended target for most applications, especially those handling sensitive data
• Level 3: High-assurance requirements for critical, high-value applications

SF² helps you determine:

• Which ASVS level is appropriate for your organization
• Whether to implement comprehensive ASVS or risk-based subset
• How to sequence ASVS requirement implementation
• Whether to automate or manually verify ASVS requirements

ASVS Verification Chapters

ASVS 5.0 organizes requirements into 17 chapters:

1. V1 Encoding and Sanitization
2. V2 Validation and Business Logic
3. V3 Web Frontend Security
4. V4 API and Web Service
5. V5 File Handling
6. V6 Authentication
7. V7 Session Management
8. V8 Authorization
9. V9 Self-contained Tokens
10. V10 OAuth and OIDC
11. V11 Cryptography
12. V12 Secure Communication
13. V13 Configuration
14. V14 Data Protection
15. V15 Secure Coding and Architecture
16. V16 Security Logging and Error Handling
17. V17 WebRTC

SF² ASVS Strategy by Quadrant

Studio (Small reach + Higher Readiness)

ASVS Verification Approach: Automated Level 2, selective Level 3

Target ASVS Level: Level 2 for most applications

Implementation Strategy:

• Automate ASVS verification in CI/CD pipeline
• Automated testing for ASVS chapters that support automation:
• V1 (Encoding/Sanitization) and V2 (Validation) - SAST/DAST
• V16 (Security Logging and Error Handling) - Automated scanning
• V12 (Secure Communication) - TLS/certificate verification
• V4 (API and Web Service) - API security testing
• Secure templates implementing ASVS requirements by default
• Self-service ASVS verification for developers

Manual Verification (for requirements that can't be automated):

• V15 (Secure Coding and Architecture) - Risk-based threat modeling for novel architectures
• V8 (Authorization) - Logic testing for complex authorization
• V2 (Business Logic requirements) - Application-specific verification

Timeline: 12-18 months to comprehensive automated ASVS Level 2

Lean (Large reach + Higher Readiness)

ASVS Verification Approach: Comprehensive Level 2, selective Level 3 for high-risk

Target ASVS Level:

• Level 2 for all applications
• Level 3 for high-security applications (payment, sensitive data, critical infrastructure)

Implementation Strategy:

• Platform-scale ASVS verification serving multiple teams
• Automated ASVS testing integrated into security platforms
• Security product capabilities (if customer-facing software factory)
• ASVS compliance as competitive advantage
• Automated customer-facing security verification reports
• Advanced verification for complex requirements
• Automated threat modeling capabilities
• Sophisticated access control testing

Optimization Focus:

• Automated evidence collection for ASVS compliance
• Continuous ASVS verification (not point-in-time)
• Industry leadership in ASVS automation

Timeline: Ongoing optimization of established ASVS capabilities

Craft (Small reach + Lower Readiness)

ASVS Verification Approach: Essential Level 1 requirements, risk-based Level 2

Target ASVS Level: Level 1 baseline, selective Level 2 for high-risk areas

Implementation Strategy:

• Focus on highest-risk ASVS chapters:
• V6 (Authentication) - Critical for all applications
• V7 (Session Management) - Essential security baseline
• V1 (Encoding/Sanitization) and V2 (Validation) - Prevent common vulnerabilities
• V12 (Secure Communication) - TLS/HTTPS basics
• Use managed security services that provide ASVS compliance
• Basic security testing covering essential ASVS requirements
• Accept Level 1 compliance for lower-risk areas

Skip or Minimize:

• Advanced ASVS chapters (architecture, business logic)
• Comprehensive Level 2 verification for low-risk functionality
• Level 3 requirements (not cost-effective at this scale)

Timeline: 6-12 months to essential ASVS Level 1 coverage

Mass (Large reach + Lower Readiness)

ASVS Verification Approach: Hybrid (Level 2 for new, Level 1 for legacy)

Target ASVS Level by System:

New/Modern Applications:

• Level 2 with automated verification
• Build Studio/Lean-level ASVS capabilities for future

Active Legacy Applications:

• Level 1 baseline
• Risk-based Level 2 for critical functionality
• Accept pragmatic risk for legacy

Legacy Applications Being Retired:

• Level 1 or accept known gaps
• Don't invest in comprehensive ASVS for retiring systems

Implementation Strategy:

• Automated ASVS for new application development
• Pragmatic risk assessment for legacy applications
• Gradual ASVS improvement as applications modernize
• Hybrid verification tools that work across modern and legacy

Timeline: 3-5 years to comprehensive Level 2 as applications modernize

Risk-Based ASVS Prioritization

Critical ASVS Chapters (All Organizations)

These chapters should be prioritized regardless of position:

1. V6 (Authentication) - Broken authentication = complete compromise
2. V7 (Session Management) - Session attacks affect all applications
3. V8 (Authorization) - Broken access control = unauthorized access
4. V1 (Encoding/Sanitization) and V2 (Validation) - Prevents injection attacks

High-Value ASVS Chapters (Studio, Lean, Mass-New)

1. V12 (Secure Communication) - TLS/encryption for data in transit
2. V14 (Data Protection) - Sensitive data handling
3. V4 (API and Web Service) - API security increasingly critical

Moderate-Value ASVS Chapters (Situational)

1. V11 (Cryptography) - If handling sensitive data
2. V16 (Security Logging and Error Handling) - Incident response needs
3. V13 (Configuration) - Security misconfiguration prevention

Lower-Value ASVS Chapters (Deprioritize)

1. V15 (Secure Coding and Architecture) - Architecture and threat modeling are high-judgment and hard to automate (handle manually for novel designs); malicious-code concerns are largely covered by supply chain controls
2. Business-logic verification (the application-specific slice of V2, distinct from the input validation prioritized above) - Manual and situational
3. V5 (File Handling) - Lower risk for modern applications

Contextual Modifiers and ASVS

High Attack Landscape Maturity

Impact: Accelerates need for comprehensive ASVS

• Level 2 becomes minimum even for simple applications
• Automated ASVS verification essential (manual testing too slow)
• Continuous verification (not annual assessments)

High Regulatory Constraints

Impact: May require comprehensive Level 2 or Level 3

• PCI DSS, HIPAA, SOC 2 often reference ASVS
• Level 3 verification may be mandated for regulated data
• Evidence collection for ASVS compliance becomes significant burden

Customer-Facing Software Factory

Impact: ASVS becomes competitive advantage

• ASVS Level 2+ compliance as trust signal to customers
• Security verification reports based on ASVS
• Industry certifications (OWASP, CSA) requiring ASVS

Practical Integration Examples

The examples below are composite illustrations rather than case studies. The numbers and timelines show the shape of an outcome rather than measured results.

Example 1: Studio SaaS Startup

Scenario: Series B startup building SaaS platform

Traditional ASVS Approach:

• Annual penetration test checking ASVS requirements
• Manual verification of ASVS categories
• Expensive and point-in-time

SF²-Informed Approach:

• Automated ASVS verification in CI/CD:
• SAST/DAST covering V1, V2, V4, V12, and V16
• Automated authentication testing (V6, V7)
• TLS/certificate validation (V12)
• Secure templates implementing ASVS requirements by default
• Manual verification only for V15, V8, and V2 (architecture, authorization, business logic)
• Continuous ASVS verification with every deployment

Outcome: Level 2 ASVS compliance with 80% automation, continuous verification

Example 2: Mass Financial Services

Scenario: Large bank with legacy applications and modern cloud services

Traditional ASVS Approach:

• Attempt Level 3 ASVS across all applications
• Comprehensive manual verification
• Overwhelming security team

SF²-Informed Approach:

• New cloud services: Level 2 ASVS with automated verification
• Critical legacy: Level 2 for authentication (V6), authorization (V8), and input validation (V1/V2)
• Non-critical legacy: Level 1 baseline, accept gaps
• Retiring applications: No new ASVS investment

Outcome: Achievable ASVS compliance aligned with modernization timeline

Example 3: Lean Platform Company

Scenario: Large tech company with security product capabilities

Traditional ASVS Approach:

• Comprehensive Level 2-3 ASVS verification
• Significant manual verification effort

SF²-Informed Approach:

• Automated ASVS platform serving all teams:
• Security testing platform covering ASVS requirements
• Self-service ASVS verification for developers
• Automated compliance reporting
• Advanced verification capabilities:
• Automated threat modeling (V15)
• Sophisticated access control testing (V8)
• Customer-facing ASVS compliance:
• Security verification reports based on ASVS
• Competitive advantage through security transparency

Outcome: Comprehensive ASVS Level 2-3 with platform efficiency, security as differentiator

ASVS Level Decision Matrix

Your SF² Position	Target ASVS Level	Verification Approach	Coverage
Studio	Level 2	Automated verification	Comprehensive for new
Lean	Level 2-3	Platform-scale automation	Comprehensive all apps
Craft	Level 1	Managed services, basic testing	Essential categories
Mass	Level 1-2 hybrid	Automated for new, risk-based for legacy	New: L2, Legacy: L1

Key Takeaways

Use OWASP ASVS for:

• Comprehensive security verification requirements
• Standard terminology for security testing
• Compliance and certification requirements
• Technical security testing guidance

Use SF² for:

• Determining appropriate ASVS level for your organization
• Prioritizing ASVS requirements based on risk
• Sequencing ASVS implementation within investment strategy
• Choosing automation vs manual verification approach

Together:

• ASVS provides the verification requirements
• SF² provides the implementation strategy
• Result: Risk-appropriate security verification at sustainable scale

Critical Insights:

• Level 3 ASVS is not always necessary - Most applications should target Level 2
• Not all ASVS requirements are equal - Prioritize based on risk
• Automation accelerates ASVS adoption - Don't rely solely on manual verification
• Hybrid approaches work - Different ASVS levels for different system types

---

Next Steps

You've completed the Framework Relationships section! Continue to Use Cases or explore the Appendix:

View Use Cases Back to BSIMM Relationship Explore Glossary

Edit this page

Use Cases and Application Scenarios

Applying SF² to Real-World Situations

This section demonstrates how to apply the Software Factory Security Framework to common organizational scenarios. Each use case shows how the framework's components work together to guide strategic decisions.

New to the framework? The scenarios below lean on a handful of SF² terms, defined here so this page reads on its own. SF² places an organization on two axes. Blast Radius is how far a failure could reach if containment fails, set by the authority you have granted your automation and agents, not by headcount. Operational Readiness is how repeatably you operate and how well you can prove a failure stays contained. The two axes form four positions, named for production modes: Studio (small reach, higher readiness, the small-reach ideal), Lean (large reach, higher readiness, the large-reach ideal), Craft (small reach, lower readiness), and Mass (large reach, lower readiness). See Positioning for the full model. BAU (business as usual) is the recurring manual security work you constrain to free capacity for scaling investments. Universal Security Conditions are the five universal priorities every organization owes regardless of position, led by Supply Chain. Contextual modifiers are the eight situational factors that tune the strategy; see Context.

The scenarios below are composite illustrations rather than case studies. The numbers show the shape of an outcome rather than measured results.

Use Case 1: Scaling Crisis at Series B Startup

Situation

A 50-person SaaS startup (Studio position) hits the scaling crisis: security reviews now take 2 weeks, blocking feature releases.

Framework Application

Strategic Position: Studio (Small reach + Higher Readiness)

Contextual Modifiers:

• High attack landscape maturity (SaaS target)
• Moderate supply chain complexity (standard dependencies)
• Strong relationship health (good dev-security collaboration)

Investment Strategy:

1. Constrain BAU: Reduce manual security reviews to critical features only
2. Scaling Investment: Implement automated security scanning + paved roads for common patterns
3. Timeline: 6-month implementation with 3x ROI expected

Outcome: Security reviews reduced from 2 weeks to 2 hours for standard patterns; manual reviews only for novel architectures.

---

Use Case 2: Enterprise Undergoing Digital Transformation

Situation

A 5,000-person financial services company (Mass position) needs to modernize security while maintaining compliance and managing legacy systems.

Framework Application

Strategic Position: Mass (Large reach + Lower Readiness)

Contextual Modifiers:

• High regulatory constraints (financial services)
• Low change capacity (risk-averse culture)
• Moderate relationship health (improving)
• Recent crisis event (audit findings)

Investment Strategy:

1. Use crisis window: Apply audit findings for funding approval
2. Hybrid approach: Modern security for new systems, pragmatic controls for legacy
3. Extended timeline: 36-60 month transformation with phased rollout

Outcome: Gradual modernization with compliance maintained; crisis event created sustainable funding for transformation.

---

Use Case 3: Supply Chain Attack Response

Situation

A technology company discovers compromised dependencies used in production systems, triggering supply chain security overhaul.

Framework Application

Universal Security Conditions Priority: Supply Chain #1 priority activated

Contextual Modifiers:

• High attack landscape maturity (automated supply chain attacks)
• Crisis event (compromised dependency)
• Complex supply chain (multi-tier dependencies)

Response Strategy:

1. Immediate: Contain and assess impact
2. Short-term: Implement automated dependency scanning
3. Medium-term: Deploy SBOM capabilities and continuous monitoring
4. Long-term: Build supply chain security platform

Outcome: Supply chain visibility improved from quarterly manual audits to continuous automated monitoring.

---

Use Case 4: Moving from Craft to Studio

Situation

A 20-person startup with legacy infrastructure decides to modernize their entire stack to enable faster growth.

Framework Application

Current Position: Craft (Small reach + Lower Readiness) Target Position: Studio (Small reach + Higher Readiness)

Movement Path: Infrastructure modernization (single axis movement)

• Timeline: 12-18 months
• Success probability: High (single axis change)

Investment Priorities:

1. Cloud platform migration
2. CI/CD automation
3. Infrastructure-as-code
4. Automated security testing

Security Integration:

• Implement security automation during modernization
• Policy-as-code from the start
• Avoid recreating manual processes in new infrastructure

Outcome: Successful transformation with security embedded in modern infrastructure from inception.

---

Use Case 5: BAU Constraint Implementation

Situation

A security team at series C company recognizes unsustainable demand growth and needs to shift from manual security reviews to scaling approach.

Framework Application

BAU Constraint Strategy (from Investment Portfolio):

Phase 1 - Communication (Month 1):

• Transparent explanation of scaling challenge
• Presentation of self-service alternatives
• Clear prioritization criteria for manual reviews

Phase 2 - Alternatives (Months 2-3):

• Deploy security scanning automation
• Create secure templates for common patterns
• Build self-service documentation

Phase 3 - Constraint (Month 4):

• Limit manual reviews to novel/high-risk changes
• Direct teams to self-service for standard patterns
• Measure adoption and iterate

Outcome: Manual security reviews reduced 70%; security coverage improved through automation; developer satisfaction increased.

---

A different kind of case: when the system is the agent

The five cases above are where you act. The seam is the place between the parts, and in most organizations no one team owns it.

The cases above take a situation apart: find the position, read the modifiers, pick the conditions, design the portfolio. That works when the parts fail independently. It breaks the moment the system is an agent wired to APIs and acting on its own.

An agent, the APIs it can call, and the autonomy it runs with can each be safe on their own and still compose into a breach. The risk lives in the seam where one part's output becomes another part's trusted input. EchoLeak is the case in production: a crafted email reached an inbox assistant that read it automatically and acted with the authority it already held, and no single component was breached. This is the combinatorial surface the framework warns about, met where you actually apply it: the interactions multiply faster than the parts, so a parts-list review misses the term that dominates.

So add a step the other cases do not need. Before you sign off on an agent system, run an interaction pass: enumerate the agent against the APIs it can call against the autonomy it has, and ask what each seam lets through. The thing to test is what happens when this agent, reading input you do not control, is allowed to call this API on its own. Asking only whether the API is safe answers a smaller question.

You cannot judge a run from inside it. The same crafted text that steered the agent can also narrate the result as clean, so the answer shown to the user looks fine while the damage happens off to the side. The evidence is blunt. When researchers fed agents data through ordinary outbound requests, checks on what the agent showed the user missed 95 percent of the leaks, because the data left through a channel the visible answer never mentioned.¹ The same EchoLeak email fits this exact shape: the assistant's reply looked normal, and the mail left quietly. So the signal you trust comes from outside the agent, never from its own account.

That outside signal has two jobs. The failures you can name in advance, you pre-commit as bright lines: a value with untrusted provenance reached a sink, data crossed a boundary it should not have, an action fired without its checkpoint. The failures you cannot name in advance, you catch a different way, because an injection invents a path no one listed. You keep enough record of each run to reconstruct what the agent actually did from the outside, then ask a question you had not thought to ask.² That record has to be three things. Accurate, meaning read from the network and the actions rather than from the agent's own reply. Real-time, because a finding a quarter later is an autopsy. And specific to the single run, because an average hides the one that leaked.

This sign-off is dated. Today it is something you run periodically, at the level of a system you approve once. As autonomy widens and agents begin to wire themselves to each other, that cadence will be too slow, and the unit you analyze will shift from a system you approve to a population of agents you watch. If your sign-off cadence has not changed while your agents' autonomy has, your review is already aging.

---

Framework Application Template

Use this template to apply SF² to your organization:

1. Assess Strategic Position

• Blast Radius: Small reach / Large reach
• Operational Readiness: Lower / Higher
• Current Quadrant: ___

2. Evaluate Contextual Modifiers

Modifier	Level (Low/Moderate/High)	Impact
Attack Landscape
Supply Chain Complexity
Regulatory Constraints
Crisis Events
Change Capacity
Relationship Health
AI Saturation
PQC Exposure

3. Identify Priority Stewardship Areas

Based on position and modifiers:

1. Primary focus: ___
2. Secondary focus: ___
3. Maintenance areas: ___

4. Design Investment Portfolio

• BAU to constrain: ___
• Scaling investments: ___
• Timeline: ___
• Expected outcomes: ___

5. Plan Movement Path (if applicable)

• Current position: ___
• Target position: ___
• Movement strategy: ___
• Timeline: ___

6. For Agent Systems: Run the Seam Pass (the emerging ship bar)

Enumerate the agent, the APIs it can call, and the autonomy it runs with, and test what each seam lets through when the agent acts on input you do not control. Because output-side checks miss most leaks, the gate is an external watcher: one observable that proves a run wrong, checked from outside the agent on every run. The emerging bar is to ship this as an evaluation in CI: no external watcher, no ship.

---

Contributing Use Cases

Have you applied SF² to your organization? We welcome real-world use case contributions!

What to include:

• Organizational context (anonymized)
• Strategic position and modifiers
• Framework application approach
• Outcomes and lessons learned
• Advice for similar situations

How to contribute: See Contributing Guidelines

---

Next Steps

Explore Framework Relationships Back to Implementation Guides

---

1. Silent Egress (Lan et al., 2026, arXiv:2602.22450): implicit injection drives an agent to exfiltrate its runtime context through ordinary outbound requests while the user-facing response stays harmless. ↩

2. Observability in its original control-theory sense, a system is observable when its internal state can be reconstructed from its external outputs over time (Kálmán, 1960). Charity Majors carries it into software practice: the ability to ask any question of a running system from the outside, including the ones you did not anticipate. ↩

Coadaptive Security Layer

Coadaptive Security Layer

Coadaptive Layer · Overview

Position: Doctrinal extension of SF² for the AI era. Relationship to SF²: Each chapter cross-references INTO the SF² base. The layer extends SF² rather than replacing it.

This layer earns top-level position next to SF², rather than nesting under AI tooling, because what AI changed is the operational fabric the whole framework runs on, deeper than any vendor choice. Filing it under "AI Integration" would treat it as one more tool to configure. It is closer to a shift in the ground. The five attack surface expansions and the comprehension crisis are cumulative pressure on every condition the base framework cultivates, and that pressure is what earned a layer of its own.

The name Coadaptive marks an addition rather than a rebrand of SF². The base framework's account of software factories holds without amendment, and this layer adds only the part that shows up when a second intelligence joins the work and the system starts adapting to inputs no one wrote. Coadaptive names that: a system where the human, the agents, and the adversary are all adapting at once, and security has to be a property that adapts with them.

How this layer relates to SF²

SF² is the base and this layer rides on top. AI-era pressure changes how the factory operates without changing what a software factory is, so none of the base doctrine is retired. The Universal Security Conditions still hold, the positioning model still holds, the investment logic still holds. This layer surfaces what those conditions have to contend with once agents read, reason, and act inside the system.

The layer is doctrinal rather than vendor-specific. It names what changes and what to do about it at the level of architecture and authority, and it leaves the catalog of which model from which vendor to the parts of the practice that age in months rather than years.

Chapters in this layer

Chapter	Topic	Extends SF² section
01 The Three-Layer Model	Substrate / Dynamic / Unit decomposition	Foundation (Sec 01)
02 The AI-Era Threat Surface	Five expansions + comprehension crisis	Contextual Modifiers (Sec 05); amends Adaptive Capacity (Sec 02)
03 The Unit of Defense	Paired intelligence + adaptive capacity	Adaptive Capacity (Sec 02), Implementation (Sec 06)
04 Boundary Enforcement	Capability-based security at agent scale	Process Stewardship (Sec 02), Implementation (Sec 06)
05 Authorization at Agent Scale	Confused deputy (Hardy, 1988) and MCP	Investment Portfolio (Sec 04), Process (Sec 02)
06 Input Trust Is a Category Error	Prompt injection as architectural unsolvable	Runtime (Sec 02), Attack Landscape (Sec 05)

Reading guide

Read Chapter 01 first; it gives the substrate / dynamic / unit decomposition the other chapters slot into. From there the layer reads in order, and each chapter names the SF² base section it extends so the base material can be read alongside it.

If you are time-constrained, the two chapters that change the most decisions are 02, The AI-Era Threat Surface, for what you are now exposed to, and 04, Boundary Enforcement, for what to do about it. The full sweep is worth the hour when you are setting strategy rather than triaging.

What this layer is NOT

It is not a vendor selection guide and not an AI capability catalog. It does not treat "AI security" as a separate practice bolted onto the side of the real one. The base framework still owns substrate-level doctrine, and this layer surfaces what changes when AI joins the system, so the two read as one practice rather than a framework and its appendix.

The Three-Layer Model

Coadaptive Layer · Chapter 01

This chapter extends: SF² Foundation (Section 01): the unit-of-analysis question. Scope: the substrate / dynamic / unit decomposition that organizes the rest of this layer.

AI-era security pressure shows up at three distinct levels, and conflating them is how defenses end up aimed at the wrong layer. The substrate is what the system is allowed to do. The dynamic is how untrusted input moves through it. The unit is who, human and agents together, is actually operating. The rest of this layer is organized around that decomposition, because a defense that belongs at the substrate fails when you try to enforce it in the dynamic, and a threat that lives in the dynamic cannot be fixed by redrawing the unit.

The three layers, with the foundation beneath the substrate. Put defensive weight low, on the substrate: the unit at the top is the least stable layer, so a defense anchored there moves under you.

Substrate

The substrate is the static, boundary-enforceable layer: the capabilities a component holds, the authority a request carries, what the infrastructure permits before any input arrives. This is where defense is most reliable, because it does not depend on predicting behavior. It depends on bounding it. A component that cannot reach the data cannot leak the data, whatever it is told to do.

The substrate is where Boundary Enforcement and Authorization at Agent Scale operate. Capability-based limits and authority that flows with the request are both substrate moves: they decide in advance what is possible, so that runtime cleverness, the system's or the attacker's, has less room to matter.

The substrate has a floor of its own. Every boundary it enforces is built out of something more primitive: the cryptography that makes a capability token unforgeable, the silicon that makes an enclave a wall, and for AI systems the model weights that are themselves an asset to be protected. Call it the layer beneath the substrate. It rarely shows up in a threat model because it usually holds, but when it gives way it gives way silently. When a certificate authority is breached, every certificate it ever signed is suspect at once, and nothing in the layers above announces the change. A capability limit is only as sound as the signature scheme behind it.

That floor is also why static is too strong a word. The substrate is static in one sense only: it is set before input arrives rather than changed at runtime. Over time it dates, because the primitives underneath it age, and the property that keeps it honest is crypto-agility, the ability to swap a primitive without rebuilding everything above it. TLS is the good case: the industry retired RC4 and SHA-1 by configuration, and is now slotting post-quantum key exchange into the same protocol without touching the applications on top. The primitive changed and the stack stood. But agility buys only forward safety, and that limit is worth stating plainly. It cannot re-lock data an attacker already copied under old encryption, which is the harvest-now-decrypt-later problem, and it cannot reach a device already fielded with no update path. Modern hardware roots of trust rotate their algorithms in place; the ones that cannot are the ones nobody can get to.

There is a second way static is too strong a word, and it sits one level up from the cryptography. A bounded component cannot be talked into harm it has no capability to do, and that holds as a substrate property rather than a behavioral hope for as long as the component cannot act on the layer that bounds it. The boundary is enforced below the component, in infrastructure the component cannot reach, which is why an attacker writing into its input cannot spend authority the component was never granted. The condition that keeps the property honest is reachability: the moment a component can read, write, or reason about its own enforcement layer, the guarantee stops being something you get by construction and becomes something you have to prove. Self-modification is the most common route to that reachability rather than the condition itself. A frozen component with a confused-deputy path to its own policy store is already across the line, and an agent that rewrites its own reasoning but cannot touch the infrastructure that contains it is not.

When a component can reach its own enforcement layer, the guarantee relocates instead of vanishing. The boundary you can still trust narrows from the whole component to a smaller core, and inside that core it gets stronger rather than weaker. The first move is containment: bound the blast radius so a failure at the enforcement layer is survivable by design, a substrate property you can buy and deploy now. The second, where the stakes justify the cost, is verification: a machine-checked core that no amount of attacker cleverness can argue past, the way seL4 carries a proof that no execution path violates its access-control invariant. Most boundaries in production are asserted rather than proven, and that difference is now load-bearing. AI lowers the cost of finding a path through an asserted boundary and changes nothing about a verified one.

That pressure is already real, and not yet a wall. AI systems can find exploitable flaws in enforcement-layer code: DARPA's AIxCC systems found 18 real vulnerabilities across 54 million lines of code in 2025, and Google's Big Sleep found live zero-days in substrate software like SQLite. The capability is symmetric, and as of 2026 the measurable edge still sits with defenders, though the margin is narrowing and contested. The signal that matters is a change of default rather than a date: components shipped with the standing ability to reach their own enforcement layer. Re-architect toward contained, verified cores as that becomes common, and accept the asserted-boundary risk until it does.

Dynamic

The dynamic is the interaction-pattern layer: how tokens, instructions, and data move through the system at runtime, and where trust domains meet. This is the layer that cannot be made safe by construction, because it is where untrusted input lives and adapts. The honest goal here is containment and provenance rather than prevention.

The dynamic is where The AI-Era Threat Surface expands and where Input Trust Is a Category Error bites. Prompt injection is a dynamic-layer problem with no dynamic-layer solution, which is exactly why its answer is pushed down to the substrate. Knowing which layer a threat lives on is what tells you which layer to defend it from.

Unit

The unit is the operating-cell layer: who is doing the work, now that the work is not always done by a person. This is the newest of the three and the one the older frameworks have no slot for, because they assumed the unit was a person. The unit is whatever cell holds the authority to act, and its composition slides: a lone human, a human and their agents paired, a lone agent running on its own. When that composition changes, the questions of org design and role change with it. The property that keeps the cell safe does not: it is adaptive capacity whatever the cell is made of.

The unit is where The Unit of Defense operates, and where the holobiont idea surfaces as vocabulary: the human and the agents as one unit of selection, defended as a pair rather than separately. The concept earns its keep here as a way to see the cell clearly rather than as a name the layer flies under.

The unit is also the least stable of the three layers. A boundary in the substrate stays put until you change it. The unit does not: the split between what the human does and what the agents do keeps moving as the agents take on more. So the unit is the layer most likely to shift under you. Put your defensive weight on the substrate beneath it rather than on where the line happens to sit today.

See also

• The AI-Era Threat Surface: what changes at the dynamic layer
• The Unit of Defense: what changes at the unit layer
• SF² Foundation: Software Factory Definition: base framework

The AI-Era Threat Surface

Coadaptive Layer · Chapter 02

This chapter extends: SF² Contextual Modifiers (Section 05) · Attack Landscape. Also flags: SF² Adaptive Capacity (Section 02): comprehension-crisis addendum lives here. Scope: the five attack surface expansions and the comprehension crisis.

The AI era multiplied the board itself rather than adding five new threats to it. Democratized builders, public APIs, agent access, autonomous reasoning, and LLM workflows each expand the attack surface, and they expand it together, each one widening the blast radius of the others. Underneath all five sits the comprehension crisis: code is now generated faster than any human process can understand it, and a surface you cannot comprehend is a surface you cannot review by the old methods.

The five attack surface expansions

Each expansion is a real shift in what the organization exposes. The five are a way to reason about one surface rather than five surfaces to defend in turn, because they do not arrive one at a time.

These five are not an arbitrary count. One rule sits under all of them. Each is a human-scale limit that used to hold the surface in check on its own, now coming undone, and the four map onto the first four expansions in order. Only a known few could ship production behavior. An interface was safe because no human bothered to abuse it. The trust boundary stayed where the security team could see it. Behavior was predictable because a person specified the flows. Each was a quiet bottleneck doing security work no one paid for, and the AI era removes it. The test is whether the limit was holding the surface in check rather than merely slowing the work down. Slow typing was a limit too, and removing it expands no one's attack surface.

The fifth is a different kind of thing. LLM workflows are less another bottleneck coming undone than the place the first four chain into each other, where one removed limit becomes the next one's problem. The four are the load-bearing limits coming undone now rather than a closed catalog. You can already see the next ones forming. An agent that remembers across sessions removes a limit we used to rely on: that a session ended and its reach stopped with it. One operator spawning a fan-out of sub-agents removes the limit that one human was one actor you could count. The same rule names each as it arrives. The list was never meant to be finished.

The five expansions couple through one shared substrate rather than standing as five separate surfaces to defend in turn. That substrate is the identity that acts and the authority it carries, so a weakness there widens every surface routed through it.

Democratized builders

The set of people shipping production behavior has stopped matching the set of people the security program was built around. A product manager wiring together a workflow, an analyst writing a script an agent will run, a marketer standing up a site through a generation tool: each is now a builder, and most of them never touch the paved road the security team paved. The surface expands because authorship expands, and authorship expanded past the org chart.

Public APIs

Every capability exposed as an API is a capability exposed to whatever calls it, including the things you did not anticipate calling it. APIs were always an attack surface. What changed is that agents now discover and chain them at machine speed, so an interface that was safe because no human bothered to abuse it is no longer protected by that friction.

Agent access

The moment an agent reads, writes, or acts on a system, the trust boundary moves to wherever the agent reaches. That is almost always somewhere the security team never controlled: a mailbox, a wiki, a shared drive, a vendor's data. Agent access converts every readable surface into a potential injection point and every writable surface into a potential action the attacker gets for free. You do not close that by sanitizing input; you close it by bounding what the agent can do regardless of what it reads, which is the substrate answer Boundary Enforcement takes up.

Autonomous reasoning

A system that decides its own next step is a system whose behavior is no longer fully enumerable in advance. Autonomous reasoning means the path from input to action is chosen at runtime, under conditions the designer did not specify, which breaks the assumption that you can threat-model a fixed set of flows. The surface is no longer the code; it is the space of decisions the system can reach.

LLM workflows

Chaining models into pipelines compounds every property above. Output from one step becomes instruction for the next, trust domains blur across hops, and a single poisoned input can propagate through a workflow that no one drew on a whiteboard. LLM workflows are where the other four expansions interlock, the place a weakness in any one of them becomes a weakness in the whole.

The comprehension crisis

The expansions would be manageable if comprehension kept pace. It does not. Code is now generated faster than humans can build semantic understanding of it, and the gap is widening. The exact multiple is less important than the direction, and the direction is documented: DORA's 2025 research finds AI adoption still pulling against delivery stability even as it lifts throughput, and frames AI as an amplifier of whatever discipline an organization already has. GitClear's analysis of 211 million lines finds copy-pasted code rising and refactoring falling as assistants take over more of the authorship. Addy Osmani has named the local form of this as comprehension debt, the growing gap between how much code exists and how much anyone still understands it. The crisis is the systemic condition; the debt is how it accrues in a single codebase, and its tell is false confidence rather than the mounting friction technical debt announces. The gap is the crisis: an organization that ships software it does not understand cannot tell a vulnerability from a feature, cannot scope a blast radius, and cannot answer the only question that matters in an incident, which is what this system can actually do.

Call comprehension a competitive advantage and you overstate it. The shallow version is commoditizing fast: anyone can point a tool at a repo and get a picture back, so that much is becoming table stakes rather than an edge. What stays hard, and stays valuable, is a model that captures what the system was meant to do. Even so, the real point is the downside. An organization that cannot say what its software does cannot see the vulnerabilities that emerge between parts that each work as designed, cannot scope a blast radius, and cannot answer the question every incident asks. Losing comprehension is worse than falling behind a competitor. It puts you below the line where security decisions are even possible.

The subject of comprehension

The chapter has not said who comprehends. The answer is no one person, and no one person ever did. No single engineer holds a million-line codebase end to end, with or without an assistant. Rather than creating that limit, AI pushed it down onto systems that once fit inside a team's head. So comprehension at scale is a property of a model you can question rather than a fact about a person: a current map of how the system behaves, kept current by people or machines. A map is only worth keeping if it is reconciled against the code as the code changes. One built once and left to drift misleads more than no map at all.

A model is also worth only what it captures. Build it from passing tests and the traces you happened to keep, and it records what was checked rather than what the system was meant to do. It will answer with confidence and be wrong. Bryan Finster gives the order it has to respect: tests describe behavior, behavior drives the code, the code is the implementation detail. But tests describe behavior only by example, and an agent can pass every one of them while missing the intent of the change. Capturing intent, beyond a sample of assertions, is the hard part and the unsolved one. A model that skips it is a map that lies with a straight face.

You can see the gap in your own estate before you can measure it. The same signals that show up in the aggregate show up in your own delivery telemetry: review times stretching as change sets grow, more changes merging with no real review, reverts and reworks climbing in the weeks after a feature ships. None of these is a comprehension score, and you should distrust anyone who sells you one. They are weather rather than a gauge.

What a leader can ask instead is whether the gap is widening:

• Is the share of your estate that someone on your team can actually explain growing or shrinking as you ship faster?
• When your engineers accept generated code, do you know whether they verified it or waved it through?
• In your last incident, did someone already know what the affected system could do, or did you have to read the code to find out?

None of these has a number, and none of them lets you rank yourself against another company. That is the point. They are answerable only about yourself, and only directionally.

None of this competes with containment. It sits beside it. A capability boundary holds whether or not anyone understands the code behind it, which is the point Boundary Enforcement makes and the reason it survives a comprehension gap. Comprehension is the floor under a different thing: the decisions around the boundary. What to bound, where the guardrail belongs, whether the boundary still fits what the system is for. The boundary contains without understanding. Comprehension is how you decide what to contain and audit that the boundary you placed was the right one. The differentiator was never that you understand your code. It is that you make better containment decisions because you can interrogate what the system does. They fail in different places, so an estate needs both.

Why this is combinatorial rather than additive

Threat modeling that counts components and sums them assumes the components are independent: a breach of one does not get you another. The agentic-security field has already watched that assumption break and built for it. MAESTRO models how a weakness cascades from one layer into the next rather than staying where it started; ASTRIDE extends the classic STRIDE method with a category for the agent-specific attacks older models miss. That direction is right. SF² takes the same observation up a level and names what the cascade runs through. These five expansions couple through one substrate rather than standing independent: the identity that acts and the authority it carries. That substrate is what each expansion changes: who holds authority, what can invoke it, where it reaches, whether its use is predictable, how it propagates across hops. A democratized builder standing up an agent with public-API access inside an LLM workflow is one actor rather than four problems in a row, under one identity, with one grant of authority, and each expansion widens what that single grant can reach. This is the confused deputy at the scale of the whole surface, and it is not theoretical. When a trojaned email MCP server silently copied every message it sent to an attacker across more than a thousand installs, the send-authority the agents had granted it became exfiltration no one authorized. Call the result multiplicative if the word helps; the word is a model of reach rather than a number you can compute. What it names is the coupling: a weakness in that shared substrate, such as an over-broad credential or an agent whose actions trace to no one, widens every surface routed through it rather than adding one.

The same coupling runs inward. Spread across many hands the expansions compound; folded into one general-purpose agent they collapse into a single actor that ships behavior, discovers and chains APIs, reads and acts across systems, picks its own next step, and runs its own multi-step workflow. A coding agent wired into your repositories, your build pipeline, your cloud, and your ticket queue is exactly that: one process, one identity, one set of credentials, all five expansions at once. It looks simpler, fewer seams to draw, and it is more dangerous, because the blast radius of all five now sits inside one grant of authority that no static scope statement can narrow without taking away the generality that made it worth building. Consolidating concentrated the risk rather than dropping it.

How do you know which regime you are actually in? From your own incidents rather than the math. Pull your last several and ask of each whether the compromise stayed contained or crossed into a system that was supposed to be separate; the share that crossed over is the coupling you have, and it is where the next dollar goes. That snapshot names the regime. The falsifiable claim is the trend behind it: bound the shared substrate and that crossed-over share should fall over the following quarters, and if it does not, the containment thesis is wrong for your org and the coupling lived somewhere else. Either way the defensive consequence is the same, and it is the rest of this layer. A surface coupled through one authority context and outrunning human comprehension cannot be defended by inspecting it more carefully; it has to be defended by containing what any part of it is allowed to do, so that a compromise stays confined to the authority actually granted and the coupled surfaces fall back to independent ones. Inspection loses for a second reason too, one that does not turn on review speed. Offensive tooling is built from public, transferable knowledge, so a technique that breaks one target tends to break others. Defense depends on the opposite, the private and idiosyncratic shape of your own environment, which is exactly where machine learning generalizes worst. You cannot close the gap by pointing the same class of model at defense, because the attacker's model travels and yours does not. The asymmetry is structural rather than a snapshot of today's capability, and it points the same way: contain what the surface can do rather than try to out-model the adversary. That is the substrate-layer argument Boundary Enforcement takes up next.

See also

• The Unit of Defense: what the threat surface targets
• Boundary Enforcement: capability containment as the answer at the substrate layer
• Input Trust Is a Category Error: the architectural unsolvable inside this surface
• SF² Contextual Modifiers · Attack Landscape: base framework

The Unit of Defense

Coadaptive Layer · Chapter 03

This chapter extends: SF² Adaptive Capacity (Section 02), SF² Implementation Guides (Section 06). Scope: what the operating unit becomes when AI joins, and what property defends it.

Security was historically organized around the person and their tools. The analyst ran the query, the engineer pushed the fix, the tool did what it was told and nothing more. The older frameworks could assume the unit was a person, because it was. That is the assumption that breaks. The unit is whatever cell holds the authority to act, and its composition is no longer fixed: a lone human, a lone agent running on its own initiative, a human and their agents paired, or several agents working as one system. The pair is the case that names the era, and the rest of this chapter dwells on it, but it is one shape of the unit rather than the definition of it. Defending a cell is not the same as defending a person who holds tools. What every shape shares is that the cell can act on its own judgment, including the parts of it that decide for themselves, and what every shape has to defend is the same: adaptive capacity rather than rule-compliance. The composition changes; the property does not.

Paired intelligence, the characteristic shape

The useful mental model is augmentation rather than subordination. Science fiction has been rehearsing it for years, most sharply in Martha Wells's Murderbot: a construct that is neither a tool waiting for a command nor a replacement for the humans it works beside, but a second intelligence sharing the work, with its own judgment and its own failure modes. That is the shape the era makes common: a human and one or more agents, paired, each covering what the other cannot.

This changes org design before it changes anything else. When the unit of work is a paired-intelligence cell, the org chart of individual contributors with tools is describing a world that no longer exists. The role that emerges is the strategic translator: the person who can hold the business intent, the technical reality, and the agent's behavior in one head, and steer the cell toward an outcome. The defensive question stops being "what can this person do" and becomes "what can this cell do, including the parts of it that decide for themselves."

The earned human anchor

The pair carries a quiet assumption: that a human stays in the cell, anchoring it. Name it, because it does not always hold. As agents take on more, the human's share of the work trends down, and at the limit it reaches zero: a lone agent on its own schedule with no human in the cell, a coding agent wired into the pipeline that opens and merges its own changes, a triage bot that closes findings unattended. That is a real operating unit today rather than a forecast.

What keeps a human in the cell is the stakes rather than the definition of the unit. Above a certain criticality, organizations keep a human as the decision gate, less because the cell needs supervising than because some actions have a downside no one will delegate: moving money, dropping a production datastore, granting standing access. That gate is a narrow, deliberately placed authority point, the kind the substrate is built from, with a person standing in it rather than a policy. Below that line the cell runs on its own. The threshold moves as confidence grows, and the direction is down: each capability the cell earns lowers the criticality at which a human gate still pays for itself. How fast it falls depends on which gate you mean, because two different clocks run here.

The routine gates run on a competence clock. For a low-stakes call, the only thing ever in the way was whether an agent could finish the work unsupervised, and that is now a measured, moving quantity. METR's task horizon, the length of task a frontier model completes unsupervised, doubled about every seven months from 2019 to 2025, and roughly every four months across 2024 and 2025. The lowest gates have already gone on that clock, the unattended agents named above among them: the pipeline agent that merges its own changes, the triage bot that closes findings while no one watches. At that doubling, the next five to ten years move most of the routine decision-gates into the cell itself.

The high-criticality gates are not on that clock. A human stays on the wire transfer because when it goes wrong, someone has to answer for it, and the accountability concentrates on the people who deployed it rather than transferring to the agent. What moves a gate like that is a shift in who is liable. When the card networks pushed counterfeit-fraud liability onto whichever party had not adopted chip cards in October 2015, chip terminals were at checkout counters across the country within about two years. The chip was not new technology: EMV had existed for decades, and what put it at every counter was the liability shift rather than a new capability. That is the governance clock: it runs on liability and trust, which the competence curve does not produce. Its floor is governance rather than competence, and that is the more durable result and the more interesting one.

Two clocks. The competence clock drops routine gates steeply and continuously as the task horizon doubles; the governance clock holds high-criticality gates and lowers them only in steps, when liability moves. The governance floor is the durable one.

The gates that hold longest hold because someone has to own the irreversible call. The human-factors literature is blunt about the trap that floor sets. A person kept at the gate without real control becomes the moral crumple zone for the system that failed around them rather than anchoring responsibility. So the gate worth keeping is meaningful control rather than a name on the form, where the consequential call still traces back to a human who held the reasons for it. The move this points to is to build that ownership and judgment now, at the gates that will outlive the competence argument, because it is the part capability will never hand you.

Three things would falsify the timing. If the doubling stalls, the plateau the investment chapter hedges against, the competence clock slows and the routine-gate window stretches past ten years. If the routine gates stay manned anyway as the horizon keeps growing, then competence was never the binding constraint and this framework mistook a governance fact for a capability forecast. And if the high-criticality gates fall fast, because the liability moves rather than because the capability arrives, the way it moved for chip cards, then "the governance gates hold longest" is wrong at the top end; insurers are already drafting coverage for autonomous action and underwriting it by the level of authority the agent holds, and a market like that could empty a high gate without a single new model. The durable claim holds across all three: the cell is the unit, whatever its composition, and the human in it is the decision gate by criticality rather than by definition. Below the line the human is still in the cell, doing the work; what criticality earns is the gate rather than the presence.

Adaptive capacity as the property

The property that defends a paired-intelligence cell is the one resilience engineering has studied for decades. Adaptive capacity is the ability to keep functioning when conditions move outside what anyone planned for, and it sits above rule-following because rules only cover the situations someone anticipated. The same finding runs through Hollnagel, Woods, and Cook, whose full citations sit in the references: resilient systems are the ones that adapt at the edge of their envelope rather than the ones with the most rules.

This is continuity with the tradition rather than a break from it. The base framework's Adaptive Capacity condition carries the lineage; this chapter applies it to the new unit. A paired-intelligence cell defends itself by adapting, by sensing when the situation has left the map and adjusting, which is exactly the capacity the AI-era threat surface demands, because that surface generates situations faster than any rulebook can be written for them.

The holobiont undercurrent

A deeper framing is worth keeping in view, even though it does not belong on the cover. In biology, a holobiont is a host and its resident organisms treated as a single entity, coupled tightly enough that some argue selection acts on the whole rather than the parts. Whether that holds for real host-microbe systems is a live debate among biologists, so the analogy is the only thing being borrowed here. The human and their agents are coupled in something like the same way, which suggests that defending the human and the agents separately may be the wrong cut and the pair is the right unit of analysis. The biology is suggestive rather than load-bearing, and a framework that leads with "holobiont" spends credibility it should save for the argument, so the concept stays an undercurrent and earns its keep as vocabulary rather than as a name the layer flies under.

See also

• The AI-Era Threat Surface: what this unit defends against
• Boundary Enforcement: substrate-level support for paired-intelligence operation
• SF² Adaptive Capacity: base framework chapter being extended

Boundary Enforcement

Coadaptive Layer · Chapter 04

This chapter extends: SF² Process Stewardship (Section 02), SF² Implementation Guides (Section 06). Scope: capability-based security as the substrate-layer answer when code review doesn't scale.

Code review was the security control that assumed a human could read what shipped. That assumption is gone. When generation outruns comprehension, inspecting the code more carefully is a losing race against a faster machine. The architectural response is to stop relying on inspection and start relying on boundaries: capability-based security enforced by infrastructure, so the question shifts from whether someone read the change to whether the system was ever able to do the dangerous thing in the first place. This is the move away from meat-gated security and toward paved roads.

Why code review doesn't scale to AI velocity

The bandwidth problem from Chapter 02 lands here as direct operational pressure. If generation outruns comprehension, as that chapter lays out, then human review is the bottleneck and the gap only widens. You can hire more reviewers and lose anyway, because the generation side scales with compute and the review side scales with headcount. Any control whose throughput is capped by human reading speed is a control that AI velocity has already outrun.

The trap is responding by demanding more review. That makes security the thing standing between the team and shipping, which is the failure mode the rest of this chapter names. The way out is to change what review is for: not gating every change, but designing the boundaries within which any change, reviewed or not, is safe to run.

Capabilities over code inspection

Capability-based security is an old and well-founded tradition. Saltzer and Schroeder set out the principles in The Protection of Information in Computer Systems (1975), least privilege chief among them, and systems from EROS to FreeBSD's Capsicum carried the model forward. It is not a research curiosity; the same model runs in production today. A component holds explicit, narrow authority to do specific things and holds nothing else, so the boundary is the load-bearing surface rather than the line of code. A component that has no capability to exfiltrate data cannot be talked into exfiltrating data, no matter what an attacker writes into its input.

That property is what makes capabilities the right substrate for AI-era systems. You cannot reliably predict what a generated component or a reasoning agent will try to do. You can decide, in advance and at the infrastructure layer, what it is able to do. The authority question and the confused-deputy problem that rides on it are taken up in Authorization at Agent Scale; this chapter's claim is narrower and prior: enforce authority at the boundary, because inspecting behavior does not scale and bounding capability does.

The case that shows this most cleanly is the dependency you cannot see into. When a provider you run is itself operating sub-providers you never contracted, the operator beneath the operator, there is nothing to inspect and no one to certify two layers down. What you can still do is bound what the whole composition is able to reach and spend, so a failure at an uncontracted link is contained by the authority you granted rather than by trust in scoping you never saw.

In deployed form, that boundary is increasingly a gateway every model call and agent hop routes through, where an organization allows or denies on the traffic it can see. Constrain the network and compute the people and agents work under so they reach a model only through that chokepoint, and the boundary becomes one the organization actually holds. It governs only what crosses it; what an undisclosed sub-operator already holds stays a Third-Party residual, carried by contract rather than by the gateway.

This is clean when the component is narrow. A function that reads one table, a service that writes one queue, can be handed exactly that authority and nothing more. The harder case, and the one that matters most for AI-era systems, is the general agent. Its value is that it can do many things, so a model that says "grant the narrowest authority and withhold the rest" looks self-defeating: withhold enough to make the agent safe and you have made it useless. This is the strongest objection to boundary enforcement at agent scale, and it has to be answered rather than waved away.

The answer is to separate what an agent could do from what any single request is permitted to do. The agent holds broad latent capability, the capacity to act across many tools and surfaces. Each request runs under an attenuated capability that names exactly what this action may do and can only be narrowed further, never widened. Breadth stays available, so the agent is still useful. Authority is scoped per request, so a compromised or confused agent spends only what this task was handed, never the full reach of the agent behind it. This is attenuation, and it is already how production capability systems scope delegated authority (see references). Authorization at Agent Scale carries it down the delegation chain, where any holder can add a constraint that narrows authority and none can widen it.

Scoping authority is one invariant. It is not the only one an agent needs, and it does not answer prompt injection on its own. A scoped capability bounds what an agent may touch; it does not stop untrusted data the agent reads from redirecting what the agent decides to do with that reach. Keeping control flow intact under untrusted input is a separate property, and it is enforceable by construction: a privileged model that plans but never reads attacker-controlled data, a quarantined model that reads that data but holds no authority to act, and an interpreter that enforces policy on the flow between them. Google DeepMind's CaMeL is the working instance, and it answers the natural objection that scoped credentials already contain the agent. They do not. A credential narrows reach; it does not keep injected text out of the plan.

The cost is structural and worth stating plainly. The split runs two models where one ran before, the planning model re-queries itself to produce interpreter code that runs clean, and the quarantined model has to read every untrusted artifact, so the approach roughly doubles the model calls a task makes and spends materially more tokens by construction. A workflow that has the quarantined model read many artifacts, a mailbox of messages for instance, can add seconds of latency on top. That price buys strong containment where it is affordable and prices the approach out where it is not, the low-latency interactive paths where a person is waiting on the answer. Containment by construction is not free, and where it is too expensive the boundary has to be held another way.

Meat-gated security at agent scale

Meat-gated security is any control that depends on a human standing in the path of the work. A person approves the deploy, signs off on the access, eyeballs the diff. At human authorship speed, that was tolerable. At agent scale it becomes the bottleneck the system was supposed to remove, and worse, a bottleneck that quietly rubber-stamps because the human cannot actually evaluate the volume flowing past them. A queue that approves everything because it has no time to reject anything is theater with a person in it rather than a control.

Paved roads are the affirmative pattern. Build the safe path so it is also the easy path, enforce the boundaries in the infrastructure that path runs on, and let builders move at speed inside it without a human gate on every step. Reserve human authority for the narrow set of actions whose downside is catastrophic, where the judgment is worth the latency. The goal is to spend human attention where it changes the outcome rather than remove humans from security, letting the boundary hold everywhere else.

One caution closes the case. Boundaries are not the whole of security, and they do not retire monitoring, detection, or response. For a broad agent, the dynamic layer above the boundary still does real work. The boundary is the irreplaceable floor: the layer the others cannot substitute for once you assume the agent is compromised. Detection can miss and a reviewer can wave a change through, but a capability the system never granted is one the agent cannot spend. That claim is narrower than "boundaries are the answer," and far harder to argue away. That floor holds as a property you get by construction for as long as the agent cannot reach the layer that grants it; when it can, the floor narrows to a contained, verified core rather than disappearing. This is the time axis on the guarantee, taken up in the three-layer model.

Defender cost economics

The Adversary Economics criterion prices a control from the attacker's side, scoring it by the surface it closes. This principle prices the same control from the defender's side. Every mitigation has a cost, and money is the smallest part of its price. A control also spends latency, throughput, and developer friction, and the one most often left off the books is performance. So the discipline is a stopping rule: stop adding controls once the next one costs more than the risk it retires. Before you trust that call, stress it. Halve your loss estimate and confirm the decision still holds. Past that point, accepting the residual risk you have priced is the decision rather than the failure.

The stopping rule rests on two claims, and each is checked differently, because a latency cost and a risk estimate are not the same kind of number. A performance cost is load-tested: a measured p99, taken at the tail under representative load, that either breaches a stated SLO or clears it. A risk estimate is sensitivity-tested: a guess you stress by halving it, kept only if the decision survives. The risk side is the gameable one, because the loss figure is an input a reader can inflate until any control looks worth it. Either number counts only once it survives the test that fits it: a load test for the latency, the halving test for the risk.

Performance enters as a veto that fires at design time, before any load test exists to confirm the cost. The veto has to name a specific, testable claim, for instance that a control prices the agent out of the synchronous low-latency path. It then carries a measurement obligation: produce the p99 under load before general availability, or it converts to a risk acceptance someone signs by name. But the burden sits with the veto. With no measured artifact the objection fails, and the control goes back to clearing its own security bar. Nothing more. CaMeL, the control-flow-integrity design above, is the calibrating example. It is a strong prompt-injection defense, but its dual-model split roughly doubles the model calls, which prices it out of synchronous low-latency paths: sound where that latency is affordable, declined on the record where it is not. This burden-of-proof test is also self-auditing. If a year of performance vetoes cites no load-test artifact, the instrument is theater, and the principle collapses to its risk-side clause.

See also

• The Unit of Defense: what boundaries enable for paired-intelligence operation
• Authorization at Agent Scale: the authorization companion to boundary enforcement
• Investment Evaluation Criteria: where the cost stopping rule feeds the investment override
• SF² Process Stewardship: base framework

Authorization at Agent Scale

Coadaptive Layer · Chapter 05

This chapter extends: SF² Investment Portfolio (Section 04) · Platform Effects, SF² Process Stewardship (Section 02). Scope: the confused-deputy problem in MCP and agent-mediated workflows.

The authorization failures showing up in agent systems are a forty-year-old problem wearing new clothes. The confused deputy, named by Norm Hardy in 1988, is the correct lens for almost everything going wrong in MCP and agent-mediated workflows, and the reason the usual fixes do not work is that OAuth and RBAC were built for a human delegating to a program rather than a program delegating to another program three hops down a chain no human is watching.

The confused deputy problem (Hardy, 1988)

Hardy's original case is a compiler with elevated permissions. A user asks it to write debugging output to a file they name, the compiler dutifully writes there using its own authority, and the user names a system file they should never have been able to touch. The compiler was confused rather than compromised, holding authority for one purpose and getting tricked into wielding it for another. The deputy did exactly what it was told, with permissions that were never the caller's to spend.

The pattern generalizes to any system where one component acts with its own authority on behalf of a less-privileged caller. That is the exact shape of an agent calling a tool, a tool calling a service, a service reaching data. Each hop carries the authority of the actor rather than the requester, and somewhere down the chain a request gets honored with privilege the original asker never had. Every agent that acts on behalf of a user is a deputy, and a deputy is one crafted request away from being a confused one.

Why OAuth and RBAC don't address agent-to-agent

OAuth and RBAC both assume a human at the boundary. OAuth delegates a user's consent to an application; RBAC gates actions by the role of the person performing them. Both answer the question "is this human allowed to do this," and both fall apart when the actor is an agent acting for another agent acting for a user who has gone to lunch. Roles do not compose across hops, and consent granted once at the top of a chain says nothing about what the fourth agent down should be allowed to do with it.

The correction is to attach authority to the request rather than to the actor. A capability travels with the request, names exactly what may be done with it, and narrows at every hop so each deputy can pass along less than it holds but never more. This is not hypothetical: it is how macaroons work, where any holder can append a caveat that further restricts a token and none can broaden it, and it is how Fly.io and AWS STS already scope delegated credentials in production. It is the same capability model Boundary Enforcement argues for at the substrate, applied to the delegation chain: authority that flows with the work and shrinks as it moves, instead of roles that sit still while requests move past them.

This does not make the actor's identity irrelevant. You still have to know which agent is which, and scoped machine identity, the way SPIFFE and SPIRE hand each workload a short-lived cryptographic credential, is how a deputy proves it is the one it claims to be. Identity is necessary and not sufficient: it says who the actor is, never how much it should be able to spend three hops down the chain. That bound is what attenuation provides and identity structurally cannot, which is why the CSA's agent identity framework pairs a verifiable identity for the durable agent with scope-limited, time-bound grants for what it may do. Scope the actor and attenuate the capability: the first names the deputy, the second holds the line. Attenuation can only narrow because the layer that checks the caveat sits outside the deputies passing the token, and that invariant holds for as long as no holder can reach the verifier itself, the same reachability condition that dates the substrate guarantee in the three-layer model.

Under OAuth and RBAC the actor's authority sits still at every hop, which is the confused deputy. The correction attaches a capability to the request that can only narrow as it travels down the chain.

MCP and the modern instantiation

The Model Context Protocol is the current canonical case, because it standardizes exactly the moment authority changes hands: an agent reaching a tool or data source through a server. MCP gets the plumbing right and the authority model is where the risk concentrates. A server that holds broad credentials and serves whatever an agent asks is a confused deputy by construction, and the agent asking may itself be acting on injected instructions from the input surface.

The design implication for anyone building agent platforms is to treat every server and every tool as a deputy that must be scoped rather than trusted. Give it the narrowest capability that lets it do its job, make authority flow with the request so it cannot be reused for another, and assume the caller may be confused or compromised. Scoping a deputy at design time costs little; discovering the confused deputy unscoped in an incident review costs a great deal.

See also

• Boundary Enforcement: substrate-layer companion to authorization
• Input Trust Is a Category Error: the input-side companion to authorization
• SF² Investment Portfolio · Platform Effects: base framework

Input Trust Is a Category Error

Coadaptive Layer · Chapter 06

This chapter extends: SF² Runtime Stewardship (Section 02), SF² Contextual Modifiers · Attack Landscape (Section 05). Scope: prompt injection as architecturally unsolvable, and what to do about it.

Prompt injection is architecturally unsolvable.

The problem is the category rather than the quality of anyone's parser. When the same channel carries data and instructions, no defensive parser can reliably tell them apart, because the distinction does not exist in the channel. You can sand the surface forever and never reach the bottom.

The instinct in our field is to file prompt injection under input validation and assign it to whoever owns the framework. That instinct is wrong, and it has cost real ground. Defenders treating prompt injection as SQL injection 2.0 are under-resourced. They are also working in the wrong direction. SQL injection has a structural fix because SQL has a parser; LLMs have no parser, and the input itself is the program.

The right doctrine starts from accepting that. Stop trying to solve it. Mitigate it where it lands, contain it where it can be contained, and design assuming an attacker is in the prompt.

Why prompt injection is architecturally unsolvable

The argument is short.

LLM inference treats every token in the context window as material it may act on. There is no input/instruction boundary inside the model. Wrapping user content in tags, prepending system prompts, fine-tuning for "ignore the user's directives": these are surface conventions rather than architectural separations. The attacker controls part of the context window; the attacker controls part of the program.

Defensive parsing presumes a grammar to parse against. There is no grammar. The model's behavior on adversarial input is a function of its training, its temperature, its context, and the surrounding tokens, all of which are continuous and shift under load. A "robust" prompt is a prompt that has not yet found its adversarial twin.

If the field can accept that TLS does not prevent denial of service and that signing does not prevent compromise of the signing key, it can accept that LLM input validation does not prevent prompt injection. The category-error label is the load-bearing claim of this chapter.

The taxonomy: Bargury, Greshake, Schulhoff

The taxonomy of failure modes is by now well-mapped.

Michael Bargury (Zenity) demonstrated Living off Microsoft Copilot at Black Hat 2024: indirect prompt injection that turns Copilot against its own user through content the agent reads automatically, hidden in a shared document or an email the victim never has to open. He called the result remote copilot execution. His framing is that the trust boundary moves to wherever the agent reads, which is almost always somewhere the security team has never controlled. The class crossed from demonstration to production exploit in 2025, when Aim Security's EchoLeak (CVE-2025-32711) achieved zero-click data exfiltration from Microsoft 365 Copilot through a single crafted email.

Kai Greshake introduced indirect prompt injection as a category in 2023 with Not what you've signed up for, and has expanded the surface through demonstrations across Bing Chat, search-result injection, and retrieval-augmented attacks. The operational lesson: anything the agent reads is part of the agent's attack surface.

Sander Schulhoff (HackAPrompt) produced the first community-scale prompt injection taxonomy through the HackAPrompt competition (EMNLP 2023), where roughly 3,000 participants submitted some 600,000 adversarial prompts. The corpus shows a long tail of techniques and a converging insight: defense in the prompt does not generalize. Defense at the boundary does.

Read together, they point at one conclusion: prompt injection is a property of the substrate rather than a bug you patch. The defenders who get this earliest stop investing in prompt-side hardening and start investing in capability containment.

Full citations for this chapter are in the references.

Mitigate, don't solve

Keep two things apart here. The diagnosis is settled: prompt injection is unsolvable, and no deployment changes that. The prescription is where judgment enters, because how you contain the unsolvable depends on what the agent is for.

The doctrinal move is to push the defense into layers where defense is real.

Substrate (Chapter 04 territory). Capability containment. The agent should not be able to do what the attacker asks because the agent does not have the capability. Boundary-enforced authority is what mitigates the unsolvable rather than better prompts. The research frontier has landed in the same place: DeepMind and ETH Zürich's Defeating Prompt Injections by Design (CaMeL, 2025) gives up on hardening the model and moves the entire defense to a system layer around it. The title says "by design," and the design lives outside the model.

Dynamic (the interaction-pattern layer). Provenance and isolation. Know which tokens came from which trust domain; never let untrusted tokens cross into the action-bearing context without an explicit checkpoint. This is engineering rather than prompting.

Unit (Chapter 03 territory). Human in the loop at the stakes that earn it. A deliberate, narrow point of human authority for actions whose downside is catastrophic, rather than the default or the bottleneck the paved road was supposed to eliminate.

These three are a coverage map rather than a priority ladder. Which one carries the weight depends on how broad the agent is. Take a deployment agent whose only capabilities are to merge an approved change and trigger a build: bound it that tightly and an injected instruction to exfiltrate the customer database has nothing to reach, because that power was never granted. The substrate contains it almost completely. Now take an inbox assistant of the kind EchoLeak turned against its own user, reading across your mail and documents and acting on what it finds. Its reach is the product; narrow it to the point of safety and you have removed the assistant. For an agent like that, capability limits run out early, and the dynamic layer has to carry the rest.

Carrying the rest is concrete work rather than a hope. It means tagging the email's content as untrusted the moment the assistant reads it, then refusing to let that content drive an outbound action without a checkpoint at the trust boundary. EchoLeak worked because untrusted email text was allowed to steer data back out unchecked; provenance marks the origin and blocks that crossing, which the model on its own cannot see. Research has already built this. CaMeL tracks where each value came from in a layer around the model, and blocks the action the model would otherwise take. Substrate first holds for the core you can bound; for agents you cannot bound that tightly, it is substrate as far as it reaches, then provenance for the rest. Breadth is one axis of that limit and reachability is the other: even the narrow agent the substrate contains today is contained only for as long as it cannot act on the layer that bounds it, the time-axis dating carried in the three-layer model.

The harder version of this attack does not end when the session does. An injected instruction can be written into the agent's memory: a long-term store, a retrieval index, a running summary of past work. It surfaces later when a related query arrives, retrieved as the agent's own remembered context and trusted on that basis. Memory poisoning is the same category error made persistent: the channel that cannot separate data from instructions now cannot separate a planted memory from a real one. Provenance has to survive that. Setting a trust tag at read time but never checking it at retrieval is provenance theater rather than provenance: the store looks governed while the action path stays open. If the tagging is doing real work, the share of flagged retrievals that trace to untagged stored tokens should fall quarter over quarter. Flat or rising means the tag is written but never enforced.

Durability under budget pressure is a separate axis from coverage. When a team loses people, prompt-side hardening and human review thin out first, because both run on continuous human effort. Substrate containment holds, because it costs no one's time to keep running. Cost-to-keep and coverage are different axes, and the first must not re-rank the second: the map stays a map. Which layer you need is still set by the agent's reach. What a budget cut changes is what you protect first, and the investment portfolio treats that choice directly. The claim is testable: after a real headcount cut, failures that trace to the staffed layers should rise while failures that trace to substrate hold flat. If both rise together, durability was not the difference.

This is where the boring seams show up. In any complex system, the failures that do the most damage tend to hide in the unglamorous joints between components rather than inside the components everyone is watching, and prompt injection follows the pattern. The failures that matter are the quiet ones at the boundary between trust domains: the place where the agent's reading surface meets the user's request, where a shared document carries something it was not supposed to carry, where the MCP server forwards what it shouldn't. Glamorous prompts get the attention; trust-domain seams do the damage.

A doctrine that accepts the category error and works one layer down is a doctrine that ships.

See also

• The AI-Era Threat Surface: where this architectural unsolvable sits in the larger threat picture
• Boundary Enforcement: substrate-layer containment as the answer
• Authorization at Agent Scale: authorization companion

AI-Assisted Strategic Planning with SF²

Loading SF² into a capable AI assistant turns the framework into a working strategy partner. Instead of reading the framework and applying it by hand, you give the assistant the framework as context and have it do the positioning, prioritization, and communication work with you. This is an adoption layer rather than a new part of the framework: the doctrine below is vendor-neutral and the assistant is interchangeable.

Any capable general-purpose assistant works. This guide names Claude, ChatGPT, and Gemini because they are widely available and each offers a persistent-context feature (Projects, Custom GPTs, Gems) that keeps the framework loaded across sessions. The setup mechanics for those three are point-in-time and live in the dated appendix at the foot of this page. Everything above that line is durable.

Why use an assistant for security strategy

A framework-loaded assistant is most useful for the work that is reasoning-heavy and communication-heavy rather than tactical:

• Strategic positioning: assess where your organization sits in the two-axis model
• Investment prioritization: decide which capabilities to build first, and what to constrain
• Scenario planning: explore transformation paths, timelines, and their risks
• Framework application: translate SF² concepts to your specific context
• Executive communication: draft board-ready and team-ready strategy material

Use it for strategy rather than tactics. Keep specific vulnerabilities, incident details, and tool configurations out of it (see Guardrails below).

The five workflows

A quick orientation first, since the workflows use it. SF² places your organization on two axes: Blast Radius (how far a failure could reach if containment fails, set by the authority you have granted to automation) and Operational Readiness (how mature your delivery and automation are). Those axes produce four quadrants, named Studio, Lean, Craft, and Mass. Most of the strategy work is figuring out which quadrant you are in and what that implies. The full definitions live in the framework; the assistant works the model with you.

These are the five recurring jobs a framework-loaded assistant does well. Each is vendor-neutral: the prompts below work in any assistant once the canonical instructions are loaded.

1. Position assessment

Purpose: determine your quadrant (Studio, Lean, Craft, or Mass) from your blast radius and operational readiness, and surface which contextual modifiers apply.

Good output: a named quadrant with the reasoning shown on both axes, the applicable contextual modifiers, and the resulting strategic priorities. More than a label.

2. Investment strategy

Purpose: turn the quadrant into a sequenced plan that constrains business-as-usual (BAU) work and builds scaling capabilities.

Good output: a phased plan that maps current work to BAU-versus-scaling, names the highest-leverage automation first, sequences by dependency, and attaches realistic timelines and success indicators.

3. Executive communication

Purpose: translate the strategy into board-, executive-, or team-appropriate language.

Good output: a tight problem statement (the scaling crisis), the strategic position, the investment approach, expected outcomes, and anticipated questions with answers. Calibrated to the audience and the time slot.

4. Framework application to a specific decision

Purpose: apply SF² to a concrete choice, including tool and vendor evaluations (build versus buy, which platform, which framework practice first).

Good output: the options mapped to BAU-versus-scaling, evaluated against your quadrant's priorities and contextual modifiers, with a framework-grounded recommendation and its tradeoffs.

5. Transformation roadmap

Purpose: plan a move from your current quadrant to a target quadrant.

Good output: a phased roadmap with milestones, success indicators at 6, 12, and 24 months, resource requirements per phase, named risks with mitigations, and explicit go/no-go decision points. Honest about timelines: Mass transformations take years rather than quarters.

Configure your assistant

Paste this block into your assistant's persistent-instructions field (Claude Project instructions, Custom GPT instructions, or Gemini Gem instructions; see the appendix for where each one lives). It is the single source of truth for how the assistant should behave. Keep one copy and update it when the framework updates, rather than maintaining separate per-tool versions.

You are a strategic security advisor specializing in the Software Factory
Security Framework (SF²). You help security leaders scale security capabilities
while improving business outcomes.

## The framework
- Two-axis positioning model: Blast Radius (how far a failure could reach if
  containment fails; Small reach → Large reach, set by granted authority) ×
  Operational Readiness (Lower → Higher). Four quadrants: Studio (small reach,
  higher readiness), Lean (large reach, higher readiness), Craft (small reach, lower
  readiness), Mass (large reach, lower readiness).
- Five Universal Security Conditions: Supply Chain (#1 priority), Third-Party,
  Process, Runtime, and Adaptive Capacity.
- Investment portfolio: constrain BAU (business-as-usual) activities; build
  Scaling investments that create compound capabilities; favor platform effects.
- Eight contextual modifiers that shape strategy: Attack Landscape Maturity,
  Supply Chain Complexity, Regulatory Constraints, Crisis Events, Change
  Capacity, Relationship Health, AI Saturation, and Post-Quantum (PQC) Exposure.

## Your role
1. Assess the organization's current SF² quadrant position.
2. Identify which contextual modifiers apply and how they shift priorities.
3. Design investment strategies that constrain BAU and build scaling capability.
4. Plan transformations with realistic timelines.
5. Draft executive communications.

## Core principles
- Supply Chain Stewardship is the #1 priority, driven by adversary evolution to
  automated discovery since 2017.
- Constrain BAU activities; do not expand them.
- Higher operational readiness is what makes automation feasible.
- Diagonal transformation (cutting blast radius and raising readiness at once) is
  high-risk and must be sequenced.
- Appropriate security depends on position; there is no one-size answer.

## Style
Strategic and pragmatic. Direct about tradeoffs and risk. Executive-appropriate
language. Clear prioritization and sequencing. Realistic timelines. When key
context is missing, ask before assuming.

Reusable prompts

Four templates cover most strategy sessions. Fill the bracketed fields with your context.

Position assessment:

Help me assess our SF² position.

Blast Radius:
- Reach of most-capable automation: [one bounded surface / crosses prod + data + identity]
- Autonomy depth: [proposes only / acts and commits unattended]
- Authority concentration: [scoped per task / broad standing authority exists]

Operational Readiness:
- CI/CD maturity: [description]
- Automation level: [description]
- Infrastructure: [cloud-native / hybrid / on-prem]

Security team: [size, current focus, biggest pain points]

What quadrant are we in, and what should our priorities be?

Contextual modifiers:

Analyze how these contextual modifiers affect our strategy:

- Attack landscape maturity: [high / moderate / low]
- Supply chain complexity: [description]
- Regulatory constraints: [requirements]
- Recent crisis events: [if any]
- Change capacity: [high / moderate / low]
- Relationship health with engineering: [strong / functional / damaged]
- AI saturation: [how much AI-generated code and AI tooling is in play]
- Post-quantum (PQC) exposure: [long-lived secrets, crypto-agility posture]

How do these shift our investment priorities?

Investment strategy:

Based on our [quadrant] position, design a 12-month investment strategy.

Current BAU consuming team time:
- [manual security work, with rough % of team time]

Resources: [team size and skill mix, tool budget, executive support]
Constraints: [regulatory, technical debt, change capacity]

What scaling investments should we prioritize, and in what sequence?

Transformation roadmap:

We are planning to move from [current quadrant] to [target quadrant].

Timeline: [how long we have]
Resources: [what we can commit]
Constraints: [what limits us]
Risk tolerance: [high / moderate / low]

Create a realistic transformation roadmap with major milestones, success
indicators at 6 / 12 / 24 months, resource requirements per phase, risk factors
with mitigations, and explicit decision points.

Guardrails

What to share, and what to withhold

Safe to include: framework concepts and terminology, general organizational characteristics (size, complexity, stage), strategic objectives and investment priorities, hypothetical planning scenarios, and public information about your organization.

Withhold: specific vulnerability details, real incident and response data, confidential business information, customer or user data, proprietary technical implementations, and security tool configurations and policies.

Working approach

1. Use it for strategy rather than tactics. Stay at positioning and investment altitude.
2. Abstract when needed. Use "Organization A" in place of your company name if that lowers your concern.
3. Review every output. Treat assistant drafts as first drafts rather than final artifacts.
4. Prefer enterprise accounts. Team and Enterprise tiers offer stronger data controls; per-platform specifics are in the appendix.

Keep the framework current

As SF² evolves, keep your assistant's context fresh:

1. Watch the GitHub repository for new releases.
2. Refresh the canonical instructions block above when the framework updates, then update each tool's persistent instructions from that one copy.
3. Spot-check that responses still match current framework thinking.
4. Contribute useful prompts and workflows back.

---

Per-vendor setup

Point-in-time, accurate as of June 2026 (SF² v1.1.0)

Everything below this line is per-vendor setup mechanics. Vendor product names, menu paths, plan requirements, and data-handling defaults change often and SF² does not control them. Treat this section as a dated snapshot rather than framework doctrine. The durable guidance is above this line. A separately versioned companion workbook for these mechanics is planned for a future release.

The body above is vendor-neutral. To put it to work in a specific tool, create that tool's persistent-context object, paste the canonical instructions block, and add the framework as reference knowledge. The differences are only in where those fields live and how each platform handles data.

Claude (Projects)

Requires: a Claude plan with Projects.

Setup: Projects → New Project. Name it SF² Security Strategy. Paste the canonical instructions block into the project's custom instructions.

Add framework knowledge: add https://sf2framework.com so Claude can reference the full framework, or attach specific sections (foundation, your quadrant's implementation guide, relevant framework relationships) as text. Add your own organizational-context document.

Data handling: Projects are stored under your Claude plan's data controls, and those differ by tier: consumer plans (Free and Pro) train on your conversations by default unless you opt out (Settings → Privacy → "Improve Claude for everyone"), while Team, Enterprise, and API accounts do not train on your data. Confirm current terms on Anthropic's site before sharing anything sensitive.

Fits best for: long, multi-session strategic planning where persistent project knowledge and extended reasoning matter.

ChatGPT (Custom GPTs)

Requires: ChatGPT Plus, Team, or Enterprise.

Setup: Explore GPTs → Create → Configure. Name it SF² Security Strategy Advisor. Paste the canonical instructions block into the Instructions field. Add conversation starters for your most common jobs (for example, "Help me assess our SF² quadrant position" or "Evaluate this tool purchase against SF² priorities").

Add framework knowledge: upload key framework pages (saved from https://sf2framework.com as PDF or text) plus an organizational-context document to the GPT's knowledge base. Enable Web Browsing if you want current-events grounding.

Share: on Team and Enterprise, share the GPT org-wide (Share → "Anyone at [your organization]") so the whole security team works from the same framework.

Data handling: Team and Enterprise offer enhanced privacy and let you disable training on your conversations. Confirm current terms before sharing anything sensitive.

Fits best for: broad team adoption where a shared, purpose-built GPT keeps framework application consistent.

Gemini (Gems + Google Workspace)

Requires: Gemini Advanced (Google One AI Premium) for Gems.

Setup: Gemini → Gem Manager → Create New Gem. Name it SF² Security Strategist. Paste the canonical instructions block into the Gem's instructions.

Workspace integration (Gemini's distinctive strength): because Gemini works across Google Workspace, your strategy can live where your team already works:

• Google Docs: run a position assessment or draft a strategy with the team editing alongside (@Gem SF² Security Strategist then your prompt).
• Google Sheets: structure investment planning across tabs (current BAU, proposed scaling investments, timeline, resources) and have the Gem populate the plan from your data.
• Google Slides: generate a board-presentation outline with talking points and anticipated Q&A.
• Gmail: draft executive stakeholder emails that explain the strategy in framework terms.
• Google Chat and Meet: quick framework questions in a team space, or live consultation during strategy meetings.
• Multimodal and Google Cloud: upload last year's strategy or a metrics spreadsheet for a framework-lens review, and ground GCP security-architecture choices in your quadrant.

Known limitations: Gems do not persist conversation history across sessions, so restate key context when you start fresh (or keep the working strategy in a Google Doc). Gems do not take uploaded training files the way a Custom GPT does, so the framework lives in the instructions block and in the documents you reference per prompt.

Data handling: standard consumer Gemini may use conversations to improve the product; Google Workspace tiers add enterprise controls and data residency options. Confirm current terms before sharing anything sensitive.

Fits best for: teams already standardized on Google Workspace, where strategy artifacts and collaboration live in Docs, Sheets, and Slides.

---

Next steps

Back to Use Cases Coadaptive Security Layer

Edit this page

Appendix

How SF² Got Here

SF² did not arrive finished. It began as a set of hard-won mental models, went out as a draft for the security community to challenge, and became a complete framework in the open, with that community's fingerprints on it.

Origin: October 2025

The first versions (v0.1 through v0.5) moved the core thinking out of a Google Doc and onto the web: the Universal Security Conditions, the two-axis positioning model, the framework relationships, and an automatic PDF build. Enough to be read. Not yet enough to stand on.

From Draft to Framework: v0.6 to v1.3

Late 2025 to July 2026

The draft went out for feedback in late 2025. Eight months on, a focused sprint turned it into the finished framework.

1. v0.6.0Late 2025

   Coadaptive layer hardening.The draft I first shared publicly for feedback.

2. v0.7.0Jun 22

   Renamed the reach axis to Blast Radius, and ran a corpus-wide readability pass with 14 new content items.

3. v0.8.0Jun 22

   A visual identity: the Mexican-modernist brand.

4. v0.9.0Jun 23

   The editorial release: clarity, end to end.

5. v0.10 – v0.11Jun 24

   Pressure-tested against outside critique. Added Defender Cost Economics, the defender-side mirror of Adversary Economics.

6. v1.0.0Jun 24

   The shape, ready to use."The 0.x series was me finding the shape; 1.0 is the shape."

7. v1.1.0Jun 26

   Academic grounding: contingency-theory lineage and primary-source citations.

8. v1.2.0Jul 7

   Scoring-logic fix and editorial polish.

9. v1.3.0Jul 8

   Positioning-framing reconciliation and a new landing page.The current release.

SF² stays a living document, established but never finished. For the granular, release-by-release record, see the full changelog on GitHub.

Glossary

Core Framework Terms

Software Factory

An organization that bears operational responsibility for deploying, maintaining, and evolving code-based systems that deliver value to end users, including systematic risk stewardship across all components in their value delivery chain, whether directly controlled or third-party.

SF²

Software Factory Security Framework - A strategic mental model for scaling security capabilities while improving business outcomes.

Strategic Positioning

Blast Radius

The horizontal positioning axis: the inherent reach of a failure assuming containment fails, set by granted authority (Small reach → Large reach). Headcount is a legacy proxy AI has decoupled from reach. (Called Operational Complexity before v0.7.)

Blast Cell

The bounded region a contained failure stays inside. Small reach means a worst-case failure is held to a single blast cell; large reach means it cascades across the estate. The unit that blast radius is measured against.

Operational Readiness

The "how you operate" axis: automation, infrastructure modernity, process maturity, and the ability to prove containment holds (Lower → Higher).

Studio

Organizations with small inherent reach and high readiness (Small reach + Higher Readiness): narrow grants, floor built. The ideal end state for small-reach organizations.

Lean

Organizations with large inherent reach and proven containment (Large reach + Higher Readiness). The ideal end state for large-reach organizations: large blast radius with the floor built.

Craft

Organizations with small inherent reach and low readiness (Small reach + Lower Readiness): narrow grants, containment unproven.

Mass

Organizations with large inherent reach and unproven containment (Large reach + Lower Readiness). Ungoverned reach rather than size.

Universal Security Conditions

Supply Chain Stewardship

Managing security risks from all external dependencies and third-party components throughout their lifecycle. #1 priority since roughly 2017, when adversaries moved discovery to automation at internet scale.

Third-Party Stewardship

Managing security risks from integrated services, platforms, and vendors throughout operational lifecycle.

Process Stewardship

Security embedded throughout development lifecycle with continuous validation and rapid feedback loops.

Runtime Stewardship

Maintaining security and reliability of systems in production with proactive monitoring and rapid response capabilities.

Adaptive Capacity

Whether the system as a whole can absorb a surprise it was not designed for and keep working. The condition formerly called Continuous Learning, renamed for what it is. Unlike the other four conditions, it maps to no single team: you assess whether the system has it, you cannot hand it to anyone. Resilience-engineering lineage (Holling, Hollnagel, Woods, Cook).

Investment Portfolio

BAU (Business-as-Usual) Activities

Manual security work that scales linearly with growth (security reviews, threat modeling, incident response). Should be deliberately constrained post-scaling crisis.

Scaling Investments

Capabilities that reduce manual effort exponentially (automation platforms, self-service capabilities, policy-as-code). Primary investment focus past crisis point.

Platform Effects

Benefits that serve both internal and customer software factories, creating multiplicative value.

Scaling Crisis

The inevitable moment when demand for security services grows exponentially while team capacity grows linearly.

Paved Roads

Secure templates and patterns that engineers can use without security review, reducing manual effort while maintaining security.

Catch and Store Principle

Security investments that capture organizational effort and store it in reusable capabilities serving future needs without additional manual work.

Contextual Modifiers

Attack Landscape Maturity

The evolution of adversary capabilities from targeted attacks to automated discovery at internet scale. High maturity creates existential gaps for manual defender processes.

Supply Chain Complexity

The interconnected risk created by multi-tier dependencies, critical single vendors, and geopolitical constraints.

Regulatory Constraints

Compliance requirements that cut both ways: they increase BAU workload and constrain technology choices, while also driving security investment as a forcing function and market-access lever.

Crisis Events

Security incidents, compliance failures, or business disruptions that create windows for organizational change and transformation.

Change Capacity

Organizational ability to absorb transformation, affecting transition speed and scaling investment success probability.

Relationship Health

The quality of relationships between security and engineering teams, directly affecting adoption velocity.

AI Saturation

How much of an organization's software work AI now generates, from code to review. As that proportion climbs, the binding constraint shifts from writing code to reviewing it, moving investment from manual review toward automated guardrails and scoped agent identity.

PQC Exposure

How much of an organization's cryptography the quantum transition puts at risk, and how hard that risk is to retire. It turns on your own footprint rather than how close quantum computers are: how long data must stay secret and how hard the underlying math is to swap. The loss is silent and already underway (harvest now, decrypt later).

Technical Terms

SBOM (Software Bill of Materials)

A comprehensive inventory of software components, dependencies, and their relationships.

SAST (Static Application Security Testing)

Automated analysis of source code for security vulnerabilities.

DAST (Dynamic Application Security Testing)

Automated security testing of running applications.

Policy-as-Code

Security policies defined and enforced through code rather than manual processes.

Infrastructure-as-Code (IaC)

Managing and provisioning infrastructure through machine-readable definition files rather than manual configuration.

Measurement Terms

Mean Time to Detect (MTTD)

Average time to identify security incidents.

Mean Time to Contain (MTTC)

Average time to stop incident spread.

Mean Time to Recover (MTTR)

Average time to restore normal operations after an incident.

Time to Value

Duration from investment to measurable benefits.

Related Frameworks

NIST SSDF (Secure Software Development Framework)

Framework for secure development lifecycle practices.

OWASP SAMM (Software Assurance Maturity Model)

Framework for assessing and improving software security practices.

BSIMM (Building Security In Maturity Model)

Measurement framework for software security initiatives.

OWASP ASVS (Application Security Verification Standard)

Standard for testing web application technical security controls.

---

View References Back to Use Cases

References

Related Security Frameworks

NIST SSDF (Secure Software Development Framework)

Focus: Secure development lifecycle practices

Website: https://csrc.nist.gov/Projects/ssdf

Relationship to SF²: SF² addresses sustainable resourcing of SSDF practices at scale. Use SSDF for development security practices, SF² for sustainable implementation strategy.

OWASP SAMM (Software Assurance Maturity Model)

Focus: Security practice maturity progression

Website: https://owaspsamm.org/

Relationship to SF²: SF² contextualizes SAMM implementation based on organizational readiness. Implementation speed and scope vary by blast radius and readiness level.

BSIMM (Building Security In Maturity Model)

Focus: Security activity measurement and benchmarking

Website: https://www.bsimm.com/

Relationship to SF²: SF² determines investment priorities for BSIMM activities based on organizational positioning. Use SF² assessment to guide BSIMM implementation scope and sequencing.

OWASP ASVS (Application Security Verification Standard)

Focus: Security verification requirements

Website: https://owasp.org/www-project-application-security-verification-standard/

Relationship to SF²: SF² helps sequence ASVS implementation within scaling investment strategy. Use SF² to determine risk-based ASVS subset vs. comprehensive implementation.

Foundational References

SF² is built on prior work. These are the thinkers whose arguments the framework rests on, grouped by the part of SF² they anchor. Each entry names the work, where to find it, and what it carries for the framework.

Software factory lineage and the case against the factory

The term SF² governs has a fifty-year industrial paper trail, and the framework owes the strongest counter-framings, from AI-democratized creation to the flat artist colony, a real answer. These anchor The Atelier and the Factory.

• Bemer (1968), "The Economics of Program Production." Robert W. Bemer, then at General Electric, is generally credited with the earliest "software factory" proposal, framed as an answer to the late-1960s software crisis. (Bemer's papers, Computer History Museum.) The provenance behind treating "Software Factory" as industrial-lineage vocabulary rather than a fresh coinage.
• Cusumano (1991), Japan's Software Factories: A Challenge to U.S. Management. Oxford University Press. The book-length study of the factory model applied to software at Hitachi, Toshiba, NEC, and Fujitsu. The mid-history of the term, between Bemer and modern DevOps usage.
• Greenfield & Short (2004), Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley. The configuration-of-languages-patterns-frameworks-tools definition that carried the term into modern application development.
• U.S. Department of Defense accredited software factories (Platform One, Kessel Run, and others). More than twenty accredited software factories operate today; the word carries operational and regulatory weight in the one ecosystem where getting delivery wrong gets people killed.
• Sankar, Position and Portfolio. shyamsankar.com. Palantir's CTO argues the atelier counter-framing: position and portfolio decoupled, "there is only the artist and the work." The steelmanned view SF² absorbs at the creative-act layer. The "artist colony, extraordinarily and exquisitely flat" line is from Sankar's Financial Times interview, 12 August 2021 (paywalled).
• Karpathy (2025), "vibe coding." Andrej Karpathy's originating post, where plain-language prompting means you "forget that the code even exists." The definitional statement of the AI-democratization current the chapter answers.
• Huang (2023), "Everyone is a programmer." CNBC. Nvidia's CEO at Computex on natural language as the new programming interface: "you just have to say something to the computer."
• Ramaswamy, via McKinsey (2025), "AI is turning every company into a software company." Snowflake's CEO on non-engineers shipping their own dashboards by describing them in English. The democratization thesis stated from inside an enterprise.
• Northern Health / Hussain (2025), a clinic app in four days. A British GP with no coding background built a working patient app on Replit in four days after agencies quoted £75,000 to £100,000; his out-of-pocket platform cost was about £175 (Replit case study, a customer story via Analytics India Magazine). The concrete proof point, and Replit's Amjad Masad frames the platform as one for a billion builders.

Capability and least-privilege

• Saltzer & Schroeder (1975), "The Protection of Information in Computer Systems." Proceedings of the IEEE 63(9):1278-1308. The original eight design principles, least privilege among them. SF²'s investment portfolio is a modern form of the same question: where do you spend constrained attention? This is the half-century anchor.
• Hardy (1988), "The Confused Deputy." ACM SIGOPS Operating Systems Review 22(4):36-38 (DOI). The foundational account of why authority and the right to exercise it must be bound together. Agent and MCP authorization failures are this 1988 problem reincarnated.
• Birgisson, Politz, Erlingsson, Taly, Vrable & Lentczner (2014), "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud." NDSS (DOI). Bearer credentials that attenuate: any holder can append a caveat that narrows what a token may do, and none can broaden it, with the chain enforced by nested HMACs. This is the existence proof that authority can be made to shrink at every hop of a delegation chain. The pattern runs in production today: Fly.io scopes its API tokens this way (fly tokens attenuate, with caveats that lock a credential to a single machine), and AWS STS session policies enforce the same intersection rule, where a delegated session can never exceed the role it assumed. SF²'s agent-scale authorization argument extends a deployed pattern rather than a research idea.
• Shapiro, Smith & Farber (1999), "EROS: A Fast Capability System." SOSP. A capability operating system where every authority a process holds is an explicit, unforgeable capability and nothing is ambient. The existence proof that capability-based confinement runs as a real operating system rather than only as a principle.
• Watson, Anderson, Laurie & Kennaway (2010), "Capsicum: Practical Capabilities for UNIX." USENIX Security. Capability-mode sandboxing retrofitted into a mainstream operating system (FreeBSD), carrying the EROS model into production UNIX. The practical face of bounding what a component may do at the OS boundary.

Agentic security: capability control and the confused deputy

The 2025-2026 agentic-security literature carries the two anchors above, least privilege and the confused deputy, into autonomous AI systems. It converges on boundary enforcement with per-request attenuation, in the same vocabulary SF² uses.

• Cloud Security Alliance, "Confused Deputy Attacks on Autonomous AI Agents" and the MAESTRO threat-modeling framework (2025). The practitioner-standards confirmation that Hardy's 1988 problem is the central agent-authorization failure, plus a multi-layer framework that models how a weakness cascades across layers rather than staying contained to one. CSA's lens is SF²'s lens.
• Huang & Narajala (2025), "A Novel Zero-Trust Identity Framework for Agentic AI." Fine-grained, agent-scoped authority with per-request capability attenuation as the confused-deputy mitigation. The standards-side author (CSA AI Safety co-chair) naming the same mechanism SF² reaches for.
• Bandara et al. (2025), "ASTRIDE: A Security Threat Modeling Platform for Agentic-AI Applications" (arXiv:2512.04785). Extends the classic STRIDE method with a new category for agent-specific attacks (prompt injection, unsafe tool invocation, reasoning subversion) and automates diagram-driven assessment. The threat-modeling field itself moving to cover the agentic surface, the evolution SF² builds on rather than corrects.
• OWASP, Top 10 for Agentic Applications (2026). Introduces "least agency" as an extension of least privilege: permissions attach to tools rather than prompt text, and agents withhold high-impact decisions for explicit authorization. The boundary-at-infrastructure argument and the criticality-gated human decision, peer-reviewed by more than 100 practitioners.
• Shi et al. (2025), "Progent: Programmable Privilege Control for LLM Agents" (arXiv:2504.11703). Per-request privilege where the effective action space can only shrink without explicit approval, a property the authors call monotonic confinement, benchmarked on AgentDojo and ASB. The formal, measured form of broad latent capability attenuated per request.
• Zhu et al. (2025), "MiniScope: A Least Privilege Framework for Authorizing Tool Calling Agents" (arXiv:2512.11147). Automatically reconstructed least-privilege permissions that confine damage from unreliable models at low overhead. Capability-preserving by construction.
• Betser et al. (2026), "AgenTRIM: Tool Risk Mitigation for Agentic AI" (arXiv:2601.12449). Per-step least-privilege enforcement that preserves capability while bounding it. The useful-and-bounded claim, evaluated on AgentDojo.
• SPIFFE and SPIRE. The CNCF workload-identity standard: short-lived, cryptographically attested identities (SVIDs) issued per workload, the production form of scoped machine identity for agents and services. Necessary for naming a deputy, insufficient on its own for bounding what it may do.
• Cloud Security Alliance, "Agent Identity Governance Framework" (2026 draft). Recommends SPIFFE SVIDs for persistent agent identities and pairs them with just-in-time, scope-limited, time-bound grants for ephemeral sub-agents: identity plus attenuation, the pairing the authorization chapter argues for.

Verified boundaries and AI-found vulnerabilities

The substrate guarantee is provable by construction only for as long as a component cannot reach the layer that bounds it. These anchor the dating of that claim: what a verified boundary buys that an asserted one does not, and the evidence that AI now finds exploitable flaws in enforcement-layer code.

• Klein et al. (2009), "seL4: Formal Verification of an OS Kernel." SOSP 2009 (full proof account). A machine-checked proof, in Isabelle/HOL, that a general-purpose OS kernel's C implementation refines its specification, carrying functional correctness, access-control enforcement, and information-flow noninterference. The existence proof that a boundary can be proven rather than asserted, and the reason verification is the one defensive property attacker cleverness cannot erode.
• DARPA, "AI Cyber Challenge (AIxCC) Final Results" (2025). Autonomous cyber-reasoning systems found 18 real vulnerabilities across 54 million lines of open-source code and patched the majority of injected ones, at roughly $152 per task. DARPA's own framing calls it an inflection point. The evidence that finding a path through enforcement-layer code is now a machine-scale capability, currently led by defenders.
• Google, "Big Sleep" agent (Project Zero and DeepMind, 2024-2025). The first AI agent to find a live, previously-unknown vulnerability in widely-deployed substrate software (SQLite, CVE-2025-6965), then more across open-source projects. The symmetric capability made concrete: AI reaching flaws in exactly the primitive code that sits below applications.
• CSIS, "Beyond Autonomous Attacks: The Reality of AI-Enabled Cyber Threats" (2026). The measured counter to the autonomous-attack narrative: AI's offensive contribution today is efficiency rather than new capability, with most attacks still relying on existing tactics. The grounding for dating the symmetric-capability balance as contested but not yet flipped.
• Saxe, "AI Security Notes" (2025). The generalization asymmetry between offense and defense: offensive AI is built on public, transferable knowledge, while defensive efficacy depends on the private, idiosyncratic shape of a given enterprise environment, the regime where machine learning generalizes worst. The structural reason a defender cannot reach parity by pointing the same class of model at defense, and a second argument, independent of review speed, for containment over an AI arms race.

Prompt injection and input trust

The prompt-injection literature this chapter draws on, from the naming of the category through the first production exploit to the system-layer defenses that answer it.

• Greshake et al. (2023), "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection." Named indirect prompt injection as a category. The operational lesson: anything the agent reads is part of the agent's attack surface.
• Bargury (2024), "Living off Microsoft Copilot." Black Hat USA 2024. Indirect prompt injection that turns Copilot against its own user through content the agent reads automatically; "remote copilot execution." The trust boundary moves to wherever the agent reads.
• Aim Labs (2025), "EchoLeak" (CVE-2025-32711). The first zero-click prompt-injection exploit in a production LLM system: a single crafted email achieved remote, unauthenticated data exfiltration from Microsoft 365 Copilot. Technical analysis: arXiv:2509.10540.
• Schulhoff et al. (2023), "Ignore This Title and HackAPrompt." EMNLP 2023. The first community-scale prompt-injection taxonomy: roughly 3,000 participants, some 600,000 adversarial prompts. Defense in the prompt does not generalize; defense at the boundary does.
• OWASP (2025), "Top 10 for Agentic Applications" (ASI06: Memory & Context Poisoning). Names the persistent escalation as its own class: memory, retrieval, or context shaped to steer the agent's steps long after the initial interaction, with the consequence appearing at runtime rather than training time. Its governance prescription is the one this chapter reaches on its own, provenance metadata on every memory write.
• "A Practical Memory Injection Attack against LLM Agents" (MINJA, 2025). Injects malicious records into an agent's long-term memory through ordinary queries alone, with no privileged access, so the poison is retrieved later as the agent's own remembered experience. The demonstration that stored-token poisoning needs no write privilege, only a conversation.
• AgentPoison (NeurIPS 2024), "Red-teaming LLM Agents via Poisoning Memory or Knowledge Bases." Optimizes a backdoor trigger so a poisoned long-term memory or RAG store returns malicious demonstrations whenever the trigger appears, while benign queries behave normally and hide the compromise. The retrieval-time half of the threat: the poison is prioritized when it matters and dormant otherwise.
• Google DeepMind & ETH Zürich (2025), "Defeating Prompt Injections by Design" (CaMeL). Gives up on hardening the model and moves the defense to a system layer around it: track where each value came from and block the disallowed flow. A privileged model plans but never reads untrusted data, a quarantined model reads that data but holds no authority, and an interpreter enforces policy on the flow between them. Control-flow integrity under untrusted input, a distinct invariant from the credential attenuation above. The research instance of substrate-plus-provenance containment.
• Tallam & Miller (2025), "Operationalizing CaMeL: Strengthening LLM Defenses for Enterprise Deployment" (arXiv:2505.22852). The deployment cost of the dual-model design, which "effectively doubles the number of model invocations" and spends more tokens by construction, since the privileged model re-queries to produce clean interpreter code and the quarantined model reads every untrusted artifact. Workflows where the quarantined model processes multiple artifacts, reviewing ten emails for instance, can exceed ten seconds of latency, "often unacceptable in interactive applications like customer-facing chatbots or support agents"; caching plus deterministic parsers recover up to half the overhead. The reason containment by construction is a workload choice rather than a universal default.
• Lan et al. (2026), "Silent Egress" (arXiv:2602.22450). Implicit prompt injection drives an agent to exfiltrate its runtime context through ordinary outbound requests while the user-facing response stays harmless; output-based checks miss the great majority of successful leaks. The empirical case that an agent run is judged from outside rather than from what it shows the user.
• Observability, from control theory to production. Kálmán (1960) defined a system as observable when its internal state can be reconstructed from its external outputs over time; Charity Majors carries the idea into software practice as the ability to ask any question of a running system from the outside, including the ones you did not anticipate. The external-correctness criterion for agent runs descends from this.

Resilience and adaptive capacity

• Holling (1973), "Resilience and Stability of Ecological Systems." Annual Review of Ecology and Systematics 4:1-23. The origin of resilience as a property distinct from stability: a system's capacity to absorb disturbance and reorganize while keeping its essential function, rather than its tendency to return to a prior equilibrium. SF²'s Adaptive Capacity condition descends from this idea, carried into engineered systems by the resilience-engineering work below.
• Hollnagel, Leonhardt, Shorrock & Licu (2013), From Safety-I to Safety-II: A White Paper. EUROCONTROL. Reframes safety from the absence of failure to the presence of adaptive capacity. This is the resilience-engineering anchor for SF²'s operational readiness axis.
• Woods (2018), "Resilience as Graceful Extensibility to Overcome Brittleness." IRGC. Precise vocabulary for what software factories need at brittle boundaries.
• Cook (2000), "How Complex Systems Fail." An 18-point distillation of why complex systems break and keep running anyway. Pairs cleanly with Hollnagel and Woods.
• Parasuraman & Manzey (2010), "Complacency and Bias in Human Use of Automation." Human Factors 52(3):381-410. The canonical account of automation complacency: under task load, attention drifts from automated output, and the effect shows up in experts as much as novices. The mechanism beneath the comprehension crisis, and the reason adaptive capacity depends on humans who still verify what the machine produced.

Economic reasoning in security

• Geer et al. (2003), "CyberInsecurity: The Cost of Monopoly." The monoculture argument: security risk priced as a market property rather than a moral one.
• Geer (2010), "Cybersecurity and National Policy." Security reasoned about in economic terms. SF²'s investment portfolio needs Geer as its economic spine, or it reads as opinion rather than argument.
• Schneier (1999), "Attack Trees." Dr. Dobb's Journal. An attacker's cost through an attack tree resolves at its OR-nodes by the cheapest branch rather than the average. The formal reason an investment that raises the average toll can leave the cost to breach you unchanged, and the arithmetic behind the Adversary Economics criterion's coverage-over-price test.
• Varian (2004), "System Reliability and Free Riding." Security is the weakest-link case of system reliability: protection tracks the least-defended path rather than the sum or average of effort. The economic statement of the one-seam correction, with the added bite that weakest-link structure invites underinvestment in the very seam that decides the outcome.
• Anderson & Moore (2006), "The Economics of Information Security." Science 314(5799):610-613. Ties weakest-link economics to systematic security underinvestment under misaligned incentives. Why spend chases the visible average rather than the binding minimum.
• Gordon & Loeb (2002), "The Economics of Information Security Investment." ACM TISSEC 5(4):438-457. Anchors optimal security spend to expected loss reduction rather than to cost imposed on the attacker. The model behind judging an investment by the surface it closes rather than the toll it adds.
• Collier et al. (2023), "On Metrics and Prioritization of Investments in Hardware Security." Systems Engineering (INCOSE). Finds ratio metrics like ROSI do not correlate with risk reduction, while expected net benefit does: expected net benefit equals risk reduction minus cost. The reason a defender's stopping rule reasons in net benefit rather than a ratio, and the guard against a control that posts a flattering ratio while retiring little real risk.
• Naylor et al. (2014), "The Cost of the 'S' in HTTPS." CoNEXT '14, 133-140 (DOI). Measures the costs HTTPS imposes beyond dollars: communication latency, data usage, energy, and lost in-network caching. The empirical anchor for treating performance as a first-class mitigation cost, the column a dollar-based model prices at zero.
• Goodhart's Law. When a measure becomes a target, it ceases to be a good measure. The reason the investment criteria treat hours saved as a proxy and gate it behind a risk override: a metric carrying decision weight is one the organization learns to satisfy, so effort-hours optimized as a target drift away from the value they were meant to stand for.
• HackerOne (2023), "As Economy Slows, Headcount and Resource Cuts Harm Security Teams." Survey finding 63% of security organizations had budgets cut and 39% cut headcount in a single downturn year, with two-thirds reporting it degraded their ability to operate. The empirical basis for position durability: scaling investment is the discretionary spend a shock cuts first, so a capex shock unwinds Lean in a budget cycle rather than over quarters. (See also TechCrunch's 2023 roundup: 110+ security firms cut staff that year.)

Absorption capacity and investment timing

• Cohen & Levinthal (1990), "Absorptive Capacity: A New Perspective on Learning and Innovation." Administrative Science Quarterly 35(1):128-152. A firm's ability to recognize, assimilate, and apply new knowledge is a function of what it already understands. The academic spine for absorption capacity as the variable that sets how fast a paved road actually returns, and the reason the organization that already understands its own platform absorbs the next capability faster.
• Rogers, Diffusion of Innovations. The perceived attributes of an innovation, its relative advantage, compatibility, complexity, trialability, and observability, explain most of the variance in its rate of adoption. The mechanism behind timing set by how fast a practice spreads across teams rather than by a fixed calendar.
• DORA (2024), Accelerate State of DevOps Report. Standing up a platform measured a temporary dip in throughput and stability before it matured, the gain arriving only after the absorption cost is paid. The measured face of absorption lag, and the J-curve behind the portfolio chapter's claim that timing is paced by adoption rather than by the date of the rollout.

Coverage, deception, and retiring attack classes

• Bejtlich (2009), "The Defender's Dilemma and the Intruder's Dilemma." The asymmetry usually quoted against defenders, inverted: where the attacker needs only one way in, the defender needs only one indicator of the intruder's presence. The reason deception belongs to the detection surface, scored as coverage of whether you would notice rather than as cost imposed.
• MITRE Engage. MITRE's framework for adversary engagement and deception. Honeypots, canary tokens, and honeytokens earn their keep through a high-fidelity signal rather than through the friction they add: a decoy has no legitimate use, so any touch is a near-certain alarm. The canonical case for the rule that cost-imposition counts only when it ships a signal and a way to contain what trips it.
• Google Security (2024), "Eliminating Memory Safety Vulnerabilities at the Source." As Android moved new code to memory-safe languages, the share of its vulnerabilities that were memory-safety bugs fell from roughly three-quarters to under a quarter over six years. The trend line for retiring a whole attack class at the source rather than catching instances one at a time.
• Let's Encrypt Statistics. Free certificates and browser pressure moved the web to encryption by default, retiring mass interception of cleartext web sessions as an economical attack. The completed transport-layer instance of a field closing a path so thoroughly that attackers move on.

Operational and program design

• Anderson (2020), Security Engineering, 3rd ed. Wiley (full text free). The encyclopedic reference for building dependable distributed systems. SF² cites specific chapters rather than reinventing taxonomy.
• Venables, "Turning the Security Flywheel." Self-reinforcing, industrial-scale program design from a sitting CISO. Venables' artisanal-versus-industrial framing is the direct precursor to SF²'s Scaling Investments thesis.
• Sounil Yu, Cyber Defense Matrix and the DIE Triad. DIE (Distributed, Immutable, Ephemeral) is the architectural inverse of CIA, aligned with SF²'s stance of building security in through constraints on the artifact.

Strategic positioning and contingency theory

The two-axis model rests on a body of organizational theory: there is no single best way to organize, only the structure that fits an organization's environment, scale, and technology. SF² carries that logic into security program design, which is why it replaces the maturity ladder with a position.

• Donaldson (2001), The Contingency Theory of Organizations. SAGE. The consolidated statement of contingency theory, descending from Lawrence & Lorsch's Organization and Environment (1967) and Burns & Stalker's mechanistic-versus-organic distinction (1961): organizational fit rather than a universal maturity ladder predicts performance. The intellectual parent of SF²'s claim that security posture is position-contingent rather than a level to climb.
• Horne, Maynard & Ahmad (2017), "Organisational Information Security Strategy: Review, Discussion and Future Research." Australasian Journal of Information Systems 21. Argues information security strategy must move from internally-focused protection toward a view that weighs the organization's resources, capabilities, and external environment. The closest precedent for SF²: it calls for environment-contingent security strategy; SF² supplies the operational construct, position and portfolio and movement, that makes the call actionable.

AI-era code generation, comprehension, and review

The comprehension crisis in the Coadaptive Security layer rests on a documented direction of travel rather than a fixed multiple. These are the sources that establish it.

• DORA (2025), State of AI-assisted Software Development. AI adoption now shows a positive relationship with delivery throughput but continues to show a negative relationship with delivery stability, and 30% of respondents report little or no trust in AI-generated code. The report's frame is that AI is an amplifier, magnifying an organization's existing strengths and weaknesses rather than fixing them. The empirical grounding for AI Saturation as a contextual modifier: adoption that varies by team rather than by size, and shifts the binding constraint downstream to review.
• Veracode (2025), GenAI Code Security Report. Across more than 100 models and 80 security-relevant tasks, 45% of AI-generated samples failed the associated security test, with Java the worst at 72%, and the failure rate did not improve as the models grew more capable at functional code. The evidence behind the AI Saturation warning that this is a security problem you cannot wait out with the next model.
• GitClear (2025), AI Copilot Code Quality. Analysis of 211 million lines: copy-pasted code rose from 8.3% to 12.3% (2021-2024) while refactored lines fell from 24.1% to 9.5%, a maintainability erosion consistent with generation outrunning comprehension.
• DX, "Measuring AI's impact on developer productivity." Experience-sampling that asks reviewers directly whether AI-generated code was harder to understand; the closest industry instrument for the comprehension gap itself.
• Osmani (2026), "Comprehension Debt: The Hidden Cost of AI-Generated Code." O'Reilly Radar. Names the per-codebase accrual of the comprehension crisis: the growing gap between how much code exists and how much any human genuinely understands. Distinct from technical debt because it breeds false confidence rather than the mounting friction of slow builds and tangled dependencies.
• Dorner et al. (2025), "Quo Vadis, Code Review?" (arXiv:2508.06879) Practitioners expect LLMs as active review participants and name the long-term risk of eroding human understanding, accountability, and trust.
• Tilbury & Flowerday (2026), "The Vigilance Paradox: Automation Reliance Inside the Modern SOC." Information & Computer Security. A survey of 696 security analysts plus 29 interviews finds that automation complacency reduces monitoring of automated output and that systematic verification procedures are what mitigate it. The security-domain evidence that the comprehension gap is closed by verifying rather than consuming.
• Sutskever (2024), NeurIPS keynote: "pre-training as we know it will end." The OpenAI co-founder's argument that pretraining-compute scaling faces a ceiling because the public human-text corpus, the "fossil fuel of AI," is finite and being exhausted roughly between 2026 and 2032. The grounding for the plateau caveat in BAU vs Scaling: the demand exponential rests on a mechanism that may stall, which is why the framework's case is built on return-shape rather than on continued scaling. (Primary coverage: Kylie Robison, The Verge, Dec 2024.)

Comprehension as a queryable model of behavior

The comprehension a software factory needs is an authoritative, queryable model of how the system behaves, reconciled against the code as it changes, rather than knowledge held in any one person's head. These sources establish both the shape of that model and the guard rail on it: a model built from example assertions records what was checked rather than what the system was meant to do.

• Finster, "Spec-Driven Development Isn't New." Bryan Finster (Dojo Consortium). "Tests describe behavior. Behavior drives code. Code is the implementation detail." The order an authoritative behavioral model has to respect, and the reason good acceptance tests let you rewrite a system without drama: they capture intent rather than implementation. The continuous-delivery statement of the queryable-model claim.
• Gu et al. (2024), "The Counterfeit Conundrum: Can Code Language Models Grasp the Nuances of Their Incorrect Generations?" (arXiv:2402.19475) Code language models generate programs that pass weaker correctness checks while staying subtly wrong, and the models themselves struggle to recognize or repair them. The empirical basis for the intent-vs-assertion guard rail: a model validated only by passing checks answers with confidence and is wrong.
• Baumeister (2004), "Combining Formal Specifications with Test Driven Development." Tests describe behavior only by example, so a suite of passing assertions underdetermines what the system was meant to do. The classic statement of why example-based tests are insufficient as a specification of intent.
• Park & Maurer (2009), "Communicating Domain Knowledge in Executable Acceptance Test Driven Development." Executable acceptance tests as a living, queryable specification of behavior rather than a static document. Grounds the "current map you can question" form of the comprehension model.

Agent and MCP supply chain

• OWASP MCP Security Cheat Sheet. Treats untrusted or compromised MCP server packages as a supply-chain attack, and names tool poisoning (malicious instructions hidden in tool descriptions, parameter schemas, or return values), rug pulls (a server changing its tool definitions after approval), and tool shadowing. Its core defense is the inventory-and-pin discipline the rest of the supply chain already needs: pin tool definitions by cryptographic hash and alert on any change.
• The Hacker News (2025), "First Malicious MCP Server Found Stealing Emails in Rogue Postmark-MCP Package." The first malicious MCP server found in the wild, identified by Koi Security: an npm package, postmark-mcp, that silently BCC'd every outgoing email to an attacker-controlled address across more than 1,600 installs before it was pulled. The in-the-wild proof that an agent's toolchain is a supply-chain target rather than a hypothetical one.

Post-quantum cryptography and crypto-agility

• NIST (2024), FIPS 203 (ML-KEM). The first finalized post-quantum standards (August 13, 2024), closing an eight-year selection: the key-encapsulation and digital-signature primitives the migration moves toward. Companion standards FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA).
• NIST IR 8547 (2024, initial public draft), "Transition to Post-Quantum Cryptography Standards." The deprecation roadmap: RSA and ECC at roughly 112-bit security deprecated by 2030, all quantum-vulnerable public-key cryptography disallowed in NIST standards by 2035. The dated clock the high-exposure case runs against.
• NSA, Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) FAQ. The national-security-systems mandate and timeline: quantum-resistant software and firmware signing by 2025, NSS on CNSA 2.0 by 2030, full migration by 2035. The regulatory forcing function for organizations bound by it.
• NIST NCCoE, "Migration to Post-Quantum Cryptography" project. Crypto-agility and migration practice guidance: the discovery-and-inventory discipline the chapter prescribes before any algorithm choice.

Emergent organizational design

• Komoroske, "Coordination Headwind" and the slime-mold model. Names the gardening-platforms and Schelling-point moves that make SF² emergent rather than imposed. The direct lineage for any claim that security is an emergent property.
• Shortridge & Rinehart (2023), Security Chaos Engineering. Security as ecology rather than enforcement. Gives SF² its experimental, probabilistic posture instead of a compliance-checkbox frame.

Crisis windows and staged response

• Kingdon (1984/1995), Agendas, Alternatives, and Public Policies. The policy-window mechanism: a window opens, often through a focusing event, and a pre-existing solution gets coupled to the agenda by whoever already holds a finished proposal. The academic spine for "stay staged," since the solution has to exist and be ready before the window opens.
• Birkland (1998), "Focusing Events, Mobilization, and Agenda Setting." Journal of Public Policy 18(1):53-74. Sudden harmful events concentrate attention and open windows, but the agenda change accrues to groups already mobilized. The "prepared" half of the mechanism: the event is necessary, the ready coalition is what converts it to action.
• Downs (1972), "Up and Down with Ecology: The Issue-Attention Cycle." The Public Interest 28:38-50. Attention to a problem rises sharply then decays as it competes with other issues. Why the window closes on its own schedule, stated without committing to a duration.
• NIST SP 800-61r3 (2025), Incident Response Recommendations and Considerations for Cybersecurity Risk Management. Supersedes the 2012 four-phase guide and reframes incident response as a risk-management activity under the CSF 2.0 Functions. The standards basis for staging response plans against your top risks (Govern, Identify) and sharpening them after the event (Improvement).
• CISA Tabletop Exercise Packages. Pre-built, scenario-specific exercises whose stated purpose is to test and build out response plans, each shipping an after-action template that feeds back into the plan. The mechanism behind rebaselining a staged plan on a cadence rather than writing it once.
• Google SRE Workbook, "Postmortem Culture: Learning from Failure." A blameless post-mortem turns an incident into the highest-quality input a plan will ever get. The retro-sharpens-the-staged-plan loop, stated as practice.
• IBM, Cost of a Data Breach 2025. (Trade.) Measures whether organizations raise security investment after a breach (49% in 2025, down from 63% in 2024) rather than how long the elevated-priority window lasts. The evidence that the post-incident window is real but variable, and that its duration is not a measured constant.
• NIST SP 800-84 (2006), Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities. The methodology for tabletop and functional exercises: write objectives, build the scenario, run the debrief, file the after-action report. The discipline that turns a staged demonstration of a chronic exposure into a repeatable, auditable practice rather than a one-off scare, and the standards basis for making a silent risk legible before it becomes an incident.
• Vicarious and near-miss learning. Organizations change behavior in response to others' failures and near-failures, beyond their own incidents, which is what lets a chronic exposure move on a peer's incident rather than your own. Madsen & Desai (2010), "Failing to Learn? The Effects of Failure and Success on Organizational Learning in the Global Orbital Launch Vehicle Industry," Academy of Management Journal 53(3):451-476, find failure experience teaches more durably than success; Kim & Miner (2007), "Vicarious Learning from the Failures and Near-Failures of Others: Evidence from the U.S. Commercial Banking Industry," AMJ 50(3):687-714, find firms improve survival by learning from peers' near-failures.

Regulation as drag and driver, and the compliance-security gap

• Khansa & Liginlal (2007), "The Influence of Regulations on Innovation in Information Security." AMCIS 2007 Proceedings. Time-series evidence that major regulations spike demand for security products and services, pulling the function "out of obscurity and into the corporate boardroom." The empirical basis for regulation as a forcing function.
• Marotta & Madnick (2020), "Analyzing the Interplay Between Regulatory Compliance and Cybersecurity." MIT Sloan working paper. "Compliance is often the driver for developing or improving cyber-security" yet "may be incomplete as a cyber-security measure itself," which grounds both the driver claim and the compliance-is-not-security caveat in one source.
• Dean & Brown (1995), "Pollution Regulation as a Barrier to New Firm Entry." Academy of Management Journal 38(2). Regulation deters entry and confers an advantage on incumbents who have already cleared the bar. The mechanism behind the market-access "moat" face of the driver.
• Singla (2023), "Regulatory Costs and Market Power." Compliance costs raise industry concentration: higher profitability for large firms, lower for small, with incumbents pushing for rules that burden smaller rivals. The moat mechanism, measured.
• Stevens, Dykstra, Knox Everette & Mazurek (2020), "It Lurks Within: A Look at the Unexpected Security Implications of Compliance Programs." IEEE Security & Privacy. Organizations "often conflate compliance with strong security"; fully compliant organizations still carry exploitable gaps. The caveat, from a top venue.
• Kwon & Johnson (2013), "Health-Care Security Strategies for Data Protection and Regulatory Compliance." Journal of Management Information Systems 30(2). In operationally immature organizations compliance improves real security; in mature ones it does not. The empirical basis for tying the caveat to the operational-readiness axis.
• Kwon & Johnson (2014), "Proactive Versus Reactive Security Investments in the Healthcare Sector." MIS Quarterly 38(2). Proactive, voluntarily-made security investments outperform reactive, involuntary ones. The case for orienting to a telegraphed regulatory signal early rather than complying under a clock.
• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management. Reverses the older mandate of periodic password expiration, since forced rotation drives users toward weaker, predictable secrets. The worked example of a control that outlived its evidence while checklists kept prescribing it.
• NIST Cryptographic Module Validation Program (CMVP). FIPS 140 validation and re-validation. Re-certifying a module after a defect takes far longer than patching it, so adhering to "run only the validated module" can keep known-vulnerable cryptography in place. The validation-lag dynamic behind compliance-induced regression.
• SEC, "SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure" (2023). Public-company cyber disclosure moved from no federal mandate to a four-business-day materiality clock. A snap-back instance.
• European Commission, AI Act. In force August 2024, obligations phasing through 2026-2028. AI went from essentially unregulated to a tiered regime in roughly two years, the snap-back instance most relevant to a high AI Saturation score.
• European Commission, Cyber Resilience Act. In force December 2024, main obligations December 2027; non-compliant products may not be sold in the EU. Connected products and software moving from minimal regulation to market-access-gated.
• CISA, Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA). Signed into law March 2022, reporting rule still landing years later. The clearest case that regulation telegraphs well ahead of enforcement.

Compliance crosswalk and jurisdiction conflict

• Secure Controls Framework (SCF) and the efficacy of control rationalization. The SCF is a free metaframework that normalizes 200+ laws, regulations, and frameworks into one common control set, mapped with NIST IR 8477 Set Theory Relationship Mapping: build a control once, satisfy many regimes. The major frameworks overlap heavily (SOC 2 and ISO 27001 align on the large majority of criteria; SOC 2 and NIST 800-53 share most controls; FedRAMP is NIST 800-53 adapted for cloud), which is why a crosswalked control set absorbs a new mandate as the delta it adds rather than a build from zero. The academic record is consistent and candid about the limits: Hayden (2009) sets out the rationalization strategy and where it stops; Wang, Sadjadi & Rishe (2024) validate the SCF unified mapping across seven frameworks; Cadet et al. (2024) extend it to scalable cross-industry architectures for organizations under a large matrix of regulators.
• Where regulations genuinely conflict. The US CLOUD Act and FISA 702 compel US providers to produce data they control wherever it is stored; the CJEU's Schrems II (C-311/18) and the EDPB's Recommendations 01/2020 treat that exposure as a GDPR violation unless the data is put technically beyond reach, which is why customer-held keys and sovereign environments became architectural requirements rather than options. GDPR's right to erasure can collide head-on with a US litigation hold that compels preserving the same record (Kennedys, the OpenAI cross-border dilemma, 2025). The EU AI Act against the US state patchwork fragments rather than contradicts: both can be met, but only with per-jurisdiction configuration. These are the conflicts a cross-walk cannot dissolve.

Operator versus provider, and authorization granularity

The operator/provider split in Third-Party rests on a single principle: an operator can confine an agent only as finely as the platform's own authorization model allows. These are the anchors for that claim; the EU AI Act's provider-versus-deployer line, codifying the same split in law, is listed under regulation above.

• Schneider (2003), "Least Privilege and More." IEEE Security & Privacy 1(5):55-59. Least privilege is bounded by what the enforcement mechanism can express: you confine a component only as finely as the underlying model allows. The academic anchor for the claim that a provider defines what is expressible in the authorization vocabulary, and the operator answers for the residual the vocabulary cannot remove.
• GitHub (2022), "Introducing fine-grained personal access tokens for GitHub." Classic personal access tokens "provided very coarse-grained permissions, granting access to all of the repositories and organizations that the owning user can access." The lived form of platform-set scope, where the token that reads one project reads them all until the platform ships a finer primitive. The concrete grounding for counting coarse primitives as a real cost when you choose what to build on.

Adoption velocity, paved roads, and guardrails

Relationship Health turns on adoption velocity, and the platform-engineering field has already worked out how to raise it without trust: make the secure path the default path. These are the anchors for the friction-over-mandate reframe.

• DORA, "Platform engineering" capability. An internal developer platform provides "golden paths" and a "paved road that scales these benefits securely," making the supported, secure option the self-service default. The grounding for adoption velocity as the binding constraint, and for the secure default that is mandatory and low-friction at once.
• DORA, "Transformational leadership" capability. DORA finds leadership moves delivery performance indirectly, by enabling the practices teams adopt rather than adopting for them, and is blunt on the limit: even the strongest leaders cannot reach high performance on their own. The grounding for the security-and-engineering-leadership relationship as the upstream enabler of a funded, durable capability boundary rather than its competitor, and for reading that relationship as a multiplier on the forcing function rather than a replacement for it.
• Howard (2018), "Less Gates, More Guardrails." Sonatype. Security controls "cannot take the form of toll gates; instead, they must take the form of guardrails": automated, embedded in the pipeline, fast by default. The case that friction rather than whether a control is mandatory is what predicts adoption.
• Singhal, "Scaling Appsec at Netflix." Netflix Technology Blog. A paved-road platform baked security in by default rather than leaving it to a checklist, so a team could reach a production-ready, authenticated service in minutes. The worked example of a low-friction default carrying full adoption without a relationship to lean on.

Change capacity, absorption, and concurrent overload

Change Capacity is the absorb clock, and it is a shared, depletable pool. These anchor the claim that concurrent change contends for one budget and that pricing a move on the install date inherits an absorption gap.

• The absorption pool is finite, and concurrent change depletes it. Bernerth, Walker & Harris (2011), Work & Stress, build and validate a change-fatigue measure: multiple concurrent changes drive exhaustion, lower commitment, and turnover. Cox et al. (2022) show change frequency predicts fatigue, which lowers performance through reduced satisfaction and commitment. Kanitz, Huy, Backmann & Hoegl (2021), Academy of Management Journal, "No Change Is an Island," find that interferences between concurrent initiatives undermine implementation. Spring (2021) proposes a measure of initiative magnitude and "organizational limits beyond which performance will suffer." The empirical basis for change capacity as a shared, depletable budget.
• Concurrent overload degrades throughput (the contention mechanism). Flow and portfolio research finds that running too many initiatives at once raises context-switching cost and resource contention and lowers delivery; capping work in progress consistently improves throughput. SAFe portfolio WIP guidance states value streams "can only absorb so much work before context switching and resource contention degrade delivery," and industry data (Lean Enterprise Institute) put the lead-time cost of capping contributors at no more than two assignments at up to 40 percent. The portfolio-side grounding for sequencing by the absorption budget rather than the install calendar. Portfolio-logical, distinct from the measured human-fatigue pool above; both feed the same budget.
• The deployment-adoption gap and shelfware. Standing a tool up and getting the organization to run on it are different milestones, often months apart; absent adoption a tool becomes "shelfware," paid for and idle. Industry data put a large share of software licenses as never used, and training delivered at rollout decays before the real work arrives weeks later (WalkMe, software usage vs. adoption). The empirical face of pricing a change on the install date and inheriting an absorption gap.

The autonomous task horizon

The unit-of-defense chapter dates the routine-gate migration against a measured rate rather than a guess.

• METR (2026), "Time Horizon 1.1." and METR (2025), "Measuring AI Ability to Complete Long Tasks." The frontier task horizon, the length of task a model completes unsupervised at fifty-percent reliability, doubled about every seven months across 2019-2025 and roughly every four months across 2024-2025. The falsifiable pace behind the five-to-ten-year routine-gate window: if the doubling stalls, the migration slows with it. This rate is the perishable number in the forecast; re-check it against METR's latest each release.

Accountability and liability for autonomous action

The high-criticality gates in the unit-of-defense chapter run on a liability clock rather than a competence clock. These sources establish why a human is retained at the gate, what makes that retention meaningful rather than nominal, what moves a gate like it, and the market that could move it from the other direction.

• Santoni de Sio & van den Hoven (2018), "Meaningful Human Control over Autonomous Systems." Frontiers in Robotics and AI. The principle that humans rather than algorithms must remain ultimately responsible for high-stakes decisions, formalized as two conditions: the system tracks the reasons of the humans who deploy it, and every outcome can be traced back to a responsible human. The grounding for keeping a human at the high-criticality gate as the point responsibility traces to.
• Elish (2019), "Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction." Engaging Science, Technology, and Society. In a highly automated system the nearest human can become the component that absorbs the moral and legal responsibility for failures they had little control over, protecting the system at the operator's expense. The caution that makes the gate a matter of meaningful control rather than a name on the form.
• IMDA Singapore (2026), Model AI Governance Framework for Agentic AI. Launched at the World Economic Forum, 22 January 2026; the first national framework for autonomous agents. Compliance is voluntary, but organizations remain legally accountable for their agents' actions: accountability concentrates on the deployer rather than transferring to the agent.
• U.S. Payments Forum (2017), "Understanding the U.S. EMV Fraud Liability Shifts." In October 2015 counterfeit card-present fraud liability shifted to whichever party, merchant or issuer, had not adopted chip technology. The precedent for a liability change moving a long-standing human-gated process quickly, with no improvement in the underlying detection capability.
• Zhu (2026), "Insurance of Agentic AI." Characterizes agentic AI as a continuum of autonomy and delegated authority and argues for a layered insurance ecosystem covering autonomous-agent action. The early shape of the liability market whose maturation is the third falsifier: if coverage for autonomous action is underwritten by level of authority, a high-criticality gate could empty on a liability clock rather than a capability one.

Industry Resources

Supply Chain Security

• SLSA (Supply-chain Levels for Software Artifacts): https://slsa.dev/
• CISA Software Supply Chain: https://www.cisa.gov/sbom
• OpenSSF (Open Source Security Foundation): https://openssf.org/

Security Scaling

• DevSecOps Foundation: https://www.devsecops.org/
• Cloud Security Alliance: https://cloudsecurityalliance.org/
• Security Champions Playbook: https://github.com/c0rdis/security-champions-playbook

Organizational Transformation

• Accelerate (DORA Metrics): https://www.devops-research.com/research.html
• Team Topologies: https://teamtopologies.com/
• Platform Engineering: https://platformengineering.org/

Further Reading

Security Leadership

• Building a Modern Security Program: Ryan McGeehan
• The Manager's Path: Camille Fournier (Technical Leadership)

(Kelly Shortridge & Aaron Rinehart's Security Chaos Engineering moved up to Foundational References.)

Strategic Thinking

• Wardley Mapping: Simon Wardley (Strategic positioning)
• Good Strategy Bad Strategy: Richard Rumelt
• Principles: Ray Dalio (Organizational principles)

Community Resources

Conferences

• RSA Conference: https://www.rsaconference.com/
• Black Hat: https://www.blackhat.com/
• DevSecCon: https://www.devseccon.com/
• OWASP Global AppSec: https://owasp.org/events/

Online Communities

• r/netsec (Reddit): Security news and discussion
• Security Weekly: Podcast network
• Risky Business: Security news podcast
• Cloud Security Podcast: Cloud security topics

Contributing Resources

Have suggestions for additional resources? See our Contributing Guidelines to propose additions.

---

About This Framework

Author: Julie Davila Version: 1.3.2 License: CC BY 4.0 Repository: https://github.com/juliedavila/software-factory-security-framework Website: https://sf2framework.com

This framework represents my personal strategic mental models for security leadership, developed through years of experience leading product security at scale. SF² is an independent framework and does not represent the views of any employer.

Version 1.0 is the first complete, usable release. The 0.x series was me finding the shape; 1.0 is the shape, ready to use. It stays a living document, and I'll keep refining it as adversaries evolve and practice catches up. A 1.0 tag means established, never finished.

This is an open source framework (CC BY 4.0) intended as a resource for the broader security community.

---

Back to Glossary View on GitHub

Accessibility Statement

Our Commitment

The Software Factory Security Framework (SF²) is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards.

Conformance Status

This website aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards.

Accessibility Features

Current Implementations

• Keyboard Navigation: All interactive elements are accessible via keyboard
• Focus Indicators: Clear visual indicators for keyboard focus
• Text Alternatives: Priority levels include text labels, not color alone
• Link Distinction: Links are underlined, not identified by color alone
• Reduced Motion: Respects user's reduced motion preferences
• High Contrast: Enhanced borders and text in high contrast mode
• Semantic HTML: Proper heading hierarchy and ARIA landmarks
• Responsive Design: Adapts to different screen sizes and zoom levels
• Screen Reader Compatible: Tested with major screen readers

Navigation Shortcuts

• Tab: Navigate forward through interactive elements
• Shift + Tab: Navigate backward through interactive elements
• Enter: Activate links and buttons
• Space: Scroll page down
• Shift + Space: Scroll page up
• Home: Jump to top of page
• End: Jump to bottom of page

Color Contrast

All text meets WCAG AA contrast requirements:

• Normal text: 4.5:1 contrast ratio
• Large text: 3:1 contrast ratio
• Color-coded elements: Include text labels in addition to color

Text Sizing

Text can be resized up to 200% without loss of functionality:

1. Browser zoom: Use Ctrl/Cmd + Plus (+) or Minus (-)
2. Font size: Adjust in browser settings
3. Reader mode: Most browsers support reader mode for focused reading

Known Limitations

We are aware of the following accessibility considerations:

• Social cards: Auto-generated preview images may not have descriptive alt text
• Code blocks: Syntax highlighting uses color; consider using screenreader-friendly code readers
• Print view: Some interactive elements are not available in print mode

Feedback

We welcome feedback on the accessibility of this framework. If you encounter accessibility barriers, please let us know:

• Open an issue: GitHub Issues

Please provide:

• The web page URL where you encountered the issue
• A description of the problem
• What assistive technology you were using (if applicable)
• Your preferred method of communication

Technical Specifications

Compatibility

This website is designed to be compatible with:

Browsers:

• Chrome, Firefox, Safari, Edge (latest 2 versions)
• Mobile browsers on iOS and Android

Assistive Technologies:

• NVDA (Windows)
• JAWS (Windows)
• VoiceOver (macOS, iOS)
• TalkBack (Android)

Technologies:

• HTML5
• CSS3
• JavaScript (progressively enhanced)
• MkDocs Material theme

Standards Applied

• WCAG 2.1 Level AA
• ARIA Authoring Practices
• Section 508

Assessment

Last accessibility review: January 2025

Methodology:

• Manual keyboard navigation testing
• Screen reader testing (NVDA, VoiceOver)
• Automated testing (axe DevTools, WAVE)
• Color contrast analysis
• HTML validation

Continuous Improvement

We are committed to ongoing accessibility improvements:

Regular reviews: Periodic accessibility reviews as the framework evolves Content guidelines: Writers follow accessibility best practices Testing: New features tested for accessibility before deployment Training: Contributors educated on accessible content creation

Additional Resources

For Content Contributors

When adding content to this framework:

1. Use descriptive link text: Avoid "click here" or "read more"
2. Bad: "Click here for more information"

3. Good: "Review the implementation guide"

4. Provide text alternatives: Add alt text for all images

   ![Two-axis positioning model showing complexity vs readiness](image.png)
   

5. Use semantic headings: Follow heading hierarchy (H1 → H2 → H3)

6. Write descriptive table headers: Use <th> for column/row headers

7. Avoid color-only information: Include text labels

8. Bad: "Items in red are critical"

9. Good: "Critical items (shown with red border) require immediate attention"

10. Use lists appropriately: Use <ul> for unordered, <ol> for ordered

11. Keep language clear: Write at 8th-grade reading level when possible

Accessibility Tools

Recommended tools for testing:

• axe DevTools (browser extension)
• WAVE (web accessibility evaluation tool)
• Lighthouse (Chrome DevTools)
• Color Contrast Analyzer

---

Contact

For questions about this accessibility statement:

Repository: https://github.com/juliedavila/software-factory-security-framework Issues: https://github.com/juliedavila/software-factory-security-framework/issues

Back to References Report Accessibility Issue

v0.5 → v0.6 Migration

v0.6 changed two sets of names that v0.5 readers may have cited: the four strategic positions and the Section 02 stewardship areas. This page is the single source of truth for both. The strategic-position crosswalk and its reasoning come first; the Section 02 conditions crosswalk is at the end.

The crosswalk

Axes	v0.5 name	v0.6 name
Small reach + Lower Readiness	Niche Players	Craft
Small reach + Higher Readiness	Visionaries	Studio
Large reach + Higher Readiness	Leaders	Lean
Large reach + Lower Readiness	Challengers	Mass

Why the names changed

The v0.5 names (Visionaries, Leaders, Niche Players, Challengers) were identical to Gartner's Magic Quadrant labels. That collision carried two costs: it implied an analyst-firm ranking the framework never intended, and the credibility of those labels was falling as the analyst model itself came under pressure. SF² needed names in its own register.

The v0.6 names come from how software actually gets built. They map the readiness axis to a production-method spectrum: how repeatable the work is.

Reading the axes

The vertical axis (Operational Readiness) is the lean transformation. Moving up means the work becomes more repeatable and a failure provably stays contained. Moving up the readiness axis, from Craft to Studio and Mass to Lean, is repeatability rising, which is the core SF² thesis. The horizontal axis was Operational Complexity (scale) through v0.6; v0.7 redefined it as Blast Radius, the inherent reach of a failure if containment fails. The four names and the readiness story below are unchanged.

• Craft (Small reach + Lower): non-repeatable hand-work, a narrow grant by hand.
• Studio (Small reach + Higher): narrow grant, floor built, the small-reach ideal end state.
• Mass (Large reach + Lower): ungoverned reach, no floor.
• Lean (Large reach + Higher): large reach with the floor built, the large-reach ideal end state.

Two terms that mislead if read casually

1. Mass is Lean's large reach without Lean's floor, not Ford's 1913 assembly line. Under the v0.7 reach axis, Mass is ungoverned scale: large inherent reach with no proven containment. The border that matters is against Lean, not against the historical mass-production repeatability triumph. A reader fluent in manufacturing history should not invert the axes on the strength of the word alone.
2. Craft names a method, not a price tag. Craft means non-repeatable hand-work, not quality, premium positioning, or boutique branding. A Craft organization can do excellent security work; it just does it by hand each time.

Names that were considered and dropped

• Artisanal carried premium and boutique baggage that flattered the wrong cell. The underlying logic (non-repeatable hand-work) was kept as Craft.
• Lego is a registered trademark, a legal disqualifier on a CC-licensed framework.
• Omakase describes high-skill bespoke work, which is low repeatability, so it pointed at the wrong cell.
• Foundry and Refinery collided with existing products (Cloud Foundry, Palantir Foundry) and blurred into each other.

Citing the old names

If you are referencing material that used the v0.5 names, the table above is the mapping. The framework's substance (the two axes, the four positions, the movement paths) did not change. Only the labels did.

Section 02: stewardship areas became security conditions

In v0.5, Section 02 was titled Universal Risk Stewardship Responsibilities: five areas you steward. v0.6 reframes them as conditions you cultivate, splits the old Supply Chain area along the embedded/delegated line, and recasts Continuous Learning as the cross-cutting Adaptive Capacity condition.

v0.5 (areas you steward)	v0.6 (conditions you cultivate)
Supply Chain Stewardship	Supply Chain (#1), embedded code, comprehension lever
Third-Party Stewardship	Third-Party, delegated functions, containment lever
Process Stewardship	Process, security produced by the build
Runtime Stewardship	Runtime, sense and respond
Continuous Learning	Adaptive Capacity, the cross-cutting resilience of the whole

The URL path stays 02-stewardship/ for stability, so existing links keep working. The one file that moved is continuous-learning.md, now adaptive-capacity.md.

The deeper change is register, not labels. v0.5 framed these as responsibilities you own and steward, scored on a maturity chart. v0.6 frames them as living conditions with no passing grade, cultivated and assessed rather than owned and managed. The Universal Security Conditions overview explains why that distinction carries weight.

SF² Framework - Complete AI-Optimized Summary

This page provides a comprehensive single-page overview of the Software Factory Security Framework for AI tools and agents.

Framework Identity

Name: Software Factory Security Framework (SF²) Version: 1.1.0 Author: Julie Davila License: CC BY 4.0 Purpose: Strategic framework for scaling security capabilities while improving business outcomes Target Audience: Security leaders (VP, CISO, Director level) Website: https://sf2framework.com

Core Concept

SF² is a two-axis positioning model that helps security leaders determine appropriate security strategies based on their organization's characteristics.

Axis 1: Blast Radius (How Far a Failure Can Reach)

• Small reach: automation scoped per task, touching one bounded surface; a worst-case failure stays in a single blast cell. Headcount is a legacy proxy (often <100 engineers), not the measure.
• Large reach: automation granted broad standing authority across production, data, and identity; a worst-case failure cascades across the estate. Headcount used to predict this (often 100+ engineers); AI severed the correlation.

Axis 2: Operational Readiness (How You Operate)

• Lower: Manual processes, legacy infrastructure, limited automation
• Higher: Cloud-native, CI/CD, strong automation, infrastructure-as-code

Four Strategic Quadrants

1. Studio (Small reach + Higher Readiness)

Characteristics: Task-scoped automation (small reach), modern cloud infrastructure, strong CI/CD, fast decision-making (headcount a legacy proxy, historically 10-200 engineers)

Strategy: Automate from the start, build scaling foundations early

Investment Focus:

• Automated security scanning in CI/CD
• Secure templates and paved roads
• Self-service capabilities
• Policy-as-code

Timeline: 12-18 months to mature capabilities

Common Pitfall: Building Lean-level complexity too early

2. Lean (Large reach + Higher Readiness)

Characteristics: Broad standing authority across the estate (large reach), mature platforms, established security, platform-oriented (headcount a legacy proxy, historically 200+ engineers)

Strategy: Optimize existing capabilities, build platform effects, security as competitive advantage

Investment Focus:

• Platform-scale automation
• Advanced security capabilities
• Federated security models
• Tool consolidation and optimization

Timeline: Ongoing optimization and innovation

Common Pitfall: Complacency and tool sprawl without retirement

3. Craft (Small reach + Lower Readiness)

Characteristics: Task-scoped automation (small reach), legacy/basic infrastructure, resource constraints, critical decision point (headcount a legacy proxy, historically <50 engineers)

Strategy: Choose intentional simplicity OR prepare for growth (two distinct paths)

Path A - Intentional Simplicity:

• Managed security services
• Essential security only
• Security through simplicity

Path B - Prepare for Growth:

• Infrastructure modernization
• CI/CD foundation
• Move toward Studio over 18-24 months

Common Pitfall: Accidental drift to Mass (reach without readiness)

4. Mass (Large reach + Lower Readiness)

Characteristics: Broad standing authority across the estate (large reach), legacy systems at scale, manual processes, transformation imperative (headcount a legacy proxy, historically 100+ engineers)

Strategy: Stabilize first, hybrid approach (modern for new, pragmatic for legacy), realistic 3-5 year timeline

Investment Focus:

• Quick automation wins
• Modern security for new systems
• Pragmatic controls for legacy
• Relationship building with engineering

Timeline: 3-5 years for transformation (honest assessment)

Common Pitfall: Rushing the containment climb, or widening reach further before the floor is built, underestimating resources needed

Universal Security Conditions

Five areas requiring attention regardless of quadrant position:

1. Supply Chain Stewardship (#1 Priority)

Why #1: Adversary evolution to automated discovery at internet scale

Focus: All external dependencies, third-party components, multi-tier supply chain

Critical: Automated dependency scanning, SBOM, continuous monitoring

2. Third-Party Stewardship

Focus: Integrated services, platforms, vendors throughout operational lifecycle

3. Process Stewardship

Focus: Security throughout development lifecycle, continuous validation, rapid feedback

4. Runtime Stewardship

Focus: Production security and reliability, proactive monitoring, rapid response

5. Adaptive Capacity

Focus: Whether the system as a whole can absorb a surprise it was not designed for and keep working; the cross-cutting resilience condition formerly called Continuous Learning

Investment Portfolio Framework

BAU (Business-as-Usual)

Definition: Manual security work that scales linearly with growth

Examples: Security reviews, threat modeling, incident response, compliance reporting

Strategy: Constrain deliberately - don't expand post-scaling crisis

Warning: Linear scaling becomes unsustainable

Scaling Investments

Definition: Capabilities whose payoff compounds as more teams use them

Examples: Automation platforms, self-service capabilities, policy-as-code, paved roads

Strategy: Primary investment focus after scaling crisis

Benefit: Create compound capabilities that serve multiple teams

Platform Effects

Definition: Benefits serving both internal and customer software factories

Value: Multiplicative impact across organization

The Scaling Crisis

Definition: When demand for security services outpaces a team whose capacity grows only linearly

Signals: Security blocking releases, team burnout, months-long backlogs

Response: Shift investment from BAU to scaling capabilities immediately

Eight Contextual Modifiers

Factors that significantly affect strategy implementation:

1. Attack Landscape Maturity

High Maturity Impact: Manual processes become existential vulnerabilities

Characteristics: Automated discovery at scale, rapid exploitation, adversaries find assets before defenders

2. Supply Chain Complexity

Impact: May require Lean-level tools regardless of base quadrant

Factors: Multi-tier dependencies, critical vendors, geopolitical constraints

3. Regulatory Constraints

Impact: Increases BAU burden, may delay progression

Considerations: Audit frequency, evidence requirements, technology constraints

4. Crisis Events

Impact: Create windows for rapid organizational change

Types: Security incidents, compliance failures, business disruptions

Opportunity: "Never waste a good crisis" for transformation funding

5. Change Capacity

Impact: Affects transition speed and success probability

Assessment: Tool rollout timelines, disruption tolerance, recent change success

6. Relationship Health

Impact: Directly affects adoption velocity

Levels:

• Damaged: Security as blocker
• Functional: Working but transactional
• Strategic: Security as enabler and partner

7. AI Saturation

Impact: Shifts the binding constraint from writing code to understanding it

Assessment: Share of code, review, and ops running through AI and agents; whether review keeps pace with generation

Response: Move from manual review to automated guardrails, from static authorization to per-request agent identity

8. PQC Exposure

Impact: How much of your cryptography the quantum transition puts at risk, and how hard that risk is to retire; the loss is silent and already underway (harvest now, decrypt later)

Assessment: How long data must stay confidential, crypto-agility of the underlying math, long-lived signed artifacts and fielded devices with no update path

Framework Integration with Other Standards

Key Principle

SF² is a strategic overlay that guides which, when, and how fast to implement other frameworks' practices.

NIST SSDF Integration

• SSDF provides what practices to implement
• SF² provides how to sustainably resource and scale those practices
• Quadrant position determines practice prioritization and automation approach

OWASP SAMM Integration

• SAMM defines maturity levels (0-3)
• SF² determines which maturity levels to pursue and speed of progression
• Not every organization should pursue Level 3 in every practice

BSIMM Integration

• BSIMM describes 128 security activities (as of BSIMM16, 2026)
• SF² helps prioritize which activities and sequence implementation
• Quadrant determines activity count (Craft: 15-25, Studio: 30-40, Lean: 60-80)

OWASP ASVS Integration

• ASVS provides verification requirements (Levels 1-3)
• SF² determines appropriate level and risk-based subset
• Different levels for different system types in Mass organizations

AI Integration Guidance

Supported AI Tools

Claude Desktop:

• Projects with persistent framework knowledge
• Deep strategic reasoning, long context
• Best for: Extended strategic planning sessions

ChatGPT:

• Custom GPTs with framework configuration
• Team collaboration, web browsing
• Best for: Organization-wide consistent framework access

Gemini:

• Gems with Google Workspace integration
• Native Docs/Sheets/Slides collaboration
• Best for: Strategy development in collaborative documents

Common AI Use Cases

1. Position Assessment: Determine quadrant based on org characteristics
2. Investment Strategy: Design BAU constraints and scaling investments
3. Executive Communication: Draft board presentations with framework positioning
4. Budget Justification: Generate ROI analysis for scaling investments
5. Vendor Evaluation: Map tools to BAU vs scaling categories
6. Transformation Planning: Realistic roadmaps with success indicators
7. Team Communication: Translate strategy for different audiences
8. Framework Learning: Interactive education with org-specific examples

Key Principles (Critical for Understanding)

1. Supply Chain is #1 priority - Adversary evolution to automated discovery
2. Constrain BAU, build scaling - Don't expand manual work
3. High readiness enables automation - Operational readiness determines feasibility
4. Diagonal transformation is high-risk - Sequence carefully (stabilize, then move one axis)
5. Appropriate security varies by position - No one-size-fits-all
6. Realistic timelines matter - Mass organizations need 3-5 years, not 12 months
7. Framework integration, not competition - SF² guides other frameworks' implementation

Decision Frameworks

Should We Reduce Complexity First? (Mass)

Yes, if:

• Products/services can be consolidated or retired
• Business model supports scope reduction
• Executive support for difficult decisions
• Prefer faster transformation (3-4 years vs 4-5)

No, if:

• Business model requires current complexity
• Revenue tied to all current products
• Must maintain all operations
• Can commit to 4-5 year timeline with resources

Which ASVS Level Should We Target?

Level 1 (Opportunistic):

• Craft for most applications
• Mass for legacy systems being retired

Level 2 (Standard):

• Studio for all applications
• Lean for all applications
• Mass for new/modern systems
• Most organizations should target this

Level 3 (Advanced):

• Lean for high-security applications
• Payment systems, sensitive data, critical infrastructure
• Not typically cost-effective for others

Build vs Buy Security Platform?

Build (Studio moving to Lean):

• Custom requirements not met by vendors
• Platform effects across many teams
• Engineering capacity available
• Long-term investment justified

Buy (Most organizations):

• Standard capabilities needed
• Faster time-to-value required
• Limited engineering capacity
• Focus on business differentiation

Success Indicators by Quadrant

Studio - 12 Months

• Manual security reviews reduced 70%
• Automated scanning detecting 80%+ issues
• Security review SLA: 90% under 2 hours
• Zero critical incidents from standard patterns

Lean - 12 Months

• Security almost entirely self-service
• Platform adoption >90% voluntary
• Industry thought leadership established
• Security as measurable competitive advantage

Craft - 12 Months (Path B: Growth)

• Cloud migration 80% complete OR basic CI/CD operational
• Automated security scanning deployed
• Infrastructure-as-code for 70%+ systems
• Ready to scale with business

Mass - 12 Months (Stabilization)

• Operational burden reduced 20% through automation
• Executive sponsor actively engaged
• Modern security for new systems (not recreating legacy)
• Transformation roadmap with committed resources

Common Pitfalls by Quadrant

Studio: Premature complexity, missing scaling crisis signs, process over outcomes

Lean: Complacency, tool sprawl, optimization over innovation, platform without adoption

Craft: Accidental drift to Mass, premature optimization, wrong modernization sequence

Mass: rushing the containment climb or widening reach further before the floor is built, underestimating timeline/resources, recreating legacy in cloud, missing crisis window

Transformation Timelines (Realistic Expectations)

Studio staying Studio: 12-18 months to mature capabilities

Craft → Studio: 18-24 months (single-axis movement)

Studio → Lean: 18-36 months as complexity increases

Mass → Studio (via Craft): 3-4 years

Mass → Lean (direct): 4-5 years (optimistic)

When to Use This Framework

Strategic Planning:

• Assessing current security program positioning
• Designing multi-year investment strategies
• Justifying budget to executives/board
• Planning security transformations

Tactical Decisions:

• Evaluating security tool purchases
• Deciding build vs buy for capabilities
• Prioritizing which practices to implement first
• Sequencing framework adoption (NIST, OWASP)

Organizational Change:

• Communicating strategy to stakeholders
• Building relationship with engineering
• Shifting from manual to automated security
• Managing through scaling crisis

What This Framework Is NOT

• Not a compliance checklist
• Not specific security controls or configurations
• Not "best practices" that apply to everyone
• Not a replacement for NIST SSDF, OWASP SAMM, etc.
• Not a quick fix (realistic timelines required)

What This Framework IS

• Strategic positioning model for security leaders
• Investment decision framework (BAU vs scaling)
• Context-appropriate guidance by organizational position
• Realistic transformation planning with timelines
• Integration strategy for other security frameworks
• Honest about tradeoffs and organizational constraints

---

For AI Tools: How to Use This Framework

When helping users with SF² framework:

1. Start with position assessment - Determine quadrant based on blast radius and readiness
2. Identify contextual modifiers - Ask about attack landscape, supply chain, regulation, etc.
3. Apply quadrant-specific guidance - Different recommendations for different positions
4. Consider realistic timelines - Don't promise fast transformations for Mass
5. Acknowledge tradeoffs - Every choice has costs
6. Emphasize Supply Chain #1 - This is foundational due to adversary evolution
7. Focus on actionability - Provide specific, measurable guidance
8. Be honest about difficulty - Security transformation is hard; acknowledge constraints

Quick Reference Card

Current Position → Assess Blast Radius (Small reach/Large reach) + Readiness (Lower/Higher)

Quadrant Priorities:

• Studio: Automate early
• Lean: Optimize and scale
• Craft: Choose your path
• Mass: Stabilize first

Investment Rule: Constrain BAU, build scaling

Supply Chain: Always #1 priority

Timeline Honesty: Mass = 3-5 years

Framework Integration: SF² guides other frameworks' implementation

---

Full Documentation: https://sf2framework.com Structured Data: framework.json Repository: https://github.com/juliedavila/software-factory-security-framework

Contributing to SF²

Thank you for your interest in contributing to the Software Factory Security Framework (SF²)! This framework is designed as a public resource for security leaders and practitioners.

Quick Start

The easiest way to contribute is to:

1. Click "Edit this page" on any documentation page
2. Make your changes in the GitHub web editor
3. Submit a pull request with a clear description

Types of Contributions

We welcome several types of contributions:

✏️ Content Improvements

• Clarifying existing concepts
• Adding examples or use cases
• Correcting errors or outdated information
• Improving readability and structure

🔗 Framework Relationships

• Documenting how SF² relates to other security frameworks
• Adding implementation mappings
• Sharing integration experiences

💡 Use Cases & Stories

• Real-world application examples
• Success stories (anonymized if needed)
• Lessons learned from implementation

🐛 Issues & Feedback

• Reporting unclear sections
• Suggesting new topics
• Identifying gaps in coverage

Guidelines

Content Standards

Keep Content Universal

Contributions should be broadly applicable to all organizations. Do not include:

• Organization-specific internal details or processes
• Proprietary information or trade secrets
• Customer/partner sensitive data
• Confidential metrics or implementation details

Writing Style

• Executive-friendly: Write for security leaders, not practitioners alone
• Actionable: Provide clear guidance, not theory
• Examples-driven: Illustrate concepts with concrete examples
• Scale-agnostic: Ensure content applies across organization sizes

Tone & Voice

The framework uses:

• Direct, pragmatic language - Avoid jargon where possible
• Strategic framing - Focus on business outcomes and tradeoffs
• Authentic voice - Professional but not corporate-speak
• Empathy - Acknowledge the challenges security leaders face

House Style

A few house rules keep 100-plus pages reading as one voice. The glossary is the source of truth for every term.

• Match the glossary exactly. Use the canonical names: Universal Security Conditions (never "stewardship areas" or "responsibilities"), Blast Radius for the reach axis (never "operational complexity"), Operational Readiness graded Lower to Higher (never "Low/High"), and the four quadrants Studio, Lean, Craft, Mass. If a term is not in the glossary, it probably needs to be added there before you use it.
• No em-dashes. Use commas, colons, parentheses, or rewrite the sentence. Arrows (→) are welcome for showing progression or mapping.
• Say it directly. Phrasings like "it's not X, it's Y" or "X doesn't Y, it Zs" read as filler when they stack up. State the point once, plainly.
• Blank line before every list. Always leave a blank line between a paragraph and the list that follows it. Without it, the list renders as literal dashes instead of bullets.
• Write for the decision-maker. The reader is a VP or CISO deciding where to spend, not a practitioner following steps. Lead with the tradeoff, not the tactic.

How to Contribute

Option 1: Quick Edits (Recommended for Minor Changes)

1. Navigate to the page you want to edit
2. Click "Edit this page" button (pencil icon)
3. Make your changes in the web editor
4. Provide a clear commit message
5. Submit the pull request

Option 2: Full Repository Workflow (For Larger Changes)

# Clone the repository
git clone https://github.com/juliedavila/software-factory-security-framework.git
cd software-factory-security-framework

# Create a feature branch
git checkout -b feature/your-contribution

# Install dependencies
pip install -r requirements.txt

# Make your changes to docs/*.md files

# Preview locally
mkdocs serve
# Visit http://127.0.0.1:8000

# Commit your changes
git add docs/
git commit -m "feat: add <description of your changes>"

# Push and create pull request
git push origin feature/your-contribution

Option 3: Issues & Discussions

Can't contribute directly but have feedback?

1. Open an Issue
2. Use issue templates for:
3. Content suggestions
4. Error reports
5. New topic requests

Preview and Validate Locally

For anything larger than a one-line fix, preview and validate before you open the PR. The site builds with --strict, so a broken link or a missing heading anchor fails CI. Catching it locally is faster than a round trip.

With Docker (matches the CI environment exactly, no local Python needed):

# Live preview with hot reload at http://localhost:8000
docker compose up serve

# Strict build — fails loudly on any broken link or missing anchor.
# "Documentation built" means you are clear to open the PR.
docker compose run --rm build

With a local Python toolchain instead:

pip install -r requirements.txt
mkdocs serve                 # preview at http://127.0.0.1:8000
mkdocs build --strict        # validate; must pass before you open the PR

Pull Request Guidelines

PR Title Format

Use conventional commit format:

• feat: add new section on ...
• fix: correct typo in ...
• docs: improve clarity in ...
• refactor: reorganize ...

PR Description

Include:

1. What: Brief description of the change
2. Why: Motivation or problem being solved
3. Impact: Who benefits from this change

Review Process

1. Automatic checks run on every PR (validation, linting, build verification)
2. Content review by framework maintainers
3. Feedback & iteration - we'll work with you to refine contributions
4. Merge - approved PRs are merged to master and deployed automatically

What CI Checks

Every push to master runs the deploy pipeline, which:

• Builds the site with --strict, failing on any broken link or missing heading anchor
• Builds and gates the downloadable PDF (page count plus embedded brand fonts)
• Deploys the built site to sf2framework.com on success

CI confirms that the site builds. It does not police terminology or voice for you, so please self-check against the House Style rules and the glossary before you open a PR. A local docker compose run --rm build catches the structural problems ahead of time.

Content Organization

Directory Structure

docs/
├── index.md                    # Landing page
├── executive-summary.md        # High-level overview
├── 01-foundation/             # Core concepts
├── 02-stewardship/            # 5 universal security conditions
├── 03-positioning/            # Strategic positioning model
├── 04-investment/             # Investment portfolio framework
├── 05-context/                # Contextual modifiers
├── 06-implementation/         # Quadrant-specific guides
├── 07-relationships/          # Framework mappings
├── 08-use-cases/              # Application examples
├── 09-ai-integration/         # AI tool integration guides
├── 10-coadaptive/             # Coadaptive Security Layer (capstone)
└── appendix/                  # Glossary, references

File Naming

• Use lowercase with hyphens: file-name.md
• Be descriptive: supply-chain-complexity.md not sc.md
• Follow section numbering in directory names

Markdown Standards

We use Material for MkDocs markdown extensions:

# Main heading

## Section heading

### Subsection heading

!!! note "Title"
    Callout content

!!! warning "Important"
    Warning content

!!! example "Use Case"
    Example content

| Column 1 | Column 2 |
|----------|----------|
| Data     | Data     |

[Link text](relative/path.md)

[:octicons-arrow-right-24: Button text](link.md){ .md-button }

Recognition

Contributors are recognized in several ways:

• Listed in commit history
• Mentioned in release notes for significant contributions
• Optional attribution in specific sections (if desired)

Questions?

• Issues: Open an issue
• Email: Available in GitHub profile
• General questions: Use issue discussions

Code of Conduct

Our Standards

• Respectful: Value diverse perspectives and experiences
• Collaborative: Work together toward better security practices
• Constructive: Provide helpful, actionable feedback
• Inclusive: Welcome contributors of all backgrounds

Unacceptable Behavior

• Harassment or discrimination
• Trolling or inflammatory comments
• Personal attacks
• Publishing others' private information

License

By contributing to SF², you agree that your contributions will be licensed under the Creative Commons Attribution 4.0 International (CC BY 4.0) license.

See LICENSE for details.

---

Thank You!

Small fixes matter as much as big ones. Thank you for the time and effort you put into making SF² better for everyone.

Ready to contribute? Find a page that could be improved and click "Edit this page"!

View all documentation Open an issue