Keep dependencies
legible.
A practical continuity guide for identifying important third-party components and agreeing how to respond when one changes, degrades, or becomes unavailable. It is not a vulnerability scan or supplier assurance.
USE IT TO: Use to make the dependency surface, ownership, version decisions, and fallback assumptions reviewable before a release.
Work the next known step.
- List customer-path dependencies: application packages, build tools, external APIs, delivery providers, and operational services. Assign an accountable owner to each material dependency.
- Record the version or service configuration in the release evidence. Use the team’s approved lockfile, provenance, or supplier-review controls rather than unreviewed substitutions.
- For each dependency, document the customer-facing effect if it is delayed or unavailable and the approved graceful-degradation or escalation option, if one exists.
- Review supplier notices and observed behavior through approved channels; make changes through the normal reviewed release path rather than changing a dependency during an incident without authorization.
Check that each material dependency has an owner, a source of truth, and a current release reference.
Compare the planned release dependency set with the reviewed lockfile or platform record using the team’s approved tooling.
Tabletop a single dependency interruption: identify who decides, what customer behavior is acceptable, and when to escalate.
Source notes, not borrowed certainty.
Planning basis: OWASP software supply-chain guidance
- OWASP — Software Supply Chain Security Cheat Sheet ↗OWASP recommends dependency inventory, automated SBOM generation where appropriate, monitoring, version pinning, build-tool inventory, and provenance controls.
Authorship: SIU Enablement editorial draft; source-bounded operational guidance. Reviewed by: Engineering, platform, security, and supplier owners review the material dependency list. Revalidate: Revalidate quarterly and before a dependency, build, supplier, or fallback-mode change.