No one likes paying bills, or at least I don’t. However, what is absolutely worse is finding yourself with an unexpected bill that is coming due. For software developers, there is a big bill coming due in the terms of a Software-Bill-of-Materials (SBOM). While there has been some debate if governments, including the US, would formally mandate SBOMs or let industry self-regulate, this debate is now over. Governments around the world are exploring how to mandate SBOMs for software either sold to the government or sold in a specific market. This post is going to focus on the upcoming bill due to the US federal government, since this is the most near-term bill coming due.
The US government’s Cybersecurity & Infrastructure Security Agency (CISA) and National Security Agency (NSA) summed up the value of an SBOM in their recent publication “Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption”.
SBOMs provide improved visibility into the pedigree of the software that the customer organization is evaluating, deploying, and/or operating within their environment. This increased visibility into all software is critical for proper supply chain risk management and overall enterprise risk management. SBOM content provided to and consumed by customers informs risk management for customer organizations without impacting sensitive intellectual property interests of software suppliers. Even before the SBOM data is consumed by the customer, the customer benefits from the supplier having the SBOM data and the potential to use it to inform risk decisions. This does not guarantee that the supplier will use this data, but having the data is a necessary first step.
If a supplier does not have visibility into their software supply chains, customers should be cautious of the trust placed on that software and its supply chain. While there may not be any currently known active exploits or vulnerabilities, such a supplier may not be in a position to make any claims or assurances. A supplier that provides an SBOM signals its visibility, and the quality of this visibility, into its supply chains.
The Executive Branch has issued multiple cybersecurity guidance documents over the past couple of years – from the National Cybersecurity Strategy, to different Office of Management and Budget (OMB) Memorandums, and to a variety of agency specific planning documents. One of the common threads throughout nearly all this guidance is that software producers should be held to a higher standard when it comes to producing secure software, and that the SBOM is the key deliverable to ensure that happens.
We can (and I do often) debate the actual value of an SBOM within the broader picture of application security as a measure of risk, but that debate is unlikely to persuade the US Government from mandating SBOMs from software vendors. SBOM can be a valuable tool for risk reduction but, in itself is insufficient. In my opinion, it is more important how you use the insight provided by the SBOM to manage risk, than collecting an SBOM itself.
So, what is happening?
Some highlights from what I know as of today:
- The Department of Homeland Security will be mandating SBOMs within all existing and future contracts.
- The Army is formally asking industry on how best it can mandate SBOMs.
- DHS and the Cybersecurity Infrastructure Security Agency (CISA) has started the process of requiring contractors to attest that all software produced was done in accordance with NIST 800-218, which includes SBOMs (sort of).
- The Department of Defense (DoD), General Services Administration (GSA), and National Aeronautics and Space Administration (NASA) has proposed updates to Federal Acquisition Regulation to include mandating the delivery of SBOMs.
- The Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) issued public guidance on how customers of SBOMs can effectively consume SBOMs, and why they should require them from their software vendors.
I suspect this is just the tip of the iceberg given that OMB literally is directing federal agencies to adopt SBOMs through M-22-18. This is no longer a question of if, but rather of when, and how.
I spent 24 years in the Air Force, primarily within the complex DoD acquisition process. I’m going to get out my acquisition crystal ball and forecast how I think this will play out over the next year or so. I think there will be some significant challenges for the US Government to achieve the value they desire from SBOMs, and I will discuss what challenges I think they will have.
All Proposals Will Require SBOMs
We are seeing this trend start already, just search SAM.GOV for SBOM. I expect all Request for Proposals to require the vendor to submit SBOMs. The submission will be mandatory and failure to submit the SBOM is likely to result in being non-compliant and excluded from the award.
The easy contracting approach is to just require the SBOM within the proposal, and the box is checked. I think this approach will be used for a vast majority of acquisitions. I think we will see a subset of the acquisitions that incorporate the SBOM within the technical evaluation process. Once this approach happens, the complications start.
To effectively incorporate the SBOM into the technical evaluation process, the Government is going to be challenged in a) ensuring that the SBOM is comprehensive, b) dealing with what may be false positives, and c) how do you assess it in a protest resistant manner. While this could be a valuable tool in the technical assessment, this will lead to several successful protests before the Government develops protest proof processes to incorporate SBOMs into the technical evaluation.
All Contracts will Require SBOM as a Deliverable
I expect every contract to include an SBOM as a deliverable. I think that this will be the minimum. This doesn’t mean that anyone will look at or use the SBOM for anything. For many, it will be a checkbox to meet agency guidance. Overtime and with software or cybersecurity specific acquisition programs, I think we’ll see the contracts to go beyond just requiring a deliverable.
We see this already in the draft language for the DHS, which requires delivery of an SBOM that certifies that all software delivered to be free from all known vulnerabilities. This is an unrealistic requirement and that opens the discussion on what to do with the vulnerabilities included in the SBOM. Even the DHS understands this, since they continue in their draft language to require the vendor to provide a plan to remediate all the vulnerabilities identified in the SBOM.
As a minimum, I expect all contracts to require an SBOM to be delivered. For software and cybersecurity focused programs I expect:
- Either monthly or quarterly deliveries of an SBOM
- SBOMs being delivered with each software release
- Companies having to provide and maintain a remediation plan – this may be called a Plan of Actions & Milestone (POA&M), a Risk Register, or something new
Security will have Consequences
I see a lot of opportunity to use SBOM’s to influence vendor behavior. I expect that there will be a few attempts at this in the short-term, but we are unlikely to see this broadly adopted until sometime in the future. It will take some time to build up the skill and government resources to do this effectively, and to do so in a manner that a) avoids outright conflict with the vendor, and b) doesn’t drive away the vendors you are interested in from the acquisition to start with.
My experience leads me to two conclusions about incentives: a) the Government is more comfortable doing negative incentives, and b) positive incentives are more effective than negative incentives. So, I’m going to skip the negative incentives and focus on positive incentives.
While Fixed Price Contracts have been all the rage for recent development efforts, I think those days may be numbered. I think SBOMs, and more importantly the vulnerability data can easily be incorporated in both award fee and incentive fee determinations. So, for cost plus contracts, I think the vendor’s profits will get tied to the deliverable of software with objectionably measurable minimum number of vulnerabilities.
My favorite approach here would be the use of a Cost Plus Incentive Fee (CPIF) contract, where the incitive fee is based on the measured security risk posture of the software being delivered. The higher the security posture, the higher the incentive fee is to the contractor. Using third party tools like Checkmarx One, would allow the contractor to know objectively before the software release is submitted to the Government of the measured security posture. The same tooling would be used by the Government to generate the incentive fee. This is important since there needs to be agreement on how the incentive fee will be calculated to be effective, and the contractor must have a good understanding of their score in time to change their behavior. As a cloud native solution, the Government could provide the contractors Checkmarx One accounts as Government Furnished Information/Equipment (GFI/GFE) which can effectively negate the contractor’s argument on how different their internal tooling is compared to the Governments measurements.
I like CPIF because they are supposed to be more objectively measurable and with tools like Checkmarx One, fairly simple and straightforward to implement. This approach can also work with Cost Plus Award Fee (CPAF) contracts as part of the award fee determination process. Award Fees are notoriously subjective, so it may be more of a challenge for a contractor to characterize the return on any investments in improved application security to their profit. Award Fees are a powerful tool for incentives if used properly, and can use objective inputs such as application security risk scores, as well as subjective observations.
Whether the incentive is based on CPIF or CPAF, the reality is that application security will have consequences. Specifically, application security will directly impact the developer’s profit, as it should. The beauty of using a tool like Checkmarx One is that both the developer and the Government will have the same application security picture, and the developer can make an informed decision on the prioritization of application security knowing the potential impact to contract compliance and profitability.
Next Steps
It really doesn’t matter what kind of software you develop; you would be wise to ensure that you have the ability to generate an SBOM. While the US Government is working on mandating SBOMs for software delivered to the Government, the European Union’s draft Cybersecurity Resiliency Act (CRA) is likely to mandate SBOMs for all software sold commercially within the EU. At some point once SBOMs are in place within the US Government, large enterprise customers will be expecting the same. Don’t fight it, figure it out and build out the capability. This includes working with your entire supply chain to ensure you have a complete accountability of the software within your product. But please don’t build SBOMs for SBOM sake. Use SBOMs as a tool to identify and prioritize risks and take action to reduce the risk posture of your product.
Application security is here to stay and SBOMs are an inherent part of application security. I’m excited to be in Checkmarx, where we are leading in the building of tools that help developers meet the upcoming US Government requirements. My passion is to enable innovative companies to sell to the US Government, but you can’t sell if you can’t produce an SBOM. If you’d like to learn more about Checkmarx, and how Checkmarx One can get your company prepared for the upcoming SBOM requirements, please reach out to us. We’d be happy to help you be successful in all thing’s application security, including SBOMs.