Skip to content
steelabs

Template

Dependency verification and triage register

Verify package identity and record vulnerable-version exposure, reachability, upgrade decisions and retest evidence. Includes an SBOM inventory structure.

Download editable Markdown

How to use this

Useful for: Teams reviewing dependencies, including packages suggested by an AI assistant.

  1. Verify a suggested package against its official repository and registry before installing it. A plausible name or generated installation command is not evidence of identity or maintenance.

  2. Record the exact deployed version and dependency path. An advisory about an absent package differs from an advisory about a reachable dependency in production.

  3. Explain affected configuration and reachability without treating absence of a reproduction as proof of safety. Escalate unresolved exposure to the responsible security owner.

  4. Make the remediation decision time-bound and reviewable. Capture the replacement version, compatibility checks and remaining exception rather than relying on a cleared scanner summary alone.

Scope and limitations: This register supports triage. It is not a substitute for a complete software bill of materials, provenance verification or specialist vulnerability assessment.

Document preview

# Dependency verification and triage

## Identity check before installation
- Official project and registry references:
- Exact package name / namespace / maintainer:
- Repository activity, release date and licence:
- Why this dependency is needed:
- Independently verified version and integrity record:
- Approval owner:

Do not install an AI-suggested package solely because a generated answer mentions it. Confirm that the intended project actually publishes that registry name.

## Inventory / SBOM input
| Component | Exact version | Direct / transitive path | Package URL | Licence | Deployed scope |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

Use the team's approved SBOM format and generator where a complete machine-readable bill is required. This table is a planning and triage view, not a claim of format conformance.

## Advisory review
| Advisory reference | Affected versions | Our version | Exposure / reachability | Decision | Owner / date |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

## Remediation evidence
- Upgrade or configuration change:
- Reason and compatibility risk:
- Build and regression checks executed:
- Scanner or advisory follow-up:
- Remaining uncertainty and specialist review:
- Accepted exception, approving owner and expiry:

Example — fictional: a development-only tool is affected, but the team still checks whether its vulnerable parsing path can be reached in CI with untrusted input. “Not in the runtime bundle” does not settle that question. If the configuration remains uncertain, record the uncertainty and investigate rather than closing the advisory with an unsupported claim.

Review changes to dependency identity, lockfiles and installation scripts as code changes. Keep secret registry credentials outside both the register and any downloadable example.

Read alongside this worksheet

Get help applying itAll resources