Our recent trade fair appearances made one thing very clear once again: cybersecurity as a whole—and Identity and Access Management (IAM) as a crucial part of it—continues to gain importance. But no company should let that trigger a sigh of relief just yet. Because one major attack vector still revealed significant knowledge gaps: the software supply chain.

Why hack a single company when you can infect an open-source component that ends up in thousands of software packages with far less effort? Welcome to the reality of modern software development.

If that gives you pause, then yes—open source is widely celebrated, and for good reason. Anyone willing to take a closer look can inspect publicly available source code for vulnerabilities and, if they have the skills, fix them. But of course, they can also exploit them.

Software rarely comes from a single vendor anymore. Today, it is more like a construction kit: bits and pieces assembled from in-house developments, open-source components, and code fragments from service providers around the world. That approach can create a massive problem: if one open-source library is compromised, hundreds of products can suddenly contain vulnerabilities. The consequences often only become apparent when it is already too late. One reason is that organizations frequently neglect the painstaking task of reviewing source code themselves—or assume that “other users” will take care of it.

Today, many companies have little idea what is actually inside the software they use. Origin, version, internal dependencies on open-source libraries? Unknown. Documentation? Missing. Control? Minimal. Worse still, some decision-makers are not even fully aware that security risks in the software supply chain exist in the first place.

That makes it all the more encouraging that regulators are stepping in with obligations and security requirements. And this is important to keep in mind: even where the wording is more general, these rules also apply to the software supply chain. A brief overview:

NIS2 Directive (Network and Information Security)

• Risk assessment obligation: Companies must regularly assess the security practices of their suppliers and service providers and take appropriate steps to ensure supply chain security.
  
• Board responsibility: Company leadership is required to oversee and approve cybersecurity measures and to receive corresponding training.
  
• Board responsibility: Company leadership is required to oversee and approve cybersecurity measures and to receive corresponding training.
  

Digital Operational Resilience Act (DORA):

• Requirements for financial entities: DORA requires financial institutions to ensure resilience against all types of ICT-related disruptions and threats.
  
• Third-party risk: A key focus lies on identifying and managing risks stemming from third parties, especially within the software supply chain.
  
• Vulnerability reporting obligations: DORA imposes extensive reporting requirements for serious security incidents, comparable to those under NIS2.

KRITIS Umbrella Act

• Supply chain risk management: Under KRITIS as well, deployed IT components and service providers must be assessed with regard to their security practices—especially in terms of origin, operation, and control.
  
• Audit and evidence obligations: Security measures must not only be implemented, but also demonstrated through audits and supporting evidence. This also applies to software products in use.
  
• Obligation to provide security updates: Systems must be continuously updated and patched, especially when they perform security-critical functions.
  

The Cyber Resilience Act (CRA) is the only framework that explicitly requires an SBOM (Software Bill of Materials)—more on that below. This also has far-reaching implications for companies outside the IT sector.

Cyber Resilience Act (CRA):

• Security requirements for products: The CRA defines binding cybersecurity requirements for products with digital elements, including software and connected hardware.
  
• Obligation to provide security updates: Manufacturers must ensure that their products remain protected throughout their entire lifecycle. This includes the provision of security updates.
  
• Conformity assessment: Products are classified according to criticality, with each class subject to different requirements for security assessment and certification.
  

These points are only excerpts. The graphic shows what else is required and where the frameworks overlap or differ (✅ already required, ⭕ not required / possibly planned).

There are different ways to implement these requirements. But one thing should not be missing: a Software Bill of Materials (SBOM)—and not just for CRA compliance. An SBOM is a structured list of all components, libraries, and dependencies contained in a software application. If organizations maintain their SBOMs diligently, the first benefit is transparency.

But decision-makers should dig deeper in the next step. Real-world attacks show us every day that exploited vulnerabilities in software cannot always be uncovered with conventional analysis alone—just think of the SolarWinds incident, which involved an unfortunate combination of vulnerabilities and human error at the service provider. If a threat or risk has not been identified and cataloged, it becomes very difficult to implement the right countermeasures.

And because source code is often unavailable in purchased software, the focus must shift to analyzing the delivered binaries. Binary analysis examines executable files in order to uncover tampering, hidden malware, or undocumented changes. This is particularly important because not all vendors provide a clear overview of the libraries used through metadata alone.

A truly comprehensive software supply chain security strategy therefore relies on a combination of SBOM and binary analysis:

• Transparency: SBOMs provide a clear overview of all components in use.
• Depth of analysis: Binary analysis uncovers hidden risks that are not visible in metadata.
• Fast response: When new vulnerabilities become known, affected components can be identified and updated quickly.

If this article has convinced you to take software supply chain security seriously, and if you would like to explore solutions such as those offered by our partner ReversingLabs in more depth, then your cybersecurity strategy should not focus only on identity security. It should also include software supply chain security. That way, companies can close a wide range of security gaps and move decisively toward compliance.