Security strategy starts with where you actually stand.
A strategic mental model for scaling security in the software factory: where your organization sits, what to fund first, and why it compounds.
Featured in tl;dr sec Open on GitHub CC BY 4.0
The scaling wall
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. The usual answer, hiring more security people, buys time and then stops scaling.
SF² (the Software Factory Security Framework) takes a different route. Capacity is one factor among several, and the deeper question is strategic: where does your organization actually stand, and what security work compounds from there. It compounds because the investments that scale, like automation, self-service, and policy-as-code, keep paying down manual effort for every team downstream. Answer that first, and resourcing becomes a positioning decision instead of a hiring race.
The model
Two ideas carry the framework, and each is an entry point into the docs.
Five Universal Security Conditions
Every software-producing organization owes the same five, in priority order.
Four strategic positions
Placement on Blast Radius and Operational Readiness sets your sequence. Blast Radius is how far a failure reaches if containment fails; Operational Readiness is how much of your security is built and proven, rather than done by hand. There is no ladder to climb and no single destination. Wherever you sit, the move is up: build the floor, the proven containment that keeps a failure from cascading, at the reach your business already has. Both top-row positions are ideal end states: Studio for small reach, Lean for large.
On the v0.6 draft, late 2025
The level of completion on this framework is inspiring. Thrilled you put this out with CC.
Super detailed, tons of great insights. I especially like the Investment Evaluation Framework for what to invest in, and Designing Security Capabilities That Compound. Awesome work!
How this was made
I shipped a draft and asked the security community to tell me what I got wrong. People did. CISOs, researchers, and engineers pushed on the framework in public, some of it pointed, and the framework changed because of it. One example: after that public critique, the framework added its Defender Cost Economics analysis. The quotes above date to that v0.6 draft. They are early reception, and the framework has changed substantially since.
Read the framework
Disagree with a call it makes? Challenge it on GitHub.