 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
2022 was a heck of a year for open source security troubles, but at the same time, the Open Source Security Foundation (OpenSSF) did its best to help secure vital programming infrastructure.
In 2021, not 2022, things went awry in a big way for open source software security. I am, of course, referring to the Log4J vulnerability. It’s been over a year, and it’s still hanging around. This, in turn, woke people outside the developer and security worlds to the dangers to the software supply chain. I’d predicted that open source and Linux developers would take security much more seriously in 2022. It looks like I was right.
To meet these security needs, OpenSSF and numerous other developer players, including Apache, Google, Apple, and AWS, met at the White House with the US government’s executive branch. As White House National Security Advisor Jake Sullivan said when he called for the meeting, it was a “national security concern” that volunteers maintained foundational open source software.
Well. Yes, we, the open source community, knew that. Of course, it’s not like the proprietary software development companies have covered themselves with glory.
Afterward, IBM’s enterprise security executive Jamie Thomas said, “government and industry can work together to improve security practices for open source.” This starts with “encouraging widespread adoption of open and sensible security standards, identifying critical open source assets that should meet the most rigorous security requirements, and promoting a collaborative national effort to expand skills training and education in open source security and reward developers who make important strides in the field.”
This is where, Kent Walker, Google and Alphabet’s president of global affairs, blogged, “Open source software is a connective tissue for much of the online world — it deserves the same focus and funding we give to our roads and bridges.” Given the slow rollout of President Biden’s Building America Better infrastructure law, that doesn’t make me feel that good.
Still, the OpenSSF rose to the challenge with numerous initiatives in 2022.
For example, when the OpenSSF hosted the Open Source Software (OSS) Security Summit II in May, it brought together executives from companies and U.S. federal government leaders to reach a consensus on critical actions to improve the resiliency and security of the open source software. This is the Open Source Software Security Mobilization Plan. This sets out ten streams of investment to make immediate OSS security improvements. It backed that with $30 million in pledges. It’s not a finished plan, but it’s a good start, and it spells out the dollars and cents needed to make securing open source a reality rather than just nice words.
Before that, in February 2022, OpenSSF launched the Alpha-Omega Project. Its goal is to “improve global OSS supply chain security by working with project maintainers to systematically look for new, as-yet-undiscovered vulnerabilities in open source code” and then fix them. In particular, the “Alpha” aims to improve global OSS supply chain security by working with the most critical open source project maintainers to help them identify and fix security vulnerabilities. The “Omega” portion focuses on the long tail of OSS projects, helping systematically find and remediate vulnerabilities in at least 10,000 widely deployed open source projects. So far, Alpha-Omega has sponsored critical security work in several projects. This includes a $460K grant to the Rust Foundation, a $300K to Node.js, and a $400K grant for the Eclipse Foundation. Regardless of the project’s details, the goal is always the same at the top level: Improve security.
A key component of the Mobilization Plan is using a software bill of materials (SBOM) as a foundational building block to improve the security posture of all of OSS’s projects: SBOM Everywhere. Its first effort was to fund work on a Software Package Data Exchange (SPDX) Python library to support SBOM creation and processing. Given Python’s almost daily list of successful software chain security attacks, Python can use all the security help it can get.
Another working group, the Vulnerability Disclosures WG, is crafting a new guide on vulnerability disclosures. For now, tracking down vulnerabilities is more of an art than a science. Eventually, Vulnerability Exploitability eXchange (VEX), a Cybersecurity and Infrastructure Security Agency (CISA) working specification, will provide machine-readable security advisories.
On the purely technical side, the Security Tooling WG has released Fuzz Introspector. Now we all have our favorite fuzzing tools — OK, in my circles, people have favorite fuzzing tools, and mine is OSS-Fuzz. You can’t fuzz everything — an automated technique for finding bugs by feeding unexpected inputs to the program — because you can run into roadblocks (aka blockers) that prevent effective fuzzing. Fuzz Introspector provides developers with actionable insights to identify blockers so they can be resolved.
The OpenSSF Supply Chain Integrity Working Group is also working on refining the Supply chain Levels for Software Artifacts (SLSA, pronounced “salsa”). This is a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure. A draft is already public, and work continues to refine it for a “version 1.0” release.
I think it’s important here to note that even as everyone says, they support SBOMs and, to a lesser extent, SLSA, we are far from perfecting them yet. What’s in one company or group’s SBOM isn’t in another. We need a lot of standardization before they’ll be as useful as we hope they will be.
That actually can sum up OpenSSF’s efforts in general. Are they making progress? Oh, yes. Are they there yet? Nope. We’re off to a good start. And considering how we — and by we, I mean everyone involved in programming — have historically put securing code on the back burner — that’s a good thing. But, more, much more, needs to be done.
