Guard sits between your builds and the public registries for npm, PyPI and Maven, behind your existing Artifactory or Nexus if you have one, and decides allow or block for each package as it is requested. It works from your own self-hosted hub and keeps no copy of the packages. The scanner tells you what is already in your estate; Guard screens what arrives next.
A package your policy blocks never reaches the build, because the decision is made before the download completes.
Every download is checked against the registry’s own checksum, and a mismatch is refused.
An optional waiting period keeps brand-new releases out of builds until they have been public for as long as you choose. Exceptions are granted per version, and every one is recorded.
Every decision is recorded in the hub, so you can see what was allowed and what was stopped.
Internal packages are routed around Guard for now, from your own registry.
Hub
Evidence an auditor can read, and proof that follows the release
The hub now produces control evidence for SOC 2, ISO 27001, PCI DSS, the EU Cyber Resilience Act and NIST: component inventory, vulnerability remediation, risk acceptance and end-of-life, each as a page and a CSV, with the control text beside it. Mapped by depproof; your assessor decides. Remediation is measured against your own targets, and what you accepted travels with the release, signed.
Remediation measured against the targets you set per severity, or CISA’s due date for known-exploited vulnerabilities: on time, late, or cannot tell.
Signed vulnerability statements per repository that travel with the release, verifiable by anyone you share your organisation’s public key with.
Chain of custody: which pipeline built which image, which image runs where, and for each environment whether the evidence covers it, naming the gap where it does not.
SBOMs on demand from the hub, CycloneDX or SPDX, for any scan or release.
Policy history shows what each revision changed, with an audit export.
Scanner
Signed SBOMs, and evidence of which packages actually load
SBOMs now carry the new fields in CISA’s 2026 minimum elements and can be signed with your own key, so anyone you hand one to can check it was not altered. The scanner can also tell you which packages actually loaded when your tests or your app ran, and what packages did while installing and building. Both rank findings; neither ever hides one.
SBOM tool name and version, generation context, author and component hashes, plus an optional signature with your own key. The signed original can be attached to your release.
Which packages actually loaded, now on Gradle, Python and multi-module builds, and from an app’s startup for repositories with no tests. A package that did not load is never treated as unaffected.
What packages do at install and build time: npm install scripts, Maven and Gradle plugins, Python source builds, and code that runs every time Python starts, each attributed to the package responsible.
A package that ships through any path is reported as shipping, even where another copy is development-only. Filtering out development-only findings therefore skips fewer of them; that is the correction.
More of the tree read correctly: nested Python requirements, Gradle versions set in variables, and npm packages installed under an alias.
The PR comment counts each finding once, however many manifests it appears in.
A slow licence service now costs one wait per run, not one per lookup.
The scanner now audits .NET projects alongside Java, JavaScript, Python and Go. It is also versioned 1.0 from here, so a breaking change to anything public means a 2.0, and every image is signed with its provenance attached, so you can verify what you run before you run it.
GitHub Action users moved to 1.0 automatically. Running the container directly? Move to the v1 tag; the older v0 line is frozen.
Your organisation’s gate can come from the hub, so every repository follows the same policy.
A brief error from the advisory source is retried, rather than reported as an unscanned project.
Scanner
Findings in the Security tab, and a PR comment that says what to change
Findings now appear in your repository’s Security tab and inline on the pull-request diff, so the people reviewing a change see them where they already work. The PR comment was rewritten around one question — what do I change — with a single upgrade version per package, licence results beside the vulnerability counts, and a pass that states what was checked.
Security tab and inline on the diff — one setting turns it on, and alerts are uploaded even when the gate fails the build, which is when they matter most.
A scan that could not look never shows as clean. An unreachable advisory source, an unreadable lock file or a partly resolved graph is uploaded as a visible alert, never as an empty Security tab.
One upgrade target per package — a version above the one you have that clears every advisory on it, never a downgrade onto an older release line.
The PR comment groups findings by package, reports licence results next to vulnerabilities, and says what was checked when nothing failed.
An unreadable lock file is reported as unscanned, never as a project with no dependencies.
Python projects on the standard lock file (PEP 751, pylock.toml) are now scanned.
Workflows that check out a different ref — a release tag, a pinned branch — can record the commit that was actually scanned.
Scanner
Stop failing on what you do not ship
A build can now ignore findings on development-only dependencies, so the gate fails on what reaches production rather than on a test harness. Nothing is hidden: those findings are still scanned, reported and kept in the SBOM — only the gate changes. You can also declare your own private packages, so they are reported as unscreened rather than counted as clean.
Test-only and build-only dependencies can stop failing the build. Suppressed findings are still listed by name, and a known-exploited one is called out separately.
A dependency whose scope could not be determined is never suppressed.
Development-only dependencies are identified more accurately across JavaScript, Python and Go projects.
Declare your own private-registry packages. They are reported as status unknown, never counted as clean, never fail the build, and the SBOM stops claiming they came from a public registry.
Packages built inside the same repository — Maven and Gradle modules, npm workspaces, local Go and Python paths — are recognised as your own automatically.
A scan names its own coverage gaps on the run page instead of passing quietly.
Scanner
Gate on what is actually being exploited
A severity threshold alone ships the vulnerability attackers are using: plenty of actively-exploited findings are rated only medium. The CI gate now takes exploitation evidence, CVSS score, and whether a fix exists — and a new fidelity rule fails the build when the dependency graph could not be fully resolved, the one case where a short findings list is the warning rather than the all-clear.
Fail on findings CISA lists as known-exploited, whatever their severity — or on modelled exploitation probability (EPSS). Exploitation data is served by your own self-hosted hub.
Gate on a CVSS base score, and separately on findings that could not be graded at all — an ungraded advisory is no longer silently treated as low.
Narrow any rule to findings with a known fix, so a build fails on what your team can act on today. Excluded findings are still counted and reported, never dropped.
Fidelity gate — fail when a dependency graph was never fully resolved. The only rule that can fail a build with an empty findings list, which is the point.
A Markdown run summary for any CI, a GitHub job summary, and a PR comment updated in place rather than one per run.
Scanner
Go module support
The scanner now audits Go projects alongside Java, JavaScript, and Python — the resolved module graph checked against OSV advisories for Go, licenses classified to SPDX, and Go components included in the CycloneDX SBOM and the CI gate. Same self-hosted container; your source never leaves your runner.
Go modules resolved from the project’s own module graph, with a go.mod fallback
Known-vulnerability detection for Go packages on open data (OSV.dev)
Go dependency licenses classified and normalized to SPDX
Go components in the CycloneDX SBOM and the pass/fail CI gate
Hub
The depproof hub — org-wide governance, waivers & audit trail
The self-hosted hub aggregates every repo’s scan reports into one cross-repo view — blast-radius search and org-wide license posture — and adds cybersec-owned waivers with an append-only audit trail (posture snapshots, expiry, OpenVEX/CSV export). A centrally-accepted finding stops failing every repo’s CI. Runs in your own network; reports never leave your infrastructure.
Org-wide dashboard — every repo’s findings, policy, and blast radius in one view
Cross-repo blast-radius search — find a CVE anywhere in your estate
The depproof scanner — self-hosted dependency & license audit
Audit your dependencies for known vulnerabilities and license risk across Java (Maven, Gradle), JavaScript/Node (npm, pnpm, yarn, bun), and Python (PyPI) — the full transitive tree, a CycloneDX SBOM, and a pass/fail CI gate. Runs self-hosted in GitHub Actions, GitLab CI, or any container; your source never leaves your runner.
Ecosystems: Maven (no build), Gradle (post-build), npm/pnpm/yarn/bun (from the lockfile), Python (from the lockfile)
Known-vulnerability + malicious-package detection on open data (OSV.dev)
Every dependency’s license classified and normalized to SPDX
CycloneDX SBOM + a self-contained HTML report
Pass/fail CI gate — fail-on: critical | high | medium | low | none
Zero-config in GitHub Actions and GitLab CI — self-hosted, no source uploaded