How do you scan the container images of a company you just acquired?

Start with an inventory, not a scan. Get read-only access, list every image that runs and every registry that holds one, then scan by digest and group findings by owner and base image. Fix the exposed and exploitable items first, and record what you inherited so the baseline is on the record.

Why acquisitions are different

In your own company you know where the images live. In an acquired one you do not. Teams may use registries you have never heard of, base images nobody maintains, and build tooling that predates the deal. Some images belong to services that are being retired. Some run customer workloads with commitments attached. The first month sets how well you understand the risk you bought.

Be careful about what you can do before the deal closes or before integration is approved. Access to systems needs authorization from the other company, and legal terms may limit what you may scan or share. Check with your legal and security leaders before you touch anything. This post covers the technical plan once access is properly granted.

Week 1: get access and make a list

1. Agree the scope in writing: which cloud accounts, registries and clusters are in.
2. Ask for read-only credentials, created for this purpose and set to expire. See what registry permissions a scanner needs.
3. List images from four places: running clusters, build pipelines, registries and deployment files. The method is in build a container image inventory.
4. Key the list by digest.
5. Add a column for the service, the team and the customer impact, even if you only know some of it.

By the end of the week you should know roughly how many distinct images run, which registries matter, and which images have no known owner.

Week 2: scan and baseline

1. Scan every deployed digest. Use one scanner and one policy for the whole set, so the numbers are comparable.
2. Record the results as a baseline with a date. This is the state you inherited, and it should stay separate from your own company's numbers.
3. Group findings three ways: by base image, by service and by severity with exploitation signals.
4. Mark images on end-of-life operating systems or runtimes.
5. Note images that cannot be scanned, for example unusual formats, and handle them by hand.

A baseline protects you. When the board asks in six months why the combined number went up, you can point to the date you inherited the images.

Week 3: triage

Use a simple order.

Check which findings are really reachable, since many are not. A reachability view helps you cut the list to what matters first.

Week 4: ownership and policy

• Assign an owner to every image, even if the owner is "to be decided by date X."
• Retire images for services that are being shut down, after confirming nothing depends on them.
• Move base images toward your approved list over time, not all at once.
• Apply your standard policy in report-only mode first, then enforce on new builds.
• Start rescans on a schedule so new findings do not wait for the next project.

What to tell leadership

Keep it short and factual.

• How many images, in how many registries.
• How many have no owner.
• The count of images on unsupported bases.
• The count of exposed images with known exploited issues.
• The plan and dates.

Do not promise a clean score. Promise a plan with owners.

A sample first report

A short report at the end of week three might look like this. The numbers are illustrative only.

Each line has a next step. The 22 unowned images go to a review with the acquired team's leads. The 14 end-of-life images get a migration plan with dates. The 3 exposed images get a fix or a mitigation this week. The 5 unscannable images get a manual review to learn why they failed, for example an unusual format or a missing layer.

Working with the acquired team

Technical work goes better when the people who built the images are involved. Ask them which images matter most to customers, which are on their way out, and which they worry about. Share the baseline openly, and frame it as an inventory of inherited work, not a verdict on their engineering. Agree who approves changes to images that serve contractual commitments, and who is on call if a fix breaks something.

It also helps to agree on a small number of shared rules early: pin base images by digest, label images with an owner, and scan every build. Three rules the team can live with beat a long policy they ignore.

Risks to watch

• Credentials left in images or pipelines. Treat any secret you find as exposed, report it through your process and arrange rotation with the owning team. Do not use or copy it.
• Customer commitments that fix versions or dates, which limit how fast you can change an image.
• Different licenses or compliance obligations attached to some images.
• Shadow registries that nobody listed.

Common mistakes

• Scanning first and building the inventory later, which hides what you missed.
• Folding inherited findings into your own metrics without a baseline.
• Forcing your policy on day one and stopping the acquired team's releases.
• Skipping the conversation with the people who know why an image exists.

Try it yourself

Click through it at your own pace, or open it full screen.

Follow how findings move from detection to prioritization to closure, and match that flow to the four weeks above.

Where Safeguard fits

Safeguard offers asset discovery, reachability analysis, SBOM and dependency scanning, and policies and gates, which help with the inventory, triage and policy stages. You can try a free scan at gold.safeguard.sh/scan.

Quick check

Last reviewed: 19 October 2026.