What is a software supply chain?
Every modern web application is built on layers of third-party components — web servers, CMS platforms, JavaScript frameworks, analytics services, payment processors, CDN providers, and cloud infrastructure. Together, these form your software supply chain: the full set of external vendors and open-source projects your service depends on to function.
A supply chain vulnerability occurs when one of those third-party components contains a security flaw. Because your application inherits the risk of every dependency it uses, a single compromised library or an outdated CMS plugin can expose your entire service — even if your own code is perfectly secure.
High-profile examples include the Log4Shell vulnerability in the Java logging library Log4j, backdoored npm packages distributed through typosquatting, and the credential-harvesting code injected into the Python package litellm. In each case, organizations that had no idea they were running the affected component were caught off guard.
Why this matters for European companies
The EU has introduced two regulatory frameworks that make supply chain visibility a compliance obligation, not just a best practice:
Cyber Resilience Act (CRA) — Requires manufacturers and distributors of products with digital elements to maintain secure development practices across their entire supply chain. If your web application ships with a known-vulnerable component, you may be held liable.
NIS2 Directive — Requires entities in critical and important sectors to implement supply chain security measures, including assessing the security of direct suppliers and service providers. Covered organizations must be able to demonstrate that they understand and manage the risks introduced by third-party dependencies.
For Swedish SMBs selling to enterprise clients or operating in regulated sectors, the ability to show a current inventory of your third-party vendors — and evidence that you monitor them for vulnerabilities — is increasingly becoming a prerequisite for doing business.
How ExposureIndex discovers your vendors
During every scan cycle, ExposureIndex performs passive fingerprinting of your externally visible services. This is a non-intrusive process — we never log in, install agents, or access internal systems. Instead, we analyze what your infrastructure reveals to any visitor on the public internet:
HTTP response headers — Server banners (Server: nginx/1.24.0), technology markers (X-Powered-By: PHP/8.2), and CDN identifiers (CF-RAY, X-Fastly-Request-ID) reveal your web server, application runtime, and content delivery provider.
HTML and resource analysis — Meta generator tags (<meta name="generator" content="WordPress 6.5">), known JavaScript library paths, and CSS framework fingerprints identify your CMS, frontend frameworks, and third-party scripts.
DNS and email infrastructure — MX records reveal your email provider (Google Workspace, Microsoft 365, etc.), SPF includes expose authorized sending services (Brevo, Mailchimp, SendGrid), and CNAME records can point to SaaS platforms like HubSpot, Shopify, or Heroku.
TLS certificate details — Certificate issuer, subject alternative names, and chain structure can indicate hosting providers and CDN services.
WAF and proxy detection — Specific header patterns and response behaviors fingerprint web application firewalls and reverse proxy services (Cloudflare, Akamai, Imperva, Fastly, F5).
The result is a vendor inventory built entirely from what your services already broadcast — no access credentials required.
How ExposureIndex checks for supply chain vulnerabilities
Once we have identified the third-party components and their versions, we cross-reference them against known vulnerability databases:
CVE matching — Detected software versions are checked against the National Vulnerability Database (NVD) and vendor-specific security advisories. A WordPress 6.4.2 installation, for example, would be flagged if a critical CVE affects that version.
End-of-life detection — Components running versions that no longer receive security patches are flagged even if no specific CVE exists yet. An unsupported PHP branch or a deprecated CMS version is a supply chain risk by definition.
Nuclei-based DAST scanning — Our vulnerability scanner uses regularly updated detection templates that include checks for known CVEs in popular frameworks, plugins, and server software. When a scan finds a vulnerable component, the finding is linked to the specific CVE and rated by severity.
Findings are included in your ExposureIndex report with plain-language explanations and prioritized remediation steps — update the component, apply a vendor patch, or replace a dependency that is no longer maintained.
What to do
Keep an inventory
You cannot protect what you do not know about. Maintain a list of every third-party service, library, and platform your application depends on. ExposureIndex builds this inventory automatically from the outside — but your internal dependency manifests (e.g. package.json, requirements.txt, composer.json) should be tracked as well.
Update promptly
When a vendor publishes a security update, apply it as soon as possible. Subscribe to security mailing lists for your key dependencies. Enable automatic security updates where your platform supports it.
Reduce your surface
Every dependency is an additional risk. Remove unused plugins, decommission services you no longer need, and consolidate vendors where possible. Fewer moving parts means fewer things that can break.
Monitor continuously
Annual penetration tests do not catch the vulnerability disclosed last Tuesday. Continuous monitoring ensures that newly published CVEs affecting your stack are detected within your next scan cycle, not months later.
Supply chain visibility by plan
Not all ExposureIndex plans include the same level of supply chain insight:
| Capability | Starter | Growth | Pro |
|---|---|---|---|
| Infrastructure fingerprinting (web server, WAF) | Basic | Full | Full |
| Third-party vendor inventory | — | ✔ Complete list of all discovered vendors | ✔ Complete list of all discovered vendors |
| Supply chain vulnerability monitoring | — | — | ✔ Continuous CVE monitoring with alerts |
| Remediation guidance for vendor risks | — | — | ✔ Prioritized, version-specific guidance |
Starter focuses on core exposure metrics — email security, security headers, and basic infrastructure checks. Supply chain details are not included.
Growth adds a complete inventory of all third-party vendors and technologies discovered during scanning. You see exactly which CMS, server software, JavaScript frameworks, email providers, CDN services, and WAFs are part of your external footprint.
Pro extends this with active vulnerability monitoring across your entire vendor inventory. When a CVE is published that affects a component we have detected in your infrastructure, it appears in your next report with severity rating and remediation steps — giving you the evidence trail that NIS2 and CRA compliance requires.
Last updated: April 4, 2026