{{ result.summary.heading }}
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Use a header row when adding owner, tests, compatibility, or release age columns. Headerless rows keep package,current,target,scope,security,notes order.
{{ sourceMeta }}
Risk score bands:
{{ activeThresholdBand.label }}
The active band tracks the highest scored dependency update in the current batch.
{{ band.label }} {{ band.range }} {{ band.note }}
{{ field.help }}
{{ field.suffix }}
{{ header }}Copy
{{ cell }}
{{ emptyResultTitle(tab.key) }}
{{ emptyResultNote(tab.key) }}
Add at least one dependency update row to render this chart.
Tags: Devtools, Security
Git Diff Risk Analyzer Analyze Git diff summaries before review, scoring churn, sensitive paths, deletions, generated files, and binary rows into a reviewer queue.
JUnit Test Report Analyzer Analyze JUnit XML from CI runs in your browser with pass-rate gates, failure triage, retry clues, skipped cases, and slow-test flags.
Container Security Scan Analyzer Analyze container scan output in your browser, normalize vulnerability findings, test release gates, and rank fixable packages for remediation.
CODEOWNERS Coverage Analyzer Check CODEOWNERS coverage for a pull request, spot missing, ownerless, or catch-all ownership gaps, and export a review-ready fix queue.
Customize
Advanced
:

Dependency updates look like routine maintenance until one changed library touches request routing, authentication, database access, build output, or cryptography. A lockfile refresh can contain dozens of rows with different stakes: a patch for a vulnerable runtime library, a major framework migration, a fresh pre-release target, and a low-impact development tool may all appear in the same pull request. Treating those rows as equal slows harmless updates and lets risky ones hide inside bulk automation.

Version change is the first useful clue. Semantic Versioning uses major, minor, and patch positions as compatibility signals when a project follows the convention. Major version zero is different because the public API is not considered stable, and pre-release labels such as beta, rc, next, or canary also deserve caution. Version numbers help sort the batch, but they cannot prove that the update is safe for a specific application path.

Runtime scope
A dependency that ships with the application can change deployed behavior, request handling, data access, or client code.
Security update
A fix tied to a vulnerability needs urgency, but it still needs proof that the patched version covers the affected range.
Test confidence
Green tests reduce uncertainty only when they cover the paths touched by the dependency.
Owner review
A named owner can read migration notes, approve risk, and prepare rollback steps before merge.

Security pressure is the easiest place to misread update risk. Delaying a known fix can leave production exposed, yet merging a large framework jump without a release plan can create a different incident. A good triage pass separates urgency from release control: some security patches should move quickly through focused checks, while breaking-class upgrades need an owner, release notes, and rollback planning.

Dependency update risk triage flow

A risk score is a triage aid, not proof of safety. It makes the next review meeting shorter by showing which dependency rows look routine, which ones need focused checks, and which ones deserve a separate guarded release.

How to Use This Tool:

Work with one repository, service, or dependency group at a time so the rows share the same ownership, release window, and test assumptions.

  1. Set Project name and Ecosystem so the report labels the update batch in terms your team recognizes.
  2. Choose Test confidence, set Review threshold, and list Critical packages such as frameworks, database drivers, crypto libraries, authentication packages, or platform components.
  3. Keep 0.x minor policy enabled when minor changes under major version zero should count as breaking-class updates for your project.
  4. Paste dependency rows, drop a CSV or TXT file, choose Browse CSV, or use Load sample. A header row can add owner, tests, compatibility, release age, and notes.
  5. Use Compatibility floor and Fresh release window only when your source data contains those values. Leave either field at 0 when that signal is not available.
  6. Read Upgrade Risk Ledger for all scored rows, then use Owner Review Queue for the rows at or above the threshold. The Upgrade Risk Matrix and Risk Factor Stack show whether SemVer, scope, security, tests, or optional signals pushed a row across the gate.

If the warning says At least one dependency update row is required, add a row with a package name and target version before trusting the ledger, queue, charts, or JSON output.

Interpreting Results:

Start with the Risk score beside each package. Scores below the watch band are routine candidates after normal continuous integration. Scores inside Batch with checks need focused validation before they stay grouped. Scores at or above the review threshold enter Owner Review Queue, and scores at least five points above the threshold move to Block and plan.

Do not treat Routine as no risk. It means the visible signals are low under the current settings. Confirm the lockfile diff, release notes, package task, and tests that cover the affected paths. Block and plan does not mean a security update should wait indefinitely; it means the fix needs a controlled merge path with rollback notes and owner sign-off.

Output cue Best reading Verification step
Signals Lists the reasons that raised the score, such as breaking-class bump, runtime surface, security fix, critical package, low test confidence, compatibility below floor, or fresh release. Check each reason against release notes, advisory data, test evidence, and the package's real role.
Release lane Converts the score band into a merge posture. Decide whether the update can stay automated, stay batched, receive owner review, or move into a separate release plan.
Validation focus Names the first useful check for rows in the queue. Assign that check before approving the dependency update pull request.
Merge action States the release-control decision for the row. Resolve owner sign-off, rollback notes, or batch splitting before final merge.

Technical Details:

Dependency update scoring combines compatibility hints with release risk. The version jump estimates how likely an interface changed, while the scope estimates where the dependency can affect the system. Security flags, critical-package matches, weak tests, low compatibility scores, and fresh releases add review pressure because they change the cost of a mistaken merge.

Semantic Versioning assigns meaning to major, minor, and patch increments only when the project follows that convention. A major update usually signals incompatible API changes, a minor update usually signals backward-compatible functionality, and a patch update usually signals backward-compatible fixes. For major version zero, minor updates may still break consumers because the API is not promised to be stable.

Formula Core:

The score adds separate weights for the visible risk factors in one dependency update row.

R = Wsemver + Wscope + Wsecurity + Wcritical + Wtests + Woptional

Here R is the displayed Risk score. Each weight comes from one row's version change, dependency scope, security flag, critical-package match, test notes, compatibility score, and release age.

Factor Scoring rule Why it changes review effort
Semantic change Same 0, patch 1, minor 3, major 6, pre-release 4, downgrade 4, unknown 2. Estimates compatibility pressure from current and target version numbers.
Runtime scope Production-like scope 3, build or test tooling 1, development or optional scope 0.5, transitive or unknown scope 1.5. Raises dependencies that can affect deployed behavior or hidden dependency paths.
Security signal 3 when the row marks the update as a security fix. Keeps vulnerability-related updates visible even when the version jump is small.
Critical package 2 when the package name contains a configured critical-package fragment. Adds caution for libraries that affect frameworks, data stores, authentication, cryptography, or platform behavior.
Test confidence Global low confidence starts at 2, medium at 1, high at 0. Missing or manual-only row tests add 2; pending or gap language adds 1. Turns weak validation evidence into review pressure instead of leaving it as a note.
Optional source signals Compatibility below the floor adds 1.5 or 3. A target release inside the fresh release window adds 1.5. Adds caution for low imported compatibility scores and very recent target releases.

Rule Core:

The review threshold T defines the owner-review gate. The lower watch band begins at max(3, T - 3), which prevents tiny thresholds from labeling every low score as routine.

Tier Boundary Release lane
Routine score < max(3, T - 3) Automation candidate after green continuous integration.
Batch with checks max(3, T - 3) <= score < T Keep grouped after focused checks pass.
Owner review T <= score < T + 5 Require owner sign-off and rollback notes before merge.
Block and plan score >= T + 5 Do not batch; isolate the update and schedule a guarded release.

Headered CSV rows can include package name, current version, target version, scope, security status, owner, test notes, compatibility score, release age, and notes. Headerless rows use package, current version, target version, scope, security flag, and notes in that order. Rows without both a package name and target version are ignored because they cannot produce a useful update score.

For example, a runtime express update from 4.18.2 to 5.1.0 with security marked yes, medium global test confidence, pending row tests, a critical-package match, compatibility 74 against an 80% floor, and release age 9 inside a 14-day fresh window scores 19.0. With the default threshold 8, that lands in Block and plan.

Privacy Notes:

Dependency rows can expose internal project names, framework choices, and vulnerability work. Pasted text and selected CSV or TXT files are read by your browser for scoring; the analyzer does not upload those rows to a server-side scoring service. Treat exported tables and JSON as project-sensitive material if the package names or notes reveal private systems.

Advanced Tips:

  • Set Review threshold to match your team's review capacity. Lower values produce a larger Owner Review Queue; higher values keep more rows in Batch with checks.
  • Use Critical packages for package-name fragments that represent high-impact surfaces in your own system, such as routing, authentication, payment, database, encryption, or build tooling libraries.
  • Turn on Compatibility floor only when the imported compatibility value is meaningful and comparable across rows. A mixed set of vendor scores, manual notes, and blank cells can make that signal look more precise than it is.
  • Use Fresh release window for teams that want extra caution around brand-new target versions. Leave it at 0 when release age is unknown or when your package policy already handles fresh releases elsewhere.
  • Export Owner Review Queue as CSV or DOCX when assigning follow-up work, and use the Risk Factor Stack chart when a reviewer needs to see which factors created the score.

Worked Examples:

Major runtime security update

A payments service moves express from 4.18.2 to 5.1.0, sets scope to runtime, marks security as yes, lists express as critical, uses medium Test confidence, and imports compatibility 74 with release age 9. With Compatibility floor set to 80% and Fresh release window set to 14 days, the Risk score reaches 19.0, so Owner Review Queue places the row in Block and plan.

Patch fix at the review gate

A lodash update from 4.17.20 to 4.17.21 is only a patch change, but it is runtime scope, security-related, and scored with medium global test confidence. With the default threshold of 8, the visible factors reach 8.0, so the row lands in Owner review even though the version bump is small.

Incomplete import

A reviewer clears the sample rows and pastes notes without package and target values. The page shows At least one dependency update row is required. Add a row with a package name and target version, then confirm the source status shows a loaded update count before reading Upgrade Risk Ledger.

FAQ:

What CSV columns can I paste?

A header row can include package, current version, target version, scope, security, owner, tests, compatibility, release age, and notes. Without a header, use package, current version, target version, scope, security, and notes in that order.

Why did a minor update score like a major update?

When 0.x minor policy is enabled, a minor update under major version zero is treated as breaking-class because Semantic Versioning does not promise a stable public API for major version zero.

Does the security flag prove a vulnerability is fixed?

No. The security flag adds score weight and queue visibility. Confirm the advisory, vulnerable range, patched version, and regression coverage with your normal package audit or software composition analysis process.

Why is a patch update in the owner queue?

Patch updates can enter Owner Review Queue when other signals add up, such as runtime scope, security status, critical package match, weak test confidence, compatibility below the floor, or a very fresh target release.

Why did a row disappear from the ledger?

Rows need a package name and target version before they can be scored. Add those values, or use a header row so the parser can find the package and target columns in your CSV.

Does selecting a CSV send the file away for scoring?

No. The selected CSV or TXT file is read by your browser so the rows can be scored and shown in the ledger, queue, charts, and JSON output.

Glossary:

Semantic Versioning
A versioning convention where major, minor, and patch positions signal incompatible changes, backward-compatible additions, and backward-compatible fixes.
Runtime scope
A dependency role that can affect deployed application behavior, such as server code, client code, API handling, data access, or required libraries.
Critical package
A package name or name fragment that your team treats as high impact because it touches important application surfaces.
Compatibility floor
An optional minimum imported compatibility percentage; rows below the floor receive extra score weight.
Fresh release window
An optional release-age window that adds caution when the target version is very new.
Owner review
A queue state where the update needs a responsible reviewer, validation focus, and merge decision before approval.

References: