From software supply chain security to regulatory compliance and plenty in between, there are many compelling reasons why it’s important to generate an up-to-date, accurate software bill of materials (SBOM).
But given the sheer volume of different software components in modern applications — a recent GitHub report noted that projects analyzed had close to 700 dependencies on average — this can be quite difficult without the right SBOM tools.
Fortunately, solutions like FOSSA (which earned the highest score possible (5/5) for SBOM support in the recent Forrester Wave) automate key parts of the SBOM generation process, saving users significant time and improving data accuracy.
In this Q and A, we’ll address several common questions related to FOSSA’s SBOM solution. We’ve grouped the questions into three categories: you can select from the links below to navigate directly to the respective sections.
If you have any additional questions about using FOSSA to generate an SBOM — or if you’d like to get started with our solution — please reach out to our sales team.
General Questions
There are several SBOM solutions on the market today. Why should we pick FOSSA?
Here are a few of the reasons why organizations use FOSSA’s SBOM solution:
- A software bill of materials is only as good as your inventory of dependencies. So, the foundational element is to have an accurate inventory of the dependencies that we’re using. FOSSA seamlessly integrates into your CI/CD pipeline and leverages the build environment to accurately generate the dependency inventory. We also employ false positive reduction techniques to ensure an accurate bill of materials.
- FOSSA offers seven different export formats (including SPDX); we can also host your SBOM for you. This has the advantage of enabling auto-updates, where the SBOM is automatically updated after each new release.
- FOSSA’s SBOMs are the most customizable on the market. When you generate an SBOM with FOSSA, you can choose to include a wide variety of component data, including direct dependencies, deep dependencies, license summary, project declared license, and any commercial or first-party licenses. Also, depending on the different open source licenses in your project, you may have different obligations. FOSSA automatically computes these obligations based on the license inventory. From there, you can configure your dependency metadata to include (or exclude) details like dependency path, author, homepage, and more to meet the obligations of the open source license.
- You can either leverage our CLI or API to generate SBOMs programmatically as part of your CI/CD process. So, the entire process can be automated from start to finish.
- You don’t have to take our word for it. As mentioned, leading analyst firm Forrester gave FOSSA the highest score possible (5/5) in its SBOM support criterion, writing that our “SBOM support was among the most mature of vendors in this Forrester Wave.”
Which SBOM export formats does FOSSA support?
FOSSA’s seven supported export formats are: CycloneDX, SPDX, HTML, CSV, Markdown, PDF, and Plain Text.
As part of the Biden Administration’s cybersecurity executive order, the U.S. federal government recently published the minimum required elements for a software bill of materials. Does FOSSA support them?
Yes, we do!
As per the executive order (and subsequent guidance from the U.S Department of Commerce and National Telecommunications and Information Administration), the minimum required elements of an SBOM are grouped into three categories: data fields, automation support, and practices and processes. We’ll explain how FOSSA supports each category below.
Data fields: SBOMs must include seven data points that document baseline information about each component. They are: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of SBOM data, and timestamp. FOSSA provides the necessary information for all seven of these fields. (For the unique identifier field, we support Project URL.)
Automation support: The key requirement in the “automation support” category is that organizations export an SBOM in one of three formats (which are all machine-readable and human-readable): SPDX, CycloneDX, or SWID Tag. FOSSA supports the SPDX format. This information can also be made available in JSON, which can be leveraged to generate other formats like CycloneDX and SWID Tag.
Practices and processes: Requirements in the “practices and processes” category cover how and when organizations should convey SBOMs, so tooling is not directly relevant. It is important to note, however, that FOSSA offers SBOM hosting, which can address the “delivery and distribution” requirement in this section.
How can you use SBOMs to help protect against software supply chain attacks?
FOSSA customers often take advantage of our SBOM data to get visibility into the makeup of their software supply chain — and whether any of those components have known security or compliance issues. FOSSA detects these issues very early in the build process, which enables your developers to identify and remediate those problems in a timely manner before those dependencies make it to the built artifact and are distributed.
How much depth in dependencies does FOSSA’s SBOM provide?
There is no limit to how deep we can look for dependencies. FOSSA will identify and generate a comprehensive inventory of all the dependencies your program uses no matter their depth.
You mentioned FOSSA is able to host SBOMs for its customers. Do you also provide a tool to compare different versions and track changes?
FOSSA tracks every commit. As such, FOSSA enables users to compare the results of the previous scan vs. the current scan, or, basically, any two scans at any point in time. From there, you can analyze what changes were introduced, what new dependencies were added, what dependencies were removed, and so on.
How can we get started using FOSSA to generate SBOMs?
Please contact our sales team by filling out the form on this page. We’ll then be in touch to set up an introductory call.
Technical Questions
Is FOSSA run locally or offline?
FOSSA has a SaaS option and an on-prem offering. But even with our SaaS, our CLI runs locally on the client environment. One of the key advantages customers see with FOSSA is that even with SaaS, if you use our CLI, your proprietary code never leaves your premises. So, you can run the CLI locally and generate your SBOM without having to send your proprietary code to FOSSA.
How can I be sure FOSSA isn’t sending my source code to the cloud? Can I see what FOSSA is sending first?
When you use our CLI, we only send the coordinates (name, version, ecosystem) of the dependencies as JSON metadata for analysis. We also offer an on-prem option if you prefer to send no information to FOSSA.
How does FOSSA determine which dependencies are involved in a particular project?
FOSSA uses a variety of approaches and strategies to identify dependencies. FOSSA will first leverage the build environment and the package manager to get the list of dependencies. If that option doesn’t provide a report, then we fall back to other strategies based on the ecosystem to get an accurate inventory of dependencies.
Does FOSSA have APIs? Can I add a FOSSA-generated list of vulnerabilities to my SIEM and other internal dashboards?
Yes. FOSSA has comprehensive APIs to generate reports that surface open issues, be they of the license compliance or security variety. In fact, this is a very common use case. Quite a few of our customers run a scan through FOSSA, use the API to get the open issues, then integrate with their SIEM tool to track them from a single pane of glass.
Miscellaneous Questions
Can FOSSA also generate vulnerability reports?
Yes, FOSSA also provides comprehensive vulnerability reports. These include data like the number of open vulnerabilities, how many vulnerabilities you’ve addressed over a period of time, what they are, CWEs, CVEs, and more.
Is there a way to fail a build in the event of security or license issues being discovered?
Yes. When you integrate FOSSA as part of your CI/CD pipeline, you have the option to fail the build if there are any issues found. You can control the failure sensitivity as well, so if you only want to fail on license issues, or security, or both, you can do so based on those signals.
Where do you see FOSSA fitting into the software development lifecycle: during dev, test, or release? Would you run a production app through FOSSA?
Typically, the first set of repos that customers scan with us are their production applications. Most of our customers end up integrating FOSSA as part of their CI/CD pipeline, as part of the build process. Any time a new change is committed and a build is triggered, a scan happens, and the SBOM is created as part of that process.
