Configuring Docker Image Scanning with Anchore Engine

Anchore Engine: where Docker image scanning fails

The build is the same, but the base image is pulled from someone else's registry: vulnerabilities in images enter the production environment not from your code, but from a layer you did not build and never updated.

At the same time, checking rests on manually reviewing the manifest before release — and ends exactly where the rush begins.

This breaks at scale. A floating tag points to different images on different days, the cache pins the old layer, dependencies are installed from a lock file that is months old.

A patch in the base layer was released long ago, there was no rebuild — and the vulnerability remained in production, even though formally the service composition did not change.

Anchore Engine closes exactly this gap: Docker image scanning is based on the checksum, not the tag, and the image itself is parsed into layers with an inventory of system manager packages and language dependencies.

Control of base layers rests on policy: a criticality threshold, allowlists and denylists of packages, and a ban on releasing a build that has not passed scanning in the current revision.

The difference is visible not in the report, but at the point before rollout. Checking before writing to the registry stops the build; checking after leaves the artifact in the registry and turns analysis into manual work for the on-call engineer. Below we examine how this is closed in practice and what exactly breaks most often.

What image scanning in the build pipeline provides

Image scanning has an effect only when built into the build pipeline: a report on an image built manually once a month does not affect what goes to production.

We place Anchore Engine at the build stage and tie its verdict to admission rules — then container security stops being a separate task and becomes a condition for releasing. Below is a checklist of results that show scanning is working rather than creating an illusion.

• Build coverage. Previously checks were selective, on request or before a major release; now every image gets a verdict before publication to the registry. An image without a conclusion simply does not move further.
• Time for manual review. Analyzing the report takes minutes instead of hours of manually reviewing the package list and manifests. A remark goes to the person building the image, not to the person on night duty later.
• Layer-by-layer dependency checking. The specific package and its version that cause the build to fail are visible. The fix usually comes down to one line in the build description, not rebuilding the whole service.
• A disappearing class of failures. An admission rule blocks publication of an image with a critical vulnerability level — the scenario "something no one looked at went to production" is closed at the build stage.
• Exceptions under control. Instead of silent consent — a record with a reason and review deadline. The exception register shrinks over time because each one is visible on the shared dashboard.
• Trend instead of a one-time snapshot. Across releases, you can see whether the number of vulnerabilities is growing and what exactly is driving it: an aging base image or a specific library. This is already grounds for planned replacement, not a fire drill.

The trigger threshold and exception list are configured per service: for an internal tool and for a public API, the admission levels differ.

Image scanning modes and their limitations

Anchore Engine is not turned on with a single switch — you first choose the point where the decision about the image's fate is made. The same engine gives different results depending on the depth of layer analysis, the launch moment, and the threshold at which release is stopped.

Modes and their limits

Without threshold rules, any mode produces a report but not a decision. The threshold determines what is considered blocking: the criticality level and whether a fixed package version exists.

Exceptions are moved into rules with a review date — otherwise they turn into a permanent bypass of scanning.

Implementation procedure: from registry audit to handover of regulations

Image scanning has an effect only when built into the delivery pipeline: the registry is connected, thresholds are fixed, and the scan verdict stops deployment of a vulnerable build.

That is why we start with inventory — without it, rules either miss critical items or block everything indiscriminately.

1. Image registry audit. We compile a list of repositories and active tags, mark archived ones and duplicates. The output is a prioritized map of the fleet: what we check on every publication and what we check once.
2. Registry connection scheme. We deploy Anchore Engine next to the registry, issue a read-only account, and configure image pickup on tag publication events — a new build immediately enters the scanning queue.
3. Rules and thresholds. We divide findings by criticality and type: vulnerabilities in the executable layer, outdated packages, secrets inside layers. We select the blocking threshold so that it catches real risk but does not trigger on every dependency.
4. Exceptions. For findings that cannot be closed quickly, we record a targeted exception with a deadline and owner instead of a general rule bypass.
5. Trial on live builds. We run scanning on current branches without blocking, compare verdicts with manual analysis, and remove false positives.
6. Blocking mode. Scanning becomes a gate before deployment: an image with a critical finding does not go to the production environment, and rollback remains to the previous verified tag.
7. Handover of the scanning regulations. We hand over the threshold matrix, the procedure for analyzing findings, exception rules, and instructions for updating the vulnerability database.

Implementation artifacts: configurations, schemes, and regulations

Implementation ends not with a report but with a working pipeline on your side.

Anchore Engine is deployed in your infrastructure, so settings, rules, and instructions remain with your team — to change the blocking threshold or connect a new registry, you do not need to contact us.

• Configuration files — scanner parameters, vulnerability database sources, image traversal schedule, depth and retention period of results.
• Integration scheme — the chain "registry → build → scanning → admission to rollout" with failure points and a description of behavior when the scanner is unavailable.
• Blocking policies — which vulnerability classes stop release, what goes into exceptions, with what review deadline and who removes them.
• Response regulations — criticality levels, response times for the on-call shift, escalation procedure, incident record template.
• Operations instructions — updating vulnerability databases, rotating registry access, health checks, troubleshooting typical failures.
• Baseline report — which images already violate policy at handover and how much work remains to be closed.
• Role and access matrix — who changes policy, who only reads reports, and how these actions are logged.

Everything is handed over in a versioned form: policy changes go through the same review process as code, and the change history remains recoverable.

Case study: removed vulnerable images from production

The customer is a product environment of several dozen services, with weekly releases.

Image building was streamlined, but composition checking was not: the base layer manifest and dependencies were not analyzed, so a vulnerable package could reach the production environment and live there for months.

Usually it was not we who found this, but an external perimeter scanner or incident analysis, when it was already too late and expensive to fix.

We built scanning into the build: Anchore Engine parses the image layer by layer and shows which package and which layer the vulnerability came in through.

The policy stops the build on critical findings for which a fix exists; the rest goes into a report with priority and an assigned deadline. Vulnerability database updates run on a schedule, so the image verdict does not become outdated.

Metrics before and after

Before: not a single image passed scanning, nine out of ten critical findings were discovered already in the production environment, and the average time from vulnerability appearance to fix was about a week.

After: every image goes through scanning, eight out of ten critical findings are eliminated before publication to the registry, and response to a new vulnerability in a used package is hours, not days.

For the release cycle, this brought predictability: unplanned security-only releases decreased threefold, and there were zero rollbacks due to a vulnerable layer. The team stopped spending time analyzing what should have been filtered out at build time.

How Anchore Engine differs from scanners in registries

A built-in registry scanner checks an image at push time and does not let it pass further based on a list of known vulnerabilities. This does not require separate infrastructure; the trigger threshold is set by the provider.

Then limitations begin: you cannot set your own admission rules, there is no package composition report, and finding history disappears along with an overwritten tag.

Anchore Engine is a separate service: it parses the image into layers, compiles a list of operating system packages and versions, and evaluates it against rules written by your team.

Scanning happens not only at push time but also on a schedule — a new entry in the vulnerability database moves an already released image to the "has findings" status without a rebuild.

The difference is not in the amount found. A built-in check answers the question "should the image be allowed right now"; a separate scanner keeps an inventory: you can see which packages are inside, who approved an exception, and what changed after a database update.

Technical questions about image scanning

Teams almost always ask the same questions: will Anchore Engine work in an isolated environment, will scanning lengthen the build, how to live with noisy alerts, and what to do with already running containers. Below is how each of these is addressed in configuration.

Will scanning lengthen the build?

Only if you leave it on the critical path. The scan starts in parallel with the build of the next image or immediately after tag publication — on a separate node. The pipeline does not wait for the verdict: the report arrives asynchronously, and build duration does not change.

Will false positives block release?

Blocking triggers only at the selected criticality level. Everything else is handled by exception rules: a specific vulnerability identifier, package version, record expiration, and a mandatory log entry. Silent disabling of checks does not happen.

What to do with already deployed images?

You do not need to rebuild the entire fleet at once. First, inventory the running tags, then scheduled rescanning and sorting findings by runtime reachability. Only what is actually used goes into release.

Let's discuss the task of scanning your images

To come back with a work estimate rather than generalities, we need inputs about your environment.

Image scanning with Anchore Engine is configured for a specific infrastructure: the same policy on different build environments produces a different volume of findings and different build times.

That is why we first gather the picture, and only then propose an implementation plan and mode selection.

• Registry and access: which registry is used, how many repositories and tags are active, and what read permissions for images can be granted.
• Build environment: where and with what images are built, whether there are separate release branches, and how often new versions are released.
• Base layers: public base images or internal ones, and whether there are requirements for their origin.
• Security requirements: which vulnerability classes are critical, whether license and secret control inside layers is needed, and who approves exceptions.
• Failure threshold: what level of findings blocks release, and what only goes into the log for analysis.
• Integrations: where to store reports and how to notify teams — email, tasks, chat, dashboard.
• Responsibility scope: what we cover and what remains on your side during operations.

Describe the task in a convenient format — we will come back with a work estimate, implementation plan, and selection of a scanning mode for your environment.