The supply chain is part of the attack surface
CISA describes a software supply-chain attack as a situation in which an attacker compromises a supplier's environment and introduces malicious code before the product reaches customers. The threat may enter an organization together with a new application, patch, or update.
The broader chain includes manufacturers, open-source libraries, integrators, cloud services, managed service providers, remote-access systems, repositories, build processes, and signing mechanisms. Any of these elements may receive privileged access or become a distribution point.
Common compromise paths
Compromised update process
A malicious change can be distributed through a channel that devices and administrators recognize as legitimate. A digital signature helps confirm origin and integrity, but compromise of the signing system or build process can also undermine that control.
Open-source dependency
Risks include malicious packages, name typosquatting, a compromised maintainer account, and a vulnerability in a legitimate component. The same dependency may exist inside many products even though the organization never installed it directly.
Supplier account or remote-access tool
A service partner may connect to many customers. Missing isolation, excessive privileges, or a compromised account can create a path that bypasses part of the perimeter defenses.
Hardware, firmware, and base images
The chain does not end with application code. Risk may arise in an operating-system image, firmware, hardware delivered through an intermediary, or disposal of storage without effective data removal.
Why this type of attack is difficult to detect
- traffic originates from an allowed application or known infrastructure;
- the process runs with the elevated privileges required by the product;
- the update may be signed or delivered through the correct channel;
- the same component is hidden beneath many dependency layers;
- the customer does not control the supplier's entire development process;
- after broad distribution, the compromise may activate only for selected recipients.
ENISA emphasizes that supply-chain risk management requires an approach covering risk assessment, supplier relationships, vulnerability handling, and the security quality of products and practices.
Example: a trusted update with unusual behavior
An organization uses an endpoint-management tool. The product regularly connects to the vendor and has broad privileges. After an apparently legitimate update, the process begins contacting a new domain and executing commands outside its normal profile.
Blocking the domain may limit the immediate impact, but it does not answer which hosts received the update, whether the code performed additional actions, which credentials were accessible, or whether the update mechanism remains trustworthy.
Layers that limit the domino effect
Knowledge of components and suppliers
- inventory of critical software, services, and connections;
- a named owner for every material supplier relationship;
- an SBOM or equivalent component visibility where feasible;
- a register of service accounts, certificates, and update channels.
Access boundaries
- least privilege instead of default administrative access;
- dedicated supplier accounts protected with MFA;
- maintenance windows, connection approval, and complete logging;
- segmentation that permits access only to resources actually required.
Supplier assessment
- requirements for incident and vulnerability reporting;
- secure development, signing, and update-publication practices;
- breach-notification timelines and emergency contacts;
- a plan for service termination, access removal, and data migration.
Behavior monitoring
A trusted process should still have an expected profile: defined domains, ports, connection frequency, and operations. Deviation from that profile may matter more than the vendor name displayed on the file.
When a supplier reports a compromise
- determine the exact products, versions, components, and time window;
- identify systems that received the artifact or used the service;
- preserve logs and samples according to procedure;
- restrict connections and privileges while accounting for operational continuity;
- look for secondary activity: new accounts, tasks, tokens, traffic, and exfiltration;
- do not restore trust based only on reinstalling the product;
- define conditions for safe return and subsequent monitoring.