How can I be sure this open-source software isn’t a security risk?
You’ve probably heard the phrase, “You are what you eat,” most likely as you were tucking into something unhealthy, like a donut or slice of pizza. For most of us, it is clear: Poor dietary choices will have a negative impact on our bodies. But have you ever applied this manner of thinking to your software projects?
Open-source software (OSS) has transformed the way we work, fostering collaboration, enhancing accessibility, and driving innovation. Then, of course, there is the fact that it is “free,” a benefit many of us enjoy. So it’s tempting to simply pull in an accessible module or library that quickly resolves your next programming challenge. But, like with food, shouldn’t you briefly pause before inserting it into your project?
Whoops - A Log4j story
CVE-2021-44228 (Log4Shell) caused many system admins to choke on their morning cornflakes when, in 2021, it was announced that the popular Java logging framework Log4j had a serious vulnerability. In fact, it was so severe that Apache assigned it a Common Vulnerability Scoring System (CVSS) rating of 10—the highest rating.
The details of the issue aren’t particularly relevant to this story, except to note that this logging framework was widely used in Java applications, ranging from enterprise to embedded systems. Perhaps the most devastating fact from this debacle is that the issue had been hiding in this tool for eight years.
For months afterwards, teams had to apply patches to running systems, but, of course, this could only be undertaken once any potential issues that the patch may cause had been understood. Some systems, such as IP security cameras and smart TVs, may never be patched as their manufacturers no longer offer support.
Auditing your OSS choices
You can’t know what you haven’t audited, which is why software development teams are advised to review their OSS usage as early as possible. Admittedly, this isn’t a software developer's most exciting task - ranking low with tasks like writing documentation - but there will be someone on your team who enjoys the order and clarity such work brings. Find them and use them!
This also aligns well with another topic, DevSecOps, and the 'shift-left' idea of addressing potential security issues before they arise. If you need help, there are plenty of sources available with advice on constructing a good auditing process, but here are a few starting points:
- How active is the repository? There is a reason why platforms like GitHub provide commit insights for repos. Take a look at the Apache Log4j2 project [1]. If you can’t see the commits for the cobwebs, it’s probably worth passing on, unless you intend to maintain it!
- Review previous security issues: Examine repositories and forums to identify any reported vulnerabilities. Another great place to look is CVE, the Common Vulnerabilities and Exposures website [2].
- Release cadence: When did your selected module or library last receive a release? This is worth noting before committing to using software that is only irregularly updated or devoid of a long-term support strategy.
- Formal security policy or disclosure process: If someone were to discover a vulnerability, would a response be initiated? Apache provides clarity on how their security team handles issues that are found [3].
It’s also worth reviewing the open-source licensing of the software you’ve used during this process in order to avoid any surprises later on. Check out the SPDX License List [4] if you need help!
Track dependencies, sandbox code
If this all still seems like too much work, then a Software Composition Analysis (SCA) tool might be your saving grace. Solutions like Snyk Open Source [5] not only continuously monitor dependencies, but they can go deeper and find untracked dependencies that you may not have been aware of. Additionally, they can highlight possible updates you may wish to include during pull/merge requests and identify licensing issues.
If you’re not ready for a full tool but use GitHub, it’s worth considering enabling their Dependabot feature [6]. It will automatically create pull requests to update dependencies when a vulnerability has been flagged. Alternatively, if you prefer to handle this manually, you can use the alerts provided on the “Security” tab, deciding on the best approach based on severity and likelihood of exploitation.
Other tips include using lock files to ensure that only known, tested dependency versions are used or running code in a sandbox environment so that, should the worst happen, attackers have only a limited amount of access to your systems.
Create an SBOM
In the world of hardware manufacturing, a bill of materials (BOM) is standard practice. This is a list of all the components, chips, and connectors that make up an electronic device. Software BOMs, or SBOMs, are similar, providing a documented list of the dependencies related to your software project.
While it helps to have a documented list of OSS dependencies, an SBOM should also include any proprietary code used and its dependencies. If you’re looking for a standardized format, you should take a look at the Cyclone DX BOM standard [7], which is supported by Dependency Track [8].
This tool uses an SBOM created by your CI/CD system, ingesting it into the tool using something like REST or a Jenkins plugin, before analyzing it for potential security, licensing, or operational issues. Thanks to continuous monitoring, you can take action on issues raised as they occur.
It’s not if, but when…
Your application is vulnerable to a security issue. You just don’t know when that will be. When it does, you don’t want to be wasting time gathering input on your OSS software dependencies—during that time, the hackers will already be probing your system, if they’re not already inside. While documenting dependencies and licenses takes time and is, admittedly, not the most exciting task on the to-do list, taking a shift-left approach will pay out on the day a new CVE is announced that impacts you.
If you’re looking for more detail on this topic, we can highly recommend the OWASP Top 10 Risks for Open Source Software as further reading: https://owasp.org/www-project-open-source-software-top-10/
And, if your need is acute, grasp the nettle by the thorn today and get in touch - the ape factory team is ready to help.
----
[1] https://github.com/apache/logging-log4j2/graphs/commit-activity
[2] https://www.cve.org/
[3] https://apache.org/security/
[4] https://spdx.org/licenses/
[5] https://snyk.io/product/open-source-security-management/
[6] https://github.com/dependabot
[7] https://github.com/CycloneDX
[8] https://dependencytrack.org/
