[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CAP755DB5NFP32MTR4S73V":3,"skill-same:01M6CAP755DB5NFP32MTR4S73V":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6CAP755DB5NFP32MTR4S73V","supply-chain-trust",null,"Decision aid for supply-chain trust beyond CVE\u002FSBOM — pinning depth, reproducible builds, snapshot pins, firmware locking, and vendor+hash-lock for critical-path deps.","jmagly\u002Faiwg","jmagly","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1159087?v=4","01M6C10AK8N2WCSQN11FYGTJWN","Joseph Magly","01M6C10AQ8A2RMED1Y1BSVY7NF",229,"MIT","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Fsecurity-engineering\u002Fskills\u002Fsupply-chain-trust\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"supply","chain","supply chain","supply chain trust","trust","depth","cve","for","path","lock","critical","snapshot","vendor","decision","deps","firmware","supply-chain","SBOM","Reproducible","2026-11-10 10:12:30",false,"---\nnamespace: aiwg\nname: supply-chain-trust\nplatforms: [all]\ndescription: Decision aid for supply-chain trust beyond CVE\u002FSBOM — pinning depth, reproducible builds, snapshot pins, firmware locking, and vendor+hash-lock for critical-path deps.\n\n---\n\n# supply-chain-trust\n\nDecision aid for verifying that the code you ship is the code you think you're shipping. Use when designing or reviewing systems whose threat model includes supply-chain compromise (build host, dependency mirror, package registry, firmware) — which is most production systems in 2026.\n\nThe skill is distinct from `sdlc-complete`'s SBOM and CVE-scanning capabilities. SBOM tells you **what is there**. CVE scanning tells you **what is known-broken**. This skill answers **\"can I prove that what I shipped is what I expected, end-to-end\"** — which neither of the others does.\n\n## Triggers\n\n- \"reproducible build\"\n- \"snapshot pinning\" \u002F \"snapshot.debian.org\"\n- \"vendor wheels\" \u002F \"hash-locked deps\"\n- \"firmware version\" \u002F \"firmware pinning\"\n- \"in-toto\" \u002F \"SLSA\"\n- \"transparency log\" \u002F \"Sigstore\"\n- \"build host compromise\"\n- \"supply chain attack\"\n\n## When NOT to use this skill\n\n- Pure CVE scanning of declared dependencies (use `sdlc-complete\u002Fskills\u002Fsecurity-audit`)\n- SBOM generation (use existing SBOM tooling — CycloneDX, SPDX)\n- License compliance (out of scope; use a license scanner)\n\n---\n\n## Section 1: The four layers of supply-chain trust\n\n```\nLayer 4: Hardware \u002F firmware\n            ↑ (does the chip do what it says?)\nLayer 3: Build environment\n            ↑ (was the binary produced from the source we think?)\nLayer 2: Source dependencies\n            ↑ (did we get the source we expected?)\nLayer 1: Source we wrote\n            ↑ (we can audit this)\n```\n\nEach layer has its own attack surface and its own mitigations:\n\n| Layer | Attack | Mitigation |\n|---|---|---|\n| 1 (own source) | malicious commit by insider | code review, signed commits, branch protection |\n| 2 (deps) | typosquat, compromised maintainer, malicious update | pinning + hash-lock + vendoring; transparency logs |\n| 3 (build) | compromised CI, build host malware | reproducible builds, signed-and-attested artifacts (in-toto, SLSA) |\n| 4 (hardware) | malicious firmware, supply-chain implant | measured boot, vendor diversity, audit |\n\nA system is only as trustworthy as the weakest layer in the chain it actually depends on.\n\n---\n\n## Section 2: Dependency pinning — beyond `requirements.txt`\n\n### Suggested default: full hash-locked dependency manifests\n\nFor each language ecosystem:\n\n| Ecosystem | Default tool | What it produces |\n|---|---|---|\n| Python | `pip-tools` (`pip-compile --generate-hashes`) → `requirements.txt` with hashes | `package==1.2.3 --hash=sha256:abc...` per dep, including transitive |\n| Node | `npm ci` against `package-lock.json` (with `integrity` field), or `pnpm` | per-package SHA-512 integrity |\n| Rust | `cargo` lock file (`Cargo.lock`) — versions only; for hashes use `cargo vet` |\n| Go | `go.mod` + `go.sum` (per-module SHA-256) |\n| Ruby | `Bundler` lockfile + `bundle config set --local frozen true` |\n| Maven\u002FGradle | `dependency:resolve-plugin` with checksum verification |\n\n**Required**: every dependency, including transitive, must have a hash in your lockfile. If a tool can't produce hashed locks, vendor the dep.\n\n### Vendoring critical-path deps\n\nFor dependencies in security-sensitive paths (auth, crypto, key handling), go further than hash-locking — **vendor** them:\n\n```\nyour-repo\u002F\n  vendor\u002F\n    python-fido2-1.1.3\u002F        # checked-in source of the dep\n    cryptography-41.0.7\u002F        # ditto\n    ...\n  Cargo.toml or pyproject.toml  # references vendor\u002F paths, not registry\n```\n\nWhy vendoring on top of hash-locking:\n\n- Hash-locking verifies you got the bytes you expected; vendoring lets you AUDIT those bytes\n- A compromised registry could publish a new \"version\" with a malicious patch; you control what's in `vendor\u002F`\n- Reduces transitive surface — you can prune deps that you don't actually use\n\nCost: you own update cadence. Acceptable for security-critical paths; impractical for everything.\n\n### Anti-pattern: SHA-verified `.deb` whose SHA came from poisoned `apt` repo (review M10)\n\nOriginal: bootstrap verifies SHA-256 of each downloaded `.deb`, but the SHA-256 manifest itself comes from `apt-cache` against the build-time `apt` repo.\n\nWhat this skill flags: the verification is **circular within the same trust domain**. If `apt` is compromised, the manifest is compromised, the SHAs are compromised, all three layers verify a poisoned package.\n\nRemediation:\n\n- **Pin to `snapshot.debian.org`** URLs with a specific timestamp (`http:\u002F\u002Fsnapshot.debian.org\u002Farchive\u002Fdebian\u002F20260301T000000Z\u002F`) — content-addressed, immutable\n- **Verify signed Debian `Release` file** with explicit Debian archive signing keys, ground-truth at the timestamp\n- **Pin transitive `.deb` URLs** discovered at that timestamp; commit the resulting SHA manifest to your **signed** git repo\n\nThe hash of the package must come from a **separately-trusted channel** than the package itself.\n\n---\n\n## Section 3: Reproducible builds\n\n### What it gives you\n\nA reproducible build means: given the same source, the same build environment, and the same build inputs, **any builder produces a byte-for-byte identical output**. This lets you:\n\n- Verify a third-party-built binary against your own rebuild\n- Detect compromised CI by comparing CI output to your local rebuild\n- Allow others to verify your published artifacts by rebuilding from source\n\n### Suggested defaults\n\n| Use case | Approach |\n|---|---|\n| Bootstrap installers | NixOS — reproducible by construction; the entire system specification is hash-tracked |\n| Container images | Bazel + `rules_oci` OR Nix-built OCI images; pinned base layer with verified digest |\n| Linux distro packaging | Reproducible Builds project tooling (`reproducible-builds.org`); `dpkg --reproducible` flag in Debian |\n| Cross-platform binaries | Static linking, hermetic build env (Bazel), check `diffoscope` between rebuilds |\n\n### Verification step\n\n```bash\n# Local rebuild\nbazel build \u002F\u002Fmy:artifact\nsha256sum bazel-bin\u002Fmy\u002Fartifact\n\n# Compare to CI-published\nsha256sum downloaded\u002Fartifact.tar.gz\n\n# If they differ, run diffoscope to see what diverges\ndiffoscope bazel-bin\u002Fmy\u002Fartifact downloaded\u002Fartifact.tar.gz\n```\n\nCommon reproducibility breakers: timestamps in archives, build-time UUIDs, parallel-build nondeterminism, locale-dependent string sorting. The `reproducible-builds.org` site catalogs known issues per ecosystem.\n\n### When reproducibility isn't worth it\n\nFor internal tools with a single source-of-truth build host and signed output, the value is marginal. Reproducibility shines when:\n\n- You publish artifacts users will run (binaries, container images)\n- Your CI runs untrusted code (third-party PRs, etc.)\n- Your build host might be compromised and you want a way to detect it\n\n---\n\n## Section 4: Build attestation (in-toto, SLSA)\n\n### Suggested default: SLSA Level 3+ attestation for production releases\n\nSLSA (Supply-chain Levels for Software Artifacts) defines compliance levels:\n\n| Level | What it requires | What it tells consumers |\n|---|---|---|\n| 0 | nothing | \"this came from somewhere\" |\n| 1 | build process documented | \"the build is repeatable in principle\" |\n| 2 | build runs on hosted CI; provenance generated | \"we know which CI built it\" |\n| 3 | build is hermetic, isolated; provenance is signed and tamper-evident | \"we can prove the build chain end-to-end\" |\n| 4 | additional constraints — two-person review, hermetic builds | \"highest assurance\" |\n\n**Tooling:**\n\n- `cosign` (Sigstore) — signs container images and arbitrary blobs; integrates with Rekor transparency log\n- `slsa-github-generator` — produces SLSA L3 provenance from GitHub Actions\n- `in-toto` (CMU) — generic supply-chain attestation framework\n- `Tekton Chains` — Kubernetes-native build attestation\n\n### Verification on consumer side\n\n```bash\ncosign verify --certificate-identity-regexp=...@my-org \\\n    --certificate-oidc-issuer=https:\u002F\u002Ftoken.actions.githubusercontent.com \\\n    ghcr.io\u002Fmy-org\u002Fmy-image:1.2.3\n```\n\nPin **specific certificate identities and OIDC issuers**. A bare `cosign verify` can be satisfied by any signature.\n\n---\n\n## Section 5: Hardware \u002F firmware version locking\n\n### Required pattern (review L6)\n\nFor systems with hardware-backed cryptographic operations (HSMs, YubiKeys, TPM-equipped hosts), pin to a known-good firmware range. Different firmware versions can have:\n\n- Different cryptographic primitive support (FIDO2 features, attestation behavior)\n- Different timing characteristics (side-channel surface)\n- Different bug profiles\n\nExample: YubiKey 5 firmware 5.4 vs 5.7 have **different FIDO2 PRF behavior**. Code that worked against 5.4 may fail or behave differently on 5.7.\n\n### Inventory pattern\n\n```yaml\n# .aiwg\u002Fsecurity-engineering\u002Fsupply-chain\u002Fhardware-pins.yaml\nyubikey-5:\n  tested-firmware: \"5.4.3, 5.7.1\"\n  acceptable-firmware: \">=5.4.0, \u003C6.0\"\n  test-vectors: \"tests\u002Fyubikey-5-prf.txt\"\n  last-validated: \"2026-04-15\"\n\ntpm-2.0:\n  vendor: \"Infineon\"\n  acceptable-firmware: \">=7.83\"\n  pcr-baseline: \".aiwg\u002Fsecurity-engineering\u002Fchain-of-trust\u002Fpcr-baseline.yaml\"\n```\n\nWhen a new firmware ships, run your test vectors against the new version before allowing it into production.\n\n---\n\n## Section 6: Worked examples\n\n### Review M10 — SHA-256 manifest from poisoned apt source\n\nOriginal: install-pkgs.sh verifies SHA-256 of each `.deb` file against a manifest produced by `apt-cache` at build time.\n\nWhat this skill flags:\n\n- Section 2 anti-pattern: verification within same trust domain as packaging\n- Layer 2 attack: poisoned mirror produces consistent manifest + packages\n\nRemediation:\n\n- Pin to `snapshot.debian.org\u002Farchive\u002Fdebian\u002F\u003Ctimestamp>\u002F` URLs in install scripts\n- Verify Debian `Release` file with explicit archive signing keys (`\u002Fusr\u002Fshare\u002Fkeyrings\u002Fdebian-archive-keyring.gpg`)\n- Generate `.deb` SHA manifest from the snapshot, NOT from `apt-cache`\n- Commit the resulting manifest to a signed git repo\n- Reproducibly rebuild the bootstrap partition; verify rebuild matches published\n\n### Review H3 — `python-fido2` and transitive deps in PRF hot path\n\nOriginal: bootstrap installs `python-fido2`, `cryptography`, `cffi`, `pyusb` from PyPI at first run.\n\nWhat this skill flags:\n\n- Layer 2 attack: PyPI compromise of any of 4+ packages affects PRF hot path\n- Section 2: deps are not vendored OR hash-locked\n\nRemediation (see also `auth-factor-design`):\n\n- Replace `python-fido2` with `libfido2` C tools — drops Python from hot path\n- If Python remains: vendor `python-fido2` + transitive deps with hash-locked wheels in bootstrap blob; verify per-wheel SHA-256 against manifest committed to signed repo; reproducible-build the bootstrap\n\n### Review L6 — firmware version not documented\n\nOriginal: design assumes \"YubiKey 5 with FIDO2 PRF\" without specifying firmware range.\n\nWhat this skill flags:\n\n- Section 5: hardware version not pinned\n\nRemediation:\n\n- Document tested firmware range (e.g., 5.4.0–5.7.x)\n- Maintain test vectors in repo; run against any new firmware before adopting\n- Operationally: standardize procurement to known-good firmware\n\n---\n\n## Section 7: Trust-boundary inventory\n\nMandatory exercise — for every external input to your build, document:\n\n| Input | Source | Verification | Trust anchor |\n|---|---|---|---|\n| Source code (your repo) | git origin | signed commits + signed tags | dev signing keys |\n| Source code (deps) | language registry | hash-locked manifest | dev publishes verified |\n| Base OS packages | snapshot.debian.org | Debian archive key | embedded in keyring |\n| Container base layer | OCI registry | image digest pinned | (none — ASSUMPTION) |\n| Build CI | GitHub Actions | OIDC + SLSA L3 attestation | GitHub OIDC issuer |\n| Hardware | physical procurement | (assumption: vendor not compromised) | (none — ASSUMPTION) |\n| Firmware | (vendor) | version pinned, test vectors run | self-tested |\n\nRows with \"ASSUMPTION\" are explicitly accepted risks. Document why each assumption is acceptable.\n\n---\n\n## Section 8: Output format\n\nWhen invoked as part of a review, produce findings in standard format. When authoring or updating, produce:\n\n- `supply-chain-pins.yaml` — current pins for all layers\n- `hardware-pins.yaml` — firmware versions tested\n- `trust-boundary.md` — inventory and assumption acceptance\n\n---\n\n## Related\n\n- **Existing**: `sdlc-complete\u002Ftemplates\u002Fsecurity\u002Fsbom-guidance.md` (SBOM is upstream of this skill)\n- **Existing**: `sdlc-complete\u002Ftemplates\u002Fsecurity\u002Fdependency-policy-template.md` (this skill operationalizes the policy)\n- **Companion skill**: `chain-of-trust-design` (Layer 3+4 — boot-time integrity)\n- **Companion skill**: `physical-threat-modeling` (Layer 4 — hardware implant scenarios)\n\n## Standards referenced\n\n- SLSA Framework (`slsa.dev`)\n- in-toto Specification (CMU)\n- Reproducible Builds (`reproducible-builds.org`)\n- Sigstore Cosign documentation\n- NIST SP 800-204D — Strategies for Securing Software Supply Chains\n- CISA Software Supply Chain Risk Management\n- Trusted Platform Module 2.0 Library Specification (firmware identity)\n","# supply-chain-trust\n\nDecision aid for verifying that the code you ship is the code you think you're shipping. Use when designing or reviewing systems whose threat model includes supply-chain compromise (build host, dependency mirror, package registry, firmware) — which is most production systems in 2026.\n\nThe skill is distinct from `sdlc-complete`'s SBOM and CVE-scanning capabilities. SBOM tells you **what is there**. CVE scanning tells you **what is known-broken**. This skill answers **\"can I prove that what I shipped is what I expected, end-to-end\"** — which neither of the others does.\n\n## Triggers\n\n- \"reproducible build\"\n- \"snapshot pinning\" \u002F \"snapshot.debian.org\"\n- \"vendor wheels\" \u002F \"hash-locked deps\"\n- \"firmware version\" \u002F \"firmware pinning\"\n- \"in-toto\" \u002F \"SLSA\"\n- \"transparency log\" \u002F \"Sigstore\"\n- \"build host compromise\"\n- \"supply chain attack\"\n\n## When NOT to use this skill\n\n- Pure CVE scanning of declared dependencies (use `sdlc-complete\u002Fskills\u002Fsecurity-audit`)\n- SBOM generation (use existing SBOM tooling — CycloneDX, SPDX)\n- License compliance (out of scope; use a license scanner)\n\n---\n\n## Section 1: The four layers of supply-chain trust\n\n```\nLayer 4: Hardware \u002F firmware\n            ↑ (does the chip do what it says?)\nLayer 3: Build environment\n            ↑ (was the binary produced from the source we think?)\nLayer 2: Source dependencies\n            ↑ (did we get the source we expected?)\nLayer 1: Source we wrote\n            ↑ (we can audit this)\n```\n\nEach layer has its own attack surface and its own mitigations:\n\n| Layer | Attack | Mitigation |\n|---|---|---|\n| 1 (own source) | malicious commit by insider | code review, signed commits, branch protection |\n| 2 (deps) | typosquat, compromised maintainer, malicious update | pinning + hash-lock + vendoring; transparency logs |\n| 3 (build) | compromised CI, build host malware | reproducible builds, signed-and-attested artifacts (in-toto, SLSA) |\n| 4 (hardware) | malicious firmware, supply-chain implant | measured boot, vendor diversity, audit |\n\nA system is only as trustworthy as the weakest layer in the chain it actually depends on.\n\n---\n\n## Section 2: Dependency pinning — beyond `requirements.txt`\n\n### Suggested default: full hash-locked dependency manifests\n\nFor each language ecosystem:\n\n| Ecosystem | Default tool | What it produces |\n|---|---|---|\n| Python | `pip-tools` (`pip-compile --generate-hashes`) → `requirements.txt` with hashes | `package==1.2.3 --hash=sha256:abc...` per dep, including transitive |\n| Node | `npm ci` against `package-lock.json` (with `integrity` field), or `pnpm` | per-package SHA-512 integrity |\n| Rust | `cargo` lock file (`Cargo.lock`) — versions only; for hashes use `cargo vet` |\n| Go | `go.mod` + `go.sum` (per-module SHA-256) |\n| Ruby | `Bundler` lockfile + `bundle config set --local frozen true` |\n| Maven\u002FGradle | `dependency:resolve-plugin` with checksum verification |\n\n**Required**: every dependency, including transitive, must have a hash in your lockfile. If a tool can't produce hashed locks, vendor the dep.\n\n### Vendoring critical-path deps\n\nFor dependencies in security-sensitive paths (auth, crypto, key handling), go further than hash-locking — **vendor** them:\n\n```\nyour-repo\u002F\n  vendor\u002F\n    python-fido2-1.1.3\u002F        # checked-in source of the dep\n    cryptography-41.0.7\u002F        # ditto\n    ...\n  Cargo.toml or pyproject.toml  # references vendor\u002F paths, not registry\n```\n\nWhy vendoring on top of hash-locking:\n\n- Hash-locking verifies you got the bytes you expected; vendoring lets you AUDIT those bytes\n- A compromised registry could publish a new \"version\" with a malicious patch; you control what's in `vendor\u002F`\n- Reduces transitive surface — you can prune deps that you don't actually use\n\nCost: you own update cadence. Acceptable for security-critical paths; impractical for everything.\n\n### Anti-pattern: SHA-verified `.deb` whose SHA came from poisoned `apt` repo (review M10)\n\nOriginal: bootstrap verifies SHA-256 of each downloaded `.deb`, but the SHA-256 manifest itself comes from `apt-cache` against the build-time `apt` repo.\n\nWhat this skill flags: the verification is **circular within the same trust domain**. If `apt` is compromised, the manifest is compromised, the SHAs are compromised, all three layers verify a poisoned package.\n\nRemediation:\n\n- **Pin to `snapshot.debian.org`** URLs with a specific timestamp (`http:\u002F\u002Fsnapshot.debian.org\u002Farchive\u002Fdebian\u002F20260301T000000Z\u002F`) — content-addressed, immutable\n- **Verify signed Debian `Release` file** with explicit Debian archive signing keys, ground-truth at the timestamp\n- **Pin transitive `.deb` URLs** discovered at that timestamp; commit the resulting SHA manifest to your **signed** git repo\n\nThe hash of the package must come from a **separately-trusted channel** than the package itself.\n\n---\n\n## Section 3: Reproducible builds\n\n### What it gives you\n\nA reproducible build means: given the same source, the same build environment, and the same build inputs, **any builder produces a byte-for-byte identical output**. This lets you:\n\n- Verify a third-party-built binary against your own rebuild\n- Detect compromised CI by comparing CI output to your local rebuild\n- Allow others to verify your published artifacts by rebuilding from source\n\n### Suggested defaults\n\n| Use case | Approach |\n|---|---|\n| Bootstrap installers | NixOS — reproducible by construction; the entire system specification is hash-tracked |\n| Container images | Bazel + `rules_oci` OR Nix-built OCI images; pinned base layer with verified digest |\n| Linux distro packaging | Reproducible Builds project tooling (`reproducible-builds.org`); `dpkg --reproducible` flag in Debian |\n| Cross-platform binaries | Static linking, hermetic build env (Bazel), check `diffoscope` between rebuilds |\n\n### Verification step\n\n```bash\n# Local rebuild\nbazel build \u002F\u002Fmy:artifact\nsha256sum bazel-bin\u002Fmy\u002Fartifact\n\n# Compare to CI-published\nsha256sum downloaded\u002Fartifact.tar.gz\n\n# If they differ, run diffoscope to see what diverges\ndiffoscope bazel-bin\u002Fmy\u002Fartifact downloaded\u002Fartifact.tar.gz\n```\n\nCommon reproducibility breakers: timestamps in archives, build-time UUIDs, parallel-build nondeterminism, locale-dependent string sorting. The `reproducible-builds.org` site catalogs known issues per ecosystem.\n\n### When reproducibility isn't worth it\n\nFor internal tools with a single source-of-truth build host and signed output, the value is marginal. Reproducibility shines when:\n\n- You publish artifacts users will run (binaries, container images)\n- Your CI runs untrusted code (third-party PRs, etc.)\n- Your build host might be compromised and you want a way to detect it\n\n---\n\n## Section 4: Build attestation (in-toto, SLSA)\n\n### Suggested default: SLSA Level 3+ attestation for production releases\n\nSLSA (Supply-chain Levels for Software Artifacts) defines compliance levels:\n\n| Level | What it requires | What it tells consumers |\n|---|---|---|\n| 0 | nothing | \"this came from somewhere\" |\n| 1 | build process documented | \"the build is repeatable in principle\" |\n| 2 | build runs on hosted CI; provenance generated | \"we know which CI built it\" |\n| 3 | build is hermetic, isolated; provenance is signed and tamper-evident | \"we can prove the build chain end-to-end\" |\n| 4 | additional constraints — two-person review, hermetic builds | \"highest assurance\" |\n\n**Tooling:**\n\n- `cosign` (Sigstore) — signs container images and arbitrary blobs; integrates with Rekor transparency log\n- `slsa-github-generator` — produces SLSA L3 provenance from GitHub Actions\n- `in-toto` (CMU) — generic supply-chain attestation framework\n- `Tekton Chains` — Kubernetes-native build attestation\n\n### Verification on consumer side\n\n```bash\ncosign verify --certificate-identity-regexp=...@my-org \\\n    --certificate-oidc-issuer=https:\u002F\u002Ftoken.actions.githubusercontent.com \\\n    ghcr.io\u002Fmy-org\u002Fmy-image:1.2.3\n```\n\nPin **specific certificate identities and OIDC issuers**. A bare `cosign verify` can be satisfied by any signature.\n\n---\n\n## Section 5: Hardware \u002F firmware version locking\n\n### Required pattern (review L6)\n\nFor systems with hardware-backed cryptographic operations (HSMs, YubiKeys, TPM-equipped hosts), pin to a known-good firmware range. Different firmware versions can have:\n\n- Different cryptographic primitive support (FIDO2 features, attestation behavior)\n- Different timing characteristics (side-channel surface)\n- Different bug profiles\n\nExample: YubiKey 5 firmware 5.4 vs 5.7 have **different FIDO2 PRF behavior**. Code that worked against 5.4 may fail or behave differently on 5.7.\n\n### Inventory pattern\n\n```yaml\n# .aiwg\u002Fsecurity-engineering\u002Fsupply-chain\u002Fhardware-pins.yaml\nyubikey-5:\n  tested-firmware: \"5.4.3, 5.7.1\"\n  acceptable-firmware: \">=5.4.0, \u003C6.0\"\n  test-vectors: \"tests\u002Fyubikey-5-prf.txt\"\n  last-validated: \"2026-04-15\"\n\ntpm-2.0:\n  vendor: \"Infineon\"\n  acceptable-firmware: \">=7.83\"\n  pcr-baseline: \".aiwg\u002Fsecurity-engineering\u002Fchain-of-trust\u002Fpcr-baseline.yaml\"\n```\n\nWhen a new firmware ships, run your test vectors against the new version before allowing it into production.\n\n---\n\n## Section 6: Worked examples\n\n### Review M10 — SHA-256 manifest from poisoned apt source\n\nOriginal: install-pkgs.sh verifies SHA-256 of each `.deb` file against a manifest produced by `apt-cache` at build time.\n\nWhat this skill flags:\n\n- Section 2 anti-pattern: verification within same trust domain as packaging\n- Layer 2 attack: poisoned mirror produces consistent manifest + packages\n\nRemediation:\n\n- Pin to `snapshot.debian.org\u002Farchive\u002Fdebian\u002F\u003Ctimestamp>\u002F` URLs in install scripts\n- Verify Debian `Release` file with explicit archive signing keys (`\u002Fusr\u002Fshare\u002Fkeyrings\u002Fdebian-archive-keyring.gpg`)\n- Generate `.deb` SHA manifest from the snapshot, NOT from `apt-cache`\n- Commit the resulting manifest to a signed git repo\n- Reproducibly rebuild the bootstrap partition; verify rebuild matches published\n\n### Review H3 — `python-fido2` and transitive deps in PRF hot path\n\nOriginal: bootstrap installs `python-fido2`, `cryptography`, `cffi`, `pyusb` from PyPI at first run.\n\nWhat this skill flags:\n\n- Layer 2 attack: PyPI compromise of any of 4+ packages affects PRF hot path\n- Section 2: deps are not vendored OR hash-locked\n\nRemediation (see also `auth-factor-design`):\n\n- Replace `python-fido2` with `libfido2` C tools — drops Python from hot path\n- If Python remains: vendor `python-fido2` + transitive deps with hash-locked wheels in bootstrap blob; verify per-wheel SHA-256 against manifest committed to signed repo; reproducible-build the bootstrap\n\n### Review L6 — firmware version not documented\n\nOriginal: design assumes \"YubiKey 5 with FIDO2 PRF\" without specifying firmware range.\n\nWhat this skill flags:\n\n- Section 5: hardware version not pinned\n\nRemediation:\n\n- Document tested firmware range (e.g., 5.4.0–5.7.x)\n- Maintain test vectors in repo; run against any new firmware before adopting\n- Operationally: standardize procurement to known-good firmware\n\n---\n\n## Section 7: Trust-boundary inventory\n\nMandatory exercise — for every external input to your build, document:\n\n| Input | Source | Verification | Trust anchor |\n|---|---|---|---|\n| Source code (your repo) | git origin | signed commits + signed tags | dev signing keys |\n| Source code (deps) | language registry | hash-locked manifest | dev publishes verified |\n| Base OS packages | snapshot.debian.org | Debian archive key | embedded in keyring |\n| Container base layer | OCI registry | image digest pinned | (none — ASSUMPTION) |\n| Build CI | GitHub Actions | OIDC + SLSA L3 attestation | GitHub OIDC issuer |\n| Hardware | physical procurement | (assumption: vendor not compromised) | (none — ASSUMPTION) |\n| Firmware | (vendor) | version pinned, test vectors run | self-tested |\n\nRows with \"ASSUMPTION\" are explicitly accepted risks. Document why each assumption is acceptable.\n\n---\n\n## Section 8: Output format\n\nWhen invoked as part of a review, produce findings in standard format. When authoring or updating, produce:\n\n- `supply-chain-pins.yaml` — current pins for all layers\n- `hardware-pins.yaml` — firmware versions tested\n- `trust-boundary.md` — inventory and assumption acceptance\n\n---\n\n## Related\n\n- **Existing**: `sdlc-complete\u002Ftemplates\u002Fsecurity\u002Fsbom-guidance.md` (SBOM is upstream of this skill)\n- **Existing**: `sdlc-complete\u002Ftemplates\u002Fsecurity\u002Fdependency-policy-template.md` (this skill operationalizes the policy)\n- **Companion skill**: `chain-of-trust-design` (Layer 3+4 — boot-time integrity)\n- **Companion skill**: `physical-threat-modeling` (Layer 4 — hardware implant scenarios)\n\n## Standards referenced\n\n- SLSA Framework (`slsa.dev`)\n- in-toto Specification (CMU)\n- Reproducible Builds (`reproducible-builds.org`)\n- Sigstore Cosign documentation\n- NIST SP 800-204D — Strategies for Securing Software Supply Chains\n- CISA Software Supply Chain Risk Management\n- Trusted Platform Module 2.0 Library Specification (firmware identity)\n",{"name":5,"namespace":48,"platforms":49,"description":7},"aiwg",[50],"all","main","6754967c344ccb087a8de06972f55a41067b291b","agentic\u002Fcode\u002Fplugins\u002Fsecurity-engineering\u002Fskills\u002Fsupply-chain-trust",36,"https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg","https:\u002F\u002Faiwg.io","https:\u002F\u002Fgithub.com\u002Fjmagly","https:\u002F\u002Fintegrolabs.io","ml\u002Fai, industrial automation, safety\u002Fsecurity, ssi\r\n\r\nmagly.net\r\nintegrolabs.io\r\naiwg.io\r\nfortemi.com\r\npagenary.com\r\nbytecask.com","2026-11-12 21:57:33",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add jmagly\u002Faiwg --skill supply-chain-trust",{"tool":67,"command":68},"bunx","bunx skills add jmagly\u002Faiwg --skill supply-chain-trust",{"tool":70,"command":71},"pnpm","pnpm dlx skills add jmagly\u002Faiwg --skill supply-chain-trust","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Fsecurity-engineering\u002Fskills\u002Fsupply-chain-trust\u002FSKILL.md",true,[],[76,104,128,134,141,155],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":83,"publishedAt":43},"01M70QA0BSYJ49EES9V4RE8QH1","host-hardening","Read-only system hardening baseline and plan-first host hardening recommendations for SSH, Docker bind addresses, firewall persistence, datastores, exporters and audit retention.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Fsecurity-engineering\u002Fskills\u002Fhost-hardening\u002FSKILL.md",[82],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103],"host","host hardening","hardening","read","re","recommendations","remediation","plan","port","verification","Bash","access","only","retention","audit","never","firewall","bind","secrets","request",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":114,"publishedAt":43},"01M70PNT2Z4HMZPRBTAF6073NN","exposure-analysis","Read-only firewall analysis and effective host exposure reconstruction for Docker published ports, UFW bypass, stale rules, CDN scope, IPv6 asymmetry and external probe allowlists.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Fforensics\u002Fskills\u002Fexposure-analysis\u002FSKILL.md",[110,113],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[115,116,117,87,118,92,119,120,94,121,84,122,96,123,124,99,100,125,126,127],"exposure analysis","analysis","unknown","credentials","collection","ufw","ports","internet","local","scope","reconstruction","operator","write",{"skillNo":129,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":43},"01M70P8QATMPKA78E4FT5D2TNA","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fframeworks\u002Fsecurity-engineering\u002Fskills\u002Fhost-hardening\u002FSKILL.md",[132],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[86,84,85,95,87,103,90,89,98,91,92,93,94,102,96,97,88,99,100,101],{"skillNo":135,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":140,"publishedAt":43},"01M70NMPVJ5H0JH131P60FW4R8","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fframeworks\u002Fforensics-complete\u002Fskills\u002Fexposure-analysis\u002FSKILL.md",[138,139],{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[116,115,99,118,92,119,94,117,84,122,96,123,124,87,100,121,120,125,126,127],{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":43},"01M6CB4DDR0B4NNCFK7ZK7449H","fixture-skill","Exercise rule delivery.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Frule-delivery\u002Fskills\u002Ffixture-skill\u002FSKILL.md",[147],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[149,150,151,152,153,154],"fixture skill","fixture","rule","delivery","true","exercise",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":43},"01M6CB4AVK1W76MFMPP0JP32CJ","pi-local","Pi-local duplicate-precedence fixture.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Fproviders\u002Fpi\u002Fproject\u002F.pi\u002Fskills\u002Fpi-local\u002FSKILL.md",[161],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[163,164,123,165,150],"pi","pi local","duplicate"]