Image Vulnerability Scan

The scanner's primary function is to compare the software bill of materials (SBOM) of a container image—its OS packages and application dependencies—against continuously updated databases of known vulnerabilities. These databases include:

• Common Vulnerabilities and Exposures (CVE) list from MITRE.
• National Vulnerability Database (NVD) from NIST.
• Vendor-specific security advisories (e.g., from Ubuntu, Red Hat, Python Security Response Team).

The matching is performed using package name and exact version number to generate a precise list of applicable CVEs, each with a severity score.

Not all vulnerabilities pose equal risk. Scanners use standardized scoring systems to prioritize findings for remediation.

• Common Vulnerability Scoring System (CVSS): The industry standard for assessing severity, producing a score from 0.0 to 10.0 (Critical, High, Medium, Low, Informational).
• Exploitability Metrics: Some scanners incorporate contextual data, such as whether a public proof-of-concept (PoC) exploit exists or if the vulnerability is actively exploited in the wild.
• Base vs. Temporal vs. Environmental Scores: CVSS v3.1 defines a base score (intrinsic qualities), a temporal score (changing exploitability), and an environmental score (impact on a specific organization). Scanners typically report the base score, with advanced tools allowing environmental adjustment.

Beyond OS packages, modern scanners perform Software Composition Analysis to identify vulnerabilities in open-source and third-party application dependencies. This involves:

• Parsing dependency manifest files (e.g., package.json, pom.xml, requirements.txt, go.mod).
• Building a complete dependency graph, including transitive dependencies (dependencies of dependencies), which are a common source of hidden risk.
• Detecting licenses associated with each component to ensure compliance with organizational policies. This feature is critical because application-layer vulnerabilities are often the primary attack vector, even if the base OS is secure.

To be effective, scanning must be automated and gated. Key integration features include:

• Shift-Left Security: Scanning images as they are built within the Continuous Integration (CI) pipeline (e.g., Jenkins, GitLab CI, GitHub Actions).
• Policy-as-Code: Defining security policies that automatically fail a build or block a deployment if critical vulnerabilities are found. Policies can be based on CVSS score, fix availability, or specific package blocklists.
• Admission Control: In Kubernetes, scanners can integrate with admission controllers (e.g., using Open Policy Agent) to prevent vulnerable images from being deployed to the cluster, enforcing security at the last possible gate before runtime.

Identifying a vulnerability is only half the solution. Effective scanners provide actionable remediation guidance:

• Suggested Fixed Version: The scanner identifies the nearest safe version of the package where the vulnerability is patched (e.g., "Upgrade libssl from 1.1.1k to 1.1.1l").
• Base Image Upgrade Recommendations: If a vulnerability exists in the underlying OS layer (e.g., Alpine, Debian), the scanner may recommend upgrading to a newer, patched base image tag.
• Distroless Image Advocacy: Some scanners highlight when a vulnerability exists in a package that isn't required by the application, advocating for the use of minimal, distroless base images to reduce the attack surface.

Advanced scanners go beyond static analysis of the image filesystem to analyze potential runtime behavior.

• Malware Signatures: Scanning binaries within the image for known malware signatures or suspicious patterns.
• Behavioral Analysis: Some tools execute the container in a sandboxed environment to observe its behavior, looking for indicators of compromise like cryptocurrency miners or network callbacks to command-and-control servers.
• Secrets Detection: Scanning for accidentally embedded secrets (API keys, passwords, SSH keys) in the image layers, which are a major security risk if the image is pushed to a public registry.

The cryptographic process of attesting to the authenticity and integrity of a container image using digital signatures, ensuring it has not been tampered with after being built. This is a core practice in supply chain security.

• Common Standards: Use of Cosign with keyless Sigstore or traditional PKI.
• Workflow Integration: Signing occurs post-build and post-scan, often only if the image passes policy checks. Verification happens at deployment time by the orchestrator (e.g., Kubernetes).
• Security Posture: Prevents the deployment of malicious or unauthorized images, even if a registry is compromised.

A DevOps philosophy that integrates security practices early in the software development lifecycle (SDLC), rather than treating it as a final gate before production. Image vulnerability scanning is a quintessential shift-left activity.

• Implementation: Scanning is integrated into the CI/CD pipeline, failing builds that introduce high or critical severity vulnerabilities.
• Benefits: Reduces remediation cost by fixing issues in source code or dependencies before an image is ever deployed. Fosters developer ownership of security.
• Tools: Includes SAST (Static Application Security Testing), SCA (Software Composition Analysis), and pre-commit hooks alongside container scanning.

The protection of containers and applications while they are executing, as opposed to static analysis of the image. It complements image scanning by addressing threats that manifest during operation.

• Key Capabilities: Behavioral monitoring, network policy enforcement, file integrity monitoring, and threat detection based on runtime activity.
• Relationship to Scanning: Image scanning addresses known vulnerabilities in the built artifact; runtime security addresses malicious activity, zero-day exploits, and configuration drift in the running workload.
• Example Tools: Falco, Aqua Security, Sysdig Secure.

A Kubernetes component that intercepts requests to the API server before an object is persisted, allowing for policy enforcement. It is the primary runtime gate for deploying scanned images.

• Use Case: An image policy admission controller (e.g., OPA Gatekeeper, Kyverno) can validate that pods only use images from approved registries, have passed vulnerability scans, and are signed by trusted entities.
• Policy Example: Reject any pod specification where the container image has CVEs with a severity > HIGH or where the signature verification fails.
• Enforcement Point: Provides a final, cluster-level control that is independent of the CI/CD pipeline.

A deployment model where infrastructure components, including container images, are never modified after they are deployed. Updates are performed by replacing the entire component with a new, versioned instance.

• Principle: A running container is never patched in-place. A new image is built, scanned, and deployed.
• Impact on Scanning: Reinforces the criticality of image scanning; the immutable artifact is what gets deployed. Any vulnerability in the image must be fixed in the source and a new image built.
• Orchestrator Alignment: Kubernetes deployments naturally support this model by updating Pods via ReplicaSets.