DEV Community: Marcus Morris

Software Artifact Trust Starts At Package Registries

Marcus Morris — Wed, 16 Sep 2026 23:58:59 +0000

Which software artifact should we trust?

Software package registries are open to the public, they essentially allow anyone really to share there libraries and code. I was curious about how to these packages could be vetted, inspected and triaged before ingesting/consuming.

Many times we just type...

 -> pip install <our fav package>
OR
 -> uv install <our other fav package>

This works most times and allows us to use our favorite packages from PyPI. There is a danger to be weary of, that of typosquatting, developer account take over and ultimately the publisher of the package not following OSS or PyPI best practices.
Even the most used python packages could be a risk, so to address this pre-ingestion issue, I created a tool that allows for me to triage and inspect package metadata and provenance evidence before downloading the package.

What I Learned:

PyPI is a great source for evidence of attestation.
Author or Maintainer Information can usually readily be found.
License of the package is also listed, helpful before building with varied license restrictions/liberties.
SHA is explicitly listed and verifiable with packages you plan to build with. Allowing the practice of SHA pinning to persist.
Open Source Security starts way left, at the package registry layer. All compromised cannot be caught here, but this practice can enhance OSS significantly. Inspecting packages at source.

I look forward to iterating on this tool more and more in the very near future to enhance supply chain security and my own efforts to contribute to open source security initiatives.

What tools do you like to use to inspect and vet open sources packages at the registry level?

Link to Baro Tool
https://github.com/ceaz-sec/baro

Example Triage Reports:
https://github.com/ceaz-sec/baro/tree/main/src/reports

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.