After several years of silence on software security, the federal government has finally jumped into the breach.
In just the last month the Biden administration released memo M-22-18, published as a follow up to its Executive Order 14028 from May of last year. And don’t forget about the publication, also released in September, of practice guidelines for software supply chain security by the Enduring Security Framework (ESF) Software Supply Chain Working Panel. Add to the list S.4913, proposed legislation in Congress that weighs in on the complex issue of open source and supply chain security.
For federal contractors, that’s a lot of new guidance to consider in a short time. Faced with such rapid changes and developments, let’s take a deep breath and get our bearings. Here are some thoughts on assessing the real impact of the recent supply chain guidance:
Executive orders are not laws
Executive Order 14028 aims to empower the Office of Management and Budget (OMB) to require executive branch agencies to comply with cybersecurity guidelines. The newly published memo, M-22-18, simply fills in some of the blanks from the EO and spells out how that oversight should work.
However, as an EO it does not have either the force or the staying power of a law passed by Congress. That’s important because the next occupant of the White House may sign an order rescinding a previously issued EO - or allow it to continue. There are lots of examples of both. Organizations should also note that EOs are limited in scope. They apply only to executive branch agencies that report directly to the President. That means that EOs are felt unevenly across the government and by contractors doing business with the federal government.
Lots of holes in coverage
Software providers that sell software and services to executive branch agencies are required to comply with the EO and memo. They are expected to fill out standardized self-assessment forms (standard form tbd) when requested. But that will only happen if their products fall into three stated categories: new software purchases, major version upgrades, and software renewals (e.g. software subscriptions). Not covered by the memo: minor software updates releases, directly downloaded open source packages and (critically) software developed within covered executive branch agencies by federal employees or their contractors.
Classified commercial software also gets an exemption from the requirement. It isn’t clear if unsupported or end-of-life software that’s still used by federal agencies would be covered by the requirements of the EO or the subsequent memo, given that such applications may no longer receive software updates.
Why would I lie?
Allowing software providers to “self-attest” to the security of their wares opens the door to abuse, compared with attestation provided by accredited third parties. At the end of the day, the framework for software security presented here functions as a version of the “honor system.” And, in an environment where tens or hundreds of millions of dollars in federal contracts are on the line, we can expect software publishers will feel pressure to make their software security look iron-clad, no matter the truth.
Executive branch agencies that must comply may find that they can’t do so in the accelerated schedule laid out by the memo without disrupting regular business. That’s why agencies can apply for a range of waivers and extensions for the various deadlines laid out in the memo, and for any number of reasons, including a lack of staffing, budget, or expertise.
Even without the benefit of an extension, affected firms have a long runway to comply. The memo gives them 270 days (for “critical” software) or 365 days (for everything else) from the day the memo was released to complete and return the self-assessment forms. In fact, the attestation form won’t be available until 180 days after publication of the memo. It is still unclear which part of the government (CISA or FARC) will produce it.
Not all SBOMs are equal
For all the hoopla about the federal government’s call for software bills of materials (SBOMs), both the memo and the recent practice guidelines are restrained in their embrace of SBOMs as a way to document software supply chain dependencies and manage supply chain risk.
In the memo, for example, SBOMs are offered as an optional requirement that executive branch agencies may place on software suppliers, based on the criticality of the software in question. When used, applicants must generate the SBOM in one of the data formats defined by the National Telecommunications and Information Administration (NTIA) in its The Minimum Elements for a Software Bill of Materials (SBOM) guidance or subsequent guidance from CISA.
But that guidance sets a low bar – not a high one. Vendors must document baseline information about each component in their application (e.g. supplier; component name; component version; dependency relationship; unique identifiers; SBOM author; and SBOM timestamp). An SBOM meeting these minimum standards does not even require a hash of the covered software component, easing the burden on suppliers.
Proposed Senate legislation
Not wanting the executive branch to get all the credit for software security, the legislative branch recently jumped into the fray. Senate Bill S.4913 the “Securing Open Source Software Act of 2022 was introduced on September 21 by Sen. Gary Peters (D-Mich.) and Sen. Rob Portman (R-Ohio).
It covers some of the same ground as the EO while focusing on open source software quality and its supply chain. Unlike the EO, S.4913, if passed as proposed, would stay in force even through changes in administrations. However, it’s only one of a number of bills attempting to strengthen national cybersecurity resilience. And while EOs can take force with the stroke of a President’s pen, the bill has a long and tortured path to walk before it stands a chance of being enacted as legislation.
Rather than sinking efforts to address cyber risk, expect this perfect storm of orders and draft legislation to accelerate the activities of the Biden administration in the hope that it can set the terms of the debate and see its efforts incorporated in some future legislation.
What now?
First, assume that this is not a passing storm. With the focus of the executive and legislative branches on software security and open source, supply chain, and SBOMs, expect a continued strong push towards compliance for any company that sells software and services to federal agencies.
Companies selling software to an executive branch agency within the federal government have anywhere from nine months to a year to complete a self-assessment in keeping with the recent memo. Here are some useful next steps:
- Figure out what impact the EO and memo has on the company. The EO and memo don’t apply to every software vendor. Figure out the extent of the impact and which products and customer relations are bound up.
- Know the deadlines. Full documentation for performing self-assessments will not be available for some time. In the meantime, each executive branch agency may end up having separate timelines and different acceptance criteria. Understand that executive memoranda are often amended and changed, as can the deadlines - for better or for worse.
- Assess open source exposure. If the company ships open-source components, it needs to determine what open source components are used and whether SBOMs are available for them. If not, get an assessment of the security of open source components from a third-party assessment organization (3PAO), if the organization does not want to do its own assessment.
Finally, find good partners. Federal requirements related to software security – including SBOM creation - are a work in progress. It’s important to have the help of other firms to build out conformance statements. That means connecting with vendors that can offer source code assessment, vulnerability scanning, binary analysis, as well as assessment of commercial and open source components.
That sounds like a lot, but there’s plenty of time to get it done so teams can take a deep breath, understand the options, and get to work!
Mario Vuksan, chief executive officer, ReversingLabs
