A 2021 survey found that 97% of participating organizations said they had been negatively affected by a cybersecurity breach somewhere in their supply chain. That is not the same as saying 97% suffered an attack in which malicious code was inserted into software. BlueVoyant’s survey covered broader third-party risk; a separate Aqua Security report measured respondents’ confidence in software defenses. Both findings are historical snapshots, not current breach rates.
What the 2021 report found
The headline came from a VentureBeat article published October 12, 2021, summarizing BlueVoyant’s second annual global survey of third-party cyber risk and a separate Aqua Security finding. BlueVoyant reported that respondents had experienced extensive supply-chain harm, alongside gaps in supplier visibility. Its figures describe survey answers, not a census of confirmed incidents. VentureBeat’s original article and BlueVoyant’s findings and methodology provide the original context.
| Survey finding | What it means |
|---|---|
| 97% reported negative impact from a breach somewhere in their supply chain. | Impact could occur through the wider supplier ecosystem; it does not establish that the respondent’s own software was maliciously altered. |
| 93% said supply-chain or third-party weaknesses had caused a direct cybersecurity breach. | Respondents attributed a direct breach to a supplier weakness; this is distinct from the broader negative-impact measure. |
| The average reported number of breaches rose from 2.7 in 2020 to 3.7 in 2021, described by BlueVoyant as a 37% year-over-year increase. | A comparison of the survey’s reported results, not an independently validated global incident trend. |
| 38% said they had no way to know when or whether a cybersecurity issue arose at a third-party supplier. | A visibility gap can delay response even when an organization knows its direct vendors. |
| 47% assessed or reported on vendor security no more than twice a year. | BlueVoyant discussed this in accompanying analysis; infrequent review is not continuous monitoring. |
| 13% said third-party cyber risk was not a priority, down from 31% in the previous survey; 91% said the budget was increasing in 2021. | These are reported priorities and budget direction, not proof that controls improved. |
Who answered—and what the sample can show
BlueVoyant commissioned Opinion Matters to survey 1,200 CIOs, CISOs, and chief procurement officers at organizations with more than 1,000 employees. Respondents were in the United States, Canada, Germany, the Netherlands, the United Kingdom, and Singapore, across sectors including business and financial services, health care and pharmaceuticals, manufacturing, utilities and energy, and defense. BlueVoyant’s report page describes the sample and findings.
This was an executive experience-and-perception survey—not a random sample of every business, a breach census, an independently audited incident database, or a telemetry study. It does not establish rates for small businesses, public agencies, open-source projects, or consumers. BlueVoyant is a cybersecurity vendor, a relevant commercial interest for readers weighing its survey claims.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →#1 Best Overall
Why “supply-chain breach” needs careful interpretation
Supply-chain risk covers several different events. A supplier can suffer a breach in its own environment without a customer’s systems being compromised. A customer can experience operational or financial harm from a supplier incident. A supplier weakness can lead directly to compromise of a customer’s systems. A software-supply-chain attack is narrower: an attacker compromises or abuses a trusted code, build, package, signing, or distribution path so that downstream users receive or run manipulated software.
A vulnerable library is not automatically evidence of an attack, and a third-party breach is not necessarily a software compromise. The 97% figure concerns negative impact from a breach somewhere in the wider supply chain; 93% concerns respondents’ attribution of a direct breach to supply-chain weaknesses. Neither number is a software-only attack rate.
Rank #2
Why one supplier can create risk for many organizations
Supply chains amplify both access and reach. A vendor with privileged connectivity may touch many customers; a software publisher can distribute one compromised update to a large installed base. Managed service providers, cloud and identity providers, package registries, and build systems can become concentration points. Fourth- and fifth-party dependencies further obscure which organizations handle data, code, or delivery.
SolarWinds, Kaseya, and Accellion illustrate third-party incidents with effects across industries, but they were not identical attack types. BlueVoyant cited them as examples of third-party attacks affecting multiple sectors. Their shared lesson is about dependency and reach, not that every vendor incident follows the same technical path. BlueVoyant’s accompanying analysis discusses the broader vendor-risk context.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What the separate Aqua figures add
Aqua Security separately reported that 73% of respondents were confident they could stop software-supply-chain attacks, while 32% were confident in runtime capabilities against threats such as Kinsing malware, which Aqua described as downloading at runtime. These are confidence levels, not results from independent performance tests. The available account does not establish enough about the respondent sample, the meaning of “stop,” or whether answers concerned containers specifically to treat the figures as measured protection. Aqua is also a security-product vendor. The numbers should not be combined with BlueVoyant’s survey. Aqua’s account presents that separate finding.
How software supply-chain attacks happen
- Source and identity compromise: stolen developer, maintainer, or CI/CD credentials can be used to alter code or publish releases.
- Dependency and package abuse: attackers may hijack a maintainer account, publish malicious open-source packages, exploit dependency confusion or typosquatting, or introduce harmful code through a legitimate upstream dependency.
- Build and artifact compromise: a build server, plugin, artifact repository, container image, or registry may be tampered with. Exposed secrets in logs, runners, or configuration can provide a route in.
- Distribution and signing abuse: a compromised installer or update channel can deliver altered software. Stolen or misused signing keys can make unauthorized artifacts appear to come from a trusted publisher.
- Supplier access and runtime behavior: a vendor’s remote access may be abused, or a payload may act only after deployment. Inadequate separation between build and production environments increases the consequences.
Build a program that covers suppliers, software, and runtime
1. Inventory what you depend on
Track direct and transitive software dependencies, build tools and plugins, container images, registries, SaaS and cloud providers, and vendors with network, administrative, code, or data access. Record critical fourth-party dependencies where practical. An inventory is useful only if ownership and update processes keep it current.
Rank #4
2. Tier supplier requirements by risk
Set review depth according to access privileges, data sensitivity, business criticality, ability to affect many customers, software-development and release responsibilities, subcontractor dependence, incident-notification commitments, and recovery capability. Annual questionnaires may suit low-risk providers, but should not be the sole control for a critical software, identity, cloud, payment, health-care, or infrastructure supplier. Where a smaller vendor cannot provide bespoke evidence, use proportionate compensating controls: restrict access, segment connectivity, limit data, and prepare a replacement or continuity path.
3. Protect developer identities and the build pipeline
- Require multifactor authentication, preferably phishing-resistant, for developers and maintainers; use short-lived credentials and least privilege.
- Isolate build environments, use ephemeral CI runners where feasible, protect branches, and require code review.
- Pin dependencies and control updates through approved repositories or private mirrors; scan for exposed secrets and rotate credentials quickly.
- Separate development, build, release, and production privileges. Keep build logs immutable or append-only where possible.
- Use reproducible or independently verifiable builds where practical, and sign artifacts while protecting signing keys.
4. Use SBOMs as inventory, not as a safety certificate
A software bill of materials (SBOM) records components and relationships in software. SPDX and CycloneDX are established SBOM formats. Generate SBOMs during builds, normalize supplier and version identities, and feed them into asset and vulnerability workflows so teams can find affected products and prioritize action. CISA describes SBOM consumption as part of a wider process that uses external data, prioritization, and timely action in its SBOM-consumption guidance.
Best Value
An SBOM does not prove a build was trustworthy, that a component is safe, or that the artifact was not modified. It can be incomplete or stale, miss dynamically downloaded components, and contain inconsistent names or versions. Knowing a component is present also does not reveal how it entered the artifact.
5. Verify artifacts and provenance
Sign releases and verify signatures at deployment; preserve evidence about where and how artifacts were built. Signing can expose unauthorized modification and support provenance, but it does not prove benign intent. If an attacker controls the signer or steals its key, malicious software can still be signed. Verification only helps when deployment systems enforce it.
6. Monitor supplier exposure and act on alerts
Continuous external monitoring can reveal exposed services, leaked credentials, attack-surface changes, and emerging issues. It cannot see every internal control or prove a supplier’s build process is secure, and false positives can burden both parties. Define who triages alerts, what evidence is requested, and what triggers access restriction, remediation, or notification. Monitoring without escalation and response procedures adds little protection.
7. Detect and respond after deployment
Pre-release checks can miss newly malicious behavior, production-only activation, environment-specific exploitation, valid-credential abuse, or threats without a known vulnerability record. Monitor process execution, network connections, file changes, privilege escalation, container behavior, and unexpected outbound traffic. Runtime defenses add operational complexity and require tuning to limit alert fatigue; they complement rather than replace secure development and provenance controls.
Questions to take to engineering, procurement, and suppliers
- Can we enumerate our direct and transitive dependencies, build tools, images, and critical providers?
- Who can publish production artifacts, and how are those identities and credentials protected?
- Are release artifacts signed, and do deployment systems verify signatures?
- Can suppliers notify us promptly after a compromise, and do contracts define the required information and response path?
- Can we detect unexpected behavior after software is deployed?
- Do we have a process to replace an emergency dependency and maintain operations if a critical vendor is unavailable?
The 2021 findings are useful as a record of perceived exposure and visibility problems among surveyed large organizations. They do not establish today’s breach rate or show that software-only attacks affected nearly all companies. The practical response is to distinguish supplier risk from software integrity risk, then connect inventory, governance, build protection, artifact verification, runtime detection, and recovery.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
