A Simple Way to Reduce the Grype Noise

Marcus Morris — Tue, 30 Jun 2026 18:56:02 +0000

Security Team: “I have a major Grype...with what I Syfted out of your provided image."

Developer: “Well your Grype is slowing me down...let’s tone it down a notch.”

While deploying bookstack into my local environment, this issue surfaced. It is true for many organizations today deploying images and packages in their environment.

How can this noise fatigue in the software supply chain be remedied?

Add a .gype.yaml file to the root directory of your project. This will allow grype to ignore certain CVE's that do not execute or pose a threat in your environment.

The yaml config can be as simple as below: Linux Environment

# grype.yaml
ignore:
 - vulnerability: CVE-2026-32631
  reason: "Platform-specific false positive. Git for Windows only; not applicable to this Linux-based image."

 - vulnerability: CVE-2016-2781
  reason: "Chroot escape via ioctl. Containers rely on namespaces/cgroups, not chroot, so this path isn't exploitable here."

# grype.yaml
ignore:
 - vulnerability: CVE-2026-32631
 - vulnerability: CVE-2016-2781

This will help developers and security engineers get along better. 😃

Grype config reference:
https://oss.anchore.com/docs/reference/grype/configuration/

Open source is like an amazing community swimming pool. 🏊‍♂️

Marcus Morris — Tue, 30 Jun 2026 16:20:35 +0000

It’s collaborative, it’s highly efficient, and everyone is having a great time building incredible things together.

Until someone whizzes in the water.

We’ve all seen or heard of the childhood "indicator dye" that turns bright blue the exact moment someone contaminates the pool. In the real world of software engineering, public registries (like npm or PyPI) don't have that dye built-in.

Malicious dependencies, typosquatting, and compromised upstream maintainers blend right into the clean water almost perfectly, undetected. If we treat a raw, unverified public registry like a trusted "community pool" environment, your production pipelines will be contaminated with background risk.

How do we actually build a sterile "pool experience" in enterprise software supply chains? We add in our own indicator dye and filtration systems:

The Indicator Dye (Visibility): Generating an granular Software Bill of Materials (SBOM) using tools like Syft, paired with continuous vulnerability scanning via Grype, acts as your indicator dye. It instantly exposes hidden, contaminated layers before they compromise your ecosystem. Vexctl (OpenVex) can help quiet the noise of CVE's that your company is not at risk to, reducing alert fatigue in the process.

The Guest Log (Provenance & Attestation): Stop pulling anonymous binaries. Provenance tells you the exact cryptographic history of where and how the software was built. Attestations prove that it met your rigorous build-time security requirements before it ever left the assembly line.

The Filtration System (Digital Signing & Policy): Cryptographic signing (via frameworks like Sigstore) ensures that if an artifact or container image isn't explicitly signed, verified, and matched against your governance policies, it never gets near your cluster.

Open source is a beautiful ecosystem, but public registries are distribution mechanisms, not always safe places to swim.

Do not swim blindly out there. Shift upstream to the binaries first, verify your provenance, and build a closed-loop system for your dependencies. Consider solutions like Chainguard and methods to secure images/artifacts at build.

DEV Community: Marcus Morris

A Simple Way to Reduce the Grype Noise

Open source is like an amazing community swimming pool. 🏊‍♂️