This story is the first in a series that we will post that examine the role of the security in the open source software supply chain. Check back throughout the month for updates.
What happens when the maintainer of a popular open source framework or component dies, goes to prison or just gets fed up? Developers whose software depends on that repo might have time to prepare; there might be an official repo with a formal succession process, a fast but informal community fork. Or the code might just disappear — which could affect commercial tools using it too. And even if there are a warning and time to plan, it’s only helpful if developers are aware of the dependencies in their software and monitoring their status.
Death, prison terms and abrupt departures might be rare; software vulnerabilities aren’t. As Microsoft Azure Chief Technology Officer Mark Russinovich pointed out at the RSA Conference earlier this year, hugely popular open source packages have been compromised multiple times, meaning the organizations using them are compromised too.
The build script for the Webmin web portal admin toolkit was tampered with leaving it with a credential-stealing backdoor for a year, during which it was downloaded a million times. When the Bootstrap-sass web styling framework was compromised on npm and the attackers removed the older version, it took eight days until a safe version was available. A crypto miner was added to the Node.js Event-Stream package after a new maintainer volunteered to take over an old but still popular repo.
Even large, experienced technology organizations can make mistakes in securing their repo (Canonical’s GitHub account was compromised in 2019) or miss the update that fixes a newly-discovered vulnerability in a component. GitHub only discovered that it hadn’t updated a dependency in the code for its Mercurial import that sanitized branch names, allowing attackers to craft a branch name that could run code on the GitHub servers (albeit in a sandbox on an isolated network), through its bug bounty program.
These problems certainly aren’t unique to open source but as Russinovich noted, “open source is such a massive ecosystem that we need to go after it specifically and there are some specific implementation points in the supply chain that need to be addressed for open source.”
Viewing the open source that developers and operations teams consume as a supply chain makes it easier to think about where problems occur. “How do we make sure that only packages and source code we’ve got some assurance are trustworthy enter our supply chain? How do we ensure that what we know about that supply chain is reliable: when somebody says ‘this is trustworthy, I’ve done code reviews on it, I’ve got MFA in place for checking in source code’ that that is really, truly the case. And then what do we do when there’s a vulnerability, how to identify what’s affected by it and how do we roll back to a good version?”
Importing one package doesn’t add just one dependency; it also brings the upstream dependencies that package imports.
There are multiple steps the open source community can take, starting with good hygiene software development and package management, all the way up to defining a “bill of materials” for software the way we do for physical products to make dependency tracking more effective.
Software security tools like linters, fuzzers and static code analysis can improve code quality. While Coverity is a proprietary static analysis tool, it’s free to scan open source projects written in C, C++, C#, Java, JavaScript, Python and Ruby for defects and to get explanations of the root cause.
Embold is also free for open source use. Google’s OSS-Fuzz service, run in conjunction with the Linux Foundation’s Core Infrastructure Initiative, uses multiple fuzzing engines, checks open source projects written in C/C++, Rust and Go free and has already found 17,000 bugs in 250 projects.
Rather than leaving every maintainer to check one project at a time, GitHub is hoping its Security Lab (free for open source projects) and CodeQL will help remove vulnerabilities at scale across thousands of projects.
The GitHub Security lab bounty program has a new Bug Slayer category to reward researchers who write code queries maintainers can run that find not just a specific vulnerability but a whole class of vulnerabilities. That way, the CodeQL query doesn’t just fix current vulnerabilities at scale rather than one by one but will also stop new, similar vulnerabilities from being released in the future.
Also free for open source projects is Snyk, which will scan your source code repo and tell you if you have dependencies on. Now that GitHub owns npm, it’s going to be easier to check those dependencies; as GitHub CEO Nat Friedman pointed out when announcing the acquisition, “Looking further ahead, we’ll integrate GitHub and npm to improve the security of the open source software supply chain, and enable you to trace a change from a GitHub pull request to the npm package version that fixed it.”
#development #open source #security #profile
