Exposure triage
Move from package alert to owned remediation
Rank a dependency by reachability, consequence, support and change evidence—not only by a headline severity number.
Purpose
Tie the package to an owned product capability.
- Ask
- Why is it installed and where is it called?
- Risk
- Unused experiment remains in production graph
- Evidence
- Import, runtime and build references
Reachability
Determine whether the affected behavior can execute in your context.
- Ask
- Which input and path reach the vulnerable function?
- Risk
- Severity is accepted or dismissed without analysis
- Evidence
- Call path, configuration and reproduction
Upgrade path
Understand direct, transitive and compatibility relationships.
- Ask
- Which direct package controls the transitive version?
- Risk
- Forced override silently breaks semantics
- Evidence
- Supported release notes and compatibility tests
Change proof
Verify behavior rather than trusting a successful install.
- Ask
- Which user journey and security property can regress?
- Risk
- Lockfile updates pass compilation but alter runtime
- Evidence
- Targeted tests plus representative smoke run
Ongoing ownership
Keep the graph observable after the immediate alert closes.
- Ask
- Who reviews alerts and unsupported packages?
- Risk
- Automated update queues become permanent noise
- Evidence
- Service level, owner and removal backlog
Operating principle
A dependency decision combines vulnerability and application context
Public vulnerability data describes a package issue. Your application context determines whether that behavior is present, reachable, protected or already removed during bundling.
Document the reasoning either way. Silent dismissal loses evidence; blind upgrading can create new failures. The goal is a reproducible decision with a supported path forward.
- Preserve the lockfile
- Map transitive ownership
- Test the changed behavior
- Remove unused packages
Applied example
Triage example: critical parser in a build-only path
An audit reports a critical parser vulnerability. The package appears only inside a development-time generator and its vulnerable function is not used by the configured build.
- The severity still warrants analysis
- Runtime exposure differs from build exposure
- The package may still process untrusted repository content
- A supported upgrade can remove uncertainty
Plain answers
Questions to resolve before shipping
Does zero audit findings mean the codebase is safe?+
No. Dependency databases and package matching are incomplete, and application logic, configuration and private code still require review.
Should automated updates merge automatically?+
Only when the dependency class, tests and rollback policy make that safe. Consequential runtime changes deserve review.
What if a package is abandoned?+
Reduce exposure, identify alternatives and plan removal. A temporary risk decision needs an owner, evidence and review date.