Your base image might contain someone else’s problem, right up until you ship it
Pulling a base image is routine. You grab it, build on top of it, ship the container, and move on. It is fast, reproducible, and usually reliable. The catch is that every base image comes with history, and that history is a major unknown for many teams.
When you pull a base image, whether from Docker Hub or an internal golden image, you are not just inheriting an OS and a runtime. You are inheriting every package, library, and dependency that image was built with, along with every vulnerability attached to them, including those discovered since the image was last updated.
You did not write that code. You did not choose most of those packages. But once you ship the image, you own all of it. Security tools do not care where the code came from. They only care that it is running.
How base images inherit open-source vulnerabilities
Open source software is foundational to modern development, but its scale has outgrown most teams’ ability to manage it.
According to Black Duck’s 2026 “Open Source Security and Risk Analysis” (OSSRA) report, which analyzes nearly 1,000 real-world codebases, applications contain 1,180 open source components on average. A significant portion of those components are transitive dependencies, meaning they are brought in indirectly through other libraries your team chose, often without anyone explicitly adding them.
This matters because transitive dependencies can quietly expand your attack surface. They can introduce vulnerabilities and license obligations through upstream packages, and they tend to be harder to notice, track, and prioritize than direct dependencies. This “hidden in plain sight” dynamic also shows up in containerized environments, where base images can include large sets of open source components that teams didn’t directly select.
Outdated components: the maintenance-debt problem in base images
The issue goes beyond vulnerabilities. According to the 2026 OSSRA report, over 90% of audited codebases contain components that are four or more years out-of-date, and 93% contain components with no development’s activity in the past two years. This level of maintenance debt dramatically increases the likelihood that vulnerabilities will persist long after fixes are available.
Four years is a long time in security. A vulnerability that once seemed theoretical can suddenly become exploitable as proof-of-concept code circulates, attackers automate scanning, and exploitation techniques continue to mature. When base images include components that have not been updated in years, that risk compounds across every application build on top of them.
The report also shows that application complexity continues to accelerate. At the current scale, teams cannot realistically track component age, update status, and vulnerability exposure manually. “We’ll notice if something looks wrong” necessarily becomes the default strategy, but by then it’s often too late.
Why base image vulnerabilities fall through the cracks
Security teams focus on application risk. Engineering teams focus on features and delivery. Infrastructure often belongs to yet another group.
Base images sit between those boundaries. They are not quite application code, but they are not clearly owned infrastructure, either. When ownership is unclear, maintenance and review are easy to overlook.
There is also a psychological factor. When a vulnerability appears in code you wrote, it feels actionable. When it appears in a base image someone else maintained, it feels external, regardless of your team’s decision to use it.
The OSSRA report found that maintenance debt is widespread. And base images often inherit the same aging open source, carrying long-lived risk far into production environments.
How software composition analysis reveals inherited risk in base images
These problems are solvable, but doing so requires visibility earlier and deeper in the pipeline.
Running software composition analysis such as Black Duck® SCA on the image layer reveals what’s inside application containers. This includes operating system packages, runtimes, and transitive dependencies pulled in through the base image.
And the analysis does not stop at the application layer. Black Duck SCA scans containers as part of generating a Software Bill of Materials, which gives teams an inventory that tracks artifacts instead of manual checks that live in a disconnected spreadsheet. It can even pinpoint which layer of a container image introduced a vulnerability.
When teams see the risk early in their pipeline, updating or replacing a base image becomes a straightforward design choice rather than an urgent incident response task.
Vulnerabilities in your base image may have been introduced by someone else, but shipping them without looking is still a decision you make. Knowing what is inside your base images before you ship allows teams to assess inherited risk instead of discovering it during an audit.
At the end of the day, it does not matter where a vulnerability originated. While vulnerabilities in a base image may have been created by someone else, pushing those vulnerabilities to production is always a conscious decision, which means owning and managing that risk is no longer optional.
