Open source software (OSS) is the silent, invisible engine driving today’s digital economy. From banking systems to medical applications to the dashboard in your car, its code is everywhere. The scale of this dependency is difficult to overstate. Synopsys’ Open Source Security and Risk Analysis (OSSRA) report for 2024 showed that 96% of commercial applications contain open source components, and that on average 77% of all code in these applications comes from open source. In Poland, according to data from the end of 2023, open source software was identified on more than 670,000 websites, ranking our country 13th in the world in terms of its use.
This ubiquity has given rise to a fundamental paradox. On the one hand, OSS is an unparalleled accelerator of innovation, allowing companies to build and deploy advanced technologies faster than ever. On the other hand, it has become the largest, often ignored, attack surface for modern businesses. This dichotomy is brutally exposed by the data: in 2023, as many as 74% of the code bases examined contained high-risk security vulnerabilities. This is a dramatic increase of 54% from the previous year, when the percentage was 48%.
The problem not only exists, but is dynamically worsening, spiralling out of control. Organisations are consuming open source software at a rate that far exceeds their ability to manage the associated risks, leading to a tacit acceptance of huge and growing levels of risk.
Hidden dangers in your code
Understanding today’s OSS threats requires deconstructing the problem into several key, often interrelated categories.
1. ‘Zombie code’ and security debt
One of the most fundamental risks is the reliance on old, out-of-date and often abandoned components by authors. The 2024 Synopsys report bluntly describes this condition as a ‘zombie code apocalypse’. The scale of the problem is alarming:
- 91% of the code bases analysed contained components that were outdated by 10 or more versions.
- 49% of the code base contained components where no development activity had been recorded for more than two years.
These omissions create a so-called ‘security debt’ – a concept popularised in Veracode’s ‘State of Software Security 2024’ report. Each unpatched vulnerability is like a loan taken out, which builds up over time, generating ‘interest’ in the form of increasing risk. To make matters worse, it takes 50% more time to fix vulnerabilities in third-party code (mainly OSS) than in proprietary code, showing how difficult it is to manage this type of debt.
2 The trap of transitive dependencies
The problem of code obsolescence is compounded by the existence of transitive (indirect) dependencies. These are libraries that the project does not use directly, but are required by direct dependencies. They represent ‘hidden’ code that finds its way into the application, often without the knowledge and verification of the development teams.
It is in this hidden layer that the greatest danger lurks. Transitive dependencies can make up as much as 80-90% of all application code , and it is estimated that as much as 95% of all vulnerabilities in open source software come from these intermediate dependencies. A textbook example is the Log4Shell vulnerability in the Log4j library. Many organisations had no idea they were using it at all until the global security crisis hit. Even three years after it was discovered, 13% of all Log4j library downloads are still vulnerable versions.
3. active sabotage: attacks on the supply chain
In recent years, the threat landscape has undergone a fundamental transformation – from passive vulnerabilities to actively hostile actions. Attackers have realised that compromising one popular component allows thousands of organisations to be hit simultaneously. The figures from the Sonatype report for 2024 are alarming: there has been a 156% year-on-year increase in the number of malicious packages. These attacks take a variety of forms:
- Typosquatting: Publishing a malicious package with a name confusingly similar to a popular one (e.g. crossenv instead of cross-env), hoping that a developer will install it by mistake.
- Dependency Confusion: publication in a public repository of a malicious package with a name identical to the company’s internal private package, but with a higher version number. The build system can ‘confuse’ the sources and download the public version, as happened in the attack on the PyTorch framework, among others.
- Account takeover and code injection: The most sophisticated method, of which the incident with the event-stream package was a frightening example. The attacker first gained the trust of the author and, after taking over privileges, added a new malicious transitive (flatmap-stream) dependency to the project with the aim of stealing private keys from bitcoin wallets.
Why do we lose? Systemic failures in organisations
The scale and persistence of these risks are largely the result of deep-seated cultural and process issues within the organisation.
Firstly, there is a culture of complacency and lack of strategy. The Sonatype report speaks of ‘developer overconfidence’. As many as 80% of dependencies in applications remain un-updated for more than a year, even though there is already an available, secure version for 95% of them. This means that almost all risk is avoidable. This state of affairs is due to the lack of a formal framework – only 47% of IT companies have a defined strategy for using open solutions.
Secondly, we are seeing an immaturity of security processes and tools. The 2024 Snyk report reveals a worrying trend: despite growing threats, investment in defence mechanisms is declining. There has been an 11.3 per cent decline in the adoption of security tools. Key technologies such as Software Composition Analysis (SCA) and Static Application Security Testing (SAST) are used by just over 60% of organisations, and container scanning by just 35%.
Finally, the idea of ‘shift left’, i.e. moving security to the early stages of the development cycle, remains largely an illusion. Security tools are most often integrated into build systems (around 65%), but only 40% of organisations have implemented them where they are most effective – directly in the developer’s integrated development environment (IDE). This means that control gates are being moved, rather than the actual responsibility for security. The result? Overstretched security teams, half of whom admit that they are unable to meet their goals, and 52% of companies regularly fail to meet their own SLAs for fixing critical vulnerabilities.
The road to cyber resilience: A 3-step defence model
Mitigating such complex risks requires moving away from reactive measures to implementing a comprehensive, strategic management model.
Step 1: Achieve full visibility with SBOM
A fundamental principle of security is that ‘you cannot protect something you do not know exists’. In the context of software, the tool that provides this visibility is the Software Bill of Materials (SBOM). This is a formalised, machine-readable inventory of all the components – including transitive dependencies – that make up an application. Having an accurate SBOM is becoming a global standard, driven by regulations such as the
US Executive Order 14028 and the EU Cyber Resilience Act (CRA), which make supply chain transparency a condition for market access.
Step 2: Automate protection with SCA
Visibility alone is not enough. A list of thousands of components is just raw data. To turn it into useful knowledge, Software Composition Analysis (SCA) is needed. SCA is an automated process that analyses SBOM for risk: it scans components for known vulnerabilities (CVEs), verifies licence compliance and assesses the overall quality of dependencies. Modern SCA tools not only find problems, but also help prioritise them and often offer automated remediation suggestions.
Step 3: Build a DevSecOps culture
Technology is essential, but it is not enough without a cultural change. DevSecOps is an evolution of the DevOps philosophy that integrates security as a shared responsibility at every stage of the software development lifecycle. Rather than seeing security as an isolated assembly at the end of the process, it is ’embedded’ from the very beginning. In practice, this means integrating SCA tools directly into the developer’s IDE, automatic scanning in the CI/CD pipeline and continuous monitoring of the application in the production environment. This is a real ‘shift of responsibility to the left’ that gives developers the tools and knowledge to make safe decisions.
From risk to advantage
The open source landscape is full of contradictions. We are witnessing an explosion of risk, driven by the ubiquity of OSS and systemic mismanagement. However, this alarming picture need not lead to paralysis. The path to cyber resilience is well defined and leads through the implementation of an integrated defence model based on visibility (SBOM), automated intelligence (SCA) and a culture of shared responsibility (DevSecOps). In the new reality defined by advanced threats and increasing regulatory requirements, proactive risk management in the software supply chain is no longer just a technical responsibility. It is becoming a key element of business strategy. Organisations that master this area will not only avoid disaster, but gain the ability to innovate faster and more securely, transforming the biggest source of risk into a sustainable competitive advantage.
