Signed, Immutable Releases: The FedRAMP Lesson in the OVHcloud Swap

The Federal Risk and Authorization Management Program (FedRAMP) expects control. Supply chain control includes how software artifacts ship.

A command line interface (CLI) swap showed the opposite. OVHcloud publishes the CLI for cloud administration.

Its advisory is GHSA-862f-55f5-vmvw. No Common Vulnerabilities and Exposures (CVE) number applies.

The release files changed after publication. The version numbers stayed exactly the same.

What OVHcloud says went wrong

A compromised developer GitHub account acted, OVHcloud says. It replaced assets for v0.11.0 through v0.15.0.

The window was 12:47 to 14:21 Coordinated Universal Time. The date was October 19, 2026.

That is about 94 minutes of exposure. OVHcloud reports about 250 downloads in it.

The build targeted secrets on the workstation. Cloud credentials and Secure Shell keys were listed.

Artificial intelligence tool keys were listed too. The advisory names the targeted file classes.

The Hacker News reports the checksums.txt swap. On v0.15.0, hashes matched the bad binaries.

OVHcloud names the root cause plainly. Release immutability was not configured on the repository.

What the fix looks like

OVHcloud removed the bad binaries that day. It suspended the compromised developer account.

It turned on immutable releases after that. The setting now covers its repositories, OVHcloud says.

It released v0.16.0 as an immutable release. That release also carries a signed tag.

Immutable means published files cannot change. Signed means users can verify origin independently.

Together, they close the exact gap used. A stolen account cannot quietly rewrite history.

Expectations providers should meet

Ask vendors how releases are locked. Ask who can replace a published artifact.

Ask whether tags are signed by default. Ask where attestations live for each release.

Prefer proof stored apart from the artifact. A checksum hosted beside the binary is not proof.

Build those answers into vendor reviews. Refresh them when a vendor changes platforms.

The governance lesson

You cannot govern tools you never inventoried. Signed artifacts help only inventoried tools.

List the tools inside your service boundary. Then demand artifact proof for each one.

PolicyCortex does not distribute or clean CLI tools. This article covers supply chain expectations only.

PolicyCortex makes no claim in this article about its own authorization status. The topic is vendor practice.

What to do this week

Review release settings for tools you ship. Turn on immutability where the platform offers it.

Check any October 19 CLI installs. Rotate secrets on workstations inside the window.

Sources

• OVHcloud security advisory GHSA-862f-55f5-vmvw, ovh/ovhcloud-cli repository. Root cause, window, downloads, and v0.16.0 fix.
• "Hackers Hijack Five OVHcloud CLI Releases," The Hacker News, October 2026. https://thehackernews.com/2026/10/hackers-hijack-five-ovhcloud-cli.html Checksums.txt swap detail.
• Original diagram by PolicyCortex.

Next step

Want vendor artifact evidence tracked across your boundary? See how PolicyCortex tracks it.