Open-source software (OSS) libraries are widely used in the industry to speed up the development of software products. However, these libraries are subject to an ever-increasing number of vulnerabilities that are publicly disclosed. Aside from the widely known open-source operating systems on the market, enterprise users also leverage open source productivity software, tools for administrators and developers, and various code libraries used to build their software. Even commercial software is typically built on a foundation of open-source code.
The use of OSS libraries as well as the number of available libraries are ever-increasing: Synopsys Black Duck (2019) reports that over 96% of the applications they analyzed include OSS libraries, whose code often weighs more than 50% of the average code-base; Snyk (2019) reports a growth of 102% in the number Java OSS libraries available in Maven Central and of 40% for Python libraries in the Python package index (Pypi). When a similar study was done in SAP ~1000 new OSS libraries got added in April 2021. Looking at the volume of OSS dependencies used within SAP the responsibility lies with SAP to perform its “Due Diligence” by making sure that these libraries don’t compromise any data or become a threat vector for a data breach.
Attacking the software supply chain
The recent incident reported by the Cyber Security team about a famous NodeJS library “CodeCov” puts a lot of cloud applications – at risk as this library is used by HTML5 and other common components. This is a typical example of a supply-chain attack that uses CI/CD pipelines to expose the data. A similar incident occured last year with the Solar Winds breach, where hackers put malicious code in update servers through which more than 33,000 customers downloaded the regular patch updates consisting of the malicious code. This malicious code created a backdoor to customer’s information technology systems, which hackers then used to install even more malware that helped them spy on companies and organizations. This shows, even though companies follow stringent SDLC (Secure Development LifeCycle), vulnerabilities can still be injected using one or the other loopholes.
The above information may give developers nightmares about the security practices or current security infrastructure they are responsible for. As with increasing demand in feature development and time to market pressure, software development teams consume more and more open-source libraries to fasten feature deliveries. Though the use of OSS libraries speeds up development, it comes at a cost, as vulnerabilities discovered in OSS libraries may affect the dependent applications. While using OSS components with known vulnerabilities is included in the OWASP Top 10 Application Security Risks since 2013 (OWASP Foundation 2013, 2017), the problem is still far from being solved. Establishing effective OSS vulnerability management practices, supported by adequate tools, is broadly understood as a priority in the software industry, and tools helping to detect known vulnerable libraries are available nowadays either as OSS e.g. OWASP Dependency-Check, WhiteSource or BlackDuck.
Increasing open source security
These tools differ in terms of detection capabilities, but (to the best of knowledge) the approaches they use rely on the assumption that the metadata associated with OSS libraries (e.g., name, version), and to vulnerability descriptions (e.g., technical details, list of affected components) are always available and accurate. Unfortunately, these metadata, which are used to map each library onto a list of known vulnerabilities that affect it, are often incomplete, inconsistent, or missing altogether. This also creates the misconception to development teams that using such OSS vulnerabilities tools makes their development secure. In discussions with development teams, often this statement is heard “Why is OSS vulnerabilities management by these tools not enough?”. The answer lies in the way these tools are configured: the tools only scan the source code developed by the teams, whereas the OSS libraries never get scanned by these tools in SAST (Static Application Security Testing). Also, when applying DAST (Dynamic Application Security Testing) using tools like Burp or ZAP only the functional scenarios which the product or the applications supports are covered. Additional workflows or execution paths the OSS can add to products are usually out of scope.
As more and more software development companies are moving towards delivering E2E solutions to their customers, the responsibility and the stakes are very high. They can’t simply deny the importance of creating “Due Care” practices so that the software development and delivery chain is not prone to data breaches. This is a mindset change, as all the different stakeholders like development teams, DevOps teams, security teams and finally the infrastructure teams have to work together to provide a sophisticated process in which security lies in the centre and is not considered as an afterthought of product development.
Sagar is a Senior Developer & Product Security Lead with SAP Labs based out of Bangalore, Karnataka. He is a CISSP certified, certified cloud computing architect, Blockchain Community Certified Architect and database solution advisor with over 10+ years of experience in secure software designing and cross platform architectural designing. He had published many papers in international journals like IEEE, Springer etc. on cross-domain communication and interoperability for cutting-edge solutions
Excellent article Sagar. Really eye-opener about the usage of OSS.
We typically look at the “benefit” of OSS, and try to avoid looking at the risks & vulnerabilities.
You pretty well summed up the scary picture, if companies don’t put security-first approach.
Pingback: Solving Caveats In Open Source Vulnerability Management - Cyber Protection Magazine