The fast-growing pile of unmaintained OSS projects is a security nightmare waiting to happen
It’s an open source graveyard out there, new research has revealed, with more than nine in 10 commercial applications found to contain outdated or abandoned open source components.
In its latest Open Source Security and Risk Analysis (OSSRA) report, software giant Synopsys says that 99% of codebases audited last year contained open source components. Indeed, open source made up 70% of codebases overall.
More than half of these apps contained the JavaScript library jQuery, with four in 10 containing the Bootstrap CSS framework, and a third containing the Font Awesome font and icon toolkit.
“Open source components are popular because they provide high quality solutions to complex problems at an attractive price point,” Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Centre, tells The Daily Swig.
“If you look beyond the open source usage within a single application to include the entire platform powering that application, the resultant stack is often highly dependent upon open source operating systems, virtualization platforms, and development frameworks.
“Effectively, the strengths of open source have redefined how software is delivered and how innovation occurs.”
Abandoned projects, outdated libraries
While this latest research acts as further confirmation that DevOps teams continue to embrace open source software, 91% of the codebases that were audited contained components that were either at least four years out of date or that hadn’t had any development activity in the past two years.
As a result, the report warns, there’s an increased risk of security vulnerabilities, along with functionality or compatibility issues.
This, says Mackey, reflects widespread poor DevOps processes.
“While open source components often address key foundational elements within software, such as you might find within an authentication library, if that component is simply downloaded and used without any process to keep it up to date, then you can easily become out of date,” he says.
“Further complicating matters, software developers want to ensure their code will consistently build, so if that downloaded component is then cached in an internal repository to ensure consistency, if there is no process in place to refresh the component when new versions are released, then a process has in effect been created which prevents proper patch compliance.”
Searching for the source
Three quarters of the codebases Synopsys audited contained vulnerabilities, up from 60% the previous year. Almost half contained vulnerabilities classified as high-risk – although, luckily, none was affected by the Heartbleed bug or the Apache Struts vulnerability that hit Equifax in 2017.
Unpatched components are a particular risk with open source, says Mackey, as there’s no official location for the source code. Even when there is, understanding where it is can be tricky when code has been forked to implement a new feature with the intention of merging later.
READ MORE GitHub showcases new code-scanning security tools at virtual event
“Anyone wishing for that feature prior to the merge would need to obtain their copy of the code from that fork, and there is no guarantee that any patch will be created for security issues on that fork,” he says.
“Importantly, there is also no guarantee that a patch created for the official code will even work on any given fork.”
Meanwhile, a third of the codebases audited contained unlicensed software, and two thirds had license conflicts, with internet and mobile apps being worst affected.
Mitigating OSS dependency risks
To minimize these problems, says Synopsys, development teams should be creating and maintaining a Bill of Materials (BOM) – an inventory listing all open source components, along with the versions used, the download locations for each project and all dependencies, the libraries the code calls to and the libraries those dependencies link to.
This, says Synopsys, can be done using a software composition analysis (SCA) tool.
Organizations should also develop processes to keep on top of updates and continuously review them, with input from legal and IT departments as well as the development team.
“Involving legal and IT opens the doors of communication surrounding how risk is measured and mitigated. This is important because the ramifications of developer decisions related to security will be felt by IT and dealt with by legal,” says Mackay.
“Each team will gain a greater appreciation for the concerns of their counterparts, and from there it becomes possible to talk about which tools to procure for inventory management, how best to apply patches or which open source communities to engage with.”
RECOMMENDED DevSecOps for financial services: Security leaders share best practice advice and industry horror stories
