NuGet packages, rebuilt from source.
Rorix Registry is a NuGet distribution where every package is compiled from source in our hermetic pipeline, signed with Sigstore, and patched against new CVEs on a contractual SLA. You don't inherit upstream's build — you inherit ours.
Upstream binaries carry assumptions you can't verify.
When you pull a .nupkg from nuget.org, you trust whoever built it: their toolchain, their machine, their dependencies, their build flags, their install scripts. None of that is independently verifiable from the bytes that arrive on your build agent.
Scanning the resulting binary catches some risks, but it can't reproduce the build or attest to provenance. The only way to do that is to rebuild.
- ✓Reproducible binaries from pinned source
- ✓Sigstore signature + SLSA attestation
- ✓Hardened defaults — no install scripts, no telemetry
- ✓Stripped debug symbols and unused runtimes
- ✓Patched CVEs without waiting on the upstream maintainer
- ✓SBOM emitted at build time, not inferred
A NuGet distribution we own end-to-end.
Rorix Registry isn't a proxy or a mirror. We rebuild every package in the catalog from source, on our infrastructure, with the toolchain and inputs pinned. The output is a different .nupkg with different hashes, our signature, and our build attestation.
The catalog is shared. When one customer requests a package, we build it once and every customer on a paid plan can pull it. That's how we keep prices in line — the rebuild work is amortized across everyone using it.
What ships with every package
Six things that come standard, because they're the reason to use a rebuild registry in the first place.
Rebuilt from source in our pipeline
We don't republish upstream binaries. Every package in the Rorix Registry is compiled from source on our hermetic builders, with the inputs and toolchain pinned for reproducibility.
Signed with verifiable provenance
Every artifact ships with a Sigstore signature and SLSA build attestation. You can verify offline, with cosign, or in your CI before restore — the chain is yours, not ours.
Hardened defaults
Stripped debug symbols, no install scripts, minimum required runtimes, no telemetry hooks. The .nupkg you pull contains what you need to ship and nothing more.
Contractual CVE patch SLA
When a CVE drops on a package in your catalog, we rebuild and re-publish a patched version within your tier's SLA — 7 business days on Team, 72 hours on Scale, 24 hours or custom on Enterprise.
Catalog grows on demand
Need a package we don't carry yet? Request it from the dashboard. Once it's in the catalog, every customer benefits — the rebuild work amortizes across everyone using it.
SBOM and license metadata at pull time
CycloneDX 1.6 and SPDX 2.3 manifests are attached to every package version, with full license text, file hashes, and PURLs. No separate generation step in your build.
Request → rebuild → pull → patch
The catalog grows when you ask for a package. Once it's in, every customer benefits and we own the patch SLA.
Request a package
From the dashboard or rorix CLI. Public packages join the shared catalog; everyone on a paid plan can pull them.
We build from source
On hermetic builders. Toolchain pinned, inputs hashed, output reproducible. Signed with Sigstore on the way out.
Pull from rorix.io/registry
One NuGet.config change. Authenticated by default. Cached regionally so build time impact is under 2%.
We patch when CVEs drop
Contractual SLA per tier. New version is published, your CI picks it up on the next restore, audit trail logs the change.
Scanning is not enough.
A scanner reads bytes that already exist. A rebuild produces the bytes you trust. The two answer different questions: did this binary do anything bad we know about, vs. is this binary what its source code says it should be.
For most teams the scanner is enough — that's the supply chain product. For teams in regulated industries, or anyone who has been bitten by a malicious upstream maintainer, only the rebuild closes the gap.
Rorix Registry is the second layer. Use it for the dependencies you can't afford to misplace trust in.
What you actually configure
Catalog request workflow
Anyone on a paid plan can request a new package. We confirm the build is feasible, queue it, and notify you when the first signed version lands.
Provenance verification
Every pull comes with a verifiable Sigstore signature and SLSA attestation. Block on signature failure in your CI policy.
Org-wide version pinning
Pin the exact rebuilt version your team is allowed to use. Downgrades and unauthorized version drift are blocked at the registry, not at PR time.
Quarantine on new versions
When a new upstream version is rebuilt, it sits in quarantine for a configurable window. Time to review the diff before it's allowed into prod restores.
SBOM attached at pull
CycloneDX or SPDX manifest delivered with every package. Your build inherits provenance without an extra step.
Private rebuilds (Enterprise)
Internal packages built in your isolated pipeline, with your secrets and your attestation chain. Not amortized across other customers.
Answers
How is this different from a NuGet proxy or mirror?
A proxy republishes the bytes upstream produced. We rebuild from source — different .nupkg bytes, different hashes, our signature, our build provenance. The point is the rebuild, not the routing.
How long does a new package request take?
First-time onboarding for a public package is typically 24–72 hours, depending on the build complexity. Subsequent CVE patches on that package follow your tier's contractual SLA.
What's the CVE patch SLA?
Team — 7 business days. Scale — 72 hours. Enterprise — 24 hours or a custom SLA negotiated against your compliance scope.
What about packages we keep internally?
Private rebuilds run in an isolated pipeline with your source and your secrets, and ship with your own attestation chain rather than the public Rorix one. Enterprise tier only — that work isn't amortized across customers.
Can I keep using nuget.org for packages not in the catalog?
Yes. Configure rorix as one feed and nuget.org as a fallback. We don't gate access to packages we haven't rebuilt — you just don't get the Rorix guarantees on them.