{{ summaryTitle }}
{{ summaryValue }}
{{ summaryLine }}
{{ badge.label }}{{ badge.value }}
CSV columns may include component, version, license, severity, vulnerability, state, scope, and purl.
{{ sourceMeta }}
{{ sourceActionHint }}
Auto detect resolves JSON by its format markers and otherwise uses CSV; a pinned format bypasses detection.
This label identifies the reviewed artifact in copied and downloaded evidence.
Choose the lowest normalized severity that should require explicit review before release.
Keep UNKNOWN when incomplete license evidence must enter review; confirm obligations with your own policy and counsel.
{{ workflowFeedback }}
Enter comma-separated labels such as fixture or build-only. Built-in test, dev, optional, excluded, and provided scopes already count as non-runtime.
ComponentVersionLicenseScopeVulnerabilitiesMax severityVulnerability pointsLicense pointsIdentity/scope pointsRisk scoreRisk bandCopy
{{ row.component }}{{ row.version }}{{ row.license }}{{ row.scope }}{{ row.vulnerabilities }}{{ severityLabel(row.max_severity) }}{{ row.vulnerability_points }}{{ row.license_points }}{{ row.identity_scope_points }}{{ row.risk_score }}/100{{ row.risk_band }}
PriorityComponentFindingSuggested next stepCopy
{{ row.priority }}{{ row.component }}{{ row.finding }}{{ row.next_action }}
{{ chartError }}
SARIF Security Findings Analyzer Analyze SARIF logs into a local release gate with prioritized findings plus hotspot and tracking-coverage checks for security review.
Container Security Scan Analyzer Normalize container scan reports, apply critical and high release limits, and rank fixable findings for a focused remediation queue.
npm Audit Summary Analyzer Analyze npm audit JSON or terminal output into a severity-weighted release gate and prioritized remediation queue with local processing.
Dependency Update Risk Analyzer Rank dependency updates by release movement, runtime exposure, security and test evidence to plan safer review and merge lanes for your project.

A software bill of materials (SBOM) answers which components are present in an artifact. Release risk needs more evidence: exact package identity, vulnerability records, status or exploitability context, dependency scope, license declarations, and the policy that decides what needs review.

Names alone are weak identifiers. A package URL (PURL), version, and stable component reference make it easier to connect a component with vulnerability evidence across tools. Missing identity can leave a genuine vulnerability unmatched or attach a similarly named record to the wrong package. An SBOM can therefore be syntactically valid yet still be too incomplete for repeatable triage.

Three questions should remain distinct during review:

  • Security: Which vulnerability signals apply, how severe are they, and does status evidence say they are fixed, not affected, or still open?
  • Licensing: Which declared expressions conflict with local policy or still need legal interpretation?
  • Identity: Which components lack the version, PURL, or license evidence needed for reliable matching?

A combined score can sort a queue, but it does not replace those questions. Severity, license policy, missing identity, and runtime scope represent different kinds of evidence. A low point total cannot approve a release, and a high total does not prove exploitability.

Freshness is another boundary. An inventory describes a build or artifact at a particular time, while vulnerability feeds, Vulnerability Exploitability eXchange (VEX) statements, provenance, and deployment reachability can change independently. Preserve the original SBOM and validate it with its native schema tooling before making a release decision.

How to Use This Tool:

Review one artifact at a time and set the vulnerability and license policy before interpreting its score.

  1. Name the artifact and choose Source format. Auto detection reads JSON format markers and otherwise tries component CSV. Pin CycloneDX, SPDX, Syft, or CSV when the document type is known.
  2. Choose Vulnerability gate. Medium, high, or critical is the lowest normalized severity that enters the vulnerability review queue. The gate does not change component scores.
  3. Enter denied license IDs. Keep UNKNOWN when missing license evidence must be reviewed. Add organization-specific non-runtime scope labels when test or build-only components should not receive runtime points.
  4. Paste or load the SBOM source. Browser-local limits are 2 MiB, 5,000 components, and 20,000 vulnerability records.
    A parse failure or zero-component result needs correction before scoring. For CSV without a detected header, confirm the positional order is component, version, license, severity, vulnerability, state, scope, and PURL.
  5. Review component and policy evidence separately. Start with the highest component score, then resolve gate-level vulnerabilities, license findings, missing identity, and unmatched vulnerability references against the original source.

Interpreting Results:

The 0 to 100 overall artifact score prioritizes the current review. It combines the highest component score, the mean component score, and the number of policy findings. Read the component rows and policy queue before acting on that summary.

  • Each component uses Critical queue at 75 or above, High review at 55 to below 75, Elevated at 30 to below 55, and Monitor below 30.
  • A vulnerability below the selected gate can still add component points even though it does not enter the policy queue.
  • Resolved-like states retain 15% of their severity points. Confirm that the status evidence applies to this exact component and version.
  • A Monitor result is not approval. Check inventory completeness, feed freshness, reachability, provenance, license obligations, and local release policy.

Technical Details:

Component review first normalizes several inventory shapes, then links vulnerability references to stable component identities. Scoring happens after matching, so weak references affect both the points assigned to a component and the unmatched-evidence queue.

Transformation Core:

Stage Rule Limit
Detect SPDX is recognized by packages or an SPDX version; Syft by artifacts; other component JSON is treated as CycloneDX-like. Failed JSON falls back to CSV in auto mode. XML SBOMs are not accepted.
Normalize identity Name, version, PURL, reference, scope, and license are reduced to one component record. Missing versions and licenses become unknown and UNKNOWN. Compound license expressions are compared as normalized text.
Normalize severity Explicit labels win. A numeric score becomes critical at 9, high at 7, medium at 4, low above 0, and none at 0. An absent or unrecognized value becomes unknown.
Match vulnerabilities References are matched against component reference, PURL, name, and name with version. Name containment is a fallback. An unmatched record remains an identity finding; a single-component document receives otherwise unmatched records.

Formula Core:

A component score adds vulnerability, license, missing-identity, and runtime-scope points, then rounds and limits the result to 0 through 100.

Scomponent=round(clamp( Pvulnerability+Plicense+ Pidentity+Pruntime,0,100))
Point source Construction Cap
Vulnerability Info 1, low 4, medium 10, high 24, critical 36, unknown 3. Not-affected, resolved, fixed, and false-positive states receive 15% of base points. 62
License A denied ID adds 24. Unknown, selected strong-copyleft, proprietary, commercial, restricted, or EULA-like evidence adds 18; selected reciprocal families add 10. 24
Identity Missing version, PURL, and license each add 5. 15
Runtime scope A component not recognized as non-runtime adds 6. 6

The artifact score weights the worst component more heavily than the average and adds 1.5 points per policy finding.

Soverall=round(clamp( 0.60Smax+0.25Smean+ 1.5F,0,100))

Rule Core:

Rule Boundary or effect
Component risk band>= 75 Critical queue; >= 55 and < 75 High review; >= 30 and < 55 Elevated; < 30 Monitor.
Vulnerability gateSeverity rank >= the selected medium, high, or critical gate enters the queue.
License findingA denied ID or a license classification worth at least 18 points enters the queue.
Identity findingAny missing version, PURL, or license enters the queue.
Gate independenceChanging the vulnerability gate changes policy rows and therefore the artifact score, but not any component score.

Review Limits and Privacy:

SBOM text and loaded files stay in the browser during analysis. Inventory evidence can expose product names, dependency versions, internal references, and known vulnerabilities, so protect copied and downloaded results.

  • The parser extracts selected fields; it is not a complete CycloneDX or SPDX schema validator.
  • The score is a deterministic local heuristic, not CVSS, legal advice, exploitability analysis, or a standards-approved release gate.
  • Substring matching for scope and license text can misread local labels or compound expressions.
  • Current vulnerability feeds, VEX, reachability, provenance, signatures, and attestations require separate evidence.

FAQ:

Why can Syft JSON show no vulnerability findings?

Syft inventory JSON normally lists packages without matched vulnerability records. Use an enriched supported document or component CSV when vulnerability evidence must enter the score and policy queue.

References: