As an Associate Professor of Cybersecurity, I spend a lot of time thinking about risk, and increasingly, that risk lives within the software supply chain. The current industry focus on CVEs is a necessary, but ultimately insufficient, approach to securing modern, containerized applications.

Frankly, relying on basic vulnerability scanning alone is like putting a single padlock on a vault with an open back door, it gives a false sense of security. If we are serious about container security, we need to go beyond the patch-and-pray cycle and start enforcing comprehensive, deep inspection.

The Limitation of CVE-Only Scanning

The vast majority of container security tools trumpet their ability to find CVEs or remove all CVEs from base images. While identifying known vulnerabilities is crucial, it only addresses one facet of risk. What about the other, often more insidious, security pitfalls?

• Misconfigurations: An application might have zero known vulnerabilities, but if a critical configuration file is improperly set (e.g., exposed ports, weak permissions), the image is fundamentally insecure.
• Hidden Secrets: The accidental inclusion of API keys, SSH keys, or database credentials is a depressingly common issue. A CVE scanner won’t catch these, but a single leaked secret can lead to total environment compromise.
• Supply Chain Integrity: Is a package allowed in your image? Are you using specific, approved base images? The presence of unauthorized or blacklisted packages introduces unknown, unvetted risk.
• License and attestation: Do you care about licensing and their compliance? The presence of accurate license data and attestation ensures that all software components meet legal and organizational compliance standards, reducing risk and supporting secure, transparent supply chains. 

I’ve seen first hand how a policy failure, not a zero-day, is often the weakest link. True security means moving from a reactive model of patching what’s known to a proactive model of enforcing what’s correct.

Deeper Analysis with Anchore

This is where a tool like Anchore becomes essential. Anchore shifts the focus from merely reporting CVEs to enforcing a robust security and compliance policy based on a complete understanding of the container image. It allows us to codify security expectations directly into the CI/CD pipeline.

Here’s how Anchore enables a deep inspection that goes far beyond the basic vulnerability database:

1. Configuration File Compliance

Anchore analyzes the actual contents and structure of configuration files within your image.

1. Configuration File Compliance

Anchore analyzes the actual contents and structure of configuration files within your image.

Example: You can enforce a policy that fails any image where the file /etc/ssh​/sshd_config contains the line PermitRootLogin yes. This policy ensures that a critical security best practice is always followed, irrespective of any package’s CVE status.

Anchore Enterprise’s Policy Engine is configured to enforce these advanced security checks. Let’s explore how to do this:

These policies are built from a hierarchy of gates, triggers, and actions. You can read more about policy and its components in my previous blogpost: Automate Your Compliance: How Anchore Enforce Secures the Software Supply Chain.

Let’s add a policy to fail the build of any image where the file /etc/ssh​/sshd_config contains the line PermitRootLogin yes.

To ensure configuration files comply with security best practices, you can use the retrieved_files policy gate. This gate allows Anchore to inspect the contents of files included in your image, enabling the detection of misconfigurations and other potential issues.

Learn more about the retrieved_files gate here: Anchore Documentation – Gate: retrieved_files.

To add a new rule:

1. Go to your preferred policy settings.
2. Add a new rule.
3. In the Gate dropdown menu, select retrieved_files.
4. Choose a Trigger.
5. Specify the file path (location of the files).
6. Enter the regex pattern you want to detect.
7. Finally, apply the new rule and save the updated policy.

2. Image Whitelists and Blacklists

Moving beyond just patching vulnerabilities, Anchore allows you to control the universe of components that make up your image.

• Denylisting: Automatically fail an image if it contains an unapproved or deprecated package, such as an old version of python2 or a specific cryptomining library that slipped past a developer.

• Allowlisting: Enforce that only packages from a specific, trusted vendor or build are permitted, ensuring that all components adhere to strict internal quality standards.

You can read more about allowlist here: Anchore Documentation — Allowlists

Anchore goes beyond traditional CVE scanning by giving teams precise control over what is and isn’t allowed in their container images, enabling proactive, policy-driven security that aligns with their organization’s unique compliance and quality standards.

3. Secret and Credential Detection

Perhaps the most critical “non-CVE” check is secret and credential scanning. Anchore uses the secret_scans gates to scan the entire filesystem of the container image for patterns matching sensitive data.

For example, using this gate allows you to set a rule that fails the image build if any file contains a string that looks like a high-entropy AWS Secret Key or a standard format SSH private key. This definitely goes beyond traditional CVE scanning and prevents catastrophic credential leakage before the image ever hits a registry.

Read more about this gate here: Anchore Documentation — Gate: secret_scans

4. Licensing and Attestation

For comprehensive software supply chain hygiene, Anchore also allows policies around component licensing, ensuring you meet legal and compliance obligations for open source usage. You can also enforce build-time attestation, ensuring the image was built by an approved CI/CD system and hasn’t been tampered with.

Example: Enforcing License Denylists

A critical part of software supply chain policy is preventing the accidental use of components licensed under specific, undesirable terms. Anchore uses the License Gate and its corresponding License Trigger to check for the presence of any license you want to deny.

Let’s say your organization must block all strong copyleft licenses, such as the GNU General Public License v2.0-only (GPL-2.0-only), because it requires derivative works (like your final application) to also be published under the GPL.

How Anchore Enforces This:

Detection: Anchore scans the image and identifies every package and file licensed under GPL-2.0-only.

Policy Rule: A rule is configured in the policy to target the license trigger and set the action to STOP if GPL-2.0-only is detected in any installed package.

Conclusion: Dive Deep with Anchore Enterprise

As cybersecurity professionals, we must champion the shift from reactive vulnerability management to proactive policy enforcement.

A CVE score tells you about known weaknesses. Deep container analysis with Anchore Enterprise tells you whether the image adheres to your organization’s definition of secure and compliant.

The software supply chain is where the next major cybersecurity battles will be fought. By implementing deep inspection policies now, we can move beyond the CVE and build a truly resilient, defensible container infrastructure. We simply can’t afford to do less.

The post Beyond The CVE: Deep Container Analysis with Anchore appeared first on Anchore.

*** This is a Security Bloggers Network syndicated blog from Anchore authored by Josh Sopuru. Read the original post at: https://anchore.com/blog/beyond-the-cve-deep-container-analysis-with-anchore/