U.S. Government Requirements and DevSecOps – Donald Fischer, Tidelift

This is Techstrong tv. Hey guys, thanks for the throw. We're here with Donald Fisher, c e o, for Tide Lift, and we're gonna be talking about the latest guidance from the White House about how to manage your software supply chains.

There is a lot of nuance and maybe even a few loopholes that we want to dive in. And Don, welcome to the show. Great to be here.

Thanks for, uh, covering this important area. So what is going on with this? It seems like it's a work in progress.

Is this gonna be continuously updated because nobody quite really likes to be waiting on pins and needles for the next update. So what can we take from what we know right now and act on and, and just how severe is all this? Yeah, so, um, the, the latest news in this whole, uh, secure software supply chain conversation was this, uh, new memo with some clarifi clarified guidance, uh, and additional information from the US government, uh, released on June 9th.

It's called M 2316. Uh, they have all, each of these memos has a catchy, uh, name to go with it. It's actually clarifying a bunch of the, um, ideas and programs that were introduced with, uh, M 2218 last September.

Um, but when you look past the, you know, letters and numbers, there's some, uh, pretty specific, uh, requirements that are being, uh, kind of re re uh, uh, uh, emphasized, uh, as well as clarified. So there's some good info in here for organizations that need to, uh, be paying attention to and to comply with these, uh, US government requirements. It seems like 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.

So that seems to be a little bit of nuance, but maybe, you know, highlight that for folks cuz I think that, that maybe the it equivalent of a get outta jail free card or at least postpone it. Yeah, I think it's like I, um, less of a get outta jail for free and more like a, uh, a plan to get to where everyone needs to be, I think is the way to think about it. So, you know, a couple of the things coming up in the, in the clarifications with, uh, this latest, uh, announcement from, uh, the Office of Management and Budget, um, there was some questions around the dates.

What were the binding dates going to be? Because when that had been first, uh, set forth, the dates last, uh, September, they were coming around right about now. I mean, it's June, 2023 as we're having this conversation.

And that was when the, um, requirements were set to take effect. So one of the things the, um, memo does is it clarifies, gives a little bit of a extension there because, um, the, some of the government agencies need to finish some of their work around, um, specifying the format for attesting to secure software development practices. So the dates are now gonna be relative to the final version of that form, but it's not pushing it out too, too far.

It's basically buying, uh, organizations another couple of months, uh, you know, um, uh, to, to get their arms around these requirements. Now this part about, um, you know, a, uh, mechanism to get from non-compliance to compliance, that's also, uh, been really, um, clarified in this, uh, most recent announcement. There was a hint of it in the, uh, September guidance.

There was a brief mention of a plan of action and milestones, but this new update, uh, that came out a couple weeks ago, it gets into a lot more detail as to, um, how that's going to work. And the, basically the, the way that it's going to um, happen, uh, is that organizations, if they can't provide all of the required attestations at the, uh, by the due date, they're at least going to have to show their plan, a compelling plan for how they're going to get there, and a timeline that their organization is going to follow to be able to make all of the attestations about how the software is being securely developed. And so organizations still need to be engaged right now.

They maybe don't have to complete the whole plan and be a hundred percent in compliance by the deadlines, but they need to have a plan that is going to be, uh, believable and acceptable by the US federal government agencies that they're, um, looking to be a supplier to in order to be able to continue doing business. So I actually think it's good news, um, that the government is sort of, um, acknowledging that, hey, this is a big lift to a get this figured out. And then to do all of the hard work that's necessary to ensure these secure development practices are being followed.

Um, and we're gonna be realistic and understand that maybe it can't all just be done with a snap of the fingers, but what can be done between now and these due dates is to get a plan in place and put together your, um, solutions, your partnerships to be able to, um, provide these necessary attestations. Let's hear your sense of should organizations start putting the processes in place today to kind of drive to this? Cuz many of them will kind of say, well, it feels like it's, uh, still being updated and I'm not quite clear when things are gonna happen, so we'll just wait.

But is waiting a strategy or is waiting just begging for trouble? I think it's a poor strategy and, uh, to just wait. Um, especially because one of the other things that was clarified in this new update of the guidance that just came out is what the penalties are organizations that don't, uh, comply.

And again, compliance now can, uh, include having a compelling plan of action and milestones to be able to make all of the necessary attestations. So I'll just quote the, the language of the, um, of the memo. It says, uh, in terms of what the downsides are for not for, for, for just doing nothing.

Um, the federal agency must discontinue use of the 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 the practices that they have in place to mitigate associated risk and submit a plan of actions and milestones to the agency. So, um, you know, just, uh, bearing your head in the sand and hoping that it goes away seems to be a pretty poor strategy, especially if you're currently a supplier to the US government and count on that business. Or if you're looking to become a supplier or a supplier to more federal agencies or sell more products and services to the US government.

Do you think this will drive, um, more maturity of DevSecOps workflows? It feels like we've been, you know, banging on that drum for a couple of years now at mixed success. So do you think that that's gonna force the issue?

I see it happening. I mean, you know, my conversations all day every day are with organizations that are taking this seriously, um, where this is, you know, uh, of existential importance to their organizations in many, in many cases. Um, keep in mind the US 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.

Um, so I think that this is putting the focus in the right place, and this is hard, but it's doable. And the mandatory, um, uh, secure development standards that, uh, industry is being, uh, pointed to comply with are pretty reasonable. I mean, they're basically best practices for secure development.

They're things like, you know, having a, uh, secure build environment, uh, you know, uh, code signing, um, using standard secure development tools and practices to, um, ensure that your software, uh, is secure by design, secure by default. Those are some of the phrases that the, uh, government, uh, uh, teams are using to, to describe the goal here. Um, and that's good for the government as a consumer of these things, but it's also, it's good for everyone else, uh, every other organization that consumes these products.

And ultimately, it's good for the software producers as well because they're gonna, they're gonna be better off if the products that they ship and provide to the government and provide the private industry are head off a lot of the security vulnerabilities that might otherwise, um, come to pass. As you think through this whole issue, do you think other organizations will enforce similar mandates? I mean, we will corporate entities and enterprises look at what the government is doing and say, yep, this is what we wanna have happen with all our suppliers as well.

Yeah, it's, it's very clearly, um, the intent of the US government's policies here is to use the purchasing power of the US government, not just to, um, uplevel their direct suppliers, but to uplevel, uh, the private sector as a whole. I mean, they just have straight said that in briefings on, uh, the National cybersecurity strategy and a number of these, um, mandatory, um, requirements and guidance that have come out. So, um, I think you see the US government pulling, uh, industry in this direction, and it's gonna be a, um, fortunately cascading set of requirements that flow through to direct suppliers to the US government, then to the suppliers, to those suppliers, the so-called third party and fourth party suppliers in the sort of like business, um, supply chain there.

Um, that will get to a better outcome that again, benefits both, um, you know, US government, federal agencies that are using this software directly, but it also, um, has the express intent of leveling up the private sector as a whole for everyone doing business, um, in the us. And one of the cool things is with open source as this pertains to open source, um, it actually is a global positive impact that happens because of course, you know, uh, open source is an international phenomenon. The, uh, improvements that happen to secure development practices for open source projects by mandate of these US government policies, everyone around the globe gets the benefit from those.

So what's your best advice to folks about how to get started down this path? I think, you know, folks have had scanners for their developers, they've had a mix men match of various tools, but I'm not quite clear there's been a comprehensive approach to this thing, and it's not clear to me the developers is really enjoying cybersecurity, so what's the right path? Yeah, well, I mean, the, the part of the, the path that I've been, um, focused on most intently is I think the hardest part for organizations to solve, which is the majority of their application code that actually isn't even written by developers on the payroll of their organization.

It's the code that comes from third party open source repositories, right? And we typically see that, um, third party open source code makes up 70% or more of the code in modern applications. So, um, that code is subject to all of these requirements.

It's explicitly included in the scope of what needs to be, um, what organizations need to provide secure software development at test attestations for. So I recommend that organizations start with the biggest piece of their software estate and also the one that's gonna be perhaps most challenging for them to get after and, you know, look at emerging, uh, capabilities in the marketplace. My organization, tide Lift has a unique capability here that we're bringing to bear for organizations where we've partnered directly with the independent open source maintainers behind thousands of the most widely used open source projects.

And we basically, we, we actually compensate those independent open source maintainers to both follow these specific mandated secure development practices as well as to convey the information that organizations need, the attestation 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 either be able to make the required attestations or to have a record of, um, what has happened. So all organizations need to be paying attention to this now. Um, and you know, I recommend that o organizations, uh, go and, you know, look in the market for solutions like Tide Lift that can help them get the job done.

All right, folks. Well, you heard it here. At the end of the day, you gotta get started somewhere.

And I know you think that there's all these open source developers out there that are just writing code for the love of it, but it turns out they all have jobs, hobbies, and other things to do, and compensation still drives behavior. Hey, Donald, thanks for being on the show. Glad to be here.

Thank you. All right, back to you guys in the studio.