Software development has greatly changed in recent years. In the past, a developer chose a programming language, used the underlying framework that came with it, and built software almost from scratch. Nowadays, developers rarely write software from scratch, as software development resembles Lego building more: The developer chooses the right building blocks or libraries, attaches them together, adds a bit of proprietary code, and wraps it all up as a single piece of software. The innovation of startups is typically based on combining different building blocks in a way no one has done before. It is estimated that between 70% and 90% of a given software is based on OSS (Open-Source Software), and average software contains more than 500 open-source libraries and components.
Current Solutions for OSS Security
Consequently, the exploitation of known vulnerabilities in OSS packages and libraries is on the rise, and every day numerous new vulnerabilities are discovered, disclosed, and published in central repositories such as MITRE CVE (Common Vulnerabilities and Exposures). This makes it much easier for hackers, who don’t necessarily need to search for a vulnerability in the proprietary code written by the developer, since most of the code is based on OSS, which has free and open lists of known vulnerabilities.
As a result, close monitoring of known vulnerabilities in existing and OSS components and frequent software updates became crucial. Unlike in the past, manual inspections and updates are almost impossible due to the huge amount of code and components. Automated products called SCA (Software Composition Analysis) emerged in the last few years to tackle this problem, including Snyk, Jfrog, Github Dependabot, and others. These products scan the lists of OSS components of software, compare them to a list of known vulnerabilities, generate alerts, and provide recommendations for updating to a specific non-vulnerable version. Alongside the SCA products, there are the SAST products (Static Application Security Testing) that scan the developer’s proprietary code for proprietary vulnerabilities.
Suddenly, the (AppSec) world looks like a happy place. Or is it?
The Problems with OSS Packages
With the large number of OSS packages, automation, and frequent software updates, two current major problems arose:
- The amount of OSS packages, vulnerabilities, and alerts is too high to cope with, and there are multiple false alarms; for example, a vulnerable package where the specific vulnerable function is never activated by the developer.
- Having many OSS components and frequent updates greatly increases the risk of malicious code being injected into a software project.
As for the first problem, the only current solution is to manually check the alerts of the SCA and SAST tools and rule out false positives. As the tools become more advanced (for example, when the SCA tool will identify and alert only when the specific vulnerable function is called) and AI will be integrated as a built-in part of the product decision-making, this problem will likely be somewhat minimized. False positives will not completely go away, but they will probably be easier to handle as their number will decrease.
The second problem, however, is harder, and there is no bulletproof solution for it. Moreover, the overwhelming number of OSS packages and new techniques used by the hackers to inject their malicious code into OSS packages makes this problem even harder to cope with.
How Attackers Inject Malicious Code
Some of the various techniques that attackers use to inject malicious code include:
- Typosquatting: malicious packages with names similar to famous packages, exploiting typos
- Dependency confusion: publishing malicious packages with the same name as internal dependencies to exploit package managers
- Malicious code in pull requests: disguising harmful changes as minor fixes)
- Compromising maintainers’ accounts: gaining access to publish malicious updates
- Various other techniques allowing injection of malicious code
It is estimated that in 2023, a whopping number of 245,000 malicious packages were seen in the wild. Moreover, frequent updates of OSS components to experimental non-stable or non-popular versions, or using non-popular packages, further increase the risk of malicious code injection. Updating software also creates a paradox, as on one hand it reduces the risk of known vulnerabilities, but on the other hand it may increase the risk of malicious code injection.
A similar example of malicious components is the recent exploding beepers and walkie-talkies in Lebanon. Hardware is often built with building blocks from various vendors much like software, and if one or more includes explosives that resemble malicious code OSS, the result is a major impact.
What’s the Solution?
So, what can be done? Is panicking the only option? Not necessarily.
The good news is that when it comes to malicious code in OSS, this is not only your problem. Numerous other software projects globally use the exact same malicious version as you, and it makes it serious enough for the OSS repository managers to take it seriously and remove the malicious versions soon after they are discovered and disclosed.
The bad news is that when a malicious package is removed by the OSS repository managers, it is done discreetly. There is no MITRE CVE equivalent central repository for deliberately malicious code injection into OSS packages, and there is a chance that your software could be compromised, and you would never know about it.
Compensating controls and monitoring solutions might reduce the potential impact of a malicious code scenario. However, professional attackers are often undetected because they stay under the radar, and many times, it might be too late. Moreover, these compensating controls might fail as they did in the recent CrowdStrike incident. That incident involved a faulty update rather than an intentional injection of a malicious piece of code, but it demonstrated how flawed code can go through all the compensating controls, remain undetected, reach the production environment, and cause havoc.
Software Supply Chain Security (SSCS) products like Checkmarx’s Dustico are trying to actively detect and closely monitor malicious OSS packages. Hopefully, this problem will be reduced with more awareness, advanced AI-based malicious code detection capabilities integrated into existing products, and perhaps the creation of a new, central, and transparent repository tracking malicious packages, similar to MITRE CVE tracking known vulnerabilities.
Tips for Software Developers
For now, software developers should do the following:
- Use automated SCA and SAST tools as part of the CI\CD chain, and closely monitor their output
- Perform an annual software penetration test to detect vulnerabilities, including some that cannot be detected by automated tools such as different kinds of authorization bypass
- Embed monitoring solutions and compensating controls to track suspicious behavior, especially in production environments
- Fix vulnerabilities in proprietary code found using SAST tools
- Update vulnerable OSS components found using SCA tools
- Use popular libraries and packages only, to reduce the risk of malicious OSS
- Optionally, use SSCS tools to further reduce the risk of malicious OSS
Stay safe!
Want to learn more about how CYE can help protect your organization? Contact us.
