On a typical afternoon, someone on your team ran curl -s https://raw.githubusercontent.com/ovh/ovh-cli/main/scripts/install.sh | bash to update OVHcloud's CLI tool. They got malware instead.
Here's what happened, which controls failed, and what you need to fix before it happens to your releases.
What Happened
An attacker compromised a contributor's GitHub account and replaced the download archives for OVHcloud's CLI tool with malware. The attacker targeted v0.15.0, swapping out six files covering macOS, Linux, and Windows distributions. The malicious files sat on GitHub's servers from 12:47 to 14:21 UTC, a 94-minute window where anyone downloading or auto-updating the tool received the compromised version.
The malware was designed to exfiltrate secrets. If your team's CI/CD runners pulled this update during that window, you're now asking whether your AWS credentials, database passwords, or API tokens walked out the door.
Timeline
12:47 UTC - Attacker gains access to contributor account, uploads malicious archives to v0.15.0 release.
12:47-14:21 UTC - Compromised files available for download; installation scripts fetch and execute without verification.
14:21 UTC - OVHcloud detects the compromise and removes malicious files.
Post-incident - OVHcloud enables GitHub's release immutability feature.
The 94-minute exposure shows how quickly supply chain attacks can happen. Your detection window needs to be faster than that.
Which Controls Failed
No release immutability. OVHcloud hadn't enabled GitHub's release immutability feature before the incident. This meant an attacker with contributor access could modify published releases, something that should never be possible once you've shipped.
No hash verification in installation scripts. The installation script pulled files and executed them without checking cryptographic hashes. When the attacker swapped the archives, the script downloaded and ran the malware. Your installation scripts probably do the same thing.
Insufficient account controls. A single compromised contributor account gave the attacker write access to releases. There's no evidence of MFA enforcement, code signing requirements, or release approval workflows that would've blocked this.
No integrity monitoring. The compromise went undetected for 94 minutes. There was no automated alerting when release artifacts changed, no checksum comparison against known-good builds, no anomaly detection on download patterns.
What the Standards Require
NIST 800-53 Rev 5 addresses software integrity in SI-7 (Software, Firmware, and Information Integrity). SI-7(1) requires integrity checks of software and information, SI-7(6) requires cryptographic protection, and SI-7(15) specifically calls out code authentication before execution. Your installation scripts that skip hash verification violate SI-7(1) and SI-7(15).
ISO/IEC 27001:2022 covers supplier relationships and secure development in Annex A 5.19 through 5.22. Control 8.31 (Separation of development, test, and production environments) implies that production releases shouldn't be modifiable post-publication. If an attacker can edit a published release, you've failed separation.
NIST Cybersecurity Framework v2.0 maps this to PR.DS-6 (Integrity checking mechanisms are used to verify software, firmware, and information integrity) and DE.CM-4 (Malicious code is detected). Your pipeline needs both: verify what you're shipping and detect when someone tampers with it.
OWASP ASVS v4.0.3 addresses this in V14.2 (Dependency). Requirement 14.2.4 states: "Verify that signed or integrity validated packages are used." If you're curling a shell script and piping it to bash without signature verification, you're non-compliant.
Lessons and Action Items
Enable release immutability today. GitHub's release immutability feature prevents modifications to published releases. Go to your repository settings, enable it, and document the policy. This is a five-minute fix that would've stopped this attack completely.
Add hash verification to every installation script. Your install script should:
- Download the archive.
- Download a separate checksum file (signed if possible).
- Verify the hash before extraction.
- Fail loudly if verification fails.
Don't pipe curl to bash. Download, verify, then execute.
Require signed releases. Use GPG or Sigstore to sign your release artifacts. Your installation script should verify signatures before trusting the download. This proves the release came from an authorized signer, not just someone with repository access.
Implement release approval workflows. Require two-person approval for production releases. Use GitHub's environment protection rules or your CI/CD platform's approval gates. A single compromised account shouldn't be able to ship to production.
Monitor release artifact changes. Set up alerts when release assets are modified, deleted, or added outside your normal release process. Calculate checksums of all release artifacts and store them in an immutable log. Compare on every access.
Audit contributor access. Review who has write access to your repositories. Remove contributors who don't need it. Require MFA for everyone who does. Consider separating release permissions from code contribution permissions.
Test your detection. Simulate this attack in a staging environment. Have someone with contributor access try to modify a published release. How long until you notice? If the answer is "we wouldn't," fix your monitoring.
Update your threat model. If you're still treating "compromised GitHub account" as low-probability, you're wrong. Threat actors know that one contributor account can poison thousands of downstream installations. Your release pipeline is a target.
The OVHcloud incident wasn't sophisticated. It was an attacker exploiting basic gaps in release hygiene that exist in most organizations. The 94-minute window was enough. Your window might be longer if you're not monitoring at all.
Check your release immutability settings right now. Then fix your installation scripts. The next 94 minutes might be yours.
