Go Supply Chain Security: Introducing unisupply

You can read every line of code your team writes. You cannot read every line your team ships.

A typical Go service declares a handful of direct dependencies and then inherits dozens more transitively, pulled in by those dependencies, and by their dependencies. Your go.sum is the honest record of what actually compiles into your binary. For most teams it lists modules nobody on the team has ever opened, maintained by people they will never meet.

That gap is not a knowledge problem. It is your real attack surface. And it is exactly where the last few years of supply chain incidents have lived: a transitive dependency, quietly maintained by one person, compromised long before anyone noticed.

Today we are releasing unisupply, a Go dependency supply chain risk scanner, open source under Apache 2.0. It is a single Go binary that maps your full dependency graph and scores the supply chain risk of every module in it, direct and transitive, in one pass.

What unisupply Does

Point unisupply at a Go project and it resolves the complete dependency tree, then runs nine focused scanners across every module:

Vulnerabilities. Known CVEs via the Go vulnerability database, call-graph-aware: govulncheck performs whole-program static analysis, so a CVE sitting in a dependency’s dead code that your application never actually calls does not inflate your score.

Maintenance health. Last release, archive status, and deprecation, from the Go module proxy.

Maintainer analysis. Contributor count, bus factor, recent activity, and organization verification, via the GitHub API.

Typosquatting. Levenshtein-similarity against a built-in list of just over 50 well-known modules, so a near-miss import name does not slip through.

Resilience. Release cadence, governance files, and versioning scheme.

AI-generated code risk. Heuristics that flag freshly published modules with thin release history and generic naming.

CI/CD audit. Unpinned actions, over-broad workflow permissions, and secret exposure in your GitHub Actions.

Build files. Unpinned Docker images and risky curl | bash install patterns in Dockerfiles, Makefiles, and shell scripts.

Trust Index. Optional curated trust data, covered below.

How Risk Scoring Works

Each module receives a single risk score from 0 to 100, banded into LOW, MEDIUM, HIGH, and CRITICAL. The score is a weighted composite: vulnerabilities weigh the most, followed by maintenance, dependency depth, maintainer risk, and maturity, with additional penalties for typosquatting, AI-generated-code signals, and low resilience.

Any module carrying a known CVE is floored into at least the MEDIUM band, and CRITICAL and HIGH severity CVEs force a floor at their corresponding band, so a critical vulnerability with a fix available can never be buried where it looks safe.

There is one report section we think matters more than any single score: maintenance takeover candidates. unisupply surfaces three kinds of at-risk dependency: popular packages with high star counts whose maintainers have gone dormant, single-maintainer projects with no recent activity, and archived repositories that projects still depend on. That is the precise shape of the most damaging recent supply chain attacks. Seeing those packages named, before they become a headline, is the point.

Built the Way UniDoc Builds Everything

unisupply ships as a single Go binary. No CGo, no subprocess, no sidecar, no foreign runtime to stand up next to it. It cross-compiles to Linux, macOS, and Windows on both amd64 and arm64, and it sends no telemetry.

The scanners that need external data — the maintainer and resilience checks against the GitHub API and the optional Trust Index — are skipped or degrade gracefully when network access is unavailable, so the core scan still runs in an air-gapped environment.

If you have read why we build UniPDF and UniOffice as pure-Go modules with a dependency tree you can audit in go.sum, this will feel familiar. We hold our own work to the standard unisupply measures against. The tool even scans itself as part of development.

It is also, quietly, a piece of dogfooding we are proud of: the enterprise PDF reports unisupply generates are built with UniPDF and UniChart, the same libraries our customers ship in production.

Five Ways to Read the Output

A scan can be rendered in whatever form your workflow needs:

  • Colored terminal text for interactive use
  • JSON for dashboards and programmatic consumers
  • PDF for an enterprise report you can hand to a reviewer (PDF generation uses your UniDoc license key)
  • CycloneDX 1.5 SBOM — one of the two standard software bill-of-materials formats your compliance process already understands
  • SPDX 2.3 SBOM — the other standard format

The SBOM output matters for a specific reason. Across our site we tell security teams: name your vendors in your SBOM, audit your dependency tree, make your supply chain legible. unisupply produces exactly the artifact that conversation requires.

A Policy Engine Built for CI

A risk report nobody reads changes nothing. unisupply is built to live in your pipeline and fail the build when it should.

It ships with two presets, strict and moderate, and accepts a custom JSON policy file when you need your own rules. You can fail on:

  • Critical or high-severity vulnerabilities
  • Single-maintainer direct dependencies
  • Modules left unmaintained past a threshold you set
  • Archived or deprecated packages
  • Typosquats
  • Specific modules you want blocked across the entire graph

A policy violation exits with code 2, the convention CI systems already expect for a deliberate fail-fast.

Drop it into a GitHub Actions workflow, point it at a policy file at your repo root, and every push and pull request gets gated automatically. “It passed the tests” stops being your supply chain security posture.

The Trust Index: Who, Not Just What

Your go.mod tells you what you depend on. It cannot tell you who you are trusting.

Who actually maintains that transitive module three levels deep? What organization do they work for? What country do they operate from? Has anyone verified that identity? Public feeds and heuristics — the kind unisupply’s other scanners rely on — cannot answer those questions. They are exactly the questions a procurement review, a vendor risk assessment, or hour two of an incident keeps running into.

For teams that need to go further, unisupply can optionally enrich a scan with UniDoc’s Trust Index, our curated database of Go module trustworthiness. When you point it at a Trust Index endpoint, every discovered module is sent in a single batched request and the report gains human-vetted fields: real maintainer name, the maintainer’s organization, country of operation, identity verification status, and stewardship state. When the data is available, it also surfaces a recommended safer alternative for modules flagged as risky.

The privacy posture is deliberate and matches how we run the rest of UniDoc. The lookup transmits only module paths — the same information already published in your go.mod. No versions, no source code, no scan results, nothing project-identifying. The feature is entirely opt-in: leave it off and the scan is fully self-contained, with no implicit endpoint and no data leaving your machine.

If your security or procurement team wants to evaluate the Trust Index for vendor review, talk to us.

Get Started

unisupply requires Go 1.25 or newer. Install the latest release with:

go install github.com/unidoc/unisupply/cmd/unisupply@latest

Then scan your project:

unisupply ./

For CI ingestion, produce JSON. For a vendor review, produce a PDF or an SBOM. To gate a build, add a policy preset. The full flag set is available with unisupply --help, the documentation covers every option, and the source and prebuilt binaries live at github.com/unidoc/unisupply.

It is free, open source, and yours to run on your own code today. Run it, and tell us what the score comes back as.

unisupply is the open-source supply chain scanner from UniDoc, the company behind the pure-Go UniPDF and UniOffice libraries trusted in production for over a decade. We track our own vulnerabilities publicly at security.unidoc.io, and unisupply’s own security policy holds it to the same standard.