Vantage Post-Quantum Security

A Vantage deployment is assembled from hundreds of moving parts: Slurm and Kubernetes operators, GPU and network drivers, storage, databases, observability, Vantage's own services, and the agents and VM images that nodes download at boot. All of it ends up running on customer infrastructure.

That makes the software supply chain one of the most important security boundaries we own. So we built it around one rule, and we built it to stay trustworthy after quantum computers arrive.

Every artifact Vantage ships is pinned, inspected, approved by policy, and signed with ML-DSA-87, the strongest parameter set of NIST's post-quantum signature standard. Nothing reaches a customer cluster unless that signature checks out.

Why post-quantum, and why now

Almost all software signing today uses RSA or elliptic-curve keys. A large enough quantum computer running Shor's algorithm breaks both. For signatures, that means forgery: an attacker could produce a release that verifies as if it came from the vendor, and a forged signature on a trusted release is as good as the real thing.

The timeline is no longer theoretical. NIST published FIPS 204 (ML-DSA) in August 2024, plans to deprecate classical signature algorithms from 2030, and to disallow them by 2035. The NSA's CNSA 2.0 suite names ML-DSA-87 specifically for software and firmware signing.

Signing keys and the public keys customers pin to verify them stay in service for years. A platform whose trust anchors have to outlive the classical algorithms needs to move before the deadline, not after it. So we moved.

Algorithm	ML-DSA-87 (module-lattice digital signatures)
Standard	NIST FIPS 204
Strength	NIST security category 5, the highest defined, comparable to AES-256
Policy alignment	The parameter set CNSA 2.0 specifies for software signing
Fallback	None. Every other algorithm is rejected

Against a classical attacker, a long enough RSA key can match ML-DSA-87 on paper. Against a quantum attacker, every RSA key size falls to Shor's algorithm, while ML-DSA-87 keeps its full category 5 strength.

We chose the top parameter set deliberately. A category 5 signature costs a few more kilobytes than the mid-tier option, and we sign a handful of statements per release, so the overhead is negligible. In exchange, our trust anchors carry the most margin against future advances in cryptanalysis, and meet the bar federal and defense buyers evaluate suppliers against.

We also made it the only option. When we moved every key to ML-DSA-87, we did a hard cutover: the old keys were retired, every trust bundle was replaced, and nothing signed before the switch verifies afterwards. A verifier that accepts two algorithms is only as strong as the weaker one, so ours accepts exactly one.

One path in, and it checks the signature first

The core of the architecture is simple to state: an artifact becomes reachable only through one path, and that path verifies a post-quantum signature before it publishes anything. Every image, chart, binary and VM image moves through the same five stages.

1. Pin. Third-party software is copied from upstream by content digest, not by tag. If an upstream maintainer, or someone who compromised them, moves a tag like postgres:16 to a different image, it changes nothing Vantage ships. Our own builds record the exact repository, commit and release tag they came from.
2. Build in isolation. Build jobs have no access to signing credentials. Code in a build, including a malicious dependency, can never sign its own output.
3. Inspect. Every image gets a software bill of materials (SBOM) and a vulnerability scan, and a fixed policy decides whether it passes. Critical findings block the release.
4. Sign. The signer does not trust anyone's word that the checks passed. It re-derives the decision from the evidence itself, then signs a statement that binds the artifact's digest to the digests of its SBOM, its scan, and the policy that judged it. An approval can never be detached from what it was based on.
5. Publish and verify. The signed approval, SBOM and scan are attached to the image in the registry. Before anything is published, the publishing step checks the signature again.

The gate is not advisory. When we cut a recent platform release, the pipeline refused to sign a dozen of our own images because their scans found critical vulnerabilities. Nothing unsigned was published, and each image shipped only after it was rebuilt and passed. The same rules apply to Vantage's code as to everyone else's.

Keys that cannot leave the vault

Private signing keys exist in exactly one place: a HashiCorp Vault secrets engine we built for post-quantum signing. It generates ML-DSA keys, stores them behind Vault's encrypted storage barrier, and signs on request. No API returns private key material, so no person and no workflow can export a key, and automated tests guard that property on every endpoint.

Getting a signature is tightly scoped:

• No stored secrets. CI authenticates to Vault with a short-lived OIDC identity issued per job. There is no long-lived signing token anywhere to leak.
• Fifteen-minute credentials. Each token expires quickly and can sign only with the keys its role allows. It cannot create, rotate or read out keys.
• Reviewed code only. Only reviewed workflow code on protected branches and tags can reach a signing role. Pull requests and project build jobs cannot.
• Separate keys for separate jobs. Third-party approvals, Vantage-built artifacts, and full platform releases each have their own key and policy, so a credential for one cannot sign for another.

Storage is assumed hostile

Most supply chains treat the registry or CDN as the root of trust: if it is on the server, it must be real. Ours does not. Registries, mirrors, caches and the download CDN are treated as untrusted storage. They hold bytes; they do not decide what is trusted.

That changes what an attacker can do with a stolen storage credential. Writing to the registry or the bucket is not enough to ship anything:

• Images and charts are referenced by digest and verified against their signed approvals, so a replaced tag or a fake approval fails the check.
• Binaries and VM images land in a staging area that is never served. A verification gate checks the signed release statement and re-hashes every byte against it before copying anything to a downloadable location. Swap a file after signing and the hash fails. Swap it mid-copy and the copy is refused.
• Rollback is blocked. Published versions are immutable and release channels like latest only move forward, so replaying an old, validly signed release cannot drag customers back to a version with known vulnerabilities.

Signatures that cannot be replayed out of context

ML-DSA supports a context string that becomes part of what is signed. We use it to separate domains: an image approval, a file release and a platform release are each signed under their own context. A signature made for one cannot verify as another, so an attacker cannot take a legitimate approval of one artifact and present it as a release, or vice versa.

Signed statements are also encoded canonically, so the same statement always produces the same bytes, and verifiers check the signature over the bytes exactly as received before they parse anything.

Because our signatures use the standard ML-DSA construction with no custom wrapping, any conformant FIPS 204 implementation can verify them.

Defense in depth

No single control carries the whole load. An attack has to defeat every layer on its path, and most single compromises, whether a leaked registry token, a compromised upstream maintainer, a bad dependency in a build, or a stolen CI credential, defeat at most one or two.

1. Pinning: exact digests for everything, SHA-256 and size for every file.
2. Evidence and policy: SBOMs, scans and policy, re-checked by the signer.
3. Identity: short-lived CI identities bound to specific repositories, branches, tags and workflows.
4. Keys: ML-DSA-87 in Vault, never exported, separated by domain.
5. Verify before publish: the only paths into published locations check the signature first.
6. Storage controls: narrowly scoped publish rights, unserved staging, immutable versions.
7. Verify at use: the Vantage installer verifies the signed platform release with pinned public keys before it installs anything, locally, with no call back to Vantage.

What this gives our customers

Security teams evaluating an infrastructure vendor ask the same questions: where does this software come from, how do you know it has not been tampered with, and can you prove it? We answer with signed data instead of assurances.

• A signed bill of materials for every release. Each Vantage platform release is a signed manifest of every chart and image digest it contains, and each of those carries its own signed approval.
• SBOMs and scans on request. Every approved image carries its SBOM, vulnerability scan and signed approval alongside it in the registry, retrievable for any digest you run.
• Independent, offline verification. Verifying needs only our public keys. No call to Vault, to our registry, or to any Vantage service, which also suits disconnected and air-gapped environments.
• No quantum migration ahead. Our trust chain is already on the algorithm CNSA 2.0 requires for software signing. You will not have to re-pin or re-validate our trust anchors when classical signatures are retired.
• An audit trail. Every signature names the versioned key that made it, and every signed file release records the repository, tag and workflow run that produced it.

What's next

We are explicit about where the work continues. Next up is enforcing every signed image digest at install time, so a cluster runs only the exact bytes a signed release names, and a customer-facing verification guide with a published public key bundle for your own offline checks.

A note on precision: ML-DSA-87 is a NIST-standardized algorithm and our signing is aligned with FIPS 204 and CNSA 2.0. We do not claim FIPS 140-3 module validation or a formal certification, and we would rather tell you that up front.

If your team is evaluating AI and HPC infrastructure for regulated, federal or long-lived environments, we would be glad to walk through the architecture in detail.