A container image that pulls in node:18-slim or python:3.11-slim inherits every CVE already sitting in that base layer before a single line of application code is added. Scan it with Snyk Container and it is common to see findings for packages like zlib1g, libssl3, or libc-bin that the application team did not choose, cannot patch directly, and often cannot even upgrade without waiting on a platform team to publish a new base image. When those base-layer findings sit alongside genuine, fixable issues in package.json or requirements.txt dependencies, engineers start triaging by fatigue instead of by risk. Snyk Container ships two documented mechanisms for cutting through that noise: the .snyk policy file's scoped ignore rules (including the --exclude-base-image-vulns test flag) and org-level policies that apply ignore or license rules consistently across every project. This post walks through how each mechanism actually works.
What Makes Base-Image Findings So Noisy in the First Place?
Base-image findings are noisy because they are duplicated across every image built from that base and are usually outside the scanning team's remediation control. If ten microservices all build FROM node:18-slim, a single unpatched CVE in that base surfaces as ten separate findings in ten separate Snyk projects, even though fixing it requires one action: rebuilding from a patched tag upstream. Snyk Container's scan output distinguishes vulnerabilities that originate in the OS layer (installed via apt, apk, or similar) from those introduced by application-level package managers such as npm, pip, or Maven. That split matters operationally — an application engineer can act on an npm advisory today, but the same engineer typically has no path to patch a CVE in openssl inside a base image; that responsibility sits with whoever maintains the base image, often a platform or infrastructure team. Without a way to separate the two, both categories compete for the same review queue.
How Does the .snyk Policy File Scope Ignores Instead of Muting Everything?
The .snyk policy file scopes ignores to a specific vulnerability ID, and optionally a specific dependency path and expiration date, rather than silencing a whole severity tier. A typical entry looks like this:
version: v1.25.0
ignore:
SNYK-DEBIAN11-OPENSSL-2758326:
- '*':
reason: Patched in upstream base image release scheduled for next sprint
expires: 2026-08-15T00:00:00.000Z
Because the ignore is keyed to the Snyk vulnerability ID and can be constrained to a dependency path, it suppresses that one finding — not every finding of the same severity, and not the whole image. The expires field is the part teams skip most often, and it is the part that keeps an exclude policy from quietly becoming permanent: once the date passes, Snyk surfaces the finding again on the next scan and reporting run, forcing a re-decision instead of letting a "temporary" suppression live in the repo for years. This file is checked into the repo and read automatically by snyk container test and snyk container monitor, so the same ignore logic applies whether the scan runs on a laptop, in CI, or on the scheduled monitor job.
What Does the --exclude-base-image-vulns Flag Actually Filter?
The --exclude-base-image-vulns flag filters the CLI's test output down to vulnerabilities introduced by the application layer, dropping findings attributable to the base image entirely from that run. Run snyk container test myapp:latest --exclude-base-image-vulns and the result set only contains issues tied to packages the application team added on top of FROM. This is different from a .snyk ignore rule in one important way: it is not tied to a specific CVE ID and does not require anyone to enumerate which findings to suppress. It is a blunter, session-scoped filter meant for a specific workflow — an application team that wants its CI gate to fail only on vulnerabilities it can actually fix, while a separate pipeline (often owned by whoever publishes the base image) runs an unfiltered snyk container test against the same image to track base-layer debt on its own cadence. Used well, it splits one noisy signal into two accountable ones. Used carelessly — as the only gate, with no companion scan tracking base-layer risk — it can let a genuinely exploitable base-image CVE go unmonitored indefinitely.
How Do Org-Wide Policies Apply Ignore Rules Across Every Project?
Org-wide policies apply because Snyk lets an admin define ignore and license rules once, in the web console under the organization's policy settings, and have them evaluated against every project in that org rather than requiring each repository to carry its own .snyk file edits. This matters at the scale base-image noise actually appears at: if the same base image is used across dozens of services, a security team can define a rule matching a given vulnerability or license condition and have it consistently suppressed — or consistently flagged — everywhere that condition occurs, instead of relying on each service team to copy the same YAML block into their own repo. It also creates an audit trail: because the rule lives at the org level rather than scattered across repos, a reviewer can see every active suppression and its justification in one place instead of grepping through dozens of .snyk files to find out why a known CVE isn't showing up in a report.
Where Do Allow Policies Fit Alongside Exclude Rules?
Allow policies fit in as the inverse control: instead of suppressing specific known findings, they define what is permitted by default — for example, an allowed license list or a severity threshold below which findings don't block a build. Snyk's license policy settings let an org mark specific licenses (say, MIT and Apache-2.0) as acceptable and others (say, AGPL-3.0) as requiring review, which is a different axis of noise reduction than CVE-level ignores — it addresses compliance findings rather than vulnerability findings. On the vulnerability side, the practical "allow" lever most teams reach for is a severity-threshold gate (--severity-threshold=high, for instance) combined with the exclude mechanisms above: base-image CVEs below the threshold don't block a merge, base-image CVEs above it still do unless explicitly and time-bound ignored. The combination — narrow, expiring excludes for specific known issues, plus a severity floor for everything else — is what keeps a policy from drifting into either extreme of blocking on everything or blocking on nothing.
How Safeguard Helps
Snyk's exclude and allow policies solve the triage problem inside a single scanner's output — they don't answer where a base image came from, whether it was rebuilt after the CVE it's being excluded for was patched, or whether an ignore rule someone wrote eight months ago still reflects reality. Safeguard sits at that layer of the problem. It tracks base image provenance and SBOM data across the services that consume a given base, so when a platform team ships a patched node:18-slim rebuild, Safeguard can show every downstream image still building from the stale digest — turning "we filtered this finding" into "here is the actual list of images that need to rebuild." It also treats policy exceptions as artifacts with an owner and a clock: expiring ignores, whether they live in a .snyk file or a scanner's org-level policy console, get surfaced again for re-approval instead of aging silently out of anyone's attention. For teams running Snyk Container alongside other scanners or build pipelines, Safeguard aggregates the resulting findings and exception history into one supply-chain risk view, so a security team reviewing base-image debt isn't reconciling exclude lists across five separate tools by hand.