Software supply chain attacks: due diligence for buyers

Two compromises, one lesson

Software supply chain attacks moved from theory to two concrete cases within a day of each other. Attackers hijacked a developer's GitHub account and backdoored versions 0.11.0 through 0.15.0 of the OVHcloud command-line interface, which was built to steal secrets from developer machines (BleepingComputer). Separately, AOMEI's update and notification servers were abused between April and July 2026 to push malware to backup software users, with the attackers restoring the altered files within minutes to hide the trail (BleepingComputer).

Both attacks reached customers through the channel buyers trust most: the vendor's own release and update process. Neither was stopped by a firewall or an endpoint tool. That makes it a procurement problem, not only a security operations one. When you evaluate a vendor on Scopelyst, release integrity and incident disclosure belong on the scorecard, next to price and delivery history.

Why the update channel is the weak link

The scale is not marginal. In a survey carried out in February 2026, 77% of organizations said they had experienced a software supply chain incident in the previous 12 months (Docker/Omdia). An earlier survey of 546 IT directors and CISOs put the share hit by a material third-party incident at 71%, with 5% reporting ten or more (CSO Online).

The attacks themselves are cheap to run. More than 90% of all malware advisories ever filed for open source software landed in 2025 alone, and 930 npm account-takeover advisories that year represented 92% of all such cases recorded (Endor Labs). Open source malware passed 1.233 million packages, according to Sonatype's 2026 count (Sonatype).

What changed in the AOMEI and OVHcloud cases is the entry point. Attackers did not need a flaw in shipped code. They needed write access to a release or update path that customers already treat as trusted.

What the OVHcloud case reveals

OVHcloud's chief executive said the compromised release appeared at 14:47 on October 19, 2026 and was detected at 16:21 after a customer reported it. The clean versions were 0.16.0 and the older 0.10.0 (BleepingComputer).

Two details deserve a buyer's attention. First, the continuous integration pipelines with unit tests, functional tests and vulnerability detection were not touched; the malware was built locally and uploaded. Second, GitHub's release immutability setting was switched off, so a privileged account could alter an existing release without passing checks at all. Passed tests prove nothing if the artifact you download was never built by those tests.

OVHcloud has since enabled immutability and told affected users to clean their systems and rotate every secret on the disk. That is the right response. The point for buyers is that the control existed and was optional.

What the AOMEI case reveals

The AOMEI campaign ran from April to July 2026. Researchers found three windows when AOMEI's servers served a malicious configuration file: ten minutes on May 28, six minutes on July 16 and five minutes on July 20. The attackers changed the expected checksum in the update configuration so the malicious archive would pass the software's own file verification (BleepingComputer).

A checksum only proves the file matches what the vendor published. If an attacker controls the source that states the expected value, verification is theatre. Google warned the activity was opportunistic and could have caught any organization that checked for updates during those short windows.

Questions to put in the RFP

CISA's guidance for software customers separates enterprise security, which protects the vendor's own offices, from product security, which protects what they ship to you. Most compliance certificates cover only the first (CISA). These questions cover the second.

• Can a release artifact be replaced after publication? Is immutability enforced, and by whom?
• Are artifacts built by a pipeline from a known commit, or can engineers upload locally built binaries?
• How are signing keys held, rotated and separated from the accounts that publish packages?
• Who can write to the repositories and package registries you distribute through, and is multi-factor authentication required?
• What integrity check runs on the customer side, and where does the expected value come from?
• How quickly would you notify customers of a suspicious release, and through which channel?
• Will you provide a software bill of materials and supply it on updates? The Enduring Security Framework treats it as an artifact customers should require and verify during deployment (CISA).

Compare the answers across shortlisted vendors in the IT services vendor directory rather than one at a time. Patterns show up when proposals sit side by side, and our guide on questions to ask an IT services vendor covers the commercial side of the same conversation.

Contract terms that make answers enforceable

Verbal assurance evaporates after signature. The Enduring Security Framework guidance asks customers to require notification from suppliers about ownership changes, third parties in the product, cyber incidents and investigations, and any change in security assumptions between evaluation and deployment (CISA).

1. 1Set a notification clock. A named contact, a maximum number of hours from confirmation, and a written format.
2. 2Require a fix window. If a release is found compromised, the vendor publishes a clean build and a version list within an agreed time.
3. 3Name the release controls. Immutable releases, signed artifacts from a pipeline, protected maintainer accounts.
4. 4Add a right to audit. On notice, or after any severe incident, you can review build and release records.
5. 5Keep a rollback path. Know how to pin a version and block automatic updates before an incident, not during one.

If the project is a managed service, the same terms belong in the statement of work. Cybersecurity vendors in particular should expect them; browse cybersecurity providers to see how firms position release integrity.

What vendors should fix before the next RFP

Vendors face the same questions from every serious buyer, so prepare the evidence once. Turn on release immutability and require signed commits in your main branch. Remove the ability to upload locally built binaries to a public release. Separate build credentials from publishing credentials, and rotate both on a schedule.

Assume account takeover. The OVHcloud attacker's GitHub account had been compromised for more than half a year, and researchers found a scripted history rewrite in March 2026 (BleepingComputer). Long-lived credentials are a standing invitation. Institute a cooldown before your own teams adopt freshly published third-party packages; Endor Labs found that 88% of respondents know the first days after a release are the riskiest yet only 21% enforce a waiting period (Endor Labs).

Write an incident disclosure template before you need it. A clear notice with affected versions, exposure window, what you have fixed and what the customer must rotate is a competitive asset in a tender. Firms that answer well win deals; the marketplace guide on winning RFPs makes the same point about proof over promises. Teams working on build pipelines can find partners through the software development directory.

Frequently asked questions

What is a software supply chain attack?

It is a compromise of software before it reaches the customer, usually through the vendor's build, release or update process. The attacker gains write access to code or distribution and ships malicious content under a trusted name. CISA describes the goal as compromising the customer's system through software the vendor already delivered (CISA).

How do I check whether a vendor signs its releases?

Ask for the artifact and its signature from a recent release, then verify it yourself. Confirm that the expected hashes are published from a source separate from the download server. A checksum stored on the same server as the file proves little, as the AOMEI case showed.

Should I delay installing vendor updates?

Not blindly. Updates close known flaws, and delaying them carries cost. Instead, pin versions for critical systems, test in a staging environment, and require vendors to publish a version history with hashes so you can tell a legitimate release from an injected one.

Does an SBOM prevent these attacks?

No, but it shortens response. A bill of materials tells you which components and versions sit inside a product, so an advisory becomes a lookup rather than an investigation. Ask for one at delivery and on each major update.

What this means for buyers

Treat release integrity as a scored requirement in every software and managed service decision. Before signing, get written answers on immutable releases, pipeline-built artifacts, signing key custody and disclosure timing, and attach them to the contract as obligations.

Prepare your own side too. Keep an inventory of vendor tools installed on developer machines and servers, because the OVHcloud advice was blunt: if you ran an affected build, treat every secret on that machine as exposed and rotate it. Know which of your systems accept automatic updates and which you can freeze in minutes.

For new projects, describe these requirements in the brief when you post a project, so vendors price and answer them from the start. The vendors that can show evidence of signed, pipeline-built releases are the ones worth shortlisting for anything touching production.