Article by: Phillip Ivancic, APAC Head of Solutions Strategy, at Synopsys Software Integrity Group
How much of your day-to-day life relies on open source software? Well, the reality that many people don’t realise is that open source code is woven into your life; from your privacy, healthcare records, mobile phone, internet access, electricity, smart home, and even your car all probably rely on open source software in some way or another.
In fact, Synopsys’ latest Open Source Security & Risk Analysis (OSSRA) report found that an average of 97% of all software written contains at least some open source code. Of the 17 industries represented in the report, Computer Hardware and Semiconductors, Cybersecurity, Energy and Clean Tech, and Internet of Things (IoT) contained open source in 100% of their codebases. The remaining verticals had open source in 93% to 99% in their codebases. Even the sectors with the lowest percentage—Healthcare, Health Tech, Life Sciences—had 93%, which is still very high. It’s clear that open source really is everywhere.
With high volume of open source use, high volume of vulnerabilities present
A layer deeper, the amount of open source in codebases was also high. For example, 100% of codebases in the IoT sector contained open source, and an astounding 92% of the audited code in this sector was open source. Troublingly, 64% of the IoT codebases also contained vulnerabilities.
Figure 1: Percentage of codebases containing open source vulnerabilities, by industry
Similarly, the Aerospace, Aviation, Automotive, Transportation, and Logistics sectors had open source in 97% of its codebases, and 60% of the total code was composed of open source. The real revelation came when we looked at open source vulnerabilities: 60% of this sector’s codebases had open source vulnerabilities. In the Internet and Mobile Apps sector, 99% of codebases contained open source, 80% of the codebases were composed of open source, and 56% of the codebases contained open source vulnerabilities.
This story was echoed across all industry sectors. Open source components made up the large majority of codebases, and much of those codebases were vulnerable to exploit and attack.
What are the implications?
Now, you might be asking — why should organisations, and consumers for that matter, be concerned? In the world of open source security, ignorance is not bliss. Open source software is typically built by communities of developers who contribute their knowledge and time to open source projects they find appealing. That code can then be used by individuals, communities and organisations in their software products — the only obligation they have is to play under the rules of the license with which the open source project was published. That also means that this code is not regulated and maintained by any designated person, government or company.
If organisations aren’t proactive about maintaining and reviewing their vulnerability updates, they run the risk of becoming an easy target for attackers. Additionally, if they fail to comply with open source licenses, they can put their business at risk of litigation and open themselves to threats to their intellectual property.
What should be done?
Open source vulnerability management is no easy task, but it’s necessary if you want to provide secure, dependable applications for both internal and external customers. To address vulnerabilities while avoiding interruptions to the CI/CD pipeline, organisations should approach open source vulnerability management by relying on these four critical elements:
Accurate and comprehensive sources
You can’t just rely on one data source for open source security vulnerabilities. Pulling together multiple sources including your own primary research, a National Vulnerability Database (NVD) data feed, a validated set of security sources, third-party security vendors, open source risk analysis, and component distributors is a great start. But the truly vital piece is to infuse this information directly into the software development life cycle (SDLC), and as far left as possible. If developers have known vulnerability information at their fingertips as they code, it will save time and resources later in the SDLC.
Exact identification of vulnerable components
In order to pinpoint vulnerable components in your applications, you have to first identify ALL open source components in your applications. Doing so requires that you consider all versions and forks of the code, detect components in source and binary form, analyse commercial software where open source is frequently embedded, and look beyond just what has been declared in package managers. Automating this task saves teams from having to keep manual and often inaccurate inventories of open source. It also makes it possible to very quickly pinpoint vulnerable components as they’re pulled in, and know immediately when new vulnerabilities are reported. The full inventory is the first step, because if you don’t know you have it, you can’t make sure you patch it.
Information critical to making prioritisation decisions
Once you have your inventory, and your diverse set of sources has surfaced all the known vulnerabilities, you might be left with a daunting list of things to fix. Being able to leverage additional information about the vulnerabilities will help the team prioritise the list and make sure they fix what’s most critical first. Data such as severity, exploitability, the impact of an exploit, reachability, and available solutions can all be vital to this task. The key to DevOps, though, is not just to have the information, but to automate the prioritisation using this data and your business rules, so fixes happen quickly and alerts appear where developers are already working.
Complete and expedite patch information
Finally, once you have your inventory, understand your known vulnerabilities, and know which ones to fix first, the last step is to actually make the fix. Patch information needs to come with the alert and must be clear and concise and get to the right person quickly. Armed with the information, the team has to quickly determine if the patch is compatible with the fork and ensure it won’t cause any other downstream issues