Your Artifact Registry Is Your Biggest Security Blind Spot
Most teams invest heavily in code review and CI security — then ship untrusted artifacts to production without a second thought. Here's what automatic CVE scanning, SBOMs, and Sigstore signing look like in practice.
The gap nobody talks about
Your code goes through pull request review, static analysis, and a suite of automated tests before it merges. Your CI pipeline has dependency scanning configured. Your SAST tools flag suspicious patterns. You're covered.
Then the artifact lands in your registry, sits there for six months, and gets pulled straight into production — with zero additional scrutiny.
That six-month-old Docker image you just deployed? It contains OpenSSL 1.1.1t. There have been four CVEs against that version since you built it, including one rated CRITICAL. Your registry didn't tell you. It doesn't know.
This is the artifact security gap. It's the reason supply chain attacks work.
What Trunx does on every push
Every artifact pushed to Trunx goes through three automatic steps before it becomes pullable. No configuration required. No separate pipeline to set up.
Step 1: CVE scanning with Grype and Trivy
The moment an artifact lands, Trunx runs it through both Grype and Trivy — two complementary scanners with different database coverage — and aggregates the results:
[trunx] Scanning @platform/auth-service@3.1.0 ...
CRITICAL CVE-2024-45337 golang.org/x/crypto < 0.31.0 → upgrade to 0.31.1
HIGH CVE-2025-22866 golang.org/x/net < 0.33.0 → upgrade to 0.33.0
MEDIUM CVE-2025-27144 github.com/go-jose/go-jose < 4.0.5
Summary: 1 CRITICAL · 1 HIGH · 1 MEDIUM · 0 LOW
Policy: CRITICAL threshold exceeded → artifact quarantined
Run `trunx scan report @platform/auth-service@3.1.0` for full details
You set the threshold. CRITICAL blocks? HIGH warns? Your call, per repository. The policy is enforced at push time — not after, not at deploy time, at push.
Step 2: SBOM auto-generation
Every artifact gets an SBOM attached automatically, in your choice of SPDX or CycloneDX format. Not a separate report. Not something stored somewhere else. Attached to the artifact version, retrievable at any time:
trunx sbom @platform/auth-service@3.1.0 --format spdx
# Returns a complete SPDX 2.3 document with 147 packages,
# all transitive dependencies, all licenses
This matters for compliance. SOC2 Type II auditors ask about third-party dependency tracking. ISO27001 requires it. DORA in the EU makes it mandatory for critical sectors. With Trunx, the answer to "show me the bill of materials for your production artifact as of Q3 2025" is a single CLI command.
License compliance is automatic. You configure blocked licenses (GPL-2.0, AGPL-3.0 — whatever your legal team requires), and any push containing a package with a blocked license is rejected before it lands.
trunx policy set --repo platform --block-licenses GPL-2.0,AGPL-3.0
# Next push containing a GPL-licensed dependency:
[trunx] License violation: lodash-cli@4.1.0 is GPL-2.0
[trunx] Artifact rejected by license policy
Step 3: Sigstore attestation
Every artifact is signed using Sigstore's keyless signing model. No key management. No certificate rotation. No HSM to provision.
The signature binds the artifact digest to the identity that pushed it (service account, CI OIDC token, or user credential) and records an immutable entry in Sigstore's transparency log. You can verify any artifact's provenance at any point in the future:
trunx verify @platform/auth-service@3.1.0
✓ SHA256 digest verified: sha256:a3f9b12c...
✓ Signed by: ci-service@company.iam.gserviceaccount.com
✓ Timestamp: 2026-03-28T09:14:22Z (Rekor entry #94821047)
✓ Built from: github.com/company/platform @ commit 8d3f21a
✓ No CVEs above HIGH threshold
✓ SBOM attached: 147 packages
Continuous re-scanning
This is where Trunx goes beyond what most registries even consider: artifacts are rescanned automatically as new CVE data is published.
Your auth-service@3.1.0 was clean when you pushed it in January. In March, a new CVE is disclosed against one of its dependencies. Trunx detects it overnight and changes the artifact's security status. Your team gets notified. The artifact isn't silently poisoned — you know.
trunx scan list --repo platform --status degraded
@platform/auth-service@3.1.0 Clean → 1 HIGH (CVE-2026-1234, disclosed 2026-03-27)
@platform/gateway@2.0.8 Clean → 1 MEDIUM (CVE-2026-5678, disclosed 2026-03-25)
The blast radius question
When Log4Shell dropped in December 2021, most engineering teams spent days answering one question: which of our services actually uses log4j?
With Trunx, that answer is instant. Every artifact's SBOM is indexed. The dependency graph is queryable:
trunx graph impact log4j-core:2.14.0
Direct consumers (3):
@platform/reporting@1.2.0 → pushed by team-data, deployed prod
@platform/audit@0.8.3 → pushed by team-security, deployed prod
@platform/legacy@5.1.1 → pushed by team-platform, not deployed
Total blast radius: 2 production services
Two minutes to full blast-radius analysis. Not two days.
What this costs you
Nothing extra. CVE scanning, SBOM generation, and Sigstore signing are on by default for every repository, every format, every plan. There is no "security tier". There is no add-on to purchase.
The question isn't whether you can afford Trunx. The question is whether you can afford not to know what's in your production artifacts.