DEV Community: Marcus Morris

Where does build integrity begin?

Marcus Morris — Thu, 20 Aug 2026 00:00:42 +0000

Software Product companies have to choose what materials to build their software with. Pypi, NuGet, Node, Crates, so many options abound.

With each decision it is wise to integrate build integrity in the very beginning.

What is build integrity?

Build integrity is the assurance that the software assembled and delivered to production is the software the team intended to build.
We do it everyday with physical products...
When we go shopping for groceries.
Shopping for clothing online or in-person.
Decide on build materials such as paint, wood or pipe for a DIY project.

Oftentimes due to familiarity and success with a product in the past we buy or use these materials without a second thought.

Until....

We are hit with a recall notice online or in the news about an item we purchased!!

For Software Security this is just as important. Malware and vulnerabilities can drastically damage a company overnight.

Insightful Statistics on this issue:

454,648 new malicious packages last year found.
56% of recorded malicious packages were classified as “repository abuse”

Source: Sonatype SSSC Report

The answers to the following questions should be verified before a product is downloaded:

Where did this product come from?
Has the source or repo established a reputation of quality products?
What reasons do we have to trust the manufacture of this product?
Can we cryptographically prove our reasons for trust?

OpenSSF Scorecard and manual repository research help answer these questions.

The hackers are really not the biggest threat, it is the quality of the product that we build with that is the greatest threat vector.

How does your team currently verify build integrity?

Go-go Gadget...OSV!

Marcus Morris — Tue, 07 Jul 2026 15:46:23 +0000

Are you looking for vulnerability intel that standard scanners skip?

OSV-Scanner is an awesome SCA tool for unearthing vulnerabilities in open-source dependencies, offering you a unique lens on your supply chain.

OSV-scanner has nice flexibility in how you consume the data:

Served locally via port 8000: Clean view of data in a web UI interface

osv-scanner scan image --serve <image>/latest

Standard terminal output: Great for a quick test or audit, can be piped into other tools/reports.

osv-scanner scan image <image>/latest

Either way, it's a welcomed addition to any supply chain security engineers tool-belt.

Just say Go-go Gadget OSV! 🕵️

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.