.svg)
Your manifest is not your software.
A manifest lists what your code imports. An image is what actually ships — an operating system, its packages, the language runtime, and everything the base image brought with it. Heeler scans the images your registries hold and your workloads run, reads every finding back to the layer that installed it, ranks it by the workload running the image, and opens the pull request that moves you to a clean base.
Half your CVEs never appear in a manifest.
Most of what an attacker reaches inside a container was never in your dependency file. It came from the base image — an operating system, a package set, and a runtime someone else assembled and you inherited.
The base is somebody else's build
You pick a tag and inherit an operating system, a package set, and a runtime you never chose. When one of them carries a CVE, it is in your image whether or not your code touches it.
Registry scanners rank in a vacuum
A registry knows the image has four hundred CVEs. It does not know which service runs it, whether that service is internet-facing, or whether anything runs it at all. Every image looks the same.
One line, one quarter
The fix is usually one line in a Dockerfile. Working out which line, and what the new base breaks, is what turns it into a quarter of work nobody starts.
Read to the layer that installed it.
Heeler unpacks the image layer by layer and records what each one added — the package, the version, and the build instruction that put it there. A finding names the layer and the command behind it, not just the image.
Packages, not guesses
Every operating-system package and language dependency in the image, read from the package databases the distribution and the runtime actually maintain — not inferred from the tag.
The distribution's own position
Each vulnerability carries the position of the vendor that owns the package — fixed, deferred, will not fix, or past end of life — so nobody waits on a patch that is never coming.
Secrets in the layers
A credential baked into an image stays in the layer that added it, even after a later layer deletes the file. Heeler reads the layers, so it finds them.
Support dates, not version strings
Heeler tracks when the image's operating system leaves support, so an unsupported base is a finding in its own right rather than a footnote on somebody's wiki.
Base image, or yours
Every package is attributed to the base image or to your own build, so you know immediately whether the fix is a Dockerfile change or a bump in your manifest.
The instruction behind the layer
Each layer carries the build instruction that created it, so a finding points at the line in the Dockerfile that has to change — not at the image as a whole.
The base upgrade, computed and opened.
Heeler doesn't name a newer tag and leave you to test it. It scans candidate base images, measures each one against the image you run today, and opens a pull request that changes the base line in your Dockerfile.
Scanned, not compared by version
Candidates are scanned and measured against your current image, so the recommendation rests on what the swap actually fixes rather than on which tag reads as newer.
Removes, remains, introduces
Each candidate states what the upgrade clears, what it leaves behind, and anything new it brings with it — before you take it.
One line, opened as a pull request
The change is the base image line and nothing else. It arrives as a pull request in your repository, and it is recalculated as newer bases are published.
A CVE in an image nobody runs is not an incident.
Heeler pairs every image finding with the running world. A critical CVE in an image no workload has pulled is not the same problem as the same CVE in the image behind your public API, and it shouldn't sit in the same queue. Every finding lands on one of three levels.
Urgent
The image runs a high-tier service that is exposed to the internet. Fix now.
Plan
Real risk, but contained — a lower-tier service, or an image running well away from the edge. Schedule it.
Defer
Nothing currently runs the image, or it runs only outside production. Track it.
Scanned on push. Rescanned while it runs.
An image is scanned when it arrives and scanned again while it is still in use. A base that was clean in March is not still reported as clean in September — new advisories land against images you built months ago.
Scanned on arrival
A new image is picked up and scanned as it lands in the registry — no pipeline step to add, no build to instrument.
Rescanned while in use
An image a workload is still running is rescanned against current advisories, so a CVE published today shows up against an image you built last quarter.
Rescanned, not re-reported
Rescans run on an interval rather than on every registry event, so an image that hasn't changed doesn't refill your queue with findings you already have.
The bill of materials for what actually shipped.
Heeler produces a bill of materials for the image itself — every operating-system package and language dependency actually present in the layers, not the manifest the build started from. Export it in CycloneDX or SPDX when a customer, an auditor, or a regulator asks what shipped.
See how Heeler supports audits →See what's inside the images you're already running.
A demo runs Heeler against your registries and your repositories. In your first session you'll see what is inside the images your services are running right now, which findings came from the base, and the pull request that changes it.
