{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Use the unfiltered report when the gate must account for every critical and high finding.
{{ sourceStatus || 'Drop one JSON, SARIF, CSV, or TXT file onto the textarea.' }}
Auto detect reports the resolved parser; a pinned format bypasses shape detection.
Prefer an immutable digest when the scan job provides one.
Choose the downstream decision this evidence supports.
Zero enforces a zero-critical policy; equality remains within policy.
findings
Set the number of high findings the written policy permits.
findings
Use all high+ findings unless policy explicitly gates only advisories with a listed fixed version.
Leave blank for neutral priority; add environment-specific fragments such as openssl, glibc, libssl, curl, java, or log4j.
Show the highest-pressure 5–100 findings.
PriorityFindingPackageSeverityFix stateTargetReview nextPressureCopy
{{ row.priority }}{{ row.finding }}{{ row.package }}{{ row.severity }}{{ row.fix_state }}{{ row.target }}{{ row.next_action }}{{ row.priority_score }}
EvidenceValueReview noteCopy
{{ row.label }}{{ row.value }}{{ row.note }}
{{ chartState === 'loading' ? 'Loading severity chart…' : 'Severity chart unavailable. Check your connection, then retry. CSV remains available.' }}
Parser signalValueReview noteCopy
{{ row.label }}{{ row.value }}{{ row.note }}
SBOM Component Risk Analyzer Review SBOM components with a transparent risk score and separate queues for vulnerabilities, licenses, and incomplete package identity.
Network Audit Findings Report Turn network audit findings into a ranked remediation register with escalation counts, due-state checks, owner gaps, and browser-local reporting.
SARIF Security Findings Analyzer Analyze SARIF logs into a local release gate with prioritized findings plus hotspot and tracking-coverage checks for security review.
Audit Log Anomalies Analyzer Rank suspicious audit events from common log and CloudTrail exports using transparent signals for failures, source shifts, and privilege changes.

A container scan is a snapshot of known findings against one image or artifact. It connects an advisory identifier to a package and installed version, then may add severity, a fixed version, package type, target, and vendor status. That evidence helps a release team decide what must be patched, reviewed, waived, or tracked.

Reports from different scanners rarely share one shape. Trivy groups findings by target, Grype pairs vulnerabilities with artifacts, Snyk uses dependency-focused fields, and SARIF carries results through a general static-analysis format. Normalization makes those rows comparable enough for one review queue, but it cannot make their databases, severity sources, or package detection identical.

EvidenceWhat it supportsWhat it does not prove
SeverityConsistent policy gates and first-pass orderingThat the vulnerable code is reachable or exploitable in this workload
Fixed versionA concrete package-update pathThat the update is compatible or available in the current base image
Image referenceWhich scan evidence belongs to which artifactThat a mutable tag still points to the same image later
Clean gateThe selected critical and high allowances were not exceededThat the image has no vulnerabilities, secrets, misconfiguration, or supply-chain risk

A useful release policy states the counted population and boundary clearly. “No more than zero critical findings” differs from “no more than zero fixable critical findings,” because an unfixed critical row stays visible but can be excluded by the second policy. Equality also matters: an allowance of two high findings permits exactly two and blocks at three.

Fixability and runtime relevance improve remediation order without changing severity. A package with a listed fix can move directly into a rebuild, while an unfixed issue needs vendor review, replacement, an exception, or compensating controls. Package-name hints can raise known runtime dependencies in the queue, but the scan alone cannot determine whether code is loaded or reachable.

How to Use This Tool:

Use the complete report for the exact image being judged, preferably identified by an immutable digest.

  1. Paste or load one JSON, SARIF, CSV, or text report. Use Auto detect for a recognized scanner shape, or pin the format when detection is ambiguous.
  2. Enter the image reference and choose whether the evidence supports a release, base-image refresh, or triage review. The profile changes action wording, not the numeric gate.
  3. Set critical and high allowances, then choose all high-and-critical findings or only those with a listed fix as the gate population.
  4. Add runtime package fragments only when they reflect the workload. They raise queue priority but do not change severity or gate counts.
  5. Confirm the resolved parser, duplicate count, gate population, and image identity before using the Remediation queue to assign work.

Interpreting Results:

Release blocked, Refresh required, or Escalate triage means at least one counted critical or high total is greater than its allowance. The profile changes the decision language and recommended follow-up; the same limits and counted population drive all three profiles.

Read the gate beside Severity fixability. A clear fixable-only gate may still contain unfixed critical findings, and those rows remain visible. Conversely, a blocked gate may be driven by duplicate-looking findings from distinct targets or installed versions that the deduplication rule correctly keeps separate.

Verify high-priority rows against the scanner's original report and advisory source. Parser normalization, severity fallback, and package-name matching are triage aids, not an exploitability assessment or waiver approval.

Technical Details:

Container-scan analysis has two separate decisions. The gate counts normalized critical and high findings against explicit allowances. The remediation score ranks individual findings by severity, fixability, declared runtime relevance, and an available numeric score.

Transformation Core

  1. Recognized Trivy, Grype, Snyk, SARIF, GitLab, generic JSON, and CSV fields are mapped to advisory, package, installed version, fixed version, severity, target, package type, title, source, and numeric score.
  2. Severity labels are normalized to Critical, High, Medium, Low, Negligible, or Unknown. When no usable label exists, a numeric score maps at 9, 7, 4, and greater than 0.
  3. Rows are deduplicated by advisory, package, installed version, and target after punctuation and case are removed from those comparison values.
  4. Every remaining row contributes to severity totals; the selected gate population and remediation score are then evaluated independently.

Rule Core

The gate blocks only when a counted total is greater than its allowance. Equality remains within policy.

blocked= (Ncritical>Acritical) ∨ (Nhigh>Ahigh)

All critical and high findings are counted by default. Fixable-only mode restricts those counts to rows with a non-placeholder fixed version or a fix state that resolves to fixed. Unfixed findings are not removed from the report.

Formula Core

Remediation pressure starts with a fixed severity weight and adds transparent bonuses.

P=wseverity +7Ifixable +8Iruntime +4Ihigh+ +clamp(score,0,10)
ItemValue or boundary
Severity weightsCritical 50, High 30, Medium 12, Unknown 6, Low 4, Negligible 1
Release blockerP ≥ 64
Patch branch42 ≤ P < 64
Security queue22 ≤ P < 42
Maintenance10 ≤ P < 22
TrackP < 10

The source is limited to one million characters. Critical and high allowances accept whole numbers from 0 to 9,999, and the rendered remediation queue accepts 5 to 100 rows after all accepted findings have been counted and scored.

Security and Privacy Notes:

Scanner output can omit packages, report stale advisory data, disagree with another database, or describe code that is present but unreachable. Re-scan the immutable image with the organization's approved scanner and policy before release, and record exceptions outside this triage score.

  • Pasted reports and local files are processed in the browser and are not uploaded by this analysis.
  • Reports may expose private registry names, image digests, package versions, and unresolved weaknesses. Minimize or redact them before sharing.
  • A gate covers vulnerability-report rows only. It does not inspect image signatures, secrets, runtime configuration, provenance, malware, or network exposure.

References: