If software development were a salad bar, open-source vulnerabilities would be the lettuce stuck in your teeth — everyone knows it’s there, but nobody likes to say it.
The industry’s historic hush doesn’t mean those vulnerabilities are harmless, however. A 2018 study found that 96 percent of proprietary applications use open-source components, and the average app is about 57 percent open-source code. With numbers like those, a known vulnerability in a widely used library could create serious security concerns for thousands of users and organizations.
Lately, however, the tide is shifting. Large companies are publishing software projects using open-source licenses, and they’re sharing their security successes and failures with the broader community. This approach, as it turns out, helps create tighter app security across the industry.
“It’s karmic,” said Jason Hammond, director of solutions engineering at cybersecurity startup WhiteSource. “I think development teams are realizing you can’t overcome these things through obfuscation. Just because you’re not talking about it doesn’t mean it’s not a real thing.”
After a 17-year security career spanning from identity management to network and endpoint control, Hammond landed at WhiteSource, which helps companies manage the security and compliance of open-source components in their software. We asked Hammond to share some ways developers can stay on top of the vulnerabilities in their code.
How to improve your app’s security when using open-source libraries:
- Don’t wait until you’re building to think about vulnerabilities. Incorporate that consideration into your research phase.
- Understand your software dependencies. Without a central inventory, it’s tough to track which libraries you use.
- Define and document your policies surrounding vulnerabilities. What types of vulnerabilities are acceptable, and how often will you reassess?
- Alert the community when you uncover a vulnerability in a library. You can patch it, replace it or build something new — but don’t keep it quiet.
- Don’t forget about licensing. A legal risk is its own kind of vulnerability.
Don’t wait until you’re building to think about vulnerabilities
It’s a lot easier to bypass an outdated or insecure library than it is to remediate it later. That’s why developers should incorporate security checks and balances before their fingers hit the keyboard.
Often, Hammond said, developers will introduce vulnerabilities into their code by using outdated versions of open-source projects. In their hurry to start building, they fail to search for newer versions of the libraries they want — or to check for newly uncovered vulnerabilities.
“Libraries are being updated all the time by the community. You may have used this library successfully in some other project months ago, and you need that function again, so you use the same library now,” he said. “But since then, there have been vulnerabilities identified in the older version and new point releases, or even major releases, to address that vulnerability.”
For smaller projects, there are free online tools that scan for open-source vulnerabilities — such as NPM Audit for NPM dependencies and Node.js modules, RetireJS for JavaScript and the National Institute for Standards and Technology’s National Vulnerability Database.
For larger projects, checking each library manually in a free tool may be too time-consuming. In that case, there are commercial tools that offer continuous scanning and automated patching. Some also come with browser plug-ins that surface new versions and vulnerabilities as you navigate online repositories.
“Once the product is deployed, unless you’re making a change to it, you may not even think to go scan it again.”
Another step many developers skip is reading through open-source project archives or newsletters. Browsing the project’s history and the community’s discussion can reveal important updates — or the lack thereof.
Some projects may be defunct — their maintainers have moved on and no longer implement new commits or fix newly discovered vulnerabilities. Other projects may simply have no security component. Snyk’s 2019 State of Open Source Security Report found that 25 percent of open-source maintainers do not audit their codebases. In that scenario, developers must perform security testing and code reviews themselves or defer to in-house security teams.
While it’s critical to consider open-source vulnerabilities during a project’s research phase, security checks shouldn’t end there.
“When you’re building the thing in the first place, you’re mindful of the security and potential vulnerabilities, so you’ll look for them,” Hammond said. “But once the product is deployed, unless you’re making a change to it, you may not even think to go scan it again.”
Understand your software dependencies
It’s natural for development teams to focus their efforts on the custom components of their codebases. So over time, open-source components — and the security risks they present — can fade into the background. Then, checking dependencies for new vulnerabilities seems less important than hitting deadlines and shipping releases.
“You might be using a library that has a dependency on another library that you’re not even aware of,” Hammond said.
If you don’t already have one, make it a team-wide goal to create a central inventory of your open-source dependencies, their licenses and the last time they were checked for new vulnerabilities. It’s a big job, but you can’t monitor the security of your open-source dependencies if you don’t know what they are.
Hammond said developers frequently forget that containers have vulnerabilities too. For example, if your organization has a standard Docker container for Red Hat software, it’s probably tempting to keep using it with no knowledge of its open-source components. For better security, treat the container like any other software component: examine its dependencies and intermittently check for updates and vulnerabilities.
“There may be open-source code on those containers that’s used for managing the container, not just running the application,” Hammond said. “As a developer, you’re just a consumer of that. You’re assuming that whoever provided the container environment has done their due diligence.”
Define and document your policies surrounding vulnerabilities
When it comes to auditing open-source libraries, a plan helps turn good intentions into practice.
Create documents defining your organization’s policies surrounding open-source dependencies, including how regularly developers should check for updates and vulnerabilities, the correct processes for doing so, expectations for code reviews and testing, and procedures for reporting.
These policies should also outline your organization’s tolerance for different levels of severity, depending on what type of data an app draws from. For example, if an app doesn’t deal with any sensitive customer or financial data, a known vulnerability of medium-level severity might be a risk the team is willing to take. However, a medium-level vulnerability should never show up in a shopping cart app — unless it has to.
Hammond explains: “Sometimes orgs only bother with the lowest-hanging fruit. It’s easy to define a policy that says not to use libraries with a high-severity vulnerability across the board. But a lot of times, that forces organizations to manage out of exceptions. For 90 percent of the applications, that’s OK. But for the 10 percent where you don’t have an alternative, you have to use that library. You essentially have an exception to the policy, and now that exception needs to be accounted for in every future analysis of that application.”
Even though the team in Hammond’s example could not avoid the vulnerability altogether, by setting a benchmark and flagging the exception for continual review, they made their development process more secure.
Alert the community when you discover a vulnerability in open-source software
Sharing the vulnerabilities in your software — be it with users or the developer community — is, well, vulnerable. Corporations worry it will erode customer trust, developers worry it will reflect poorly on their work, and both worry it will tip off attackers.
Those attitudes are obstacles to better industry-wide security, Hammond said. Sharing newfound vulnerabilities with the open-source community helps other organizations secure their applications. Ideally, those teams will share their findings as well, making the libraries more dependable for everyone.
However, keep in mind that patching vulnerabilities — especially without the help of automation — is immensely time-consuming for developers. That creates an incentive to ignore them, particularly when deadlines bear down. Maybe that’s why 44 percent of software flaws never get fixed.
To combat that, take steps to create a culture of transparency surrounding vulnerabilities, both in terms of corporate communication with the broader software community and internal communication among engineers and other stakeholders.
“Executive sponsorship and making it part of the corporate culture is the first step, and it trickles down from there,” Hammond said. “When developers see the example being set, they’re more willing to be open as well, because they’re experiencing the benefits.”
When open-source vulnerabilities surface, your team has the choice to patch them, replace the component with a more secure library or build something comparable in-house. Whatever you choose, share your findings honestly inside and outside your organization.
“The more you’re willing to share, the better your own security and compliance posture is going to be.”
Another way to boost code transparency is to publish custom code as an open-source project. That opens the project to community feedback, which means more hands on deck in the hunt for vulnerabilities. Even tech giants like Microsoft increasingly take this tack.
Yes, this approach will reveal your application’s shortcomings alongside its strengths. But the security benefits — and opportunities for industry leadership — outweigh the risks. For small companies, a strong open-source presence also supports branding and growth.
“The more you’re willing to share, the better your own security and compliance posture is going to be,” Hammond said. “There’s been a significant increase in the last 12 months or so of development management teams being more interested in having those conversations.”
Don’t forget about compliance
Unpatched vulnerabilities in open-source libraries create risk for your organization, but so does noncompliance with open-source licenses.
“They are two sides of the same coin,” Hammond said. “There are vulnerabilities that an attacker could use to gain access to your data, and then there’s the licensing issue, which ends up becoming a legislative and legal risk.”
Some open-source licenses allow developers to use libraries however and wherever they choose. But others, including so-called copyleft licenses like the GNU General Public License series, require derivative projects to be published with the same freedoms as the original open-source code. That means applications using code with a copyleft license are obligated to share their source code for modification and re-use. For many companies, that’s a dealbreaker. Alternatively, some free and open-source projects still contain proprietary algorithms or are published under trademarks.
“If you’re not familiar with the restrictions or limitations associated with a license to use that library, you may be inadvertently costing your company money.”
Overlooking the fine print in open-source licenses — or failing to track licenses altogether — is a financial liability for companies. They may be sued by the open-source community, or they may lose revenue when they’re forced to release the source code of a proprietary project.
As with open-source vulnerabilities, the solution lies in clear company policies and frequent auditing. Document your company’s policies on various open-source licenses so developers know what’s on and off the table. New developers, especially, will be tempted to use the libraries they’re familiar with, and their last company may have held different views on open-source licensing.
Add licensing information to your central inventory of open-source dependencies, and define processes for engineers to find and review complete licenses for the dependencies in their code. Without a comprehensive list of dependencies and licenses, it’s easy to lose track of what libraries are lurking in your codebase — and difficult to enforce company policies.
“Everybody's thinking about vulnerabilities,” Hammond said. “But if you’re not familiar with the restrictions or limitations associated with a license to use that library, you may be inadvertently costing your company money.”
