Why a network scan misses most of it
A network scan sees the certificate and cipher suites a service presents on a port. A container image contains what the service was built from: the CA bundle it trusts, the client certificates it uses to call other services, the private keys someone copied in during a build, the OpenSSL or Go or Java runtime that implements its cryptography, and the code-signing material of the packages inside. None of that is visible from outside, and much of it decides how hard a migration will be.
How image discovery works
An OCI or Docker image is a stack of layers, each a tar archive with a digest. Discovery walks each layer separately, inspects every file it can parse, including archives, packages and keystores nested inside, and records the layer digest as the provenance of each finding. The result is an inventory in which a certificate can be traced to the image, the layer and the path that introduced it, and therefore to the build step and the team that owns it.
When a local daemon is available, a runtime diff can be scanned as well: the files a running container created or changed since it started. That catches keys generated at start-up, configuration mounted from secrets and certificates fetched at runtime, attributed to the running container rather than the image.
In Cryptoramic the image becomes a container image host in the inventory, running containers become child hosts of that image, and every asset carries the layer or runtime source in its discovery path.
What it finds, and what it does not prove
Expect to find: certificates and keys, trust stores and keystores, signed packages and their signing certificates, and the cryptographic libraries and their versions. Expect the inventory to connect those libraries to known vulnerabilities and to supplier readiness evidence for the identified product versions.
Do not expect presence to prove use. A library in an image may never be called; a certificate may be a leftover from a base image. The inventory should say “present in layer 3 of image X”, not “used by service Y”, until configuration, traffic capture or runtime evidence establishes use. Keeping that distinction visible is what makes the inventory trustworthy when an engineer opens it.
When a registry makes a useful first scope
- The image is identifiable. An image digest identifies exactly what was scanned; a rescan after a change is a clean comparison.
- Ownership can be agreed. Select images maintained by a known team and build pipeline, so someone can act on the findings.
- It separates collection from running workloads. Image scanning does not require inspecting a running container, but registry access and resource use still need approval.
- It is where fixes happen. Rebuilding an image with an updated base or library is the change most findings need.
Scan the registry, review the findings with the owning teams, fix what is local, ask suppliers about the base images and packages you do not control, and rescan the new digests. Then widen to the hosts the images run on. That sequence is the argument in why an estate-wide inventory is the wrong first step, applied to the scope most organizations already have at hand.
Frequently asked questions
What cryptography is found inside a container image?
An image can contain certificates, private keys, trusted certificate stores, signed software and cryptographic libraries. Examining its layers helps identify where those items came from.
Does scanning an image affect running containers?
Scanning the stored image does not modify running containers. It reads the image’s layers from a registry or local container service. Inspecting changes inside a running container is a separate collection step.
Does presence in an image prove the cryptography is used?
No. A library or certificate may be present without being used. Check settings, network traffic or evidence from the running application to confirm actual use.