Supply-chain security means more than checking a lockfile into git. In this repository it also means controlling which tools are allowed to shape public claims, which dependencies the site actually ships, which automation surfaces can rewrite content, and which external assumptions contributors are smuggling into reader-facing pages.

Because this repo is a docs and site workspace, its live supply-chain posture is narrower than a full protocol runtime. The present-tense goal here is simple: keep the published site, the authoring toolchain, and the workflow prompts understandable, pinned, and reviewable enough that a dependency or automation change cannot silently rewrite the trust surface.

What The Current Repo Actually Uses

The live dependency story in this repository is straightforward:

That is enough to talk honestly about this repo’s supply-chain posture. It is not enough to claim that every ecosystem dependency across every future service is already covered here.

The Main Risk Classes

Supply-chain risk in this repo falls into four practical buckets.

First is dependency drift: a package upgrade can change rendering, parsing, search behavior, or build output in ways that subtly rewrite what readers see. Second is tooling drift: a helper script or automation surface can change the validation contract without contributors noticing. Third is prompt and instruction drift: local workflow assets under .github/ can reshape how AI-assisted changes are made, which matters because this repo explicitly treats those files as part of the live working surface. Fourth is external-assumption drift: contributors may import commands, trust claims, or service expectations from another repository and publish them here as if they were local facts.

None of these risks requires malicious code execution to matter. A docs repo can damage trust simply by publishing the wrong boundary with clean formatting.

Minimum Review Standard For Dependency Changes

When a dependency or build-tooling change is in scope, the minimum safe review standard should include:

1. confirm why the dependency is needed at all;
2. check whether an existing repo surface already solves the problem;
3. preserve or update the lockfile consistently;
4. run npm run lint and npm run verify;
5. re-read any affected reader-facing pages for claim drift, not only for build success.

That last step matters. A dependency can pass build checks while still changing search coverage, Markdown behavior, or content rendering in a way that alters reader expectations.

What This Page Will Not Pretend

This page does not claim that the current docs repo proves a finished advisory intake process, a full SBOM program, or complete ecosystem dependency review for every future wallet, node, or enterprise surface. It also does not treat third-party assets or external services as automatically safer because a docs page mentions them. The legal corpus is explicit that external issuers, overlays, and regulated-service duties remain external responsibilities unless separately proven otherwise.

In other words, supply-chain discipline here is about keeping the local trust surface narrow and inspectable. Broader operational hardening belongs to the systems that actually ship those services.

How This Connects To The Rest Of Security

Read Crypto Policy when a dependency change affects cryptographic claims or migration language. Read Responsible Disclosure if a dependency or tool introduces a vulnerability that should not be reported in public. Read Audits And Reviews when you need to decide what kind of evidence a future supply-chain assurance claim would require.

The common thread is that trust should move upward only when evidence moves with it.

Supply-Chain Trust Boundary

The map separates source, dependencies, generated evidence, and runtime assets. Generated reports can support a claim, but they should not become a hidden source dependency. Runtime assets can be served to users, but they should not contain application logic. Dependencies can support the build, but a dependency bump is not automatically safe because the site still builds. A security page should preserve those boundaries rather than treating the repository as one undifferentiated folder.

Content Provenance And External Links

Content provenance matters because public docs are part of the trust surface. A whitepaper citation should point to the current file under content/whitepapers/, not to an old draft copied into a support answer. A NIST or other standards link should be used for external context, not as proof that local implementation work is complete. External links should be stable, relevant, and clearly separated from project authority. If a page relies on a third-party source, the evidence section should say why that source is being used and what it does not prove.

Third-party assets deserve the same discipline. Images, icons, scripts, and downloadable files should not be added casually to public/ if their provenance, license, or integrity is unclear. A runtime asset is visible to users and should be treated as part of the public site, not as a scratchpad.

Dependency Change Checklist

Before accepting a dependency or tooling change, confirm the purpose, package name, version, lockfile effect, transitive risk, build result, and whether the package executes during build, runtime, or development only. A dev-only dependency can still affect generated output. A runtime dependency can change what users receive. A content plugin can change claim rendering. A security-sensitive dependency deserves more than a successful install.

Generated reports also need discipline. Reports under .planning/ and reports/ can prove that a review happened, but they should not be imported by application source as if they were runtime data. If a generated file becomes needed by the app, it should be promoted intentionally into the correct source or content surface with provenance explained.

Review Notes

Supply-chain review should treat content changes as trust changes. A Markdown page can change user behavior as surely as a package update can change runtime behavior. If a docs change tells users to run a command, install a tool, trust a contact channel, or disclose evidence, it belongs in supply-chain review as a public trust-surface change.

The same applies to local automation. A script under scripts/ should be cited only for what it actually does. If scripts/verify.sh runs lint, search coverage, and build, say that. Do not imply dependency scanning, cryptographic audit, or external service testing unless the script actually performs those steps.

Final Boundary

Supply-chain confidence is local and scoped. This page can speak for the current website repository, its content workflow, and its verification scripts. It cannot speak for every future wallet, bridge, issuer, operator, or protocol dependency outside this repo.

Read Next

Read Audits And Reviews for evidence interpretation, Troubleshooting for the local verification flow, and Responsible Disclosure before reporting dependency or asset-integrity issues.

Evidence and Further Reading

• package.json and package-lock.json are the current repo-local sources of truth for the Node dependency graph discussed on this page.
• README.md defines the install and verification flow that keeps dependency changes reproducible and reviewable in this workspace.
• .github/copilot-instructions.md and .github/requirements/Z00Z_WEB_DESIGN_FOUNDATION.md constrain risky automation and require evidence-backed verification before completion.
• Legal Architecture Whitepaper section 16 and sections 4, 10, 12, 17, and Appendix A explain why external-service, issuer, and operator responsibilities must not be collapsed into the base protocol’s trust claims.
• Privacy Threat Model And Metrics sections 4, 8, 9, and 10 reinforce the principle that extra tooling, telemetry, or service layers can widen exposure even when the base protocol boundary remains narrower.
• NIST Cybersecurity Framework: https://www.nist.gov/cyberframework.