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.

The National Cybersecurity Strategy makes the case that there must be a shift of the burden for cybersecurity from the consumers of software to the producers of software. We are now seeing indicators of how the US Government intends to drive the changes they believe are necessary. One of the requirements they are implementing is that all software vendors attest that they developed their software in accordance with NIST 800-218, the Secure Software Development Framework, or SSDF. In 2023, they released some draft language to this effect, and requested public input. All indications are that they still intend to implement this requirement, and it no longer a question of if, but when.

I thought I would do a walkthrough of the guidance provided by NIST 800-218, and to highlight where Checkmarx can help our customers to become compliant with it. I’m hesitant to use the term compliance, since if you read the actual language in the SSDF, you will quickly realize that it is a set of principles and guidelines instead of objectively measurable compliance requirements. This is going to make it difficult to verify any company’s attestation to being “compliant” with SSDF, and I do wonder if there will be some additional guidance on how the Government intends to verify compliance.

NIST 800-218 is currently in version 1.1 and came out in February 2022. From a NIST standard point of view, this is current and applies to modern software development life cycle (SDLC). It is also important to note that some in the government describe the SSDF as a best business practice.

This document recommends the Secure Software Development Framework (SSDF) – a core set of high-level secure software development practices that can be integrated into each SDLC implementation.^[i]

So, it isn’t a compliance framework  – it’s a set of principles that should be followed. This is an important distinction, since Checkmarx primarily supports the implementation of those practices. The practices are implemented through a combination of tools such as Checkmarx, in conjunction with the relevant processes and procedures being put into place.

One of the most interesting aspects of the SSDF, is that NIST went as far as to include Notional Implementation Examples. I love this, as it clearly identifies what at least NIST thinks would be an appropriate implementation. Overall, the SSDF is broken up into four (4) practices: Prepare the Organization (PO), Protect Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Under each practice is a set of tasks, and for each task you will find the notional implementation examples.

If I was the CEO being asked to attest to SSDF compliance, I’d be asking my team to replace the Notional Implementation Examples with our own implementation details. The fuzzy part comes into the subjective assessment around whether your implementation details are sufficient to state that you meet the intent of the task. This may be why we haven’t seen the hard requirements being implemented yet by the government. They must have some concern that vendors will claim compliance to SSDF without an implementation that would be sufficient in the government’s opinion. Given that this will become a contractual obligation at some point, the government is going to have to clarify what is sufficient.

For the rest of this post, I’m going to list out the SSDF Practices and Tasks and provide some insight into how Checkmarx can support SSDF implementation. I’ll offer my standard disclaimer here, “your milage may vary”. It all comes down to how you implement Checkmarx and how you define sufficient. For this blog, I’m going to simply provide if Checkmarx a) Directly Supports, b) Indirectly Supports, and c) Not Applicable.

This assessment is based on all the current capabilities of all the different scanning engines within the Checkmarx One platform, as well as the Checkmarx CodeBashing training application. If any of these components either completely or significantly satisfy the task, then I’ve graded it as Directly Supports. If it helps the customer satisfy the task but is not the major tool to meet the task, I’ve graded it as Indirectly Supports. If the task doesn’t have anything to do with the capabilities of CxOne, I’ve graded it as Not Applicable.

How well CxOne helps you satisfy the SSDF is highly dependent on how you implement CxOne and how as an organization you complete the SSDF tasks. 

So, as shown above Checkmarx has the ability to significantly assist any software developer in meeting the requirements defined in NIST 800-218. As always, implementation matters in how well Checkmarx supports a developer, but that is for a later discussion. If you have any questions on this or would like to have a deeper discussion on implementation in support of SSDF, please reach out to us.

^[i] From NIST 800-218, Abstract

Previously, the US government had avoided calling for tight civil and criminal liability for producers of software that isn’t secure. “Pillar Three – Shape Market Forces to Drive Security and Resilience” hits directly on this. 

Pillar Three recommends that Congress pass legislation to set national cybersecurity requirements and shift liability from customers to software producers. In fact, it goes so far as to propose a safe harbor concept for companies compliant with NIST SP 800-218, and to open up corporate liability through invalidating the indemnification clauses found in every commercial software license. If successful, this would force companies to strengthen their software security or likely go out of business.

In reality, this Congress is unlikely to pass the required legislation. Even so, this clearly indicates where the federal government is heading, and all software companies should start planning for when this becomes law. The executive branch can’t force Congress to pass laws, but as the world’s largest IT buyer, it’s willing to use its enormous buying power to push toward full implementation of the strategy.

The Implementation Plan is a clear indicator of this and includes several initiatives worth noting:

• 1.1.2 sets cybersecurity requirements across critical infrastructure sectors.
• 1.2.1 scales public-private partnerships to drive secure-by-design and secure-by-default.
• 3.3.1 explores how the government can implement the liability framework.
• 3.3.2 addresses software bills of materials and how to reduce the use of unsupported software.
• 3.5.1 involves updating Federal Acquisition Regulations to strengthen cybersecurity requirements.
• 4.1.2 promotes open-source software security.
• 4.4.1 drives adoption of cyber secure-by-design principles in federal projects.
• 4.6.1 focuses on a national cyber workforce and education strategy.
• 5.5.4 promotes the implementation of Cybersecurity Supply Chain Risk Management key practices.

Among the many initiatives detailed in the Implementation Plan, these highlight the strategy I addressed earlier. Various federal agencies are acting on these now to improve software security before it goes into production. This is proactive and preventative cyber defense.

What role does Checkmarx play in this? Checkmarx One is our cloud-native SaaS AppSec platform, and it provides a wide range of security testing tools for developers during software development and in production, as well as providing built-in security training for developers.

Here are the components of Checkmarx One, and how they align with the National Cybersecurity Strategy and its Implementation Plan.

Checkmarx One supports most if not all these initiatives, mostly through direct testing of the source code or configuration data to ensure that the application is actually secure. What aren’t included in the above table are the liability-related initiatives. Once implemented, these will be the underlying driver for all software developers that sell to the U.S. government. They will likely set a new global trend toward regulating the security of software purchased by all governments worldwide. 

At some point, and it looks to be soon, software developers will have to meet secure development and secure implementation requirements to sell software to the government. This will include not only delivering a software bill of materials, but also mitigating the risks associated with using open-source software. It won’t just be SBOMs that become a normal way of life; required compliance with NIST 800-218, the Secure Software Development Framework, is also likely.

We are at an inflection point for delivering software to the government. Security is quickly rising as a priority, competing with product features. As the government continues to implement this strategy, companies will be faced with either adopting new tools to improve their secure development processes or walking away from selling to the federal government. Walking away may work for some companies, but once this has settled down a bit, we can expect large enterprise customers to adopt similar requirements.

Throughout the evolution of this strategy and implementation, Checkmarx remains well positioned with Checkmarx One to provide a single AppSec platform that helps companies meet these challenges and requirements head on. As one of the public sector leaders within Checkmarx, I say GAME ON!

Want to learn more about the Checkmarx One enterprise AppSec platform and how it aligns with this new government strategy? Request a demo today.