Unless you are a cybersecurity and policy nerd like myself, you might have missed the issuance of Office of Management and Budget (OMB) Memorandum M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.”

With such a dreary title, your eyes would probably not have enough time to even glaze over before you move on. With that said, if you sell software to the federal government, or are a supplier to anyone who does (which is a lot of companies), then you should pay attention.

This memo represents an effort to implement Executive Order (EO) 14028, “Improving the Nation’s Cybersecurity.” OMB is basically how the president controls the executive branch (to the extent he does), and memos and circulars such as this one are how agencies figure out how to implement presidential guidance.

I had some comments on EO 14028 before it was published, and it doesn’t look like any of these were taken into consideration for the initial order or thereafter, so all of those concerns still remain unaddressed. I recommend the government take them into account with future guidance.

With that said, M-22-18 raises some new requirements and questions worthy of analysis. Since time is of essence, I have broken down the memo into its critical components, using the headings provided in the document.

Scope

• The memo applies to federal agencies using third-party software on their systems or that affect their information. This basically means every federal agency. It makes them require that their vendors and suppliers do certain things.

• The memo does NOT apply to “agency-developed” software, which is potentially an oversight. As I have mentioned before, all manner of no-, low-, and full-code are proliferating throughout enterprises, with minimal security oversight. Furthermore, it is hard to imagine that any agency is running a piece of software developed in-house that does not rely on or run on top of third-party software. Thus, it’s not clear where the dividing line is exactly. I tackled this problem previously, and think definitions matter in this realm.

Actions

• The key piece here is the requirement that “Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance.” The NIST Guidance is:

  • The NIST Secure Software Development Framework (SSDF), SP 800-218

  • The NIST Software Supply Chain Security Guidance

• To enforce this, the memo states “[s]elf-attestation is the minimum level required; however, agencies may make risk-based determinations that a third-party assessment is required due to the criticality of the service or product that is being acquired.” This can be an existing FedRAMP Third Party Assessor Organization (3PAO) or one picked by the agency.

  • I see this requirement as opening up a relatively large new market opportunity for existing 3PAOs in the FedRAMP space, as well as new ones who have pre-existing connections with one or more agencies.

  • It also opens up a big can of worms, though, because there will now be a myriad of additional firms coming out of the woodwork to attest to the self-attestations of software companies (you read that correctly). Furthermore, there is no guarantee that any of these non-FedRAMP 3rd party attestations will have reciprocity across government. I see this causing additional attestation/certification/standards sprawl on top of what already exists.

• Separately, it looks like a previous assessment from a FedRAMP 3PAO will satisfy the need for a self-attestation, but it’s not clear what standard must be met, or that the target of the assessment even needs to have passed one. There is a big difference from a security perspective between an organization that failed a FedRAMP assessment at the “Low Impact-SaaS” level and one that passed one at the “High” impact level.

• There is talk of software bills of material (SBOM), but it is pretty vague.

  • For example, the memo requires that, if an agency requires an SBOM, it must retain it unless the software provider posts the SBOM publicly. My question would be, how many versions back does the agency need to retain? SaaSBOMs could be conceivably updated daily, if not hourly. Does the agency need to retain thousands of SBOMs for software that is no longer in use? Some clarification would be good here.

  • Additionally, the memo requires that agencies “shall consider reciprocity of SBOM and other artifacts from software producers that are maintained by other Federal agencies, based on direct applicability and currency of the artifacts.” I frankly have no idea what this means.

• A good addition to the memo is that agencies may consider the existence of a coordinated vulnerability disclosure program in determining whether the software provider conforms with secure software development practices. This is pretty much a no-brainer for any organization to have, so not having one in place should be a red flag.

Responsibilities

• Within 90 days after issuance of the memo, every agency needs to inventory all software subject to the requirements of the memo, specifically identifying “critical software” as defined by NIST, pursuant to EO 14028.

  • This should be fun! I frankly will be amazed if every agency can provide an accurate list of all of the third-party software in use within three months. Many private sector organizations are in a perpetual state of not fully knowing what software they use (aka “shadow IT”) and my experience suggests the federal government is no different.

  • With that said, asset management is a vital task for conducting any sort of risk analysis, and it’s good to see efforts toward this objective.

• 270 days later, agencies need attestation letters from all critical software providers, and then within one year of the memo’s issuance, they need letters from all providers

• Agencies can request extensions or waivers for specific requirements of the memo.

  • Unfortunately, guidance for requesting waivers or extensions won’t necessarily be available until 90 days after the memo’s issuance, which is when the first deadline arrives! A hallmark of working in the federal government is being required to do or get a certain thing but not having any process through which you can get that thing. In such a case, most people just ignore the requirement, which doesn’t help with general adherence to standards or faith in the system.

• The Cybersecurity and Infrastructure Security Agency (CISA) is responsible for developing a common attestation form 120 days after the memo’s publication.

  • This is also bad, because it is quite possible that some work software providers do before issuance of this form will be wasted. Agencies are likely to just demand providers fill out whatever CISA puts out, even if the OMB memo doesn’t require it. Thus, my recommendation would be to hold off on filling out any actual paperwork until this CISA standard is established, while at the same time maturing your processes to comply with the NIST guidance.

• A year and a half after the memo’s issuance, CISA needs to demonstrate early functionality of a government-wide repository for software artifacts and attestations.

  • This also seems late. Basically, the memo will require a rushed, ad-hoc, and manual process followed by a more deliberate and automated one. While this is the way lean software startups iterate quickly toward product-market fit, it definitely is not the way the federal government and its contractors work. I foresee a whole lot of wasted effort resulting from lack of unclear systems and standards being available up front.

Conclusion

The above represents my quick analysis of this most recent guidance, and my hope, as always, has been to provide some constructive criticism and actionable recommendations.

On the software provider side, there are bound to be bureaucratic landmines along the way, and my recommendations are designed to help you navigate around them.

For the government, I always appreciate efforts to secure software, and this is overall a step in the right direction. With that said, there are some key logistical contradictions in the memo, and unfortunately this ambiguity is just going to get decided at the sharp end. And in some cases, not in a way that is advantageous to anyone. When you force people to “check the box,” they usually do.

As always, I stand ready to assist.