Software Factory - Threat Modeling the Machinery That Builds Your Software

TL;DR: Software Factory is a new trick-taking threat modeling card game for the software supply chain. It comes as two decks, one per production line: Line 1 runs from source to artifact and Line 2 from artifact to runtime. Between them they hold 17 stations, 221 threat cards and 10 Trumps, and every card carries three mitigation prompts. You play it against your own factory and leave with a findings log, not just a score.

The factory is the target

I built Elevation of Email Flow because I saw a gap in threat modeling games’ coverage of email. Software Factory came out of the same itch, pointed at a much bigger target: the machinery that turns source code into running software.

Every software company now runs a factory. There are developer laptops with AI agents on them, a hosting platform, hundreds of pipeline files, runners, caches, build tools, thousands of dependencies, scanners, registries, firewalls, SBOMs, Terraform, images and clusters. Attackers have noticed. Why attack the application when you can have the pipeline that builds it, the token that publishes it, or the scanner that inspects it?

SolarWinds, Codecov, xz Utils, tj-actions, Shai-Hulud and, in March this year, Trivy all teach the same lesson. The factory is the target.

At first glance, STRIDE should cover this. It surfaces the obvious: spoofing, tampering, elevation of privilege. However, it rarely surfaces a release cache that pull requests can write to, a cloud role that trusts every repository in the organisation, a version tag that someone else can move, or a firewall that waves everything through when its feed is down. The frameworks we do have each cover a slice. SLSA (Supply-chain Levels for Software Artifacts) covers build integrity, the OWASP Top 10 CI/CD Security Risks lists ten risk areas, and the Kubernetes threat matrices start after deployment. Nothing walks the whole factory, station by station, in a form a design review can use. So I built one.

What is Software Factory?

Software Factory is a card game for 3 to 6 players that takes 60 to 90 minutes. It uses the trick-taking engine Adam Shostack made famous with Elevation of Privilege (EoP): every card is a threat, stated as a property of a component or a design decision.

The software supply chain is too big for one hand, so the game ships as two decks. Each deck is a production line and plays on its own:

• Line 1, Source to Artifact: Workstation and Agents, Version Control, Pipeline Definition, Runners, Pipeline Identity and Secrets, Build Systems, Dependency Resolution, Scanners and Gates, and Provenance and Attestation.
• Line 2, Artifact to Runtime: Registries, Firewall and Quarantine, SBOM and VEX, Infrastructure as Code, Container Images, Container Runtime, Orchestration, and Delivery and Deployment.

Each of those 17 stations is a suit of 13 cards, ranked Ace to 2, which gives 221 threat cards. On top of them sit 10 Trumps. These are hazards of the factory itself rather than of one station, with names like Names That Move, The Guard Is Inside the Wall and Self-Propagation.

Every card also carries three mitigation prompts: plain questions your design should be able to answer. Take the Jack of Pipeline Definition, Unpinned Third-Party Step:

Workflows reference actions, orbs or plugins by a mutable tag or branch, so the publisher, or whoever compromises the publisher, decides what runs.

• Are third-party steps pinned to a full commit hash?
• Is there an allow list of actions?
• Who reviews an action’s code before first use and on every update?

You don’t have to be a security specialist to ask those questions. That is the point.

The controls are on the table too

Most supply chain material treats scanners, firewalls, signing and SBOMs as the answer. This deck treats them as components with threats of their own. Scanners and Gates, Provenance and Attestation, Firewall and Quarantine, and SBOM and VEX are full suits. The Trivy compromise is the reason why: attackers force-pushed 76 of 77 trivy-action version tags and shipped a credential-stealing scanner binary into the pipelines that ran it. The guard was inside the wall.

How do you play it?

You play against your own factory, not a made-up one. Here’s how a session runs:

1. Draw the factory. The team draws its software factory on the floor plan, an A3 sheet laid out as two production lines with a bay for each station. Most teams have never drawn theirs end to end, and an empty or overcrowded bay is often the first finding.
2. Choose the suits. Pick a line and the two or three suits that match the part of the factory under review. Shuffle them with the Trumps and deal every card.
3. Name a Scribe. The Scribe keeps the findings log, with one line for every card played: the card, the element, the claim and the result.
4. Lead and claim. The leader plays a card, reads the threat aloud and makes a claim: which element it lands on, and how. Everyone else follows suit, each claiming the threat against a different element.
5. Test the claim. The table tests each claim with the card’s three prompts. If the design can’t answer one, that is a finding. If it can, the Scribe logs no exposure with the reason, which is worth having too.
6. Take the trick. The highest card takes the trick and leads the next.

Scoring

Trumps beat every suit card, but you can’t lead one until one has been played, so they arrive late, when the log is already filling. That is deliberate. A Trump claim has to connect earlier findings to one structural cause, and that teaches players to stop patching findings one by one and look for the design decision behind them.

Finding a weakness in your own pipeline is normally unwelcome. Here it is how you win, so people go looking for it, and the most junior person at the table can outscore the architect. Who wins? The person with the most points. The real prize is the findings log, which goes straight into the backlog.

There are other ways to play too: a no-scoring walkthrough, a 30-minute station sprint, a five or six session campaign across all 17 suits, and both lines at once, with two groups sharing one floor plan.

What’s in the box?

The whole game is themed on the factory floor. Each card is a riveted gunmetal plate with an enamel nameplate and a hazard-stripe band in its line’s colour: safety yellow for Line 1, safety orange for Line 2 and signal red for the Trumps. Every card has its own blueprint of the threat at work on a production line, so that’s 231 illustrations. The back is a machine nameplate stamped THREAT.

• Two decks of standard poker-size cards, each in its own tuck box: Line 1 has 128 cards and Line 2 has 115, including the Trumps and a quick-reference card.
• A quick-rules concertina in each tuck box, so either line can travel and be played on its own.
• An A3 factory floor plan to draw your factory on.
• A pad of findings logs.
• An A3 rules sheet that folds down to the size of the box.
• The Coldwater worked example, as a 28-page pocket booklet.

All of it fits in a rigid box of 152 x 109 x 55 mm.

Coming soon. If you’d like the decks when they’re published, send me a message on LinkedIn. Knowing there’s demand helps a publisher decide which games to prioritise.

What does a good claim look like?

The hardest part of any threat modeling game is the first claim. What does “specific enough” sound like? To answer that, the game comes with a worked example against Coldwater, a fictional company I invented so the cards have something concrete to land on.

Coldwater sells a freight-tracking API, ships a desktop agent that customers install on warehouse PCs, and maintains an open-source SDK on npm. It has about 120 engineers and 400 repositories. Its factory was assembled in a hurry, and its 22 design decisions are deliberately flawed. Most of them are common.

The worked example plays two full sessions and then the Trumps:

• Session 1, Line 1: Pipeline Definition, Runners, and Pipeline Identity and Secrets, against the workflows, the runner pools and the CI secrets.
• Session 2, Line 2: Firewall and Quarantine, SBOM and VEX, and Delivery and Deployment, against the proxy, the SBOM service and the path to production.

That is 88 cards, which yield 77 findings, 13 of them critical. The other 11 cards are logged as no exposure, each with its reason. Two decisions did the most damage, with 9 findings each. One is a shared pool of persistent self-hosted runners with routes into production. The other is a set of Dockerfiles that build from mutable base tags with the npm token passed in as a build argument.

The Trumps show why they come last. Names That Move ties together release tags anyone can move, actions referenced by tag, templates pulled from @main and images deployed by tag. Each was already a finding. Together they point to one architectural response: commit hashes and digests end to end, enforced at admission. That is the first item on Coldwater’s backlog, and it is a better outcome than four separate tickets.

New groups can also play the learning game against Coldwater first and then compare their log with mine.

Where do the threats come from?

Building the deck meant building a taxonomy of the software factory: 231 threats across 17 stations, each with a principle and concrete mitigations behind its three prompts. As far as I could find, a taxonomy covering the whole factory didn’t exist. The game came first and the taxonomy is a by-product of it, not the other way round.

None of the threats are speculative. 75 of the 231 cards name a public incident or disclosure, and I checked each one against its original source. A few examples:

• Version Control: tj-actions/changed-files, where moved tags pushed a secret-dumping step into thousands of pipelines.
• Build Systems: SUNSPOT, the implant that swapped source files during SolarWinds builds.
• Dependency Resolution: dependency confusion, Alex Birsan’s research into internal package names resolved from public registries.
• Registries: Shai-Hulud, a self-propagating worm that spread from npm to Maven Central.
• Container Runtime: Leaky Vessels, whose runc flaw (CVE-2024-21626) let a container break out to its host.
• Scanners and Gates: the Trivy and KICS GitHub Actions compromises of 2026.

The other cards are threats that follow from how these components work, even where nobody has written up an incident yet.

Credits

The trick-taking format comes from Elevation of Privilege by Adam Shostack, released by Microsoft under CC BY 3.0. Software Factory reuses none of its card text or artwork. The OWASP Top 10 CI/CD Security Risks, SLSA and the many researchers behind the disclosures above did the hard work of documenting what goes wrong. The cards turn that work into questions a team can ask about its own design.

Final thoughts

The software factory is where most modern compromises now start, and it’s also the part of the system we threat model least. That’s not because teams don’t care. It’s because nobody hands them the questions. Software Factory puts 693 of those questions on cards and asks a table of engineers to argue about them against their own design.

It won’t replace a proper review of your pipeline. However, it will get the platform team, the developers, the security team and the architect in one room, looking at the same drawing and writing down what they find. In my experience, that is the part that rarely happens.

Note to platform and DevOps teams: you own most of the stations in this deck. Play one line with your own factory on the floor plan before your next audit or customer security questionnaire, and keep the findings log. The “no exposure” lines are evidence too.

Note to tool vendors: your scanner, firewall, registry or signing service is on the floor plan as well. Play its suit against your own product.

I’d love to hear how it plays at your table: the claims that started arguments, the cards that felt too easy and the threats you think are missing.

Stay tuned!

Sources

• SUNSPOT technical analysis, CrowdStrike (2021)
• Codecov security update, Codecov (2021)
• Dependency confusion, Alex Birsan (2021)
• xz Utils disclosure, oss-security (2024)
• Leaky Vessels, Snyk (2024)
• tj-actions/changed-files alert, CISA (2025)
• Shai-Hulud v2 spreads from npm to Maven, The Hacker News (2025)
• Guidance for the Trivy supply chain compromise, Microsoft (2026)
• Trivy supply chain attack, Aqua Security (2026)
• KICS GitHub Action, Wiz (2026)