DEVOPSdigest

Containers are at the heart of modern software development. They power cloud-native applications, streamline deployments, and offer unprecedented scalability. But beneath their lightweight, efficient design lies a growing security challenge that is far too often hidden from developers.

The NetRise Software Supply Chain Visibility & Risk Study, Edition 2 analyzed 70 randomly selected container images from 250 of the most commonly downloaded images on Docker Hub uncovering the hidden risks within this containerized software. This analysis offers a sobering look at the vulnerabilities and complexities DevOps teams must contend with. This blog looks at the study's findings, providing insights and practical advice to better secure containers and strengthen software supply chains.

The Scale of the Problem: Over 600 Vulnerabilities Per Container

Containers are far from secure by default. The study found that the average container contains 604 vulnerabilities, with 40.9% of these rated Critical or High according to CVSS Severity scores. Even more alarming, over 4% of these Critical/High vulnerabilities are actively exploited in the wild, categorized as weaponized vulnerabilities.

These risks are compounded by the age of many vulnerabilities. 45% are more than two years old, and some have been present for over a decade. For organizations relying on containers for critical internal and external enterprise applications, these vulnerabilities represent major risks.

Addressing this scale of risk requires prioritization. Organizations must focus on vulnerabilities that are actively exploited or pose the highest threat to their environments. But simply having visibility of the problem is the first step.

Container Blind Spots: Manifestless Components and Non-CVE Risks

Traditional container scanning tools are designed to rely on container manifests to identify software components. But the research found that 12.4% of container components lack these manifests, meaning they lack the formal metadata typically found in manifests and that they don't include details about dependencies, version numbers, or the source of the package. This leaves traditional container scanning tools and those that use them blind to the contents within.

The study also highlights the prevalence of non-CVE risks, including:

■ 4.8 misconfigurations per container, such as overly permissive identity controls.

■ Insecure URLs, weak hash algorithms, and other operational flaws that widen the attack surface.

Securing containers requires tools and processes capable of identifying risks beyond CVEs. Without this, organizations can be flying blind in critical areas of their software development and software supply chains.

Why SBOMs Are the Foundation of Container Security

A Software Bill of Materials (SBOM) is more than a compliance checklist — it's a blueprint for understanding the contents within your software. SBOMs provide transparency into the components, dependencies, and potential vulnerabilities and misconfigurations within containerized software.

However, for containerized software, only 39% of mature container users are currently creating SBOMs for the software they build and only 30% are using SBOMs for open source software they use according to a survey conducted by Anchore. This gap leaves organizations unable to track vulnerabilities effectively or meet emerging regulatory requirements like the White House Executive Order 14028 or the EU Cyber Resilience Act.

Generating and maintaining SBOMs is critical for visibility, compliance, and risk management. It's a foundational step toward securing containerized applications and can be conducted on either the container source code or compiled code using the appropriate tooling.

Bridging the Gap: Practical Steps for Securing Containers

So, how can organizations address these risks and close containerized software visibility gaps? Here we suggest 3 key strategies:

1. Adopt Advanced Visibility Tools

Use tools capable of generating detailed SBOMs and identifying hidden risks, such as manifestless components and non-CVE vulnerabilities. These tools are capable of quickly reverse engineering containerized compiled and interpreted code.

2. Prioritize Threats Based on Risk

In evaluating container vulnerabilities for response actions, prioritize weaponized vulnerabilities and those actively exploited in the wild. Leverage vulnerability intelligence from analysis of the container software to guide remediation efforts.

3. Integrate Security Across the Lifecycle

Build collaboration between DevOps, security, and compliance teams through DevSecOps practices. Embedding security into development workflows ensures risks are addressed proactively. For enterprise users, incorporate software composition analysis into processes around containerized software use.

Conclusion: The Path to Resilient Software Supply Chains

Containers are integral in the future of software development, but they're also a growing target for cyber threats. The findings from the study can serve as a wake-up call for DevOps teams, security professionals, and enterprise business leaders alike.

Visibility, supported by detailed SBOMs and advanced risk assessments from software composition analysis, is the cornerstone of securing containerized applications. By uncovering hidden components, addressing prioritized vulnerabilities, and integrating security throughout the lifecycle, organizations can build more resilient software supply chains.

It's time to move beyond blind trust in your software. Take container security seriously. The risks are real — but there are ways to address the risks.