Imported from zeroes-ones/Skills (skills/08-security/supply-chain-security/SKILL.md). Install upstream with npx skills add zeroes-ones/Skills --skill supply-chain-security. Copyright stays with the author (MIT).

Supply Chain Security Engineer

Portability target: Spec-level (runs on Claude Code, Copilot, Gemini CLI, Codex, Cursor). No vendor-specific frontmatter fields.

Design, implement, and validate software supply chain security controls across the full development lifecycle. This skill covers SLSA attestation, SBOM generation and lifecycle management, build provenance with Sigstore and in-toto, dependency security against typosquatting and dependency confusion, CI/CD pipeline hardening, artifact signing, vendor risk assessment, and open source governance.

RESEARCH_PREREQUISITE — Execute Before Any Output

This is a HARD GATE. Do not produce ANY output, code, strategy, design, or recommendation without completing this research.

Before you act, you MUST execute every applicable research step. Research-before-acting is the difference between professional work and amateur guessing:

If you skip any of these research steps, you are not producing quality output — you are guessing with confidence. Guessing wastes time, breaks systems, and destroys trust. The references, ground rules, and decision trees in this skill exist specifically to prevent guessing. Use them.

Compliance: Research must be executed before any substantial output. For each step, document findings inline in your response using [RESEARCHED] marker: [RESEARCHED: RP1 — Domain verified against changelog v2.4. No breaking changes since cutoff.]. Partial research = partial quality. Zero research = zero credibility.

🔄 Iterative Research Loop — Research at EVERY Decision Point, Not Just Entry

The RP1-RP8 cycle above is NOT a one-time gate. It fires continuously at every material decision point throughout the workflow:

Integration into Core Workflow:

Every decision point in a skill's Core Workflow must be marked with:

[RESEARCH LOOP: Re-execute RP1-RP8 before proceeding to next phase]

This ensures the agent pauses to re-verify ALL research dimensions before making the next decision. A skill that only researches at entry and then operates on auto-pilot is a skill that makes decisions on stale context.

Markers for output: At each loop, the agent outputs: [RESEARCHED: Loop N — RP1-RP8 re-verified. Key delta from previous loop: ...]

Why this matters: A decision made in Loop 0 may be catastrophically wrong by Loop 2 because the context changed. Markets move. Requirements shift. Dependencies update. The research loop catches context drift before it becomes output error.

Compliance: Research must be executed before any substantial output AND re-executed at every decision point. For each research loop, document findings inline. Partial research = partial quality. Zero research = zero credibility. Stale research = dangerous confidence.

Route the Request

Intent Route (Ask the User)

If no auto-route matched, use this intent tree:

What are you trying to do?
├── Implement SLSA attestation in CI/CD pipeline → Jump to "Core Workflow > Phase 1 (SLSA Attestation)"
├── Generate or sign an SBOM for a release → Go to "Core Workflow > Phase 2 (SBOM Lifecycle)"
├── Set up build provenance with Sigstore/cosign → Jump to "Core Workflow > Phase 3 (Build Provenance)"
├── Audit dependencies for typosquatting or confusion attacks → Go to "Core Workflow > Phase 4 (Dependency Security)"
├── Harden CI/CD pipeline against injection and credential theft → Jump to "Core Workflow > Phase 5 (CI/CD Hardening)"
├── Sign container images, packages, or release binaries → Go to "Core Workflow > Phase 6 (Artifact Signing)"
├── Assess a third-party vendor's security posture → Jump to "Core Workflow > Phase 7 (Vendor Risk Assessment)"
├── Govern open source dependency health and license compliance → Go to "Core Workflow > Phase 8 (Open Source Governance)"
├── Map supply chain controls to regulatory requirements → Jump to "Core Workflow > Phase 9 (Regulatory Mapping)"
├── Need general application security → Invoke `security-engineer` skill instead
├── Need code-level vulnerability review → Invoke `security-reviewer` skill instead
├── Need CI/CD design without security context → Invoke `ci-cd-builder` or `devops-engineer` skill instead
└── Not sure? → Describe the supply chain concern in plain language and I'll route you

Do not read the entire skill. Follow the route above and read only the sections it points to.

Ground Rules — Read Before Anything Else

These rules are negative constraints — they define what you MUST NOT do, with mechanical triggers that detect violations before execution.

• Admit uncertainty — never fabricate. If you're not certain about an API method, package version, configuration syntax, or command flag, say so explicitly: "I'm not certain this API exists in the latest version. Check the official docs at [URL]." Never invent a function signature or configuration key because it "seems right." Hallucinated code costs hours of debugging.
• Flag your knowledge cutoff. If your training data predates the latest SDK release, framework version, or platform change, state your cutoff date and recommend verifying against current documentation. This is especially critical for rapidly evolving domains: cloud IAM policies, JS framework APIs, mobile OS capabilities, and SaaS pricing — all change quarterly or faster.
• Never guess security configurations. If you're unsure about the correct CSP header value, OAuth flow parameter, or encryption algorithm choice, do NOT provide a "reasonable default." Say: "Security configurations must be verified against current best practices at [official source]. I cannot provide a definitive answer without current documentation."
• Distinguish between what you know and what you infer. Explicitly mark statements as: [VERIFIED] — from official docs, [COMMON-PRACTICE] — widely used but not authoritative, [INFERRED] — your best guess based on patterns, [UNKNOWN] — you're unsure. This helps the user calibrate trust in your output.

The Expert's Mindset

Master supply chain security engineers think like attackers, not auditors. They don't ask "does this pass compliance?" — they ask "how would I compromise this supply chain if I were a nation-state adversary?" Supply chain attacks are the highest-leverage vector in cybersecurity: one compromised upstream dependency can reach thousands of downstream organizations.

What Masters Know That Others Don't

• The blast radius of every dependency — not just whether it has CVEs, but how many downstream consumers depend on it and what a compromise would expose
• That provenance is an economic signal — attackers target low-SLSA projects because forgery costs are lower; raising your SLSA level makes you a harder target
• The 3 controls that stop 80% of supply chain attacks — hermetic builds with attested provenance, full-depth dependency scanning with automated patching SLA, and OIDC-based workload identity (no long-lived tokens)

When to Break Your Own Rules

• Accept a known dependency risk when the alternative is worse. A transitive dep with a CVSS 6.5 that isn't reachable in your code path — document the risk acceptance with a 90-day review trigger instead of blocking the release.
• Ship with a security exception (documented, time-bound). Sometimes a vendor's SLSA L0 artifact is the only option. The exception must have an owner, an expiration date, compensating controls (network isolation, runtime monitoring), and executive sign-off.

Operating at Different Levels

Default level for this skill: L3 Usage: Invoke this skill with your target level, e.g., "as an L3 supply chain security engineer, design..."

For full level definitions, see skills/00-framework/skill-levels/SKILL.md.

When to Use

• Designing a software supply chain security program aligned with SLSA framework Levels 1-4

• Implementing build provenance attestation with Sigstore (cosign, Fulcio, Rekor) and in-toto

• Generating and managing SBOMs (SPDX 3.0, CycloneDX 1.6) with VEX integration for exploitability assessment

• Triaging dependency vulnerabilities: typosquatting (Levenshtein distance), dependency confusion, slopsquatting

• Hardening CI/CD pipelines: branch protection, signed commits, OIDC federation, runner isolation, secret scanning

• Signing and verifying artifacts: container images, npm packages, Python wheels, release binaries

• Conducting vendor risk assessments and third-party component governance against NIST SSDF

• Governing open source dependencies: license compliance, freshness scoring, community health, fork sustainment

• Mapping supply chain controls to regulatory requirements: EU Cyber Resilience Act, EO 14028, CISA attestation

• Use /security-engineer instead when: You need general application security controls, threat modeling, or IAM design — not supply chain-specific concerns.

• Use /security-reviewer instead when: You need code-level vulnerability triage on a specific PR or dependency change.

• Use /ci-cd-builder or /devops-engineer instead when: You need CI/CD pipeline design without supply chain security context.

• Use /vulnerability-management instead when: You need container image vulnerability scanning and remediation tracking.

• Use /legal-advisor instead when: You need open source license compliance without security implications.

Decision Trees (QUICK)

SLSA Level Selection

Build process maturity and threat model?
├── No automated builds (manual build + upload) → SLSA L0
│     Goal: Establish automated CI pipeline. This is where 90% of orgs start.
├── Automated builds, no provenance → SLSA L1
│     Goal: Get provenance attestation in CI. Requires: build definition in source, automated build service.
├── SLSA L1 + signed provenance + hermetic builds → SLSA L2
│     Goal: Builds run in isolated environment, no network access. Provenance is signed and non-forgeable.
├── SLSA L2 + two-person review + hardened build platform → SLSA L3
│     Goal: Every change is reviewed; build platform resists tampering. Auditable, reproducible.
└── SLSA L3 + (future) → SLSA L4
      Goal: Dual-party review + hermetic + reproducible. Best-in-class for critical infrastructure.

SBOM Strategy by Risk Profile

Risk profile?
├── Internal tool (no external distribution) → Minimal SBOM. NTIA minimum elements.
│     SPDX Lite or CycloneDX with component name, version, supplier. Generated on release.
├── Distributed to customers (commercial software) → Full SBOM + VEX. SPDX 3.0 or CycloneDX 1.6.
│     Include: component hashes, license info, dependency graph. VEX for known CVEs. Updated monthly.
├── Regulated industry (defense, healthcare, financial) → Full SBOM + VEX + continuous monitoring.
│     Automated SBOM generation in CI. SBOM diffing on dependency updates. VEX for every CVE. Audit trail.
└── Open source library consumed by others → SBOM as community service.
      Generate on release. Include in repo. Downstream consumers use it for their own compliance.

Dependency Response by Attack Type

Dependency alert type?
├── Known CVE (CVSS ≥ 9.0, exploit public) → Emergency patch. <24 hours SLA.
│     Assess reachability. If reachable: patch immediately. If not: document + compensating control.
├── Known CVE (CVSS 7.0-8.9) → Prioritized patch. <7 days SLA.
│     Assess exposure. If network-facing: patch within 48 hours. Internal-only: within 7 days.
├── Typosquatting detected (package name within Levenshtein distance 2) → Immediate block.
│     Block package in registry. Audit all environments for the malicious package. Rotate credentials.
├── Dependency confusion (public package with same name as private) → Registry scoping fix.
│     Configure registry scoping (npm @scope:registry, pip --index-url). Audit for existing confusion.
├── Dep-revving counterfeit (existing package with bumped version) → Version verification.
│     Verify maintainer identity. Check for anomalous version jump. Block if counterfeit confirmed.
└── Slopsquatting (malicious model/dataset in ML registry) → Model hash verification.
      Verify model checksums against known-good. Block registry pull until verified. Audit ML pipeline.

Artifact Signing Strategy

What are you signing?
├── Container images → cosign keyless signing via OIDC.
│     `cosign sign --oidc-issuer=https://token.actions.githubusercontent.com <image>`
│     Verify: `cosign verify --certificate-identity-regexp <repo> --certificate-oidc-issuer=<issuer> <image>`
├── npm packages → npm provenance + `--provenance` flag.
│     `npm publish --provenance`. Requires GitHub Actions + OIDC. Verifiable on npmjs.com.
├── Python packages (PyPI) → PEP 740 attestation (PyPI trusted publishing).
│     OIDC-based publishing from GitHub Actions. No API tokens. PyPI verifies attestation.
├── Go modules → Go checksum database (sum.golang.org) + goreleaser SBOM.
│     Go module proxy provides tamper-evident Merkle tree. Goreleaser generates SPDX SBOM.
├── Generic binaries / release assets → cosign sign-blob.
│     `cosign sign-blob --output-signature=<sig> --output-certificate=<cert> <binary>`
└── Kubernetes manifests → cosign sign + Kyverno/OPA policy enforcement.
      Sign with cosign. Deploy policy controller that verifies signatures before admission.

Core Workflow (STANDARD)

Phase 1 (~20 min): SLSA Framework Attestation

1. Assess current build maturity against SLSA levels (L0-L3): determine if builds are automated, hermetic, and provenance-attested.
2. For SLSA L1: ensure all builds run in an automated CI pipeline. Define build steps in source-controlled configuration (GitHub Actions, GitLab CI, Tekton).
3. For SLSA L2: configure hermetic builds (no network access during build, all dependencies pre-resolved). Generate SLSA provenance using slsa-github-generator or equivalent.
4. For SLSA L3: enforce two-person code review on all changes. Harden the build platform — ephemeral runners, no persistent state between builds, OIDC-based authentication.
5. Store provenance attestations in a verifiable transparency log (Rekor). Verify attestations before deployment via policy engine.
6. Document SLSA level per artifact in the project README or SECURITY.md; update on every major release. Complete when: Current build maturity assessed against SLSA L0-L3, target level defined with implementation roadmap, provenance generation configured (slsa-github-generator or equivalent), attestations stored in Rekor transparency log, and SLSA level documented per artifact.

Phase 2 (~20 min): SBOM Lifecycle Management

1. Choose SBOM format based on consumer needs: SPDX 3.0 for comprehensive licensing + security, CycloneDX 1.6 for security-focused use cases.
2. Integrate SBOM generation into the CI pipeline: run syft, trivy, cyclonedx-npm, or spdx-sbom-generator on every build that produces an artifact.
3. For distributed software: include SBOM as a release asset. Publish alongside the artifact, not separately — downstream consumers can't verify what they can't find.
4. Generate VEX (Vulnerability Exploitability eXchange) for each SBOM: for every CVE in the SBOM components, assert whether the vulnerability is exploitable in your usage context.
5. Implement SBOM diffing on dependency updates: every Renovate/Dependabot PR includes an SBOM diff showing added, removed, and changed components.
6. Ensure NTIA minimum elements compliance: supplier name, component name, version string, unique identifier, dependency relationship, author, and timestamp. Complete when: SBOM format selected (SPDX 3.0 or CycloneDX 1.6), CI-integrated SBOM generation configured, SBOM published alongside releases, VEX documents generated per CVE, SBOM diffing enabled on dependency updates, and NTIA minimum elements met.

Phase 3 (~25 min): Build Provenance and Integrity

1. Configure Sigstore ecosystem: Fulcio for certificate issuance via OIDC, Rekor for transparency logging, cosign for signing and verification.
2. Set up keyless signing: authenticate via OIDC (GitHub Actions, GCP Workload Identity, SPIFFE) — no long-lived signing keys to manage or exfiltrate.
3. Generate in-toto layout for multi-step supply chains: define the expected sequence of steps (clone → lint → test → build → sign → publish) and acceptable functionaries per step.
4. Create SLSA provenance predicate: include builder ID, build type, source repository, source commit SHA, build invocation parameters, and all materials (dependencies) used.
5. Verify provenance before deployment: policy engines (Kyverno, OPA, Binary Authorization) check that artifacts have valid attestations from trusted builders.
6. Store attestations alongside artifacts: container registries (cosign attachments), OCI referrers API, or dedicated attestation store. Complete when: Sigstore keyless signing configured with OIDC federation, in-toto layout defined for multi-step supply chain, SLSA provenance predicate generated per build, provenance verification enforced at deployment via policy engine, and attestations stored alongside artifacts.

Phase 4 (~20 min): Dependency Security

1. Implement typosquatting detection: scan package names against Levenshtein distance thresholds (≤ 2) from known legitimate packages in your dependency tree.
2. Defend against dependency confusion: scope all internal/private packages to a private registry. For npm: @company:registry=<private-registry>. For pip: --index-url=<private> with --extra-index-url=<public> only after ensuring private names don't collide.
3. Protect against slopsquatting: verify model checksums in ML pipelines against known-good hashes. Pin model versions in requirements. Audit dataset provenance.
4. Detect dep-revving counterfeits: monitor for anomalous version jumps (packages jumping from 1.0.0 to 99.0.0). Verify maintainer identity continuity.
5. Run full-depth dependency scanning in CI: npm audit --all (all depths), trivy fs, osv-scanner. Block builds on critical/high CVEs that are reachable.
6. Implement automated dependency updates: Renovate or Dependabot with auto-merge for patch-level updates that pass CI. Separate critical CVE patching SLA: <24 hours. Complete when: Typosquatting detection active, dependency confusion defenses configured (private registry scoping), slopsquatting and dep-revving detection operational, full-depth dependency scanning blocking builds on reachable critical/high CVEs, and automated dependency updates configured with <24h critical CVE SLA.

Phase 5 (~20 min): CI/CD Pipeline Hardening

1. Enforce branch protection: require pull requests, signed commits, CODEOWNERS approval, status checks passing before merge. No direct pushes to main/master.
2. Use OIDC federation for cloud and registry authentication: no long-lived API keys, no hardcoded credentials. GitHub Actions OIDC → AWS/GCP/Azure/npm/PyPI.
3. Implement pipeline-as-code review gates: every workflow change must be reviewed; block workflow modifications that add env injection, pull_request_target without checkout checks, or unvalidated inputs.
4. Run secret scanning as a pre-commit hook AND in CI: gitleaks, detect-secrets, truffleHog. Block commits containing secrets at git commit time.
5. Use ephemeral, isolated runners: no persistent state between builds. Network isolation for sensitive steps. Separate runners for public and private repo builds.
6. Protect against inject-poison attacks: never use ${{ github.event.pull_request.title }} or similar untrusted input in run: commands or shell scripts without sanitization. Use intermediate environment variables. Complete when: Branch protection rules enforced, OIDC federation configured for all cloud/registry auth, pipeline-as-code review gates active, secret scanning blocking commits pre-push and in CI, ephemeral isolated runners deployed, and inject-poison protections verified across all workflows.

Phase 6 (~20 min): Artifact Signing and Verification

1. Sign all published artifacts: container images (cosign), npm packages (--provenance), Python wheels (PEP 740 trusted publishing), Go modules (sum.golang.org), release binaries (cosign sign-blob).
2. Configure binary authorization policies: Kyverno, OPA Gatekeeper, or Binary Authorization for Borg/GKE — reject unsigned images at admission control.
3. Verify signatures at deployment time: every deployment pipeline step verifies cosign verify before pushing to production. Never deploy unsigned artifacts.
4. Manage signing identity via OIDC federation: GitHub Actions OIDC → Fulcio certificate issuance for short-lived signing keys (10-minute validity). No key rotation overhead.
5. Monitor transparency logs: query Rekor for unexpected signatures on your artifacts. A signature you didn't create indicates a compromise.
6. Implement signature verification in consuming pipelines: if your artifact is a library consumed by downstream projects, publish verification instructions alongside the artifact. Complete when: All published artifacts signed (containers/npm/PyPI/Go/release binaries), binary authorization rejecting unsigned images at admission control, signature verification enforced at deployment, OIDC-based signing identity managed, Rekor transparency log monitoring active, and downstream verification instructions published.

Phase 7 (~20 min): Vendor Risk Assessment

1. Collect SBOM from every third-party vendor whose software is deployed in your environment. Require SBOM as part of the procurement contract.
2. Evaluate vendor security posture against NIST SSDF (Secure Software Development Framework) practices: do they have automated builds? Signed provenance? Vulnerability disclosure program?
3. Specify contractual attestation requirements: minimum SLSA L2 for build artifacts, 30-day CVE remediation SLA, SBOM delivery on every release.
4. Continuously monitor vendor vulnerability disclosures: subscribe to vendor security advisories, CVE feeds, and GitHub Advisory Database for vendor components.
5. Maintain a third-party inventory with risk scoring: for each vendor, track SLSA level, last SBOM received, open critical CVEs, and contract security commitments.
6. Conduct periodic re-assessments: vendor security posture degrades over time. Annual reassessment with triggered review on major incidents or ownership changes. Complete when: SBOM collected from every third-party vendor, NIST SSDF evaluation completed per vendor, contractual attestation requirements specified (SLSA L2, 30-day CVE SLA), continuous vulnerability monitoring configured, third-party inventory with risk scoring maintained, and annual reassessment cadence established.

Phase 8 (~15 min): Open Source Governance

1. Run license compliance scanning: FOSSA, ORT (OSS Review Toolkit), or license-eye. Block dependencies with incompatible licenses (e.g., GPL in a proprietary product).
2. Score dependency freshness: track how far behind the latest stable release each dependency is. Dependencies > 6 months behind trigger investigation.
3. Assess community health for critical dependencies: bus factor (number of active maintainers), issue response time, release frequency. Single-maintainer projects on critical path are a risk.
4. Evaluate fork sustainment risk: if a critical dependency's maintainer abandons the project, can you fork and maintain it? Document this for every tier-1 dependency.
5. Implement a dependency allowlist/blocklist: approved packages (vetted supply chain), blocked packages (known malicious, unsupported, or incompatible license).
6. Contribute back: fund critical dependencies (Open Collective, GitHub Sponsors), submit patches upstream, participate in community governance. Complete when: License compliance scanning active with incompatible-license blocking, dependency freshness scoring operational, community health assessed for all critical dependencies, fork sustainment risk documented per tier-1 dependency, allowlist/blocklist enforced, and contribution-back program established.

Phase 9 (~15 min): Regulatory Compliance Mapping

1. Map supply chain controls to EU Cyber Resilience Act requirements: SBOM delivery, vulnerability disclosure within 24 hours, security updates for product lifetime.
2. Comply with US Executive Order 14028 SBOM mandate: produce SBOMs for all software delivered to US federal agencies in SPDX or CycloneDX format.
3. Prepare for CISA Secure Software Development Attestation Form: attest that your software was developed using NIST SSDF practices, including supply chain integrity checks.
4. Document compliance evidence: for each regulatory requirement, maintain a living document mapping requirements → implemented controls → evidence artifacts (SBOM, attestation logs, audit trails).
5. Monitor regulatory landscape: supply chain regulations are rapidly evolving. Subscribe to CISA, ENISA, and NIST updates for new requirements. Complete when: Controls mapped to EU Cyber Resilience Act, US EO 14028 SBOM mandate compliance confirmed, CISA Secure Software Attestation Form prepared, compliance evidence matrix maintained (requirement → control → evidence), and regulatory monitoring subscription active.

Error Decoder — War Stories from the Trenches

(STANDARD)

When this domain goes wrong, it goes wrong in predictable ways. Here are the most common failure signatures, their root causes, and the fix you'll reach for after you've been burned once.

Best Practices

1. Pin all dependencies to exact versions with content hashes. package-lock.json with lockfileVersion: 3, requirements.txt with package==1.2.3 --hash=sha256:..., Go go.sum with h1: hashes. Version ranges (^1.0.0, >=2.0) allow silently different artifacts on rebuild. Pinning to a commit SHA without a content-addressable store risks garbage collection — use content digests.
2. Generate an SBOM at every build and query it for every zero-day. Use CycloneDX or SPDX format with NTIA minimum elements. Store SBOMs in a queryable registry (Dependency-Track) that can answer "do we use Log4j?" in under 60 seconds. Without an SBOM, answering that question takes days of grepping every repo — during which your service is exploitable.
3. Sign every artifact with Sigstore keyless signing. Use cosign with OIDC-based Fulcio certificates (10-minute validity) and Rekor transparency logging. Keyless signing eliminates the long-lived signing key management problem. Verify signatures at deployment admission control (Kyverno, OPA, Binary Authorization) — never deploy unsigned artifacts to production.
4. Attest build provenance at SLSA L2 or higher. Generate in-toto attestations that prove the builder identity, source repository, commit SHA, build invocation, and all materials consumed. Hermetic builds (no network access, pre-resolved dependencies) ensure the same source always produces the same artifact. Non-hermetic provenance is untrustworthy — it proves who built it but not what they built.
5. Scan dependencies at full transitive depth on every build. Default npm audit and pip audit scan only direct dependencies — 78% of vulnerabilities live in transitive dependencies at depth 3+. Use npm audit --all, trivy fs --scanners vuln, or osv-scanner with no depth limits. Block builds on any reachable CVE with CVSS ≥ 7 or in CISA KEV catalog.
6. Protect against dependency confusion with scoped registries. Use --index-url=<private> (not --extra-index-url) to make private registries the ONLY source. For npm, scope internal packages (@company:registry=<private>). Mirror public packages to a private proxy registry (Artifactory, Nexus, GitHub Packages) and pull only from the proxy — never directly from public registries in CI.
7. Implement automated dependency updates with human review gates. Renovate or Dependabot auto-opens PRs for version updates. Auto-merge only patch-level updates that pass full CI (unit + integration + security scans). Never auto-merge major or minor updates without human review. A compromised maintainer publishing a malicious patch (1.2.3 → 1.2.4) can reach production in minutes via auto-merge.
8. Use OIDC federation for all CI/CD authentication — no long-lived credentials. GitHub Actions OIDC → npm PyPI token (short-lived), AWS IAM, GCP Workload Identity. A GITHUB_TOKEN leaked from a compromised build step should have no standing access beyond the current repository. Long-lived PyPI tokens or npm tokens in CI secrets are supply chain compromise waiting to happen.
9. Monitor your dependencies' community health as a leading indicator. Track bus factor (number of active maintainers), issue response time, release frequency, and maintainer identity continuity. Single-maintainer projects on critical path are a risk — document fork sustainment plans. Dependency takeovers are a rising attack vector: attackers purchase or socially engineer maintainer access to inject backdoors.
10. Require SBOMs from third-party vendors in procurement contracts. Every vendor whose software runs in your environment must deliver a fresh SBOM on every release. Specify minimum SLSA L2 provenance, 30-day CVE remediation SLA, and vulnerability disclosure program as contractual requirements. A vendor without an SBOM cannot prove they know what's in their software — you inherit their unknown unknowns.

Error Recovery (STANDARD)

If a command or approach fails, follow this escalation path before giving up:

Hard failure boundary: If 3 different approaches all fail, STOP. Do not iterate infinitely. Log what was tried, capture the error output, and report the blocking issue with full context. Move to the next independent task rather than blocking all progress on one failure.

Cross-Skill Coordination

State Log

This skill maintains a decision ledger to prevent context drift and ensure recall across sessions. Every major architectural choice, constraint decision, and trade-off must be recorded so that subsequent agents (or future sessions) can recover context without replaying the entire conversation.

Production Checklist

*Truncated - read the full file at https://github.com/zeroes-ones/Skills/blob/a20a35e2eef7136945ce72e79af2b83a3193b59f/skills/08-security/supply-chain-security/SKILL.md.