For years, defenders have been playing catch-up in the SDLC domain. Just in the last year, we have seen multiple attacks all exploiting SDLC infrastructure in different ways. From the Ultralytics hijack, through Shai-Hulud waves, and up to the recent TrustWallet compromise that capped last year - attackers have realized the high ROI of targeting SDLC infrastructure. They are not just looking for vulnerabilities in code anymore; they are compromising the factories that build the code. While we have robust frameworks for protecting endpoints and cloud (first and foremost MITRE ATT&CK), the infrastructure that builds our software has largely been a "choose your own adventure" of security controls. That’s why we created SITF: SDLC Infrastructure Threat Framework.

What is SITF? 

SITF is an open framework designed to protect the "producers" - the organizations creating software. It maps attacks across the five pillars of your SDLC infrastructure: Endpoint/IDE, VCS, CI/CD, Registry, and Production:

It distinguishes itself through three core concepts:

1. Attack Flow Visualization Supply chain attacks are rarely isolated to one system. The recent Shai-Hulud 2.0 campaign demonstrated how an attacker can pivot from a Producer’s CI/CD, to a Registry, and finally to a Consumer’s Endpoint. 

SITF introduces the Attack Flow Visualizer - an interactive, drag-and-drop tool that lets you map these complex paths. It allows you to draw the arrows between an entry point (like a phishing email) and an exit point (like a secondary supply chain attack). For example, this is the final product of the SITF on the 2023 CircleCI incident:

2. A Library of 70+ Techniques We have cataloged over 70 specific attack techniques unique to SDLC infra, ranging from "Imposter Commits" in your VCS to "Action Cache Poisoning" in your CI/CD Pipelines. Every technique is accompanied by the associated set of risks and controls. Once you mark/identify/pull a threat or attack, you’ll have an encompassing list of controls for preventing the next incident.

3. The Triple Relationship / Causal Decomposition (Risk -> Technique -> Control) SITF moves beyond just listing attacks. It decomposes every event into a causal chain.

• Technique: The "What" (e.g., T-C003: PWN Request).

• Risk: The "Why" (e.g., "Allowing PRs from forks" or "Workflows with access to secrets").

• Control: The "Fix" (e.g., "Require explicit approval for workflows from forks").

By mapping these relationships, SITF allows you to move from detecting a technique to mitigating the root cause risk:

See It in Action: The Shai-Hulud-2.0 Analysis 

To prove the framework's utility, we modeled the sophisticated Shai-Hulud 2.0 attack. This campaign wasn't a single event; it was a sequence of 6 distinct steps spanning VCS, CI/CD, Registry, and Endpoints. Using SITF, we mapped the complete kill chain. Here is how the framework deconstructs the attack, starting with the initial breach.

Step 1: The Entry Point (Detailed Analysis)

The attack began with a malicious contribution to an open-source repository. SITF decomposes this single event into a causal chain:

• The Technique (T-C003: PWN Request): The attacker submitted a malicious Pull Request (PR) from a fork. This action automatically triggered a CI/CD workflow run.

• The Enabling Risks: Why was this possible? The repository was configured to "Allow PRs from forks" to trigger pipelines, and the workflow itself had "Access to secrets."

• The Missing Controls: To stop this specific technique, the organization needed "Branch Protection Rules" or to "Require explicit approval for PRs from forks" (both are settings on the VCS organizational level) or to “Use a workflow misconfiguration scanner” as a gatekeeper against the bad workflows or - even better - educate developers to write secure workflows from the beginning. Framework does not restrict security controls by their nature.

Once the initial access was achieved, the attack accelerated. In the SITF Visualizer, we mapped the subsequent steps in the chain:

• Step 2 (T-C005): Secret Exfiltration from Workflow. The malicious build script dumped environment variables to steal NPM publishing tokens.

• Step 3 (T-R004): Publishing Malicious Package. Using the stolen token, the attacker published poisoned artifacts to the public registry.

• Step 4 (T-E001): Malicious Execution on Endpoint. Unsuspecting developers and CI runners installed the packages, executing malware on their local machines.

• Step 5 (T-E003): Harvest Local Secrets. The malware used trufflehog to scrape credentials stored in plaintext on the developers' endpoints.

• Step 6 (T-C005): Secret Exfiltration from Workflow. As an additional secret harvesting technique malware created the temporary workflow to exfiltrate CI/CD secrets. If successful, this allowed secondary poisoning of packages and secondary propagation of the malware.

• Step 7 (T-E006): Register Local Machine as Runner. The attacker registered the developer's laptop as a self-hosted runner for the company, establishing persistence.

• Step 8 (T-E010): Endpoint Infrastructure Destruction. If secret exfiltration fails the malware attempts to wipe the local filesystem.

• Step 9 (V-004): Secret Exfiltration via Personal Repo. Finally, the malware tried to create a repository with the extracted secrets and upload it to the GitHub account associated with local credentials. If no necessary GitHub credentials were found locally - other existing available accounts were used.

Here is the suggested workflow: access project’s GitHub pages site -> open visualizer -> visualize the attack -> explore the techniques:

The Payoff -  The Security Controls Matrix. Once you've mapped an incident, a control matrix is available that takes into consideration every involved technique. The most efficient way to stop a supply chain attack is to break the chain as early as possible, therefore the matrix is prioritized by Attack Stage - initial access controls over post-compromise controls. The controls are also separated by the architectural component, since the application of the controls is tightly coupled to its locality: 

Why We Built SITF - Deep Dive 

We didn't build this in a vacuum. The decision to create SITF was driven by an unprecedented escalation in attacks on SDLC Infrastructure. The community kept referencing the supply chain element, but these were first and foremost attacks on SDLC Infrastructure. What began with the Ultralytics hijack quickly evolved into complex operations targeting every layer of the stack: from the lateral movement seen in tj-actions, to the runner exploitation in Amazon Q and s1ngularity, the opaque GhostAction and GlassWorm campaigns, the self-propagating Shai-Hulud and Shai-Hulud-2.0 worms, and finally to the CodeBreach misconfiguration that could have resulted in AWS platform-wide compromise.

When we attempted to model these attacks, we found that existing frameworks weren't built for this specific problem set:

• MITRE ATT&CK: While it is the industry standard for endpoints and enterprises, it lacks a dedicated matrix for SDLC infrastructure. Crucially, it focuses on detection of  "Techniques" making it difficult to build the prevention program.

• OWASP CI/CD Top 10: Excellent for prioritizing a list of risks, but it lacks the architectural context and temporal flow to show how a risk in one component (like a developer's IDE) leads to a compromise in another (like Production).

• Other Methodologies: Resources like SLSA (integrity), NIST SSDF (process), and SAP’s Supply Chain Taxonomy provide valuable pieces of the puzzle, but they miss the comprehensive, infrastructure-centric view needed for modern threat modeling.

We needed a framework that was prescriptive, actionable, and visual. We needed to answer not just "what are the risks?" but "how does an attacker move through my system?" and “how to stop the next attack?”

Get Started 

[Clone SITF from GitHub]

[Inspect SITF GitHub page]

SITF is open-source, client-side, and available now. There is no installation script, signup, or server to deploy, and no data leaves your machine. You can access it online or locally:

Online - No installation, direct browser access to an always up-to-date GitHub pages site. 

Locally - Either clone the repo or simply download HTMLs from the repository and open it in your browser.

In both cases, the Visualizer (app/visualizer.html) gives you ability to:

• Drag-and-drop modeling: immediately start mapping threats using the 70+ pre-loaded techniques.

• Auto-generate your defense: as you draw the attack flow, the tool automatically builds a Controls Matrix, giving you a prioritized checklist of defenses required to block that specific path.

• Export for stakeholders: save your models as JSON, or export board-ready PNG/PDFs and CSVs to present your findings.

In addition, use the interactive Technique Explorer (app/techniques-library.html) to search and filter attacks by component (e.g., "Registry", "CI/CD") or stage (e.g., "Initial Access"). It serves as a comprehensive audit tool for your current infrastructure.

Finally, join the community by adding SITF techniques and scenarios. The entire technique library is driven by a machine-readable JSON source of truth, which opens several possibilities:

• Contribute techniques: Found a new attack technique, risk or control? Submit a PR to the technique library. 

• Local development: Prefer local development? Have SDLC infra with unique risks and controls? Modify techniques.json, then run build-techniques.py to export the new techniques into HTMLs. Use your own HTMLs. 

• Contribute scenarios: Build the new attack flow, save it locally, add to sample-flows and submit the PR.

• Stay Current: Pull the latest updates to ensure your threat models account for the newest supply chain tradecraft.