auditing-supply-chain

Your build pipeline runs more untrusted code than your application does. A single unpinned action, a postinstall script, or a workflow with a writable token is a path from a stranger's commit to your production artifacts and your signing keys.

When to Use

• Assessing risk from third-party dependencies in an application
• Reviewing CI/CD pipelines, GitHub Actions, and release automation
• Investigating a suspicious or malicious package
• Producing or reviewing an SBOM
• Hardening build provenance and artifact signing
• Responding to a disclosed upstream compromise

When NOT to Use

• Vulnerabilities in first-party code — use auditing-code-for-vulnerabilities
• Model and dataset provenance — use securing-ai-systems
• Cloud infrastructure posture generally — use exploiting-cloud-platforms

for offensive assessment

• An in-progress compromise — use responding-to-incidents
• Prioritizing which of many dependency CVEs to fix first — use

managing-vulnerabilities; reachability analysis here feeds its ranking

Two Different Risks

Keep them separate; they need different responses.

Most programs handle the first and are blind to the second. Give the second explicit attention.

Dependency Review

# Known vulnerabilities, ecosystem-agnostic
osv-scanner --lockfile=package-lock.json --lockfile=go.sum --lockfile=Cargo.lock
trivy fs --scanners vuln,secret,misconfig .
grype dir:.

# Ecosystem-native
npm audit --omit=dev && npm ls --all --depth=99 | wc -l   # count transitives
pip-audit -r requirements.txt
cargo audit
govulncheck ./...    # reachability-aware: only reports vulns you actually call
mvn dependency-check:check

govulncheck-style reachability analysis matters: a vulnerability in a code path you never execute is a patching task, not a risk. Prioritize by reachability plus exposure, not by CVSS alone.

Transitive depth is the real surface. Direct dependencies are chosen and reviewed; transitive ones are inherited. Count them, and know which maintainers you are implicitly trusting.

Detecting Malicious Packages

Triage signals, roughly in order of how strongly they indicate malice:

# Review what actually ships, not what the repo shows
npm pack <pkg> && tar -xzf <pkg>.tgz && rg -n 'child_process|eval\(|Buffer\.from\(.*base64|https?://' package/
pip download --no-deps --no-binary :all: <pkg> && tar -xzf <pkg>.tar.gz
rg -n 'os\.system|subprocess|urllib|requests|__import__|exec\(' <pkg>/setup.py

# Block install scripts by default in CI
npm ci --ignore-scripts
pip install --require-hashes -r requirements.txt

Dependency confusion: if an internal package name is not also registered (or reserved) on the public registry, and the resolver can reach the public registry, an attacker can publish a higher version and win resolution.

# Enumerate internal-looking names and check public availability
rg -o '"@?[a-z0-9-]+/[a-z0-9-]+"' package.json | sort -u
# Fix: scoped registries with strict scope→registry mapping, and
# `.npmrc` / `pip.conf` that never falls back to the public index for
# internal scopes

Lockfiles and Pinning

• Lockfiles must be committed, reviewed in PRs, and CI must install from

the lockfile (npm ci, pip install --require-hashes, cargo --locked, go mod verify) rather than resolving fresh.

• A lockfile diff in a PR that touches packages unrelated to the change is a

review flag, not noise.

• Pin by integrity hash where the ecosystem supports it. Version pinning alone

does not protect against a re-published version in registries that permit it.

CI/CD Pipeline Security

This is where the highest-impact findings usually are.

GitHub Actions

# Unpinned third-party actions — anyone who controls the tag controls your CI
rg -n 'uses:\s+(?!actions/)[^@]+@(?!v?[0-9a-f]{40})' .github/workflows/

# The dangerous trigger: pull_request_target runs with repo secrets and
# write-capable tokens, in the base repo context
rg -n 'pull_request_target|workflow_run' -A15 .github/workflows/

# Script injection: untrusted event data interpolated directly into a shell
rg -n '\$\{\{\s*github\.event\.(issue|pull_request|comment|head_commit)' .github/workflows/

Three findings to check for on every repository:

1. pull_request_target + checkout of the PR head. This executes a

stranger's code with your secrets. It is a critical finding whenever the workflow also runs build or test steps from the checked-out tree.

1. Untrusted interpolation into run:. ${{ github.event.issue.title }}

inside a shell block is command injection with a public entry point. Pass through an env: variable and quote it instead.

1. Over-broad permissions. Default GITHUB_TOKEN scope should be

contents: read, elevated per-job only where needed. Check for permissions: write-all and for the absence of any permissions: block.

Also review: self-hosted runners on public repos (persistent compromise, no isolation between jobs), secrets available to fork-triggered workflows, cache poisoning across branches, and artifact upload of build directories that contain credentials.

General pipeline

# Secrets in history, not just in the tree
gitleaks detect --source . --redact
trufflehog git file://. --only-verified

# IaC and container config
trivy config . && checkov -d .
hadolint Dockerfile

Check: who can trigger a deploy, whether deploy credentials are scoped per environment, whether the build is reproducible, whether artifacts are signed, and whether anyone can push directly to the release branch.

SBOM and Provenance

# Generate — from the build, not from the source tree, so it reflects reality
syft dir:. -o cyclonedx-json=sbom.json
cdxgen -o sbom.json

# Consume — an SBOM is only useful if you scan it on a schedule
grype sbom:sbom.json
osv-scanner scan source -L sbom.json   # v2 takes SBOMs via -L; --sbom is gone

An SBOM produced once for a compliance checkbox has no security value. The value is in re-scanning existing SBOMs when a new vulnerability lands, which answers "are we affected" in minutes instead of days.

Provenance (SLSA framing): can you prove which source commit produced a given artifact, on which builder, with which dependencies? Sign artifacts (cosign), record attestations, and verify signatures at deploy time. An unverified signature is decoration.

cosign sign --key <key> <image>
cosign verify --key <pub> <image>
cosign verify-attestation --type slsaprovenance <image>

Responding to an Upstream Compromise

1. Determine exposure: did any build pull the affected version? Check
   lockfiles across branches AND build logs — the lockfile shows intent, the
   build log shows what was actually installed.
2. Assume credential compromise on any host that ran the package's install
   scripts. Rotate: registry tokens, cloud keys, signing keys, SSH keys.
3. Preserve build logs and runner images before they roll off.
4. Check outbound network from build hosts for the exfil window.
5. Pin and rebuild; verify the rebuilt artifact differs only as expected.
6. Only then publish an advisory.

Rotation is not optional because the package "only ran in CI." CI is where the production credentials live.

Rationalizations to Reject

• "It's a dev dependency." Dev dependencies run on developer laptops and

build servers with full credentials. That is a worse target than production.

• "It has 10 million downloads a week, it must be safe." Popularity is what

makes it a target. Several of the largest incidents were top-100 packages.

• "The scanner shows no CVEs." Scanners find known vulnerabilities. A

package that was malicious from its first publish has no CVE.

• "We'll pin it later." Unpinned actions and images are the standing risk;

pinning takes minutes.

• "The workflow is only triggered on PRs." pull_request_target on PRs is

exactly the dangerous case.

• "It's an internal package name, no one knows it." Package names leak

through error messages, source maps, job logs, and public forks.

• "We generated an SBOM." Generating is not monitoring.

Deliverable

• Dependency inventory with direct/transitive counts and maintainer

concentration

• Known-vulnerability findings prioritized by reachability and exposure
• Malicious-package triage results with the signals checked
• Pipeline findings, with pull_request_target, unpinned actions, token

scope, and injection sinks each explicitly stated as present or absent

• Secrets exposure (tree and history), with rotation status
• Provenance maturity: pinning, signing, attestation, verification-at-deploy
• Prioritized remediation, separating "patch" from "architectural"

ATT&CK Coverage

Generated from secskills-core/ttp-index.json — edit that file, then run python3 scripts/sync_attack.py --write. Re-verify IDs against the current ATT&CK release before citing them in a report.

Initial Access (TA0001)

• T1195 Supply Chain Compromise
• T1195.001 Compromise Software Dependencies and Development Tools
• T1195.002 Compromise Software Supply Chain

Defense Evasion (TA0005)

• T1553 Subvert Trust Controls — see also analyzing-malware

Credential Access (TA0006)

• T1552 Unsecured Credentials — see also escalating-linux-privileges, exploiting-cloud-platforms, abusing-ci-cd-oidc

Detection content for any of these: engineering-detections. Proactive search: hunting-threats. Post-compromise: responding-to-incidents.

References

• auditing-code-for-vulnerabilities — first-party code review
• securing-ai-systems — model and dataset supply chain
• responding-to-incidents — handling a confirmed upstream compromise
• SLSA framework, OpenSSF Scorecard, CycloneDX/SPDX, Sigstore/cosign
• osv-scanner, trivy, grype, syft, gitleaks, zizmor (Actions auditing)