Why Companies Are Betting on Cyber Resilience

Your organization can enforce multifactor authentication, monitor endpoints and maintain strict network controls while remaining exposed through a trusted supplier, an application integration or a software update.

That is the central challenge of third-party supply chain security. Modern businesses depend on external software, cloud services, managed service providers, APIs and open-source packages. These dependencies improve productivity, but they also create security relationships that extend beyond the organization's direct control.

Verizon's 2026 Data Breach Investigations Report (DBIR) reports a 60% year-over-year increase in breaches involving third parties, reaching 48% in the dataset discussed in its reporting. This figure describes the report's findings; it should not be interpreted as a universal rate for all organizations or all cyber incidents. Read the 2026 DBIR public-sector snapshot.

The operational lesson is more important than any single percentage: a company's security depends partly on the identities it trusts, the software it accepts and the access it grants to external systems.

Why Is Supply Chain Security a Major Enterprise Concern?

Direct answer: Supply chain security matters because attackers may compromise a trusted supplier, software component or update mechanism rather than attack every customer individually. The resulting exposure depends on what the compromised component can access and how effectively the customer detects and contains the activity.

A network firewall can restrict connections, and endpoint detection can identify suspicious behavior on monitored devices. Neither control independently proves that an approved software update is trustworthy or that a valid vendor account is being used by its legitimate owner.

For example, a compromised supplier account may be used to access systems that the supplier was authorized to administer. A malicious software package may execute inside a developer's environment. A compromised update mechanism may deliver an unwanted payload through an otherwise legitimate distribution channel.

These are different attack paths, so they require different preventive and detective controls. Vendor identity management cannot replace software integrity verification, and dependency scanning cannot replace controls on production access.

The National Institute of Standards and Technology (NIST) addresses these issues in its software supply chain security guidance. Its recommendations cover supplier risk assessments, software verification, open-source controls, vulnerability management and software bills of materials. NIST's SBOM guidance explains how component inventories can support vulnerability identification and remediation.

How Do Vendors, APIs and Open-Source Packages Become Attack Vectors?

1. Vendor accounts and remote access

External providers may need access to cloud consoles, business applications, production systems or remote management tools. That access is often necessary, but it increases the number of identities and organizations that must be secured.

If an attacker compromises a supplier's account or session, the attacker may be able to use permissions that the customer has already granted. The potential impact depends on the account's privileges, authentication requirements, network segmentation and monitoring.

Security teams should therefore treat vendor access as privileged access when its capabilities justify that classification. Each supplier should have a defined business purpose, an accountable owner and access limited to the systems required for its work.

Recommended controls include:

• Require multifactor authentication for interactive access, especially for privileged accounts.
• Use separate, identifiable accounts for individual supplier personnel rather than shared administrative accounts.
• Restrict remote access to approved systems and permitted time windows where practical.
• Log privileged actions and investigate unusual access patterns.
• Remove access promptly when a contract, role or operational requirement ends.

2. Overprivileged APIs and service identities

APIs connect cloud services, SaaS platforms, internal applications and automation workflows. Their credentials often belong to non-human identities, including service accounts, API keys, OAuth grants and workload identities.

The risk increases when an integration can access more information or perform more actions than its function requires. A service designed to read a limited set of records should not automatically receive broad administrative access to an entire environment.

If a token is stolen or misused, excessive permissions can increase the potential damage. Depending on the authorization model, an attacker may be able to retrieve records, modify business data or invoke other services accessible to that identity.

Reduce this exposure with the following controls:

• Apply least privilege. Grant only the scopes, resources and actions required by the integration.
• Manage the full credential lifecycle. Record ownership, expiry, rotation and revocation requirements for API keys and tokens.
• Prefer short-lived credentials where supported. Use managed workload identities or short-lived tokens when the platform supports them.
• Monitor API activity. Look for unusual data volumes, unexpected destinations, privilege changes and access outside established patterns.
• Review permissions after changes. Reassess access when an integration changes function, the vendor changes or the business requirement ends.

These practices are defensive recommendations based on established access-control principles. They should not be confused with a claim that every API integration is vulnerable or that one control can eliminate API risk.

3. Open-source dependencies and malicious packages

Open-source software is a foundational part of modern application development. Projects routinely depend on packages maintained by external developers, distributed through public registries and incorporated into automated build pipelines.

The risk is not limited to known software vulnerabilities. Attackers may publish malicious packages, compromise maintainer accounts, steal publishing credentials or introduce malicious changes into an otherwise trusted project.

Sonatype's 2026 State of the Software Supply Chain report says it identified more than 454,600 new malicious open-source packages during 2025. Sonatype reported a cumulative total exceeding 1.233 million known and blocked malicious packages across ecosystems including npm, PyPI, Maven Central, NuGet and Hugging Face. These are figures reported by Sonatype, not a count of enterprise systems confirmed to have been compromised.

Malicious packages can attempt to steal developer credentials, access environment variables, execute code during installation or use a compromised development environment to reach additional projects. The actual impact depends on the package's behavior and the permissions available to the process that runs it.

Useful controls include automated dependency analysis, review of unexpected package changes, restricted access to publishing credentials, lockfiles and version controls, and isolation of build environments. Teams should also maintain a process for identifying affected applications when a dependency is disclosed as malicious or vulnerable.

4. Compromised software updates

Software updates are another supply chain trust boundary. Customers generally expect an update delivered through a vendor's normal mechanism to contain authentic, authorized software. If the update infrastructure or distribution process is compromised, that assumption can become unsafe.

On October 20, 2026, Recorded Future News reported that AOMEI had confirmed attackers repeatedly altered configuration files on its update servers between April and July, redirecting software to download malware for brief periods. The report said the activity was investigated by ManageEngine researchers and Google Threat Intelligence Group. Read the incident report.

The reported short-lived changes illustrate why point-in-time inspection may not be sufficient to detect every update-channel compromise. A file or configuration may appear normal when inspected after a malicious change has been reversed.

NIST recommends verifying hashes and signatures for vendor-supplied software and updates where feasible. Verification is most useful when the expected hash or signing identity comes from a trustworthy source independent of the potentially compromised delivery path. See NIST's enhanced vendor risk assessment guidance.

Supply Chain Risks and Their Defensive Controls

How Can Organizations Reduce Supply Chain Risk?

Direct answer: Begin with an inventory of third-party access and critical software dependencies. Reduce unnecessary permissions, secure non-human identities, verify software components, protect build pipelines and establish a tested response process for supplier or package compromises.

1. Inventory suppliers, integrations and dependencies

Security teams cannot effectively govern connections they do not know exist. Maintain an inventory of important suppliers, SaaS applications, API clients, service accounts, remote access paths and software dependencies.

For each high-risk connection, record:

• The business and technical owner.
• The systems and data it can access.
• The permissions and authentication method it uses.
• The supplier's security contact and incident-notification process.
• The review date and conditions that require access to be revoked.

Prioritize connections that can modify production systems, administer cloud resources, publish software or access sensitive data. This gives teams a practical starting point without assuming every supplier presents the same level of risk.

2. Govern non-human identities

API keys, workload identities and service accounts need the same basic governance discipline as employee accounts. Each should have a defined purpose, an owner and permissions appropriate to its function.

Store secrets in an appropriate secrets-management system rather than source code or build logs. Rotate exposed credentials, remove unused identities and review permissions when the integration changes. Prefer short-lived credentials when the platform can support them reliably.

For vendor access, use MFA, limit privileged permissions and maintain logs that can help investigators determine which actions were performed. These controls reduce exposure but do not eliminate the need for monitoring and incident response.

3. Make dependency security part of CI/CD

Software composition analysis helps identify known vulnerabilities and other risks in direct and transitive dependencies. A software bill of materials (SBOM) records the components included in a software product or build.

Generate SBOMs where appropriate, maintain dependency records and connect those records to vulnerability-management processes. When a component is reported as vulnerable or malicious, teams need to identify where it is used, determine whether the affected version is present and take action based on the evidence.

An SBOM is an inventory, not a security certificate. It does not prove that a component is safe, that every dependency has been captured or that a software build has not been tampered with.

NIST's Secure Software Development Framework (SP 800-218) describes practices that can be integrated into software development life cycles to reduce vulnerabilities and improve software security. NIST's supply chain guidance complements that framework with recommendations for software verification, open-source controls, supplier assessments and vulnerability management.

4. Protect build and publishing systems

CI/CD systems often hold source code, signing keys, package publishing credentials and deployment permissions. Compromise of these systems can affect both the software being developed and the environments into which it is deployed.

Restrict which workflows can publish packages, minimize the permissions available to build jobs, protect secrets and isolate runners where practical. Limit outbound network access when it is not required. Verify signatures or provenance information when a trustworthy mechanism is available.

Separate development, testing and production permissions so that compromise of a low-trust build process does not automatically provide broad production access.

5. Prepare for a supplier compromise

Supplier security reviews cannot guarantee that a vendor will never be compromised. Organizations also need a plan for responding when that happens.

The response process should explain how to disable supplier accounts, revoke tokens, isolate affected systems, block compromised package versions and preserve logs. Teams should know how to identify affected applications and determine whether a supplier incident creates a credible risk to their own environment.

For critical suppliers, establish clear channels for security advisories and incident notifications. Exercise the response process before an incident so that revoking access does not depend on improvisation during an outage.

Supply Chain Security Checklist

• Inventory third-party accounts, integrations and critical software dependencies.
• Assign owners to high-risk supplier connections and non-human identities.
• Require strong authentication and restrict privileged vendor access.
• Remove unnecessary API scopes, stale tokens and unused service accounts.
• Use dependency analysis and maintain SBOMs where appropriate.
• Protect CI/CD secrets, package publishing credentials and build runners.
• Verify software signatures and hashes using trustworthy reference information where feasible.
• Monitor supplier access, unusual API activity and unexpected dependency changes.
• Document and test procedures for revoking access and responding to compromised software.

Frequently Asked Questions

Why is third-party supply chain security important?

Organizations depend on external suppliers, software components and integrations that they do not fully control. A compromise affecting one of those dependencies can create exposure for downstream customers. Access controls, software verification and incident-response procedures help reduce that risk.

What is overprivileged API access?

Overprivileged API access occurs when a credential or integration has more permissions than required for its intended function. If that credential is compromised or misused, excessive permissions can increase the data and systems an attacker can reach.

What is an SBOM?

A software bill of materials is a record of the components included in a software product or build. It helps organizations identify potentially affected components when vulnerabilities or supply chain incidents are disclosed. An SBOM supports visibility; it does not guarantee software integrity.

How can a company reduce software supply chain risk in CI/CD?

Use dependency scanning, maintain component inventories, protect build secrets, restrict publishing permissions, isolate build runners and verify artifact provenance where supported. Maintain a process for investigating and replacing dependencies that are found to be compromised.

Does following NIST SSDF guarantee secure software?

No. NIST SP 800-218 provides recommended secure development practices intended to help reduce software vulnerability risk. It supports a structured security process but does not guarantee that software or its supply chain is free from vulnerabilities or compromise.

The Bottom Line

Third-party supply chain security is not just a procurement issue. It is an engineering and operational discipline involving identity, permissions, software integrity, build systems and incident response.

Organizations should start by identifying the connections that carry the greatest potential impact. Limit their privileges, protect the credentials and systems behind them, maintain visibility into software components and prepare to revoke trust when evidence indicates a supplier or dependency has been compromised.

No single framework, scanner or vendor questionnaire can eliminate supply chain risk. A layered approach makes it easier to identify exposure, contain an incident and establish what was affected.

Sources & References

1. Verizon. 2026 Data Breach Investigations Report resources. Verizon DBIR reports.
2. National Institute of Standards and Technology (NIST). Software Security in Supply Chains: Guidance, Purpose, Scope, and Audience. Read the NIST guidance.
3. National Institute of Standards and Technology (NIST). Software Security in Supply Chains: Software Bill of Materials (SBOM). Read the SBOM guidance.
4. Sonatype. 2026 State of the Software Supply Chain: Open Source Malware. Read Sonatype's report.
5. Recorded Future News / The Record. AOMEI yet to notify customers after hackers hijacked its software updates. October 20, 2026. Read the incident report.
6. National Institute of Standards and Technology (NIST). SP 800-218: Secure Software Development Framework (SSDF), Version 1.1. February 2022. Read the publication.
7. National Institute of Standards and Technology (NIST). Enhanced Vendor Risk Assessments. Read the recommendations.

Editorial note: Statistics are attributed to their publishers, and the article distinguishes reported incidents from general defensive analysis. Security controls should be adapted to each organization's systems, threat model and operational requirements.