<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->
---
name: performing-supply-chain-threat-modeling
description: >-
  Threat model software supply chains with SBOM analysis and SLSA assessment.
domain: cybersecurity
subdomain: threat-modeling
tags:
  - supply-chain
  - sbom
  - slsa
  - dependency-analysis
  - build-security
  - third-party-risk
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack:
  - "T1195"
  - "T1195.001"
  - "T1195.002"
  - "T1199"
---

# Performing Supply Chain Threat Modeling

## Overview

Software supply chain attacks target the trust chain from source code through build, package,
distribute, and deploy. This technique applies structured threat modeling to dependency trees,
build pipelines, artifact registries, and third-party integrations using SLSA levels, SBOM
generation, and provenance verification.

Mode: `[MODE: ARCHITECT]` — Supply chain security architecture and trust verification.

## Prerequisites

- Dependency manifests (package.json, requirements.txt, go.sum, Cargo.lock)
- CI/CD pipeline configuration
- `syft` for SBOM generation: `curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh`
- `grype` for vulnerability scanning: `curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh`
- Python 3.10+

## Key Concepts

### Supply Chain Attack Vectors

| Vector | Description | Example |
|--------|-------------|---------|
| **Dependency confusion** | Substitute internal package with malicious public one | PyPI namespace squatting |
| **Typosquatting** | Register similar package name | `lodash` vs `lodahs` |
| **Compromised maintainer** | Attacker gains package publish rights | Event-stream incident |
| **Build system compromise** | Inject code during CI/CD build | SolarWinds attack |
| **Registry poisoning** | Upload malicious artifacts to registry | npm cache poisoning |

### SLSA Levels

| Level | Requirements |
|-------|-------------|
| SLSA 0 | No guarantees |
| SLSA 1 | Build process documented |
| SLSA 2 | Hosted, authenticated build; signed provenance |
| SLSA 3 | Hardened build platform; non-falsifiable provenance |
| SLSA 4 | Hermetic, reproducible build; two-person review |

## Workflow

### Step 1: Generate SBOM

```bash
syft dir:. -o spdx-json > sbom.json
node scripts/agent.js --action enumerate --input sbom.json
```

### Step 2: Assess Supply Chain Threats

```bash
node scripts/agent.js --action threats --input dependencies.json
node scripts/agent.js --action slsa --input pipeline.json
```

### Step 3: Generate Report

```bash
node scripts/agent.js --action report --input threats.json --output report.json
```

## Verification

- [ ] SBOM generated for all deployable artifacts
- [ ] Dependencies scanned for known vulnerabilities (CVEs)
- [ ] Dependency confusion protections verified (private registry, scoped packages)
- [ ] Build pipeline assessed against SLSA levels
- [ ] Artifact signing and provenance verification in place
- [ ] Third-party integration trust boundaries documented

## References

- [SLSA Framework](https://slsa.dev/)
- [NIST SP 800-218 — SSDF](https://csrc.nist.gov/publications/detail/sp/800-218/final)
- [CISA SBOM Resources](https://www.cisa.gov/sbom)
- [OpenSSF Scorecard](https://securityscorecards.dev/)
- [MITRE ATT&CK — Supply Chain Compromise](https://attack.mitre.org/techniques/T1195/)
