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.

Another Caveat

The next caveat to consider is that SBOM reports should follow a standard format that includes detailed information about each involved component. At a minimum, it needs to give the component’s name, supplier name, version, hashes and other unique identifiers, dependency relationship, author of SBOM data, and a timestamp. The report also needs to cover every software modification and update to reflect the current status of the project. An SBOM report is best accomplished using an automated process that is integrated into your CI/CD pipeline.

SBOM Methodology That Actually Enhances Security

The first and most fundamental task in generating an SBOM is analyzing the software dependencies, which is a natural undertaking for software composition analysis (SCA) solutions such as Checkmarx SCA. However, the ultimate purpose of an SBOM is not just providing a list of ingredients, but to identify potential risk. A standard SBOM provides a list of ingredients but no simple way to detect and measure risks associated with third-party dependencies. So, what else do you need to enhance software security? Simple: vulnerability and license risk information.

To meet the need for a more comprehensive SBOM, Checkmarx SCA leverages our existing infrastructure for identifying vulnerabilities, in addition to license and supply chain risks, to supplement the standard SBOM info. This creates an SBOM that provides valuable insight into the risks associated with your third-party components instead of just a list of ingredients. This methodology exceeds the requirements for what a simple SBOM contains.

The SBOM reports generated from Checkmarx SCA use the existing CycloneDX SBOM format, and SPDX and SWID formats will be added soon. The reports also provide additional “property” fields showing important risk data that organizations need to know about. The reports can be exported in XML or JSON format, making them easy for organizations to consume, track, and update.

How to Generate an SBOM from Checkmarx SCA

Using the Checkmarx SCA User Interface

• Navigate to the Scan Results screen for the most recent scan of the desired project.
• Click on the “SBOM” button. The SBOM configuration dialog is shown below:

• Select the SBOM standard. Currently, only CycloneDX is available.
• Select the output format: XML or JSON.
• Click “Generate SBOM.”

The SBOM report will be downloaded and can be viewed on any standard XML/JSON viewers.

How to Add CI/CD Integration

Checkmarx SCA provides plugins and CLI tools for various CI/CD pipelines. One method for running Checkmarx SCA scans via CLI commands is the CxSCA Resolver, which is an on-premises utility for resolving and extracting dependencies. The following section describes how to export SBOM reports using the CxSCA Resolver.

How to Generate SBOM Using SCA Resolver

An SBOM report can be exported via the CxSCA Resolver CLI using –report-extension and report-type arguments.

Example:

“./ScaResolver -s /home/jack/src/MyApp -n MyApp -a Checkmarx -u jack -p ‘demo123!’ –report-extension Xml / Json –report-type CycloneDx”

SBOM Content

Below is a view of the SBOM content, which is part of the SBOM Checkmarx SCA generates.

The standard SBOM fields are ID (purl), Component Name, Version, License, and Hashes. All of these are included in every Checkmarx SCA SBOM as required fields.

In addition, we add a Properties section with extended information  about the risks associated with each library.

SBOM Component Dependencies

Below is a view of the component dependencies, which is part of the SBOM Checkmarx SCA generates.

Each component contains its dependent components, and each dependency section contains a set of required fields and a Properties section.

Conclusion

Checkmarx is dedicated to helping organizations secure the software they develop, one line of code at a time. In response to the proliferation of open source usage, recent supply chain attacks, and the executive order mentioned in the previous post, you can use Checkmarx SCA to easily create and maintain an SBOM of your own. Plus, you’ll get real-time risk data about the open source found in your codebase to help you manage your own risk better.

In the next blog in this SBOM/Software Supply Chain series, we’ll discuss the top three software supply chain risks you need to know about.  

To see an SBOM being created live, don’t hesitate to request a demo.

Download our Ultimate Guide to SCA Here.

In this same way, it’s important to know what’s in your software before using it, so you know its ingredients are safe for your organization to consume. Since most software today is made up of open source components, combined with proprietary code (e.g., business logic) that makes everything work, having a list of all open source ingredients in the software you consume allows your organization to manage risk more effectively.

Therefore, leaning on what the manufacturing industry calls a “bill of materials” (BOM), we have the software BOM, or SBOM. An SBOM contains an accurate list of all open source software ingredients found in a software-based product. With this in mind—and due to a number of recent and notorious open source supply chain attacks drawing the attention of security experts, industry advocates, and even the US federal government—the current administration decided to act with regard to SBOMs.

On May 12, 2021, President Biden issued Executive Order 14028, “Improving the Nation’s Cybersecurity,” which states: “The term ‘Software Bill of Materials’ or ‘SBOM’ means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components.”

Security experts agree that an initial step toward the EO’s goal of enhancing software supply chain security is transparency, and an SBOM is now required for anyone selling software to the US federal government and its agencies. So, do organizations that develop their own software in-house, to be used solely to support their own operations, need SBOMs for their own applications? The answer is likely yes.

Why an SBOM for the Software You Develop Makes Sense

In the past, organizations that developed their own software applications primarily did it in-house. Developers and security teams knew the origins of the core components that made up their applications and had full control over the recipe, so to speak. However, this model is no longer acceptable to most organizations, primarily due to time-to-market demands. Management and customers alike expect faster and more frequent releases/updates thanks to their familiarity with some of the media and retail giants that update their applications and release new builds on a daily basis—if not more frequently.

This rapid-release capability is largely owed to more organizations integrating significant amounts of open source into their application stacks. Due to this move, the open source supply chain, community, and contributors are expanding exponentially. Even a weekly build might pull in loads of open source components that may have been updated by the community since the last version in use, and if developers and security teams don’t allow the updates to be performed within their own applications, they will be deploying builds with potentially known vulnerabilities. If any of your applications import libraries from NPM, Maven Central, or any other registry, then you are using open source in your codebase.

If you have complete knowledge of what open source “ingredients” are required to build or compile the applications your organization relies on, then you can mitigate a number of risks when trying to improve the security of your applications. Therefore, if a new vulnerability (e.g., CVE) is issued, you can confirm if you are affected by comparing known vulnerable versions against your existing SBOM. If you have matches, you can quickly determine which issues must be resolved before the next build is released.

Ultimately, having a better view of the open source that your applications depend on will give you a clear view of your own vulnerabilities and associated risks. However, there are quite a few caveats concerning SBOMs that you should be aware of. The first is as follows.

SBOMS Are Not Spreadsheets

Generating an SBOM report may sound relatively simple, but in most cases, it’s not. As you likely know, modern software projects make use of a long list of third-party open source packages, each of which often calls on many other packages as dependencies. This can create an extensive tree of dependencies being used by your software in the form of direct dependencies, dependencies of dependencies, and so on. Simply put, trying to create and manage an SBOM using a spreadsheet is nearly impossible, and if you attempt to manage your open source usage in this fashion, it will likely get out of hand very quickly. 

At the end of the day, SBOMs just make sense. Understanding your own risk profile and doing everything possible to effectively manage and reduce your organization’s risk falls into the realm of due care, which is defined as, “the standard of care a reasonable person would exercise in the same situation or under similar circumstances.” If due care is not being upheld, then your organization, your developers, and your security teams could be viewed as negligent.

In the next blog in this SBOM/Software Supply Chain series, we’ll discuss what an SBOM report should include and highlight the easiest approach to generating a high-quality SBOM report using Checkmarx Software Composition Analysis (CxSCA) solution  .

To see an SBOM being created live, don’t hesitate to request a demo here.

To learn more, don’t forget to join our Technical Meetup Series to dive into topics like SBOM and open source libraries. Checkmarx experts Alex Cohen, James Brotsos, and I will walk you through security vulnerabilities you might not even know you had. We’ll also discuss the latest industry trends and application security best practices. It’ll be an interactive discussion, so bring your questions and pick our brains about how to improve your processes.

Download Our Ultimate Guide to SCA Here

This is why some skeptics wonder if there is a more effective way to leverage this power and convenience without causing more problems in the long run. There should be a way to record all of the parts that are required to compile, host, and run all of the software components of the infrastructure. We call this list a “bill of materials,” and this article will be devoted to explaining how it helps us address the risks of trusting external code.

Bill of Materials for Software Development

The term “bill of materials” (or BOM) is taken from industrial manufacturing. It is a list of raw materials or assembly parts along with the quantities of each item that are needed to manufacture a complete component. You can think of it as the list of ingredients.

The BOM is vital because it serves as a verification document and helps ensure that all of the necessary parts are present and available in the proper quantities. If one part is missing, for example, or if the manufacturer was delayed in delivering the part, then there would be a flag in that BOM showing the issue with that particular part. Here is an example of a BOM file:

We can extend the analogy of the automotive recall to the software industry. This is what we call the Software Bill of Materials (sBOM), and it lists packages and library components. For example, you may have a node.js project where the node_modules folder contains all of the required packages that are used for building and running the application. If some of them turn out to demonstrate vulnerabilities or malicious code that was somehow injected via the registry, then your software pipeline is at risk.

The sBOM should list all packages used by all software components, their versions, their license models, a virus scanner report, and when they were last updated. Each package is traceable to the list of components that are connected so that you can trace the affected components if there is a failed scan. You also want to be able to upgrade or replace them in case of depreciation or a CVE exposure.

Why Do You Need a “Parts List” for Software?

A “parts list” is a list of packages and dependent libraries that your software services need in order to operate. If the programs import libraries from NPM, Maven Central, or any other registry, then you can count them as parts.

If you have complete knowledge of those parts and what is required to build or compile the applications in your organization, then you can mitigate a whole series of issues and risks involved in maintaining those programs.

For example, if a new vulnerability is issued, then you can check if you are affected by comparing the affected versions against your existing bill of materials. If you have matches, you can find out which systems are affected.

Another example would be discovering that a library or dependency has been removed from a registry for whatever reason (such as license changes, legislative requirements, or maintainer decision). In that case, you wouldn’t be able to use that component, and you would have to utilize a different version or consider a replacement. If you maintain an accurate BOM list, you might be able to find alternative parts or libraries that can be replaced. This would mean that you’d have a contingency plan attached to some critical BOM items just in case.

Ultimately, having a better view of the components that your software depends on will give you a clear view of your risks and the vulnerabilities of your components.

Sample “Parts List” Scan

How can we figure out what should be on this parts list? If you ask the developers, they will likely show you the package-lock.json or the Gemfile.lock from their projects. However, these do not include other parts like hardware, OS modules, license types, or any other details.

You can either use automated tools to retrieve that information as part of the CI/CD process or as part of your regular scanning of repos, or you can use an external vendor to manage that for you. For example, to check if some licenses are business-friendly, you can use the js-green-licenses checker from Google:

$ npx js-green-licenses –local ./

This would show you unlicensed or unsuitable packages from a predefined list. However, it only works for npm projects, and it only checks open-source licenses.

If you want to cover all bases, you will have to find all of the tools that show the list of dependencies and include some sort of policy that they must publish their parts list before deploying to production. Once this part is configured, it will be considerably easier to enroll applications and record their bill of materials.

Next Steps

With the general adoption of open source technologies, businesses are taking on the additional risks of vulnerabilities, deprecated versions, and hostile license models.

Before you jump on the bandwagon of the latest sBOM trends, it’s critical that you assess the current security posture of your organization and identify how this change would gain you more credibility and increase your customers’ confidence in your products.

Once your path is clear, it’s important to assess present standards and best practices for compiling the list. You should start by reviewing the ntia website material from top to bottom. When you have the requisite domain knowledge, you can make informed decisions about the appropriate strategy for your organization and establish some baseline policies.

You need to be on top of documenting and capturing any changes or updates; otherwise, if left to their own devices, people tend to ignore them. It’s difficult to know the best way to capture software bills of materials in advance, and since security standards change constantly, it’s incredibly difficult to establish a long-term solution.

Thankfully, there are companies like Checkmarx that can help you with that. By utilizing their SCA solution, you can scan and compile the list of materials for software components. You can check it out and request a free demo today.

Theo Despoudis is a Senior Software Engineer, a consultant and an experienced mentor. He has a keen interest in Open Source Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration. Follow him on Twitter @nerdokto. He can be contacted via http://www.techway.io/.

Download our Ultimate Guide to SCA here.