The Weakest Link in Security Is No Longer in Your Company — It's Your Supplier

TL;DR:
Problem: Attackers are increasingly targeting suppliers rather than corporations directly. A single compromised supplier can provide access to dozens of organizations (a notable example is SolarWinds).
Why an audit is not enough: An ISO/IEC 27001 certificate or a completed security questionnaire does not prove real resilience. A secure software release is worthless if the development process itself has been compromised.
What to do about it: Require practical evidence of security, such as penetration testing, red teaming, secure CI/CD practices, Secure SDLC, and a transparent SBOM.
Regulation: NIS2 and the Cyber Resilience Act are already shifting responsibility for supply chain security directly onto management.

Digitalization in Europe is bringing with it an unprecedented level of interconnectedness between organizations, their suppliers, and technology partners. Supply chains play a critical role not only in manufacturing and the automotive industry, but also in sectors such as IT, telecommunications, energy, and other areas of critical infrastructure. This interconnectedness creates new opportunities for attackers, who are increasingly targeting suppliers rather than corporations directly. In this article, we examine why audits or supplier certifications alone are no longer sufficient to objectively assess resilience, and how new European regulatory requirements are reshaping the approach to cybersecurity across the entire supply chain ecosystem.

Suppliers as the Entry Point

While large enterprises often invest millions of euros in protecting their perimeter, infrastructure, and employee awareness, attackers frequently choose the path of least resistance. Instead of targeting corporations directly, they focus on smaller suppliers or service providers through whom they can gain access to their ultimate targets much more easily. A well-known example is the SolarWinds incident, in which attackers compromised the software development and update process, allowing malicious code from a software supplier to reach thousands of organizations, including government agencies and major corporations.

New Trends

Companies themselves are responding to the growing risks associated with supply chains. One major driver is stricter regulation, such as the NIS2 Directive and the Cyber Resilience Act. The NIS2 Directive expands the scope of regulated entities, introduces stricter requirements for managing cybersecurity risks—including supply chain security—and significantly increases management accountability for cybersecurity within organizations.

Growing interest in supplier security is also driven by the increasing number of security incidents. Organizations are no longer satisfied with completed security questionnaires or ISO/IEC 27001 audits alone. Instead, they increasingly require tangible proof of technical resilience, such as penetration testing of applications or IT solutions before procurement.

Citadelo has observed this trend firsthand. While the financial sector led demand for penetration testing in 2024, our Ethical Hacking Report 2025 shows that software development companies (software houses) became the second most frequently tested segment, accounting for 11% of all projects. Organizations are also recognizing that people remain the most vulnerable link in security, as evidenced by the growing demand for simulated phishing and vishing exercises designed to assess employee readiness for real-world threats.

Methods for Verifying Supplier Security

As a result, more organizations are complementing traditional penetration testing with advanced resilience assessment techniques such as red teaming, which simulates the behavior of a real attacker across both technical and organizational layers.

Red team engagements often include social engineering activities such as phishing and vishing campaigns to evaluate how employees respond to real attack scenarios. The combination of technical testing and human-factor assessment provides a far more realistic view of a supplier's actual cybersecurity posture.

At Citadelo, we have observed a growing trend among organizations to require these practical demonstrations of security resilience rather than relying solely on formal audit compliance.

AI Services as Part of the Supply Chain Ecosystem

As the adoption of artificial intelligence and large language models (LLMs) continues to grow, AI security is becoming an increasingly important concern. Organizations are beginning to address not only the security of their own applications but also the risks associated with external AI providers. Consequently, penetration testing of AI systems and chatbots is gradually becoming a standard part of security assessments for modern applications.

Recent restrictions imposed by Anthropic on access to selected AI models for European users have also highlighted another important issue: dependence on a single AI provider can create significant operational and supply chain risks.

Software Security Starts in the Development Process

Despite the growing interest in software security testing, we continue to see significant room for improvement in software development security practices, particularly in the implementation of Secure SDLC principles and the protection of CI/CD pipelines.

Ultimately, it does not matter how secure a specific software version appears during testing if the supplier fails to secure the development process itself. Risks associated with insider threats, dependency confusion attacks involving third-party packages, or even malicious extensions within developer environments can all lead to the compromise of the final application.

As a result, a newly compromised version of an application could be deployed to customers immediately after a successful penetration test.

Security Must Be Embedded Throughout the Entire SDLC

Security can no longer be assessed solely through the final application. It must be integrated into the entire Software Development Life Cycle (SDLC).

Security begins with architecture design and continues through source code management, access control, build processes, testing, and deployment. Essential controls include protected branches in source code repositories, code reviews, access management, and automated security testing such as SAST, DAST, and dependency scanning.

Transparency regarding the libraries and packages used in software development is equally important. One effective way to achieve this is through a Software Bill of Materials (SBOM), which provides visibility into all software components and dependencies.

Only by combining these and many other security measures can organizations ensure that security is not limited to the final software product but is embedded throughout the entire lifecycle—from development to deployment and ongoing updates.

A Strategic Perspective on Supply Chain Security

Supply chain security has long since expanded beyond the scope of IT security and has become a strategic business risk. In today's interconnected IT environment, investing solely in the protection of your own infrastructure is no longer sufficient. Organizations must systematically manage risks across their entire supplier ecosystem and evaluate the actual security posture—not just the declared level of security—of the partners on whom their internal processes and operations depend.