Supply Chain & Software Bill of Materials
Your security team needs to know exactly what’s in your software supply chain. Here’s everything about ours — the components we ship, how we vet them, and the open tooling that lets you verify it yourself. Nothing here is “trust us”: every claim below points to open-source tooling or public documentation you can inspect and run for yourself.
SBOM — Generated with Syft
A Software Bill of Materials is the ingredient list for a software product. UniDoc produces one for UniPDF and UniOffice on every release using Syft, the widely adopted open-source SBOM generator.
Each SBOM enumerates every direct and transitive dependency — component name, version, license, and dependency relationships — in the two formats enterprise tooling expects.
| Formats | SPDX and CycloneDX (JSON) — the two industry-standard SBOM formats |
| Cadence | Regenerated automatically on every release |
| Contents | Component names, versions, licenses, and the full dependency graph |
| Toolchain compatible | Dependency-Track, FOSSA, Black Duck, and any SPDX/CycloneDX consumer |
| Access | Public download — no login, no NDA, no sales contact |
Supply Chain Risk — Assessed with UniSupply
Knowing what is in the supply chain is only half the job. Before every release we run UniSupply — our own open-source Go supply chain risk scanner — across the full dependency graph of UniPDF and UniOffice. Because it’s open source, you can read exactly how we assess risk and run the same checks against your own projects.
UniSupply evaluates each dependency across nine dimensions:
| Dimension | What it checks |
|---|---|
| Known vulnerabilities | CVE/OSV lookups via the Go vulnerability database (vuln.go.dev) |
| Reachability | Whether a vulnerable symbol is actually called, merely imported, or only required |
| Maintenance health | Release recency and activity via the Go module proxy |
| Maintainer analysis | Contributor count, bus factor, and project activity |
| Typosquatting | Name-similarity checks against known-good modules |
| Resilience | Release cadence, governance files, and versioning discipline |
| AI-generated code risk | Heuristics for machine-generated dependency code |
| CI/CD audit | Inspection of GitHub Actions and build configuration |
| Build inspection | Review of Dockerfiles, Makefiles, and shell scripts |
Findings roll up into a weighted risk score per dependency — vulnerabilities weighted most heavily, then maintenance, dependency depth, maintainer risk, and maturity — with additional penalties for typosquatting and low-resilience packages. Risk signals surface before a release ships, not after a customer flags them.
UniSupply produces reports as text, JSON, PDF, and as CycloneDX (1.5) and SPDX (2.3) SBOMs —
and collects no telemetry, transmitting only the module paths already visible in a
published go.mod.
Part of a Wider Security Program
SBOMs and dependency scanning are supply-chain controls — but they don’t stand alone. They’re one part of how we manage security across the whole company, governed by our Information Security Management System (ISMS): the documented policies, controls, and review processes behind our day-to-day operations.
Most vendors keep that behind an NDA. We run ours in the open — on isms.sh, the same open-source platform we build and publish at github.com/unidoc/isms:
- Documented in Git — every policy is version-controlled Markdown with full history, so you can see what changed, when, and why.
- Immutable audit trail — reviews and approvals are stamped with a SHA-256 content hash and can’t be quietly rewritten.
- Framework-aligned — mapped to the controls behind ISO 27001, SOC 2, and NIS2, among other standards.
- Open and inspectable — Apache-2.0 licensed, with a live demo at demo.isms.sh.
Coverage: UniPDF and UniOffice only. UniHTML (Chrome runtime) and UniAI (cloud-assisted) have separate supply chain documentation available on request.
Supply chain or vendor assessment questions?
[email protected]