Container Security Scan Analyzer

Introduction

Container vulnerability scan reports can be hard to use when a release decision has to happen quickly. A single image can contain operating-system packages, language dependencies, and copied build artifacts, and each scanner may describe the same problem with slightly different field names. The practical question is whether the current image has critical or high findings that exceed the team's gate, which fixes are actually listed, and which package owners need the first remediation pass.

Severity counts are a useful starting point, but they are not enough by themselves. A critical finding with no listed fixed version may need a waiver, base-image replacement, or vendor follow-up, while a high finding with a fixed version can often move directly into a patch branch. Fixability, target label, duplicate rows, and runtime package context all affect how a security review turns from a raw scan into work that someone can assign.

Container scan triage also depends on consistent thresholds. A zero-critical release policy is common in many pipelines, but some teams apply the gate only to vulnerabilities that have a listed fix. Others use the same scan as a base-image refresh brief or as a triage queue after a nightly scan. The same source report can therefore produce different release wording if the gate profile, critical limit, high limit, or fixable-only setting changes.

A scan summary does not prove exploitability, business impact, or whether an exception is justified. It translates scanner evidence into a release-gate and remediation view. The final decision still needs image ownership, package context, runtime exposure, vendor advisories, and any exception process the team uses for accepted risk.

Technical Details:

Container vulnerability scanners usually report one row per vulnerable package, advisory, and target. The target may be the image name, operating-system package database, application dependency set, or SARIF artifact location. The useful review unit is a normalized finding that keeps the advisory identifier, package name, installed version, fixed version, severity, target, title, source, and fix state together.

Severity labels come from scanner data or from a numeric score when one is available. A score of 9.0 or above maps to critical, 7.0 to 8.9 maps to high, 4.0 to 6.9 maps to medium, and a positive score below 4.0 maps to low. Rows with missing or unfamiliar severity data remain unknown. That keeps the analyzer from upgrading uncertainty into a stronger security claim than the source report supports.

Rule Core

The release gate is based on counted critical and high findings after parsing, normalization, deduplication, and optional fixability filtering.

Priority sorting uses severity first, then adds pressure for fixability, critical or high gate relevance, runtime package pattern matches, and any numeric CVSS score found in the source row. The exact score is not shown as a security standard. It is a queue sort so high-impact, fixable, runtime-relevant findings rise ahead of lower-pressure backlog items.

Parser support is intentionally broad enough for common CI artifacts. Trivy-style reports are read from result objects with vulnerability arrays. Grype-style reports are read from match objects that combine vulnerability and artifact data. SARIF reports are read from runs and results, with rule and result metadata used where vulnerability-specific properties are present. CSV input can use headers such as vulnerability, package, severity, fixed version, target, installed version, and type; without headers, the first columns are treated in that order.

The analysis is deterministic from the supplied text and settings. It does not rescan an image, download a vulnerability database, verify whether a CVE is reachable at runtime, or check whether a waiver exists in another system. It reads the report content already available to the user and turns that content into counts, gate status, queue rows, chart values, and structured JSON.

Everyday Use & Decision Guide:

Start with the exact image tag or digest in Image reference. A digest is better than a floating tag when the result will be attached to a release note, waiver, or incident review because it ties the findings to one immutable artifact.

For a release readiness check, use Gate profile set to Release gate, keep Critical limit at 0 for a zero-critical policy, and set High limit to the count your team can tolerate before blocking. Leave Gate only fixable findings off when policy treats all critical and high advisories as gate inputs. Turn it on only when the gate explicitly blocks fixable findings and sends unfixed advisories to a separate exception or monitoring process.

Paste the scanner report into Scan output or load a local JSON, SARIF, CSV, or text file. Keep Parser preference on Auto-detect unless a report is ambiguous. If the parser picks the wrong source shape or reports no vulnerability rows, choose Trivy JSON, Grype JSON, SARIF JSON, or CSV rows directly and check Parser Evidence Ledger for warnings.

• Gate Snapshot is the first review stop for the image label, gate decision, critical and high counts, fixable ratio, runtime hits, and parsed targets.
• Severity Ledger separates critical, high, medium, low, negligible, and unknown findings, with fixable and no-listed-fix counts for each severity.
• Remediation Queue gives the assignable row list with priority, finding ID, package version, fix state, target, context, and action wording.
• Parser Evidence Ledger explains source detection, normalized row count, duplicate removal, gate mode, queue cap, and parser warnings.
• Fixability Pressure Chart compares fixable findings with findings that have no listed fix across severity levels.

Runtime package patterns are useful when a review has known hot spots such as openssl, glibc, libssl, curl, java, or log4j. A package name that matches one of those comma-separated fragments receives a runtime context marker and rises in the queue. Keep the list short. Broad fragments can make ordinary backlog rows look more urgent than they are.

A calm Gate clear result means the counted critical and high findings are within the configured limits. It does not mean the image is secure, that medium findings can be ignored, or that an unknown fix state is harmless. Before copying the JSON or table rows into a ticket, compare Gate decision, Parser warnings, and the top Remediation Queue actions with the policy you intend to enforce.

Step-by-Step Guide:

Use the controls in order so the summary reflects the same policy you would apply in CI.

1. Enter the image tag, digest, artifact name, or build label in Image reference; confirm Gate Snapshot later shows the same label.
2. Choose Gate profile. Use Release gate for promotion wording, Base image refresh for base-image replacement work, or Triage only when the result should not sound like a release block.
3. Set Critical limit and High limit. The gate changes only when the counted value is greater than the limit, so 2 high findings with a high limit of 2 still respects that threshold.
4. Paste the report into Scan output, browse for a local file, or use Load sample when testing the interface. Files larger than 4 MB are not loaded into the field.
5. Leave Parser preference on Auto-detect for normal Trivy, Grype, SARIF, and CSV reports. If the alert says the input was not valid JSON or no vulnerability rows were found, switch the parser to the expected source shape and review Parser Evidence Ledger.
6. Add Runtime package patterns only for package fragments that matter to the review, then set Queue rows between 5 and 100 to control the visible remediation list.
7. Use Gate only fixable findings only when policy excludes unfixed and won't-fix advisories from gate counts. Confirm the Gate mode row says either Fixable findings only or All critical/high findings.

Finish by checking the summary badge, the critical and high rows in Severity Ledger, and the first few Remediation Queue actions before exporting or copying any result.

Interpreting Results:

The most important output is Gate decision. Release blocked, Refresh required, and Escalate triage all mean at least one configured critical or high threshold was exceeded. Gate clear or Triage within policy means the counts are within those limits, not that every vulnerability is acceptable.

Read Critical gate count and High gate count as strict greater-than checks. A Critical gate count of 1 / 0 blocks. A High gate count of 2 / 2 does not block until the count becomes 3. When fixable-only mode is on, these counts can be lower than the total critical and high rows shown in Severity Ledger.

• Fixable findings shows how much of the report has a listed update path; it does not prove the update is safe for the application.
• No listed fix means the source report did not provide a fixed version or normalized the state as not fixed, won't fix, or unknown.
• Runtime priority hits means package-name fragments matched the optional pattern list; confirm the package is actually used before treating the match as exposure.
• Parser warnings should slow the review down, especially after JSON fallback to CSV or when source shape was ambiguous.

High severity does not automatically mean reachable exploitability, and a missing fixed version does not automatically justify ignoring the row. Use the queue to assign first follow-up, then verify scanner source data, package ownership, runtime exposure, and any waiver before closing the review.

Worked Examples:

Release image with one critical row

A Trivy JSON report for registry.example.com/orders:2.8.0 contains four normalized findings: two critical, one high, and one medium. With Critical limit at 0, High limit at 2, and Gate only fixable findings off, Gate decision becomes Release blocked. Remediation Queue places the critical fixable package ahead of lower-severity rows, while the critical no-fix package remains visible for waiver or base-image review.

Boundary case at the high limit

A Grype report for registry.example.com/api@sha256:abcd has zero critical findings and exactly two high findings. With High limit set to 2, Gate decision stays Gate clear because the high count has not exceeded the limit. If a third high finding appears in the next scan, High gate count changes from 2 / 2 to 3 / 2 and the release profile blocks.

Fixable-only policy

A base-image scan has one critical advisory with no listed fix, one high advisory fixed in a newer package, and several medium rows. With Gate only fixable findings on, only the high fixed row counts against the gate. Severity Ledger still shows the critical no-fix row, and Gate Snapshot can remain clear if the high count is within limit. That result should trigger vendor-status or image-replacement follow-up, not silent dismissal.

CSV report that does not parse cleanly

A copied CSV has columns ordered as package, installed version, severity, vulnerability, fixed version, and target, but no header row. The analyzer assumes the first columns are finding ID, package, severity, fixed version, title, target, installed version, and type, so Parser Evidence Ledger may show unexpected normalized values. Add a header row with vulnerability, package, severity, fixed version, target, and installed version, then recheck Normalized findings and Parser warnings.

FAQ:

Glossary:

CVE

A public vulnerability identifier used by many scanner reports.

CVSS

A numeric vulnerability scoring system often used to derive critical, high, medium, and low severity labels.

Fixable finding

A finding whose source row lists a fixed version or fixed state.

Gate decision

The release, refresh, or triage status produced by comparing critical and high counts with configured limits.

SARIF

A JSON-based interchange format for static-analysis and security findings.

Runtime package patterns

Optional package-name fragments that raise matching findings in the remediation queue.

References:

• Trivy Reporting, Aqua Security.
• Filter scan results, Anchore Open Source.
• docker scout cves, Docker Docs.
• NVD Vulnerability Metrics, National Institute of Standards and Technology.
• Static Analysis Results Interchange Format Version 2.1.0, OASIS Open, August 28, 2023.