Commentary: It’s progress that President Biden’s executive order recognizes the need to secure open source software. What it doesn’t do is address the best way to accomplish it. Image: iStockPhoto/maxkabakov Continue Reading
Commentary: It’s progress that President Biden’s executive order recognizes the need to secure open source software. What it doesn’t do is address the best way to accomplish it.
It was just a matter of time before David Recordon’s impact on the U.S. federal government would be felt. Shortly after President Biden took office, he named Recordon the White House Director of Technology, coming a few years after Recordon ran open source initiatives at Facebook. Writing at that time, Recordon said, “The pandemic and ongoing cyber security attacks present new challenges for the entire Executive Office of the President.” Fast forward to May 2021, and President Biden issued an executive order on improving the nation’s cybersecurity, with Recordon’s open source fingers all over the document.
For example, Biden’s executive order insists upon “ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within [federal government code].” What it doesn’t do, however, is identify just how this will be done. It’s one of the key challenges for open source software, and one that an executive order can influence but not fix.
SEE: Security incident response policy (TechRepublic Premium)
Following Uncle Sam
It’s exciting that the executive order calls out the importance of securing open source software, but perhaps not surprising. As Bob Dunn, vice president, global governments, at Juniper Networks. wrote, there are a number of factors pointing to increased adoption of open source within the U.S. federal government. Though it has been easy for agencies to stick with proprietary software, “support for open standards is growing and may be reaching a tipping point in federal IT departments,” Dunn noted.
One of those factors has been Recordon and his open source roots.
And while this executive order only applies to software used within the federal government, the reality is that it will have knock-on effects well beyond Washington D.C. If it were an outrageous demand (i.e., to know what’s inside the software an organization buys and be able to secure it), then the principles outlined in the executive order would die with it. But they’re not. Given that roughly 90% of all software includes open source components, according to pretty much every analysis I’ve seen (including this one from Sonatype), and can comprise as much as 80% or more of a proprietary application, as WhiteSource Software found, it’s important that companies be able to inventory and secure that software but few can.
In other words, we’ve had an executive order remind us of the importance of securing our open source supply chain, but don’t have great ways to do that. As Tidelift CEO Donald Fischer wrote about the White House’s cybersecurity executive order, “The hard truth is that most organizations do not currently have a comprehensive understanding of all of the open source software being used in their applications,” much less a way to secure it.
Hope-based security strategies?
All of which is a long way of suggesting that the security posture of most organizations seems to be “thoughts and prayers.” This isn’t a great security strategy.
In that same post, Fischer warned: “According to a recent Tidelift survey, in organizations with over 10,000 employees, 39% of respondents reported that they were not very or not at all confident that the open source components they were using were secure, well maintained, and up to date. Only 16% were extremely confident.”
That’s a big percentage of people who aren’t “extremely confident” that they’re able to secure their software.
SEE: Biden’s executive order faces challenges trying to beef up US cybersecurity (TechRepublic)
Tidelift presents a way to remedy this problem, offering subscriptions that pay software maintainers to improve and secure their code. It’s similar in some ways to a subscription customers might pay to Red Hat (for Linux) or Confluent (for Apache Kafka), but addresses a broader array of components that customers may depend upon. It’s an interesting approach to a complicated problem, but it is a complicated problem, one that isn’t easily fixed by one solution.
For example, Kim Lewandowski, a member of the Open Source Security Foundation’s governing board, said, “We’ve seen some maintainers where they don’t want the money, or can’t take the money, or simply can’t apply it for things that we need.” A subscription to Tidelift can help cover some of the costs of securing important software, but money isn’t always the solution, to Lewandowski’s point. The OpenSSF is thus looking at different options to corral industry resources to better secure open source software.
Sometimes that will involve donations to project maintainers. Sometimes that will mean employment for them at a company that encourages them to contribute. There doesn’t seem to be One True Way™ to fund open source sustainability, so applying multiple ways toward the goal of sustaining and securing open source software is critical.
Disclosure: I work for AWS, but the views expressed herein are mine.