Skip to content

OMB M-22-18: Get ready for grilling

    
OMB M-22-18: Get ready for grilling

Do you swear to tell the truth about your secure software development, the whole truth and nothing but the truth? 

If you said “Yes,” are you sure?

In this episode of Contrast’s Code Patrol podcast, Contrast CTO Jeff Williams says he doesn’t think most software producers can take the heat in the new transparency oven of the M-22-18 memo from the federal Office of Management and Budget (OMB). The memo (PDF) — M-22-18, published on Sept. 14, 2022 — is clear in setting expectations for federal agencies when it comes to using software that’s potentially hiding buggy libraries or other threats a la Log4Shell, SolarWinds and other supply-chain attacks. 

Some developers have blanched. Some fear that the transparency will make it easier for hackers to attack. Better to hide that information away, the thinking goes, aka security through obscurity. Others think that the requirements will slow development time or that Software Bills of Materials (SBOMs) will be unwieldy. 

Williams’ response: “Having information about how the software was developed doesn't help an attacker,” he says. “It doesn't help them to know that the developers were trained in security. It doesn't help them to know that the developers followed this [software development] life cycle or that life cycle. It doesn't help them to know what tools were used on that code. 

“Hackers can attack your applications,” he continues. “They don't need any of that stuff. SBOMs don't help attackers because attackers can just look at the software and know what libraries are part of it. So this idea that keeping information about how security was done secret doesn't help the hackers, but keeping it secret definitely helps the attackers, because it allows this ecosystem to let vulnerabilities fester and not get fixed. And so by being transparent, it'll raise the bar for everyone and make it much harder for [them to] attack.”

No more selling junk apps made in junk factories

The memo itself is dry as dust — subsection 4e(i)(F) of E 14028, anybody? —but pull back the covers, and it’s “actually really pretty stunning,” Williams says. “The government has never interfered in the software market like this. Mostly they just let companies, you know, build whatever software they want, put whatever apps out there they want and [then they’re] like, ‘Hey, we're the government. We'll buy it. Consumers can buy it. It's fine.’” 

The deadlines are right around the corner. The memo gives software producers 270 days for “critical” software or 365 days for everything else from the day the memo was released to complete and return self-assessment forms. 

Up until then, basically, it has been and it will be A-OK to sell crud and to hide away your cruderrific security practices. Published as a follow-up to President Biden’s May 2021 Executive Order 14028 on Improving the Nation’s Cybersecurity, M-22-18 — what only looks like a dry memo — actually represents dramatic transparency into what companies are doing to secure the code they’re producing. 

Software producers will have to document the ways they’re building software, how they’re testing it, how they’re training developers and how they’re ensuring that there are no vulnerabilities. Those are all the things that you'd expect to do in a secure software development process, but soon, they’ll need to be public about it.

“If you're a company and you're making software and you're not proud enough of the way that you're building software to be open and transparent about it, then you're gonna have to make some changes in the next six months,” Williams says. “Potentially big changes. You're not gonna be able to get away with having a backlog of vulnerabilities sitting around.”

No more passing off pockmarked apps, and that means for everybody, not just for federal agencies. We’re talking about the code that protects your finances, your elections, your healthcare, the country’s military defense and everything else that matters in your life. 

“I think we have a right to know about the security of that code,” Williams says. 

Is your company complying with all the parts of NIST’S Secure Software Development Framework (SSDF)? Many organizations won’t be able to answer that in the affirmative, he predicts. Now’s the time to try it out, to go through the requirements and make yourself an attestation for a few year projects and figure out where you have gaps. Get in front of it before next year, because deadlines are coming up fast. 

Already great at making software? Got a great security program in place?

Nice going: This shouldn’t cause you any fear at all. All you have to do is write down what you're doing. 

Everybody else? 

Now’s the time to start. Have a listen to the podcast. Get going on the OMB work with Jeff’s blessing, and may the security road rise up to meet you. 

Listen Now




Lisa Vaas, Senior Content Marketing Manager, Contrast Security

Lisa Vaas, Senior Content Marketing Manager, Contrast Security

Lisa Vaas is a content machine, having spent years churning out reporting and analysis on information security and other flavors of technology. She’s now keeping the content engines revved to help keep secure code flowing at Contrast Security.