Yesterday, Tidelift CEO and co-founder Donald Fischer sat down with Techstrong TV’s Michael Vizard to discuss the latest government requirements and what they mean for DevSecOps teams and the open source software supply chain. You can watch the video in full by following this link—or read on for some highlights:
Mike: What is going on with this? It seems like it’s a work in progress—is this going to be continuously updated? What can we take from what we know right now and act on? How severe is all of this?
Donald: The latest news in this secure software supply chain conversation was a new memo with some clarified guidance and additional information from the U.S. government released on June 9th called M-23-16. It’s clarifying the ideas and programs that were introduced in M-22-18 last September. When you look past the letters and numbers, there’s some pretty specific requirements that are being reemphasized as well as clarified. There’s a lot of good information for organizations to be paying attention to and to help comply with these government requirements.
Mike: With some of the requirements there's a certain amount of forgiveness so long as you are willing to be forthcoming about where you are in the process of fixing things. That may be the IT equivalent of a get-out-of-jail-free card, or at least postponement.
Donald: I think it’s less of a get-out-of-jail-free and more like a plan to get to where everyone needs to be. A couple of the things coming up in the clarifications in this latest announcement from the Office of Management and Budget is that there were some questions around the dates set forth last September that are coming around right now (June 2023) when the requirements were set to take effect. This new memo gives a little bit of an extension, as some of the government agencies need to finish some of their work around specifying the format for attesting to secure software development practices. The dates are now going to be relative to the final version of that form. It’s buying organizations another couple of months to get their arms around these requirements.
This part about a mechanism to get from non-compliance to compliance has also been clarified in this most recent announcement. There was a hint of it in the September guidance, a brief mention of a plan of action and some milestones. But this new update that came out a couple of weeks ago gets into more detail on how that’s going to work. Basically, the way that it’s going to happen is that organizations, if they can’t provide all of the required attestations by the due date, they’re at least going to have to show a compelling plan for how they’re going to get there, and a timeline their organization is going to follow to make these attestations about how their software is being securely developed.
Organizations still need to be engaged right now. Maybe they don’t have to complete the whole plan and they’re not in 100% compliance by the deadlines, but they have to have a plan that is going to be believable and acceptable by U.S. government agencies that they’re looking to be a supplier to in order to be able to continue doing business.
I think it’s good news that the government is acknowledging that this is a big lift to a) get this figured out and b) to do all the hard work necessary to ensure all these secure development practices are being followed. And they’re going to be realistic and understand that maybe it can’t all be done at the snap of your fingers, but what can be done by these due dates is to get a plan in place and to get together your solutions and partnerships to be able to provide these necessary attestations.
Mike: Should organizations start putting their processes in place today to drive this? Because many of them will say that it’s still being updated, so we’ll just wait. But is waiting a strategy or is waiting begging for trouble?
Donald: I think it’s a poor strategy to wait, especially because one of the other clarifications in the guidance that just came out is what the penalties are for organizations that don’t comply. Again, compliance can include having a compelling plan of action and milestones to be able to make the necessary attestations. I’ll quote the language of the memo in terms of what the downsides are for doing nothing:
“The federal agency must discontinue use of software if the agency finds that the software producer’s documentation is unsatisfactory or if the agency is unable to confirm that the software producer has identified the practices to which it cannot attest, documented that practices that they have in place to mitigate associated risk, and submit a plan of actions and milestones to the agency.”
Burying your head in the sand and hoping it goes away seems to be a pretty poor strategy, especially if you’re currently a supplier to the U.S. government and you count on that business, or if you’re looking to become a supplier to more federal agencies, or sell more products and services to the U.S. government.
Mike: Do you think this will drive more maturity of DevSecOps workflows? It feels like we’ve been banging on that drum for a couple of years now with mixed success. Do you think that that’s going to force the issue?
Donald: I see that happening. My conversations all day, everyday are with organizations taking this seriously, where this is of existential importance to their organization in many cases. Keep in mind, the U.S. government is the largest buyer of goods and services in the world, and that’s as true for IT as it is for other domains. I think that this is putting the focus in the right place. This is hard, but it’s doable. The mandatory secure standards that the industry is being pointed to comply with are pretty reasonable.
They’re basically best practices for secure development—they’re things like having a secure build environment, code signing, using standard secure development tools and practices to ensure that your software is secure by design, secure by default. It’s good for the government consuming these things, it’s good for everyone else, every organization that consumes these products, and ultimately it’s good for the software producers as well because they’re going to be better off if the products that they ship and provide to the government or private industry head off the security vulnerabilities that might otherwise come to pass.
Mike: As you think through this whole issue, do you think other organizations will enforce similar mandates? Will corporate entities and enterprises look at what the government is doing and say, yup this is what we want to have happen with all our other suppliers as well.
Donald: It’s very clear the intent of the U.S. government’s policies here is to use the purchasing power of the U.S. government, not just to uplevel their direct suppliers but to uplevel the private sector as a whole. You see the U.S. government pulling the industry in this direction and it’s going to be a, fortunately, cascading set of requirements that flow through to direct suppliers of the U.S. government then to the suppliers to those suppliers—the third party and fourth party suppliers. That will get to a better outcome that again benefits the U.S. government agencies using this software directly, but it also has the express intent of leveling up the private sector as a whole for everyone doing business in the U.S.
And one of the cool things is with open source software, it actually has a global positive impact because open source is an international phenomenon. The improvements that happen to secure development practices for open source projects, by mandate of these U.S. government policies, everyone around the globe gets the benefits of those.
Mike: What's your best advice for folks about how to get started down this path? Folks have had scanners for their developers, they’ve had a mix-and-match of various tools—but I’m not quite clear there’s been a comprehensive approach to this thing, and it’s not quite clear to me that developers have really enjoyed cybersecurity. What’s the right path?
Donald: Part of the path that I’ve been focused on most intently, I think the hardest part for organizations to solve, is the majority of their application code which isn’t even written by developers on the payroll of their organization, it’s the code that comes from third party open source repositories. We typically see that third party open source code makes up 70% or more of the code in modern applications. That code is subject to all these requirements. It’s explicitly included in the scope of what organizations need to provide secure software development attestations for.
I recommend that organizations start with the biggest piece of their software estate and also the one that’s going to be most challenging to get after, and look at emerging capabilities in the marketplace. My organization, Tidelift, has a unique capability here where we’ve partnered directly with the independent open source maintainers behind thousands of the most widely used open source projects and we compensate these open source maintainers to both follow these specific, mandated secure development practices as well as to convey the information that organizations need—the attestations about what was done for what versions of the software so that organizations can access that, produce their documentation, produce their reports and so on to be able to make the required attestations or to make a record of what has happened.
All organizations need to be paying attention to this now and I recommend that organizations go and look in the market for solutions like Tidelift that can help them get the job done.
Mike: At the end of the day, you gotta get started somewhere, and I know that you think that there’s all these open source developers out there that are writing code for the love of it, but it turns out they all have jobs, hobbies, and other things to do and compensation drives behavior.
— — — — — —
For a summary of these regulations and a timeline breakdown, stop by our government open source cybersecurity resource center. You can also learn more about Tidelift and how we pay maintainers to validate and keep to industry and government standards.
50 Milk St, 16th Floor, Boston, MA 02109