Supply Chain Security: Managing Third-Party Risks
Key Takeaways
- The SolarWinds attack demonstrated that the software supply chain is a preferred attack vector — attacks via compromised open-source packages and build pipelines continue to increase
- An ISO 27001 certificate from a service provider says little about how secure the specific integration into your environment is — concrete questions about permissions, data flows, and compromise scenarios are more relevant
- Software Bill of Materials (SBOM) provide transparency about which components your software contains and what known vulnerabilities they carry
- Not all dependencies carry the same risk: an identity provider that controls access to all company systems is fundamentally different from a date-formatting library — risk classification is required
- Supply chain security is not a one-time task — a quarterly review cycle for critical dependencies is the minimum acceptable cadence
The SolarWinds attack in 2020 demonstrated to a broad audience what security professionals had long known: the software supply chain is a preferred attack vector. Since then, the threat landscape has not eased — quite the opposite. Attacks via compromised open-source packages, manipulated build pipelines, and insecure third-party integrations continue to increase.
For organisations that use cloud services, deploy SaaS applications, and build on open-source libraries, the question is not whether but how they manage their supply chain risks.
Why traditional approaches fall short
Many organisations rely on questionnaires and certifications when assessing third parties. An ISO 27001 certificate from a service provider is a positive signal, but it says little about how secure the specific integration into your environment actually is.
The relevant questions are more concrete: What permissions does the third-party software have in your environment? What data flows where? What happens if the vendor is compromised? How quickly would you notice?
A structured approach
1. Create an inventory
The first step is straightforward yet frequently skipped: a complete inventory of all third-party dependencies. This includes not only direct suppliers but also open-source libraries, SaaS integrations, API connections, and build tools.
Software Bill of Materials (SBOM) are a useful tool here. They provide transparency about which components your software contains and what known vulnerabilities they carry.
2. Risk assessment by criticality
Not every dependency poses the same risk. An open-source package that only handles date formatting has a different risk profile than an identity provider that controls access to all company systems.
Assess each dependency by: access privileges, data access, replaceability, and impact if compromised. Focus your measures on the most critical dependencies.
3. Implement technical controls
For software dependencies: use dependency scanning in your CI/CD pipeline, pin versions rather than pulling automatic updates, and review critical updates before deployment.
For SaaS services: restrict permissions to the minimum (least privilege), monitor API access, and define emergency processes for vendor outage or compromise scenarios.
4. Contractual safeguards
Technical controls alone are not sufficient. Your contracts with third parties should define security requirements, grant audit rights, establish notification obligations for security incidents, and include SLAs for security updates.
Continuous monitoring
Supply chain security is not a one-time task. New vulnerabilities are discovered daily, vendors change their practices, and your own dependency landscape evolves. A regular review cycle — at least quarterly for critical dependencies — is necessary.
If you would like to assess your supply chain risks in a structured manner and improve your protective measures, please get in touch.
Frequently Asked Questions
What is a Software Bill of Materials (SBOM) and do we really need one?
An SBOM is a structured inventory of all components in a piece of software — similar to a nutritional label on a food product. When a new vulnerability is disclosed (such as Log4Shell), an SBOM lets you immediately determine which of your own systems are affected. For organisations that develop or deploy custom software, an SBOM is increasingly a regulatory requirement under frameworks like DORA and NIS2.
How do I assess which third-party dependencies are critical?
Four criteria matter: access privileges of the software in your environment, access to sensitive data, replaceability (how difficult would a vendor switch be?), and impact if compromised. Dependencies that score high on multiple criteria deserve intensive monitoring and stronger contractual safeguards.
Are contractual security requirements sufficient to manage third-party risk?
Contract clauses are necessary but not sufficient. They define the framework and grant you rights such as audit access, but they cannot prevent an actual attack via a compromised vendor. Technical controls — restricted permissions, monitored API access, dependency scanning — are complementary and cannot be replaced by contractual language alone.
What should we do when one of our SaaS providers reports a security incident?
First, assess severity and scope — which data and access are affected? Second, review what permissions the provider has in your environment and consider temporarily restricting or disabling them. Third, check whether reporting obligations under GDPR or NIS2 have been triggered. A pre-defined emergency process for vendor compromises saves significant time when you need to act quickly.