Open-source software components have become essential to developers around the world—and that popularity made them a hacker magnet.
Last year global developers requested more than 1.5 trillion open-source software components and containers, while cyber attacks aimed at actively infiltrating open source code increased 430%, notes the “2020 State of the Software Supply Chain” report. Produced by Sonatype, IT Revolution, and Muse.dev, the report states:
“[Members] of the world’s open source community are facing a novel and rapidly expanding threat that has nothing to do with passive adversaries exploiting known vulnerabilities in the wild—and everything to do with aggressive attackers implanting malware directly into open source projects.”
By shifting their focus upstream, bad actors can infect a single component, which will then be distributed downstream using legitimate software workflows and update mechanisms, the report says. “The attacks are a uniquely efficient way for adversaries to gain leverage and scale by exploiting software supply chains.”
Security problems with software supply chains aren’t that different from those found in all supply chains, said Joseph Carson, chief security scientist at Thycotic, a provider of privileged account management solutions. “Organizations tend to have stronger security controls on systems they own, but greater risks with supply chain systems that they do not have access to or visibility into what security has been put in place,” he explained.
Understanding the trend is the first step (more on that below). But the report serves as a call to action, and there are a number of ways to protect your organization from software supply chain attacks. Here are seven your team should implement now.
1. Check your sources
Developers using open-source software need to verify they’re getting code from an official upstream repository. “Since open-source repositories allow access to pre-release code, it’s critical that organizations only download official releases and updates,” said Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center.
“It is in the pre-release code that attackers find the greatest traction.”
—Tim Mackey
Josh Stella, founder and CEO of Fugue, a cloud infrastructure security company, warned that developers should be careful about namesake attacks. “Instead of trying to inject harmful code into an existing component, a bad actor will make a harmful component with a similar name and try to get people to use it,” he explained. The reason: It’s hard to sneak hostile code into widely used open source because there’s a lot of eyes on it, he added.
“There’s a lot of cleverness in these supply chain attacks. You have to be really conscious of the true provenance of a component.”
—Josh Stella
Tsvi Korren, field CTO of Aqua Security, an applications security company, recommended laying down rules for developers for using open-source components. “An organization can say it’s okay to use open-source components, but you need components that have had a commit in the last three months or a project that has more than 10 maintainers so it isn’t orphaned if someone decides to abandon it.”
“You need a sanity check over whether this is a serious piece of software that deserves to be in an enterprise environment.”
—Tsvi Korren
2. Maintain an inventory of components
The most important open-source management practice that organizations should have is an inventory of which open-source components are used, and where, Mackey said. That’s particularly important because of the way many organizations obtain their open-source components, Korren said.
“Very few organizations use open source directly from GitHub. A lot of them are getting a copy of the project and putting it into an internal code repository. “
—Tsvi Korren
Teams need to go into their internal code repositories and understand whether something was written from scratch or their developers incorporated an open-source project, Korren added.
Mackey advised that when taking inventory, teams should reach beyond open-source software.
“With upwards of 90% of commercial software using open-source components, it’s no longer sufficient to simply define a process around source code management. Instead, all commercial software, including desktop and server applications, as well as firmware, should be assessed for its use of open-source componentry.”
—Tim Mackey
Once the inventory process is completed, then it becomes possible to understand if there are unpatched components or potentially obsolete components in use, Mackey added.
Creating such an inventory can be a daunting task, but there are software composition analysis tools to automate the process. The best solutions include a continuous monitoring capability such that new patches can be identified without re-scans, provide triage and mitigation guidance, and operate equally well on binaries and source code, Mackey said.
3. Keep your software up to date
Whether software is open source, commercial, or homegrown, ensuring that it is up to date, fully patched, and clean from vulnerabilities is just fundamental security hygiene, said Yaniv Bar-Dayan, CEO and co-founder of Vulcan Cyber, a remediation intelligence provider.
“Ninety-nine percent of exploited vulnerabilities are known vulnerabilities. If you can maintain good cyber hygiene, you can significantly reduce the risk of attack, particularly from upstream attacks that aim to exploit open source.”
—Yaniv Bar-Dayan
Mackey warned, however, that patching open-source components can have its perils. “What is unique to patching open-source components is that for many open-source communities, their release flow is a linear process,” he said. “In other words, there are no security hot fixes and everything is an upgrade.”
“This means that if patches are delayed, then the current patch will include not only security fixes, but could include functional changes and even features. Obviously such changes then increase the potential for the patch to introduce side effects requiring additional acceptance testing.”
—Tim Mackey
4. Implement a least-privilege policy
Should an infected component make it into an organization’s software, the risk of damage can be reduced by keeping tight controls on who or what can have access to internal resources.
“The best approach is to de-risk the environment as much as possible, which means do not give more privileges to a system than it needs. Implement a strong principle of least-privilege security.”
—Joseph Carson
5. Relentlessly scan your software for flaws
Alexander Ivanyuk, senior director for product and technology positioning at Acronis, said that with a DevOps program in place, software developers should scan libraries, components, and their final products.
“Anti-malware vendors should leave an option for their customers to scan each and every app and module regardless of its digital signature or whether it’s believed to be from a trusted source. Inside the organization every developer who uses open-source components should practice secure development through code review and behavioral and sandbox scans.”
—Alexander Ivanyuk
6. Scrutinize your vendors’ code
Determining the pedigree of the open source code you’re using in your apps is just part of a program to protect an organization from an upstream supply chain attack, as the users of SolarWinds software discovered.
“You need to scrutinize your vendors, particularly vendors selling you management tools—things that have access to privileged information—and their security policies, because you’re inheriting the results of those policies.”
—Josh Stella
Korren explained that when evaluating open-source components, there are a few things to keep in mind. “Projects maintained by few people, without recent commits, without a lot of people reviewing them should be looked at with more of a suspicious eye than projects that are well organized, have good governance, have a lot of contributors, and the commits are flowing,”
7. Shift detection and behavior analysis left
Security testing of intrusion detection and software behavior aren’t done until late in the development cycle, Korren noted. “We need to shift them left, like everything else, so if we take an open-source component, we can run it in an earlier test environment to see if it’s trying to do something bad,” he explained.
“Doing testing earlier should weed out some of the danger and give us more confidence in using open-source components.”
—Tsvi Korren
Trust is too common
Developers can also be too trusting of the open-source components they’re working with, noted Dirk Schrader, global vice president at New Net Technologies, provider of cybersecurity and compliance software.
“Quite often the assumption is that somebody else has done the review already because a certain library is widely used or the original developer has a good reputation for software quality.”
—Dirk Schrader
Recognizing an infected component can be problem for developers, said Stella. “If, while writing my code, I pull in a software library that has been injected with malicious code, I probably won’t notice that because it will appear to be a legitimate library, unless I’m very cautious about the provenance of all the components that go into my program,” he said.
“A lot of times these components are black boxes to the application teams using them. The teams trust them implicitly.”
—Josh Stella
Ease of distribution can also contribute to security problems, said Synopsis’ Mackey. He explained that developers will download components without verifying their authenticity, checking their release date, figuring out how to patch them when updates are released, and all the other items that come from managing a supply chain.
“Download is easy, and the code is free to use, so overlooking any usage responsibilities is easy.”
—Tim Mackey
Making matters worse, the assaults can be byzantine, said Candid Wuest, vice president of cyber protection research at Acronis, a provider of safety, accessibility, privacy, authenticity, and security services.
“Software supply chain attacks often span several levels, where compromised components are integrated into other components, which are then used by the final developer. These chains of dependencies are not often clear and can be complicated to monitor.”
—Candid Wuest
Better governance needed
One reason developers trust open-source components is that they’re supposedly scrutinized by the “many eyes” of the community that created them. If there are any security problems with a project, the thinking goes, the community should catch them. In reality, that’s not always the case. “The open-source world has had problems with governance over its projects,” observed Aqua Security’s Korren.
“There are projects that have very strong governance, like Kubernetes, but there are other open-source projects that are not well governed. They might be maintained by one person, and it’s not their day job. So there are opportunities to insert malicious intent into the early stages of open-source packages.”
—Tsvi Korren
Mackey added that the open-source community regularly spots malicious code contributions and quickly contains their impact, but not always before the code is posted online for other users to consume. “In open source, there is no single vendor for any given component, and as such there are many locations, known as ‘forks,’ where source code for a project might be available,” he explained. “All an attacker needs to do in that context is wait for an inattentive downloader who is also likely to have a weak governance policy in place surrounding downloads.”
Vulcan Cyber’s Bar-Dayan added that many open-source projects, especially those without big company backing, have become impossible for individual project maintainers to secure. “Often, the ‘many eyes’ of the developers contributing to open-source projects are siloed to just specific modules or repositories of a larger project,” he said.
“A combination of insufficient oversight, plus siloed contributions, often creates a situation where the ‘many eyes’ of the open source promise only to catch vulnerabilities and security flaws after the code has been pushed into production.”
—Yaniv Bar-Dayan
Best practices matter
The “State of the Software Supply Chain” report identified a number of practices that influenced successful supply chain outcomes. For example, it found that high performers deployed more frequently, detected and remediated vulnerable open-source software components more quickly, and approved new OSS components efficiently.
It also found that high performers onboarded developers onto new teams faster and that their employees demonstrated high levels of satisfaction on the job. Until the use of those best practices gain momentum in organizations, though, the problem software supply chain attacks is likely to get worse.
While open source is great for development speed and efficiency, it’s perhaps too easy for developers to run fast and loose utilizing open-source packages without checking for known vulnerabilities or other security issues. “When insecure code permeates enterprise infrastructure, it is often replicated thousands of times over, leading to a much wider attack surface and more opportunities for attackers to exploit open-source supply chains,” Bar-Dayan noted.
Stella said that it’s the next stage in the security arms race.
“As more software is written in the world, more attack surface is created for hackers. Security companies are getting more sophisticated about thwarting hackers, but it’s an arms race. It always will be.”
—Josh Stella
Recent Comments