Back in December 2020, the world discovered that SolarWinds, the IT monitoring software used by thousands of companies, had been compromised at the source: attackers had inserted a backdoor directly into software updates, which were then distributed to approximately 18,000 customers.
A year later, it was Log4Shell's turn. A critical vulnerability in Log4j, a logging library used practically everywhere (from Apple to major banking groups' software), made it possible to execute code remotely on millions of servers using a text string. Around the same time, the attack on Kaseya, an IT management software provider used by MSPs, exploited its own update mechanism to distribute ransomware across the supply chain, hitting up to 1,500 end-customer organizations in a single attack.
The list of examples could go on. The common denominator in all these incidents is that none of them directly targeted the ultimate victim. Instead, they all exploited the trust companies place in their software providers, as well as in the third-party libraries and tools that make up their software.
This is where the concept of the software supply chain comes in and, above all, why this specific supply chain needs to be protected. Let's take a closer look.
Key Points
- Software security does not depend solely on internally written code, but also on the entire open-source and third-party ecosystem surrounding it.
- Recent, large-scale attacks have targeted trusted software components rather than the core of the application itself. SolarWinds, Log4Shell, and Kaseya are just a few examples.
- Software supply chain security is a regulatory requirement, and robust frameworks are available to help organizations build software resilience.
Modern software is the sum of many components
Modern applications, including those developed in-house by organizations, are rarely written from scratch. Instead, they are built by integrating proprietary and third-party components, orchestrated through automated pipelines that build, test, and release applications, sometimes several times a day. This approach addresses a genuine structural and market need, as the pace at which libraries, frameworks, and application requirements evolve makes fully proprietary development unsustainable.
Compared with traditional physical supply chains, software supply chains are far more dynamic: new dependencies are introduced into code every day, pipelines are updated automatically, and releases follow one another at a continuous pace.
The components that make up a software supply chain are numerous and naturally interconnected:
- Proprietary code, developed internally by teams;
- Open-source libraries and packages, which account for a substantial portion of a modern application's codebase;
- Containers and their dependencies;
- Third-party plugins and binaries that extend functionality without requiring it to be developed from scratch;
- Build tools, including compilers, assemblers, and static code analyzers;
- CI/CD pipelines, which automate builds, testing, and deployment;
- Repositories that store and distribute source code and packages;
- Cloud infrastructure and APIs, on which applications run and through which they communicate.
To make the picture even more complex, software consists of more than code, libraries, infrastructure, and tools: it also involves people and processes. These include DevOps teams, developers, and external suppliers who build parts of the code or entire features for complex proprietary applications. Taken together, all these elements form the intricate software supply chain.
Software supply chain risks: from dependencies to CI/CD pipelines
The complexity of modern software is not a problem in itself, but it becomes one when vulnerabilities are introduced outside the application's core code.
The more organizations accelerate development, the more they rely on automation, libraries, and external suppliers, exponentially increasing their exposure to risk. The following examples represent only a small part of the broader picture.
-
Open source dependencies
A large company may use thousands of open-source dependencies in its software, often with only partial oversight of each one. Every imported library brings its own dependencies, in turn creating component trees that are too extensive to verify manually. A single compromised library can spread to every application that includes it, as demonstrated by the incidents mentioned above. - Infrastructure vulnerabilities
The servers, virtual machines, storage systems, and networks on which software runs are exposed to configuration errors. Human error is almost always at the root of the problem, but the complexity of cloud tools and the speed of automated provisioning amplify the issue, potentially replicating it across multiple environments before anyone notices. -
CI/CD pipeline exposure
A CI/CD pipeline is not a product in itself, but a process orchestrated by tools such as GitHub Actions, Jenkins, or GitLab CI. This makes it a high-value target because it has access to source code and deployment keys. If an attacker manages to infiltrate it, they can directly modify the process on which the application's entire build and delivery infrastructure depends, compromising everything that comes out of it. - Secret and credential leakage
API keys, tokens, and passwords can accidentally end up in repositories, logs, or configuration files, providing direct access to production systems.
AI and the software supply chain: new components, new risks
AI-related risks are more recent than the others, but no less significant. They therefore deserve separate consideration, distinguishing between two areas.
- AI Models as supply chain components
Thousands of AI models emerge every month and can be integrated into applications by companies and vendors. As might be expected, security researchers have reported a significant increase in malicious or insecure models distributed through major channels.
- AI coding assistants
Almost all companies use coding assistance systems, but these can suggest dependencies that do not exist or are no longer up to date from a security perspective. Anyone developing software with AI assistance should verify every suggested dependency before integrating it.
So, what is a software supply chain attack?
Taken together, all the risks mentioned above (and many others) reveal a clear pattern. A software supply chain attack does not directly target the final application, but rather one of the trusted components used to build it.
The goal is not to break through the defenses of a single target, but to infiltrate an upstream link that everyone trusts and let the supply chain itself propagate the damage downstream.
Software supply chain security: a matter of compliance, too
Until a few years ago, software supply chain security was a matter of voluntary best practices. That is no longer the case: laws and regulations have begun turning it into a legal obligation, often with tangible penalties for non-compliance.
- In Europe, the key reference is the Cyber Resilience Act (CRA), which imposes cybersecurity requirements on products with digital elements sold on the EU market. Among its technical requirements, the CRA makes the SBOM (Software Bill of Materials) mandatory: manufacturers must prepare and maintain an up-to-date, machine-readable list of at least their software's first-level dependencies and provide it to the authorities upon request.
- The AI Act complements this framework by introducing specific obligations for artificial intelligence systems based on their risk level. In light of the role of AI models as software supply chain components, this regulation is increasingly intersecting with the issue of supply chain security.
Alongside regulatory obligations, frameworks have emerged that define minimum controls and shared standards for the entire industry. These include:
- NIST SSDF (Secure Software Development Framework): A set of practices for integrating security into every stage of the software development lifecycle.
- SLSA (Supply-chain Levels for Software Artifacts): Defines progressive levels of integrity for the build process. The higher the level, the lower the likelihood that an artifact will be tampered with along the supply chain.
- OpenSSF (Open Source Security Foundation): Promotes various projects and tools to improve security across the open-source ecosystem.
Software supply chain security: where to start
There is no single tool that can solve software supply chain security or make an organization compliant with binding frameworks and regulations. An effective approach works across multiple levels simultaneously, starting with what is most often missing today: visibility.
An effective roadmap could look like this.
-
Map all the dependencies with an SBOM
Generating and maintaining an up-to-date Software Bill of Materials makes it possible to determine whether and where a compromised component is being used when a vulnerability is discovered, without having to find out in the middle of an active incident. - Continuously scan code and dependencies
Software Composition Analysis (SCA) tools and Static Application Security Testing (SAST) tools, integrated directly into pipelines, make it possible to detect vulnerable or malicious libraries before they reach production. - Prioritize based on impact
Automated scans can generate hundreds of alerts, but they do not all carry the same weight. Organizations need to assess which components are reachable by an attacker and which handle sensitive data or critical processes, so that prevention efforts can be focused where they matter most. - Secure the CI/CD pipeline
Least-privilege access, configuration validation, and logs and audit trails for every change to the build and deployment process are essential to prevent unwanted surprises. - Manage secrets and credentials effectively
Dedicated vaults, regular rotation, and no hardcoded credentials in code or configuration files. These are simple principles, yet they are still overlooked in many cases. - Assess the security of suppliers and third-parties
Trusting a supplier simply because it is well established in the market is not enough. Vendors must conduct and provide regular assessments, allow security requirements to be included in contracts, and, where possible, provide visibility into their development practices. - Align with recognized frameworks
Adopting practices consistent with NIST SSDF or SLSA is not just a matter of compliance. It means applying controls that have already been designed, tested, and adopted across the industry, rather than reinventing them from scratch.
At Kirey, software security is an absolute priority
At Kirey, we have been developing and implementing software for years, primarily in highly regulated industries and organizations, where security is not an option but a fundamental requirement from the outset.
We fully understand that the security of an IT system starts with its software, but we also recognize that it does not depend solely on proprietary code. It relies on an entire ecosystem of stakeholders, tools, and processes that must be continuously monitored, assessed, and tested.
That is why we adopt secure development practices that extend across the entire supply chain ecosystem, providing our clients not only with assurances of performance and innovation, but also with long-term stability and resilience.
Contact us to discover how to innovate your business securely and sustainably.
