Dependency Update Risk Analyzer

Dependency update rows:

A header row enables owner, tests, compatibility, release-age, and notes evidence. Headerless rows use package,current,target,scope,security,notes.

Project label:

Use a label that will remain clear in an owner review or release ticket.

Ecosystem context:

Python, Maven, and mixed sources use an approximate numeric movement signal and retain a human-review warning.

Test confidence:

Choose the confidence that applies before any proposed dependency change is merged.

Owner-review threshold:

This local threshold is a triage policy, not an ecosystem or security standard.

points

Critical package names:

Matching is case-insensitive and exact after trimming.

Pre-1.0 minor policy:

This policy affects only numeric versions whose current major component is zero.

{{ params.zero_major_breaking ? 'Treat as major-like' : 'Keep as minor-like' }}

Compatibility floor:

When the floor is above zero, compatibility below max(50%, floor − 20 percentage points) adds 3 points; otherwise, compatibility below the floor adds 1.5 points. Zero disables this factor. Supplied values must be finite percentages from 0 to 100; blank evidence is neutral.

Fresh-release window:

When enabled, supplied age must be a finite nonnegative number of days. Blank evidence is neutral; zero days is a supplied fresh release. No registry dates are fetched.

days

Release plan

{{ decisionHeading }}

{{ action }}

Risk points are a repository-authored triage index. Confirm changelogs, lockfile resolution, tests, and deployment evidence before merging.

Package	Change	Scope	Points	Lane	Primary signals	Copy
{{ row.package_name }}	{{ row.version_change }}	{{ row.scope_label }}	{{ formatScore(row.score) }}	{{ row.tier }}	{{ row.signals }}

Package	Owner	Gate	Why queued	Validation focus	Merge action	Copy
{{ row.package_name }}	{{ row.owner }}	{{ row.tier }}	{{ row.signals }}	{{ row.validation_focus }}	{{ row.merge_action }}

{{ chartState === 'loading' ? 'Loading risk factor chart…' : 'Risk factor chart unavailable. Check your connection, then retry. CSV remains available.' }}

Two dependency updates with the same version label can deserve very different release plans. A patch to a deeply used runtime library may carry more operational exposure than a major update to an isolated development tool. Security urgency, package criticality, test gaps, compatibility evidence, and release age can all change how much review and rollback preparation a change needs.

Version movement remains a useful signal when the package follows Semantic Versioning (SemVer). Major, minor, and patch numbers communicate intended compatibility for a public API, while a pre-release identifies an unstable target. They are promises about release intent, not proof that a particular application will remain compatible. Packages before version 1.0 and ecosystems with different ordering rules need extra care.

Dependency update evidence and the decisions it supports
Evidence	Decision it informs	What must still be verified
Release movement	Routine batch or isolated migration	Actual release notes and ecosystem-native ordering
Runtime scope and criticality	Blast radius and owner involvement	Where the resolved package is used
Security signal	Release urgency	Advisory, affected path, and patched target
Tests and compatibility	Required validation effort	Representative CI, integration, and deployment evidence
Release freshness	Extra observation or canary time	Current age and upstream adoption evidence

Risk and urgency should not cancel each other. A security fix may need rapid action and still require a guarded rollout. A low-scoring maintenance update may still fail because of an undocumented behavior change or a different transitive resolution. Review the manifest and lockfile diff, not only the direct package row.

Batching reduces maintenance overhead but makes regression diagnosis harder. Updates with similar validation needs can share a batch, while major-like movement, weakly tested runtime packages, and critical dependencies are easier to review and reverse separately. A consistent triage policy helps sort that work without pretending to predict failure probability.

Any numerical risk index is local policy. Its weights and thresholds should make review decisions repeatable, but they do not replace a package manager, vulnerability scanner, compatibility test, or approval process.

How to Use This Tool:

Supply the updates being considered and set one policy for the entire release batch before comparing scores.

Paste dependency rows or load one CSV or TXT file up to 200 KB. Every row needs a package name, current version, and target version; a header enables optional owner, tests, compatibility, release age, and notes fields.
Choose the Ecosystem context and current Test confidence. Python, Maven, and mixed sources require ecosystem-native version checks before numeric movement is trusted.
Set the owner-review threshold from 1 to 30 points, list exact critical package names, and decide whether a minor increase from a 0.x version should receive the major-change weight. Enable compatibility or freshness scoring only when those optional columns contain reliable values; zero disables each factor.
Review the release lanes first, then inspect each score's signals and validation focus. Correct any invalid row before using the plan.

Interpreting Results:

The score ranks configured concerns; it is not a probability, severity rating, or compatibility verdict. Block and plan calls for a separate guarded change, Owner review requires sign-off, Batch with checks may remain grouped after focused CI, and Routine is eligible for normal automation after green CI.

Compare scores only when the threshold, ecosystem, test confidence, critical-package list, pre-1.0 policy, compatibility floor, and freshness window are unchanged.
A security flag adds points but comes from the supplied row; no advisory is fetched or verified.
Compatibility and release-age values are also supplied evidence. Missing values add no optional context points.
A low score means fewer configured signals were present. It does not prove that the update is safe or that deployment will succeed.
Confirm release notes, the resolved dependency tree, targeted tests, canary evidence, and rollback ownership before merging.

Technical Details:

Dependency-update triage adds six independent point factors, sorts rows by total score, and assigns a lane relative to the selected review threshold. The result is deterministic for the same rows and policy settings.

Formula Core

Each row's score is the sum of release movement, scope, security, package criticality, test evidence, and optional compatibility or freshness context.

R = p_{release} + p_{scope} + p_{security} + p_{critical} + p_{tests} + p_{context}

Points can include halves, so scores are not restricted to whole numbers. No rounding is applied before lane assignment.

Lookup Core

Dependency risk point lookup
Factor	Condition	Points
Release	Same version	0
	Patch	1
	Minor	3
	Major or configured pre-1.0 minor	6
	Pre-release target	4
	Downgrade	4
	Unknown movement	2
Scope	Runtime, production, direct, application, server, client, API, or required	3
	Transitive, indirect, or subdependency	1.5
	Build, CI, tooling, lint, or test	1
	Development or optional	0.5
Security	Supplied security flag is true	3
Criticality	Case-insensitive exact package-name match	2
Global test baseline	High confidence	0
	Medium confidence	1
	Low confidence	2

Row-level test text adds 2 points when it explicitly says testing is absent or manual-only, 1 point for pending or incomplete checks, and no extra points for recognized passing or covered checks. An empty test field keeps only the global baseline, while unrecognized non-empty text adds 1 point.

When compatibility scoring is enabled, a numeric value below the floor adds 1.5 points; a value below max(50, floor − 20) adds 3 instead. When freshness scoring is enabled, a nonnegative release age less than or equal to the chosen day window adds 1.5 points.

Rule Core

Let T be the owner-review threshold. Lane boundaries are inclusive at their lower edge.

Dependency update lane rules
Lane	Score rule	Review meaning
Block and plan	R ≥ T + 5	Isolate the change and prepare rollback ownership.
Owner review	T ≤ R < T + 5	Require owner sign-off before merge.
Batch with checks	max(3, T − 3) ≤ R < T	Keep in the batch only after focused checks pass.
Routine	R < max(3, T − 3)	Eligible for routine automation after green CI.

Mechanism Walkthrough

With threshold 8 and medium global test confidence, an update from 4.18.2 to 5.1.0 scores 6 for major movement. If it is a runtime dependency, security-flagged, named critical, and its row says tests are pending, it adds 3 + 3 + 2 + 2 points for a total of 16. Because 16 is at least 13, the update enters Block and plan.

Version classification extracts numeric components and recognizes common pre-release words. This is useful for SemVer-like data but is not a complete parser for every ecosystem. The pre-1.0 option changes only a minor increase whose current major component is zero.

Privacy Notes:

Dependency rows and local files are processed in the current browser and are not uploaded. The analysis does not contact registries, advisory databases, source repositories, or package managers. Treat package names, owners, notes, and project labels as potentially sensitive, and verify every supplied security, compatibility, age, and test claim against its authoritative source.

References:

Semantic Versioning 2.0.0, Semantic Versioning.
How to update Node.js dependencies, Simplified Guide.
How to audit Node.js dependencies, Simplified Guide.