# 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.