Defending Against Supply Chain Attacks with STRIDE Threat Modeling

Introduction

In March 2024, the cybersecurity community narrowly avoided catastrophe when Microsoft engineer Andres Freund discovered a sophisticated backdoor in XZ Utils—a compression library used across millions of Linux systems worldwide. This near-miss, known as CVE-2024-3094, represents a new breed of supply chain attacks that are doubling in frequency year-over-year, with 75% of software supply chains experiencing attacks in 2024 alone.

The XZ Utils incident wasn’t a simple vulnerability—it was a multi-year social engineering campaign where an attacker gained maintainer privileges, earned trust, and systematically injected malicious code into a widely-used open source project. The backdoor was discovered purely by chance when Freund noticed SSH logins taking 500ms instead of 100ms. Without this observation, millions of systems could have been compromised with a CVSS 10.0 vulnerability.

This article explores how the STRIDE threat modeling framework—developed by Microsoft engineers Loren Kohnfelder and Praerit Garg—can help development teams systematically identify and mitigate supply chain threats before they reach production. You’ll learn practical techniques for applying STRIDE to CI/CD pipelines, third-party dependencies, and modern cloud-native architectures.

Prerequisites

Before diving into STRIDE-based threat modeling, you should have:

• Basic understanding of software development lifecycle (SDLC) concepts
• Familiarity with CI/CD pipelines and DevOps practices
• Knowledge of common security principles (authentication, authorization, encryption)
• Experience with development tools like Git, package managers (npm, pip, Maven), and container platforms
• Understanding of data flow concepts and system architecture diagrams

Understanding the STRIDE Framework

STRIDE is a mnemonic that categorizes six types of security threats. Each category maps directly to a core security property, making it easy to systematically evaluate potential vulnerabilities:

STRIDE Category	Security Property	Definition
Spoofing	Authentication	Impersonating a user, process, or system to gain unauthorized access
Tampering	Integrity	Unauthorized modification of data, code, or configuration
Repudiation	Non-repudiability	Denying actions or transactions without proof
Information Disclosure	Confidentiality	Unauthorized access to sensitive information
Denial of Service	Availability	Degrading or preventing legitimate access to services
Elevation of Privilege	Authorization	Gaining permissions beyond what’s intended

What makes STRIDE particularly valuable for supply chain security is its systematic approach. Rather than ad-hoc security reviews, STRIDE provides a checklist that ensures comprehensive coverage of potential attack vectors.

The Growing Supply Chain Threat Landscape

Supply chain attacks have evolved from rare sophisticated operations to mainstream attack vectors. Recent data paints a concerning picture:

• Attack frequency doubled in 2024, with incidents averaging 26 per month since April 2025, compared to 13 per month in early 2024
• Gartner predicts 45% of organizations will experience a supply chain attack by 2025
• Annual costs are projected to reach $138 billion by 2031, up from $60 billion in 2025
• 70% decline in simple typosquatting attacks suggests attackers are pivoting to more sophisticated methods

Notable Recent Attacks

XZ Utils Backdoor (CVE-2024-3094): A multi-year campaign where attacker “Jia Tan” gained maintainer access, earned community trust, and inserted a backdoor that intercepted SSH authentication. The malicious code was hidden in test files and only activated during specific build conditions.

npm Package Hijacking (2025): Maintainer accounts for popular packages like “chalk” and “debug” were compromised via phishing, forcing security teams worldwide to scan environments despite minimal actual damage.

CrowdStrike Incidents: Faulty updates affecting both Windows (July 2024) and Linux (April 2024) demonstrated how trusted security software can become a supply chain vulnerability itself.

These attacks share common patterns: they exploit trust relationships, target upstream dependencies, use social engineering, and leverage the complexity of modern software supply chains.

Applying STRIDE to Supply Chain Security

Let’s walk through a practical approach to threat modeling your software supply chain using STRIDE.

Step 1: Map Your Software Supply Chain

Start by creating a data flow diagram (DFD) that represents your development and deployment pipeline. Include:

This diagram identifies key components and potential attack vectors (shown in red) in your supply chain.

Step 2: Apply STRIDE Categories to Each Component

For each component in your supply chain, systematically evaluate threats across all six STRIDE categories:

Source Code Management (GitHub/GitLab)

Spoofing

• Threat: Attacker compromises developer credentials via phishing
• Real-world example: XZ Utils attacker posed as legitimate maintainer
• Mitigation: Enforce MFA, require signed commits, implement commit signing verification

Tampering

• Threat: Unauthorized code modifications through compromised accounts
• Real-world example: Malicious commits in XZ Utils versions 5.6.0 and 5.6.1
• Mitigation: Branch protection rules, required code reviews, signed commits with GPG keys

Repudiation

• Threat: Malicious actor denies making harmful changes
• Mitigation: Comprehensive audit logging, tamper-proof commit history, identity verification

Information Disclosure

• Threat: Exposure of secrets, API keys, or proprietary code
• Mitigation: Secret scanning tools, .gitignore enforcement, private repository access controls

Denial of Service

• Threat: Repository lockout or deletion affecting development
• Mitigation: Backup strategies, repository mirroring, rate limiting

Elevation of Privilege

• Threat: Developer gaining admin access to critical repositories
• Mitigation: Role-based access control (RBAC), least privilege principle, regular permission audits

Package Dependencies (npm, PyPI, Maven)

Spoofing

• Threat: Typosquatting attacks with packages mimicking legitimate names
• Example: Packages like “chalk” → “chalck” targeting developers’ typos
• Mitigation: Dependency pinning with exact versions, package verification, private registries

Tampering

• Threat: Package maintainer account compromise leading to malicious updates
• Real-world example: npm “debug” and “chalk” package hijacking in 2025
• Mitigation: Subresource Integrity (SRI) checks, lock files (package-lock.json, poetry.lock), Software Bill of Materials (SBOM)

// Example: Verify package integrity with lock files
{
  "dependencies": {
    "express": "4.18.2"  // Exact version pinning
  },
  "devDependencies": {
    "eslint": "^8.50.0"  // Avoid caret ranges in production
  }
}

Information Disclosure

• Threat: Malicious packages exfiltrating environment variables or credentials
• Mitigation: Runtime monitoring, network egress filtering, environment variable isolation

Denial of Service

• Threat: Dependency confusion attacks or registry unavailability
• Mitigation: Private package mirrors, fallback registries, vendoring critical dependencies

Elevation of Privilege

• Threat: Package gaining excessive permissions during installation
• Mitigation: Sandboxed package installation, permission boundaries, container isolation

CI/CD Pipeline (Jenkins, GitHub Actions)

Spoofing

• Threat: Unauthorized pipeline execution via stolen tokens
• Mitigation: Short-lived tokens, pipeline approval gates, federated authentication

Tampering

• Threat: Modification of build scripts or pipeline configurations
• Real-world example: SolarWinds attackers modified build environment
• Mitigation: Immutable pipeline definitions, version-controlled workflows, pipeline integrity verification

# Example: GitHub Actions with security controls
name: Secure Build Pipeline

on:
  pull_request:
    branches: [main]

permissions:
  contents: read  # Minimal permissions
  
jobs:
  build:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false  # Don't persist credentials
      
      - name: Verify Dependencies
        run: npm audit --audit-level=high
      
      - name: Build with Provenance
        run: npm run build
        
      - name: Sign Artifacts
        uses: sigstore/[email protected]

Repudiation

• Threat: Inability to prove who triggered malicious builds
• Mitigation: Comprehensive build logs, attestation frameworks (SLSA), audit trails

Information Disclosure

• Threat: Secrets exposed in build logs or artifacts
• Mitigation: Secret management tools (HashiCorp Vault, AWS Secrets Manager), log sanitization

Denial of Service

• Threat: Resource exhaustion attacks through malicious builds
• Mitigation: Build timeouts, resource quotas, parallel build limits

Elevation of Privilege

• Threat: Pipeline gaining excessive cloud permissions
• Mitigation: OIDC federation, temporary credentials, least privilege IAM roles

Step 3: Prioritize and Document Threats

Not all threats are equal. Prioritize based on:

1. Likelihood: How probable is this attack?
2. Impact: What’s the blast radius if successful?
3. Exploitability: How easy is it to execute?

Create a threat matrix:

Threat	STRIDE Category	Likelihood	Impact	Priority	Mitigation Status
Compromised maintainer credentials	Spoofing	Medium	Critical	P0	Implementing MFA
Malicious npm package	Tampering	High	High	P0	Lock files deployed
Secrets in logs	Info Disclosure	Medium	Medium	P1	Sanitization in progress
Build timeout abuse	DoS	Low	Low	P2	Backlog

Step 4: Implement Security Controls

Map each identified threat to concrete security controls:

For Spoofing Threats:

# Enable commit signing globally
git config --global commit.gpgsign true
git config --global user.signingkey YOUR_KEY_ID

# Verify signed commits
git log --show-signature

For Tampering Threats:

# Generate and verify SBOM
cyclonedx-cli analyze --input-file package-lock.json --output-file sbom.json

# Verify artifact signatures
cosign verify --key cosign.pub your-image:tag

For Information Disclosure:

# Scan for secrets before commit
truffleHog filesystem . --json --no-verification
gitleaks detect --source . --verbose

Advanced STRIDE Techniques for Supply Chain Security

STRIDE-per-Element Analysis

Rather than analyzing your entire system at once, apply STRIDE systematically to each element type:

Processes (Build agents, deployment services):

• Focus on Spoofing, Tampering, and Elevation of Privilege

Data Stores (Artifact registries, secrets managers):

• Focus on Tampering, Information Disclosure, and Denial of Service

Data Flows (API calls, file transfers):

• Focus on Tampering, Information Disclosure, and Denial of Service

External Entities (Third-party services, open source packages):

• Apply all STRIDE categories with heightened scrutiny

Trust Boundaries in Supply Chain

Trust boundaries are critical demarcation points where privilege levels change. Common boundaries include:

1. Developer Workstation → Source Control: Code enters version control
2. Source Control → CI/CD: Automated processes begin
3. CI/CD → Package Registry: External dependencies are fetched
4. Build → Artifact Storage: Compiled artifacts are stored
5. Artifact Storage → Production: Deployment to live environment

Each boundary crossing requires authentication, authorization, and integrity verification.

Continuous Threat Modeling

STRIDE shouldn’t be a one-time exercise. Integrate it into your development workflow:

// Example: Automated threat modeling in PR process
// .github/workflows/threat-model-check.yml
name: Threat Model Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - 'src/**'
      - 'package.json'
      - '.github/workflows/**'

jobs:
  threat-check:
    runs-on: ubuntu-latest
    steps:
      - name: Check for new dependencies
        run: |
          npm audit --audit-level=moderate
          
      - name: Verify SBOM changes
        run: |
          cyclonedx-cli diff base.sbom.json current.sbom.json
          
      - name: Comment PR with threats
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: 'New dependencies detected - threat model review required'
            })

Common Pitfalls and Troubleshooting

Pitfall 1: Analysis Paralysis

Problem: Teams spend months creating perfect threat models without implementing any controls.

Solution: Start small with high-priority components. Apply the 80/20 rule—focus on the 20% of components that represent 80% of your risk. For most organizations, this means:

• Source code repositories
• CI/CD pipeline configurations
• Third-party dependency management
• Production deployment processes

Pitfall 2: Ignoring Operational Threats

Problem: STRIDE focuses on design-time threats, potentially missing runtime attacks.

Solution: Complement STRIDE with runtime security monitoring:

# Example: Runtime supply chain monitoring
# Deploy with network policies restricting egress
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-package-registry-access
spec:
  podSelector:
    matchLabels:
      app: web-service
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector: {}  # Allow internal
  - to:  # Only specific external registries
    - namespaceSelector:
        matchLabels:
          name: approved-registries
EOF

Pitfall 3: Tool Over-Reliance

Problem: Believing security tools alone will identify all threats.

Solution: Tools augment, not replace, human analysis. Use tools like STRIDE-GPT or Microsoft Threat Modeling Tool to accelerate analysis, but validate findings with security experts and developers who understand your specific architecture.

Pitfall 4: Static Models in Dynamic Environments

Problem: Threat models become outdated as systems evolve.

Solution: Treat threat models as living documents. Trigger reviews when:

• New third-party integrations are added
• Major refactoring occurs
• Security incidents are discovered
• Regulatory requirements change
• Annually at minimum

Real-World Case Study: Securing a Modern CI/CD Pipeline

Let’s examine how a fictional company, TechCorp, applied STRIDE to prevent a supply chain attack:

Initial State: TechCorp used GitHub Actions with npm packages, deployed to AWS ECS, and experienced a security scare when a dependency was compromised.

STRIDE Analysis Process:

1. Created DFD: Mapped entire pipeline from developer commit to production
2. Applied STRIDE: Identified 47 potential threats across 8 components
3. Prioritized: Focused on 12 high-priority threats
4. Implemented Controls:

# Implemented SLSA Level 3 builds
name: SLSA Build
on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write  # For OIDC
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build with provenance
        uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
        
      - name: Verify dependencies
        run: |
          npm ci  # Use clean install
          npm audit fix --audit-level=high
          
      - name: Generate SBOM
        run: cyclonedx-cli analyze
        
      - name: Sign artifacts
        uses: sigstore/[email protected]

Results After 6 Months:

• Zero supply chain incidents
• 85% reduction in vulnerable dependencies
• Complete provenance chain for all production artifacts
• Automated threat model updates on every architecture change

Integrating STRIDE with Other Frameworks

STRIDE works best when combined with complementary security frameworks:

STRIDE + SLSA (Supply-chain Levels for Software Artifacts)

SLSA provides maturity levels for build integrity:

• Level 1: Documentation of build process
• Level 2: Tamper-proof build service
• Level 3: Hardened builds with provenance
• Level 4: Hermetic, reproducible builds

Use STRIDE to identify threats, then implement SLSA controls as mitigations.

STRIDE + MITRE ATT&CK

Map STRIDE threats to ATT&CK techniques for supply chain attacks:

• Spoofing → Compromise Accounts (T1586)
• Tampering → Supply Chain Compromise (T1195)
• Elevation of Privilege → Valid Accounts (T1078)

STRIDE + OWASP Top 10 CI/CD Risks

Align STRIDE findings with OWASP’s specific CI/CD security risks:

• CICD-SEC-1: Insufficient Flow Control Mechanisms
• CICD-SEC-2: Inadequate Identity and Access Management
• CICD-SEC-3: Dependency Chain Abuse

Conclusion

The XZ Utils backdoor serves as a stark reminder that supply chain security requires systematic, proactive approaches. STRIDE threat modeling provides that structure, transforming the nebulous question “what could go wrong?” into concrete, actionable analysis.

Key Takeaways

1. Supply chain attacks are accelerating: Frequency doubled in 2024, with increasingly sophisticated techniques
2. STRIDE provides systematic coverage: Six categories ensure comprehensive threat identification
3. Focus on trust boundaries: Critical transition points where privilege levels change require extra scrutiny
4. Automate where possible: Integrate threat modeling into CI/CD for continuous validation
5. Combine frameworks: STRIDE + SLSA + SBOM provides layered defense

Next Steps

Start your threat modeling journey:

1. This Week: Create a basic DFD of your most critical service’s supply chain
2. This Month: Apply STRIDE to identify top 10 threats and implement 3 high-priority mitigations
3. This Quarter: Integrate automated security controls into your CI/CD pipeline
4. Ongoing: Establish quarterly threat model reviews and incident response procedures

Remember: Perfect security is impossible, but systematic threat modeling dramatically reduces your attack surface. The goal isn’t to eliminate all risks—it’s to identify, prioritize, and mitigate the most critical threats to your software supply chain.

---

References:

1. OWASP Threat Modeling Cheat Sheet - Comprehensive guide to threat modeling methodologies including STRIDE
2. Enhancing Software Supply Chain Security Through STRIDE-Based Threat Modelling of CI/CD Pipelines - Academic research on applying STRIDE to CI/CD security
3. Sonatype State of the Software Supply Chain 2024 - Industry data on supply chain attack trends
4. CISA Alert: XZ Utils CVE-2024-3094 - Official guidance on XZ Utils backdoor
5. Cyble Supply Chain Attack Analysis 2025 - Recent supply chain attack statistics and trends
6. SLSA Framework Documentation - Supply-chain Levels for Software Artifacts framework
7. Drata STRIDE Threat Model Guide - Practical implementation guidance and best practices