Container Security Scan Analyzer

A container image can pass through a build system in seconds, but the security review behind that promotion depends on slower evidence: which operating-system packages and application dependencies were found, which advisories apply to those versions, and whether the scanner listed an update path. A container vulnerability report is the raw record of that evidence. It usually names the image or artifact scanned, the vulnerable package, the installed version, the advisory ID, a severity label, and sometimes a fixed version or vendor status.

The difficult part is not only counting vulnerabilities. Scanner reports can mix operating-system packages with language dependencies, repeat the same finding across targets, omit fixed versions, or use different names for the same basic fields. Trivy, Grype, Snyk, SARIF-producing scanners, and CSV exports can all describe the same risk in different shapes. A useful review turns those rows into consistent findings before comparing them with a release policy.

Advisory

The CVE, GHSA, vendor bulletin, or scanner rule that identifies the known weakness.

Package

The OS package or dependency version that the scanner matched to the advisory.

Fix state

Whether the report names a fixed version, says the issue is not fixed, marks it as unknown, or indicates that maintainers will not fix it.

Target

The image, filesystem area, manifest, or artifact location where the finding was reported.

Release gates usually focus on critical and high findings because those labels are meant to represent the most serious technical severity. That does not make every critical row equally exploitable in the running service. A vulnerable library may be present but unreachable, a package may be inherited from a base image, or a vendor may publish severity data that differs from another source. The gate is a policy checkpoint, not a complete threat model.

Fixability changes the first follow-up. A high finding with a fixed package version can move into a patch branch, while an unfixed critical advisory may need a waiver, base-image replacement, vendor monitoring, or a different compensating control. Runtime context matters too. A match on openssl, glibc, curl, java, or another service-critical package usually deserves faster ownership checks than a package that is present but not used by the workload.

A clean gate does not prove that an image is safe, and a blocked gate does not prove that every listed finding is exploitable. The practical goal is a defensible triage brief: normalized findings, counted critical and high rows, clear parser evidence, and a remediation order that a security or platform team can verify against its own policy.

How to Use This Tool:

Use the report, artifact label, and gate thresholds that match the release, base-image refresh, or triage review you are documenting.

1. Enter the image tag, digest, artifact name, or build label in Image reference. The same label appears in Gate Snapshot so the result can be tied back to the scanned artifact.
2. Choose Gate profile for the review. Release gate uses promotion wording, Base image refresh frames the result around replacement work, and Triage only avoids release-blocking language.
   The profile changes decision wording and recommended actions. It does not change the numeric Critical limit or High limit.
3. Set Critical limit and High limit to match the written policy. The gate uses those fields to build Critical gate count and High gate count.
   The gate blocks only when a count is greater than its limit. A High gate count of 2 / 2 is still within the limit.
4. Paste the scanner report into Scan output, drop a local report file, browse for a file, or load the sample. The status badge should change from an empty source to the detected report shape and character count.
   The report text is parsed in the browser. A local file above the 4 MB browser-side limit is rejected before it is loaded into Scan output.
5. Select Parser preference when Auto-detect does not match the report shape. Use Trivy JSON, Grype JSON, Snyk JSON, SARIF JSON, or CSV rows, then check Parser Evidence Ledger for the detected shape and warning row.
   If Review scan input reports no vulnerability rows, re-export the scan as one complete JSON/SARIF report or add clear CSV headers before using the gate decision.
6. Add Runtime package patterns when package-name fragments such as openssl, glibc, libssl, curl, java, or log4j should push matching rows higher in Remediation Queue.
7. Open Advanced only when the default queue or gate policy needs to change. Queue rows changes the visible queue length, and Gate only fixable findings removes unfixed, unknown, and won't-fix rows from the critical/high gate counts while keeping them visible.
8. Review the summary status, Gate Snapshot, and Parser Evidence Ledger before sharing the result. The evidence is ready when the parser warning row is acceptable, the gate counts match policy, and Remediation Queue gives the next package-level actions.

Interpreting Results:

Gate decision is the first result to read, but it is only a threshold decision. Release blocked, Refresh required, and Escalate triage mean the counted critical or high findings exceeded the configured limits. Gate clear and Triage within policy mean the counts stayed within those limits, not that the image has no security risk.

Critical gate count and High gate count use a strict greater-than check. A value of 1 / 0 blocks because one critical finding is greater than a zero-critical limit. A value of 2 / 2 does not block until another high finding appears. If Gate only fixable findings is on, the gate counts can be lower than the total critical and high rows in Severity Ledger.

• Severity Ledger shows the total, fixable, no-listed-fix, runtime-hit, and gate-signal view by severity.
• Remediation Queue sorts findings by severity weight, fixability, runtime package match, gate severity, and numeric severity score when available.
• Parser Evidence Ledger explains the source shape, normalized row count, duplicate removals, queue cap, gate mode, and parser warnings.
• Fixability Pressure Chart helps compare which severity groups have update paths versus no listed fix.

Verify the scanner source data before assigning work. High severity does not prove runtime exploitability, and a missing fixed version does not make a row harmless. Confirm package ownership, runtime use, waiver status, and rebuild impact before treating the queue as final.

Technical Details:

Container vulnerability triage begins with a report that has already been produced by a scanner. The analysis here does not pull an image, contact a vulnerability database, or run a new scan. It reads the supplied report text, converts scanner-specific records into normalized findings, removes exact duplicates, applies optional gate filtering, and builds review tables from that normalized set.

A normalized finding keeps the advisory ID, package name, installed version, fixed version, severity, target, package type, title, source, URL, numeric severity score when present, and fix state together. This makes counts and sorting comparable even when the original report came from different scanner families or from CSV.

Transformation Core

Parser selection starts with the requested source type. In auto mode, scanner-specific JSON shapes are tried before generic JSON and CSV fallback. The first shape that produces vulnerability rows becomes the detected source shape.

Rule Core

The gate is based on normalized findings after duplicate removal. Duplicate findings are matched by advisory ID, package name, installed version, and target. That prevents repeated rows from inflating counts while keeping distinct targets or versions separate.

Priority Score

The remediation queue uses a deterministic score to sort findings. The score is a triage aid only; it is not a substitute for reachability analysis, waiver review, or application testing.

For example, a critical finding with a fixed version and a numeric score of 9.8 receives 50 + 7 + 4 + 9.8, or 70.8, before any runtime bonus. That places it in the release-blocker band. A critical finding with no fix and no numeric score receives 50 + 4, or 54, which keeps it high in the queue but signals a different follow-up: waiver, vendor status, base-image replacement, or compensating-control review.

Limitations and Privacy Notes:

The supplied scan text is parsed in the browser. Normal site assets may still load, but the pasted report or selected local file is not uploaded by the analyzer. Treat scanner reports as sensitive anyway because they can reveal image names, package versions, dependency choices, and internal build labels.

• Scanner databases, vendor advisories, and fixed-version data can change after the original scan was produced.
• A gate result does not verify exploitability, reachability, runtime use, or the presence of compensating controls.
• Fixability does not prove that applying the update is safe for the application. Rebuild and test the image before promotion.
• CSV and generic JSON parsing depend on clear field names or predictable column order. Review parser evidence before trusting those outputs.
• Fixable-only gate mode should match written policy. Otherwise, critical unfixed advisories can look nonblocking by mistake.

Advanced Tips:

• Pin Parser preference to the scanner that produced the report when auto-detect falls back to generic JSON or CSV. Recognized scanner shapes usually preserve package, target, fix-state, and severity evidence better.
• Use Runtime package patterns as short package-name fragments, not severity filters. They add a queue priority bump to matching package names while leaving the severity counts unchanged.
• Turn on Gate only fixable findings only when the policy explicitly blocks on fixable critical and high findings. The excluded rows still need waiver, vendor-status, or base-image review in Severity Ledger.
• Raise Queue rows when the visible remediation table is too short for review. The exported JSON keeps the full normalized queue even when the table shows only the highest-pressure rows.
• Attach Gate Snapshot and Parser Evidence Ledger together when sharing a release decision. The first shows the policy result, and the second shows whether the report shape and duplicate removal were trustworthy.
• Use Fixability Pressure Chart to compare severity groups, not to assign individual package owners. Package-level assignment belongs in Remediation Queue.

Worked Examples:

These cases show how gate thresholds, fixability, parser shape, and queue ordering change the next action.

FAQ:

Glossary:

Container image

A packaged filesystem and configuration used to run an application or service in a container runtime.

Normalized finding

A scanner row converted into a consistent advisory, package, version, severity, target, and fix-state record.

Release gate

A policy checkpoint that compares counted findings with configured thresholds before promotion.

Fixable finding

A finding with a listed fixed version or source state that indicates an update path exists.

Runtime priority hit

A finding whose package name matches one of the optional runtime package patterns.

Parser evidence

The detected source shape, normalized finding count, duplicate count, gate mode, queue cap, and warnings behind the result.

References:

• Reporting, Trivy documentation.
• Vulnerability scanning, Trivy documentation.
• Grype command line reference, Anchore Open Source documentation.
• snyk test command, Snyk User Docs.
• SARIF Version 2.1.0, OASIS Open.
• CVSS v3.1 specification document, FIRST.