In December 2020, security researchers at FireEye discovered that the network monitoring software SolarWinds Orion, deployed across thousands of government agencies and Fortune 500 companies, had been modified to include a backdoor. The modification had been introduced during SolarWinds' own build process, inserted by attackers who had compromised the company's development environment. When SolarWinds distributed a routine software update, the backdoor went with it. Organisations that had deployed the update, including the US Departments of Treasury, Commerce, and Homeland Security, had been compromised without any attack on their own networks. The supply chain had been the attack vector.
The SolarWinds incident illustrated, with a clarity that had not been available before at this scale, the fundamental challenge of supply chain cyber risk: an organisation's security posture is bounded not by its own controls but by the weakest link in the network of vendors, suppliers, and technology providers on which it depends. This is not a new observation, but SolarWinds demonstrated it at a scale and in a context, trusted software updates from a major network management vendor, that forced a reassessment of how organisations should think about third-party risk.
Supply chain attacks exploit trusted relationships between organisations and their vendors to gain access that would not be achievable through direct attack. The attack surface of a supply chain is defined by the number of vendor relationships, the depth of access each vendor has to the organisation's systems and data, the security posture of each vendor, and the monitoring that exists for vendor-related access and activity.
Software supply chain attacks, like SolarWinds, target the development and distribution processes of software that is widely deployed and trusted. The 3CX attack in March 2023 followed a similar pattern: attackers compromised a widely-used VoIP software provider's build system and used a legitimate software update to distribute malware to 3CX customers. What made the 3CX attack particularly notable was that the initial compromise of 3CX's environment had itself been achieved through a supply chain attack: attackers had compromised a financial software vendor whose product 3CX employees used, using that access to pivot to 3CX's development environment.
This cascading supply chain compromise, where a fourth-party compromise enables a third-party compromise, which in turn enables a direct customer compromise, illustrates why supply chain risk management must account for fourth-party relationships, the vendors of your vendors, not just the direct vendor relationships your organisation has visibility into.
Third-party risk intelligence goes beyond the vendor assessment questionnaires and security certifications that traditional vendor risk management programmes rely on. These traditional approaches assess what a vendor claims about their security programme at a point in time; intelligence-based approaches assess what is actually observable about a vendor's security posture and threat exposure on an ongoing basis.
External attack surface monitoring of vendor infrastructure reveals configuration issues, exposed services, and vulnerability exposures that vendors may not have identified internally. A vendor whose web-facing infrastructure is running unpatched software with known exploited vulnerabilities, or whose cloud storage is misconfigured, represents a risk to their customers regardless of what their security questionnaire says. Attack surface intelligence applied to vendor infrastructure provides this continuous, externally observable assessment.
Dark web monitoring for vendor-related intelligence identifies when vendor credentials appear in credential leaks, when vendor infrastructure is mentioned in criminal forum listings, or when threat actors discuss targeting specific vendors as a path to reaching their customers. When an initial access broker lists access to a software vendor that supplies security tools to financial sector clients, that listing is relevant intelligence for every one of those financial sector clients, even though the compromised organisation is a vendor rather than the target itself.
In the aftermath of SolarWinds, significant attention has been directed toward software supply chain security: the practices and controls that software vendors apply to ensure that their build and distribution processes cannot be compromised in ways that would affect their customers. The US executive order on cybersecurity issued in May 2021 mandated software bill of materials (SBOM) requirements for software sold to the federal government, creating a requirement for software vendors to document the components of their products in a machine-readable format.
An SBOM allows organisations to assess their exposure when a vulnerability is disclosed in an open-source component: rather than manually checking which of their deployed software products includes the affected component, a machine-readable SBOM enables automated matching against a vulnerability feed. The CISA SBOM resources provide guidance on SBOM standards and implementation that organisations can use to establish SBOM requirements for their software vendors.
Code signing, the practice of cryptographically signing software packages to verify that they have been produced by the claimed author and have not been modified after signing, is a control that limits the impact of supply chain compromises at the distribution stage. However, code signing provides no protection if the attacker has compromised the signing key or the build environment before the signing step occurs, as was the case with both SolarWinds and 3CX.
An effective supply chain risk monitoring programme identifies the vendor relationships that represent the highest risk based on the access each vendor has and the vendor's assessed security posture, and prioritises intelligence collection and monitoring for those high-risk relationships. This prioritisation prevents the programme from being overwhelmed by the volume of vendor relationships most large organisations maintain.
Vendor intelligence workflows typically include continuous external attack surface monitoring for the highest-risk vendors, dark web monitoring for vendor credential exposure and criminal discussion of vendor targeting, and integration of vendor security incident disclosures into the organisation's incident response planning. When a significant vendor discloses a security incident, the organisation should assess whether its own data or systems may have been affected and implement additional monitoring for signs of lateral movement from the vendor environment.
The dark web monitoring component of supply chain intelligence is particularly valuable because it surfaces threats to vendor security before those threats produce disclosed incidents. A vendor credential appearing in a criminal forum listing, or a discussion of targeting a specific vendor on an underground forum, is a pre-incident warning that allows the organisation to increase monitoring of vendor-related access, review the scope of vendor access to sensitive systems, and prepare contingency plans before a potential incident materialises.
The operational implementation of a vendor risk intelligence programme requires a structured approach that connects intelligence collection to vendor management workflows and risk decision-making processes. Without this structure, vendor intelligence data accumulates without producing risk reduction actions, and the programme fails to deliver value proportionate to its investment.
The first step is vendor inventory and tiering: cataloguing all significant vendor relationships and categorising them by the level of access each vendor has to the organisation's systems, data, and processes. Vendors with access to sensitive customer data, critical operational systems, or security infrastructure represent the highest-risk tier and should receive the most intensive ongoing monitoring. Vendors with limited, audited access to non-sensitive systems represent a lower tier that may be monitored through periodic assessment rather than continuous intelligence collection.
For the highest-risk tier, external attack surface monitoring should provide continuous visibility into the vendor's internet-facing infrastructure: what services are exposed, what software versions are running, whether any services have known vulnerabilities, and whether any misconfigurations would allow unauthorised access. This monitoring does not require vendor cooperation and provides an objective, externally observable view of vendor security posture that complements the self-reported information from vendor questionnaires.
Dark web monitoring for vendor-specific intelligence requires defining the identifiers associated with each high-risk vendor: their domain names, IP ranges, known employee email patterns, and any specific product or service identifiers that might appear in criminal forum discussions. When these identifiers appear in monitored sources, the intelligence is triaged for relevance and potential impact on the organisation before being escalated to the vendor relationship owner and relevant security teams. This workflow connects the intelligence function to the business relationship management that makes the intelligence operationally meaningful, turning a monitoring signal into a risk management conversation with the vendor that is grounded in specific, observable evidence of exposure.
Defendis extends its external threat monitoring to the vendor relationships that matter most to your organisation, providing supply chain intelligence that connects vendor exposure to your organisation's specific risk profile and response requirements.
Most third-party risk management programmes focus on direct vendor relationships, the suppliers, service providers, and technology partners that the organisation contracts with directly. But the SolarWinds attack, in which a software vendor's build system was compromised to deliver malicious updates to the vendor's customers, demonstrated that the relevant risk universe extends beyond direct vendors to the vendors of vendors: the fourth-party relationships that the organisation has no direct visibility into and typically no contractual relationship with.
Fourth-party risk manifests when a critical vendor depends on a sub-vendor for a component or service that, if compromised, would affect the vendor's products or services in ways that cascade to the vendor's customers. The log4j vulnerability in late 2021 illustrated this comprehensively: organisations discovered that they were vulnerable to a critical library not through their own code, but because software they used internally had a dependency on a library that contained the vulnerability, sometimes several layers deep in their software dependency tree.
Mapping fourth-party dependencies requires understanding not just what a vendor provides but how they build and operate what they provide. Vendor questionnaires that ask about direct suppliers address only one layer of this problem; understanding the critical infrastructure components, software libraries, and sub-contracted services that underpin a vendor's own operations requires deeper engagement, including reviewing software bills of materials (SBOMs) when available, asking specifically about critical sub-dependencies during vendor assessments, and subscribing to the vendor's security communication channels so that their own third-party incidents that affect their service are communicated promptly. The supply chain intelligence dimension, monitoring dark web sources for discussions about vendors' own security posture and for incident disclosures that vendors have not yet made public, adds an external perspective on fourth-party risk that complements the structured questionnaire approach. Defendis tracks threat actor discussions about your critical vendors on dark web sources, providing early warning when a vendor is under attack before they formally notify their customers.
An SBOM is a formal, structured list of all components in a piece of software, including open-source libraries, commercial components, and their transitive dependencies. When a new vulnerability is discovered in an open-source component, organisations with SBOMs for their software can quickly query their SBOM repository to identify all applications that include the vulnerable component, enabling targeted remediation. Without SBOMs, identifying all affected applications requires manual investigation that can take days or weeks. US Executive Order 14028 (2021) mandated that federal agencies require SBOMs from software vendors, which has driven broader SBOM adoption in the software industry.
Vendor prioritisation for security assessments should be based on the combination of data access and criticality. Vendors who have access to sensitive data, privileged access to internal systems, or whose software runs in critical infrastructure warrant annual or more frequent assessments. Vendors who provide non-critical services without sensitive data access can be assessed less frequently or through lighter-touch questionnaire processes. Tier 1 vendors (critical access, sensitive data) should receive on-site assessments or detailed technical audits; Tier 2 vendors receive detailed questionnaires with evidence requirements; Tier 3 vendors receive simplified questionnaires. This tiering ensures that limited security team bandwidth is focused where the risk is highest.
In a direct cyberattack, the attacker targets the victim organisation's own systems and infrastructure. In a supply chain attack, the attacker compromises a vendor, supplier, or partner that the victim organisation trusts, then uses that trusted relationship to gain access to or affect the victim's systems. Supply chain attacks are often more effective than direct attacks against well-defended organisations because the trust relationship between the victim and its vendors provides an entry path that the victim's perimeter defences do not specifically block. The most damaging supply chain attacks compromise software update mechanisms, allowing attackers to deliver malicious code to all customers of the compromised vendor simultaneously.
The most frequently exploited supply chain vectors include: software update mechanisms (SolarWinds, 3CX); open-source dependency injection (typosquatting on package managers like npm and PyPI); compromise of CI/CD pipelines that build and sign software artefacts; exploitation of managed service providers who have privileged access to multiple customer environments; and credential theft from vendor employees who have access to customer systems. Monitoring for these specific attack patterns in vendor security assessments and in threat intelligence about active supply chain campaigns provides the targeted intelligence needed to prioritise defences against the most active and highest-impact vectors.
Supply chain risk has moved from a technical concern managed by IT security teams to a board-level governance topic in many organisations, driven partly by high-profile incidents like SolarWinds and partly by regulatory requirements (NIS2 in Europe, for example, explicitly requires organisations to assess the cybersecurity of their supply chains). Communicating supply chain risk effectively to board audiences requires translating technical findings into business impact terms that connect to the organisation's strategic risk appetite.
The most effective board-level supply chain risk communications focus on three questions. First, which vendors represent the highest risk if compromised? (Tier 1 vendors with privileged access or sensitive data create the greatest potential impact.) Second, what would the business impact be if each Tier 1 vendor were compromised? (Expressing this in terms of operational disruption, regulatory exposure, and reputational consequence makes the risk concrete.) Third, what controls do we have in place and what gaps remain? (Connecting the risk assessment to specific investment decisions makes the governance function of the board relevant to the operational risk discussion.)
Quantifying supply chain risk for board reporting is challenging because the probability component, the likelihood that any specific vendor will be compromised in a given period, is difficult to estimate with precision. Approaches that use the vendor's cybersecurity posture assessment score as a proxy for compromise probability, combined with the business impact assessment for each vendor, create a risk matrix that can prioritise remediation investments and third-party risk management programme development. Supplementing this internal assessment with external intelligence about threat actors targeting your vendors adds a threat-driven dimension to what might otherwise be a purely compliance-driven exercise, connecting supply chain risk management to the real-world threat landscape that the board needs to understand.
The open source software dependency chain represents a supply chain risk dimension that differs from traditional vendor risk management. When an organisation uses open source components, it has no contractual relationship with the maintainers of those components, no SLAs covering security patching, and often no visibility into when critical updates are released without active monitoring of the component's repository or vulnerability database. Yet the open source components in a typical enterprise application can represent the majority of the codebase by volume, including some of the most security-sensitive components like cryptographic libraries, authentication frameworks, and network communication stacks.
The log4j incident in December 2021 demonstrated the scale of this risk: a critical vulnerability in a widely used Java logging library required emergency patching efforts across virtually every technology organisation globally, with many discovering that they had indirect dependencies on the vulnerable library through other components they had not specifically chosen to use. Establishing the practice of generating and maintaining SBOMs for all significant applications gives organisations the inventory data needed to respond quickly to similar incidents in future, transforming what was a multi-week discovery process during log4j into a same-day query against a maintained component database.
Monitoring open source component vulnerability databases, particularly the GitHub Advisory Database and OSV (Open Source Vulnerabilities), for vulnerabilities in components present in the organisation's applications provides early warning of open source supply chain risks before they appear in commercial vulnerability databases. Connecting this component-level monitoring with external attack surface visibility creates a joined-up picture of open source dependency risk across the organisation's portfolio.
Underground forums and criminal marketplaces reveal threat actor capabilities, active campaigns, and stolen data before attacks reach their targets. Defendis monitors criminal forums, marketplaces, and supply chain intelligence sources continuously, alerting your organisation when your name, data, infrastructure, or vendor relationships appear in criminal discussions. When a threat actor announces targeting of your sector, or when data associated with your supply chain appears in a criminal forum listing, Defendis surfaces the intelligence with enough context to act before the attack materialises.
Request a demo to see how Defendis surfaces underground forum intelligence and supply chain exposure relevant to your organisation.
