The overwhelming number of vulnerabilities reported each year — nearly 30,000 new CVEs were published in 2023 alone — has put a significant burden on application security and engineering teams. Traditional vulnerability management prioritization inputs, tools, and workflows often struggle to keep pace with the volume and increasingly complex nature of these threats.

At FOSSA, we’re committed to helping security teams do vulnerability management more effectively and efficiently. That’s why our product supports EPSS scores, VEX, and multiple other prioritization filters. It’s also why we’re so excited to share that we’re joining the Secure Developer Alliance (SDA).

The SDA is a groundbreaking collaboration led by observability leader New Relic; it also includes Gigamon, Lacework, Aviatrix, and Opus. It will provide a number of resources to help organizations in New Relic’s customer base and beyond handle vulnerability management more efficiently. 

‘We’re very proud to have founding partners that are leaders in the security industry as part of our Secure Developer Alliance,” said New Relic Chief Product Officer Manav Khurana. “With their participation, our aim is to improve the overall security experience for our customers by delivering unparalleled observable security experiences that speed application release velocity, reduces risk, and significantly improves the productivity of developers.” 

“We are so excited to welcome FOSSA as a founding partner in the Secure Developer Alliance. Their expertise in open-source management complements our commitment to ensuring that developers can build securely in the cloud without sacrificing velocity,” shared New Relic Director of Product Krystle Portocarrero. ” This partnership is not just about integrating technologies, it's about forging a new path to provide an intuitive secure development journey. Together we’ll offer a seamless, integrated experience that empowers developers to innovate in the cloud and confidently leverage the full spectrum of open-source software to accelerate their projects while maintaining a strong security posture."

Several of the SDA’s first projects will be focused on education. Together, SDA members will produce courses and training materials covering areas like: 

• Best practices for implementing and managing observable DevSecOps processes and compliance
• Guidance on using technologies and tools conducive to the adoption of observable DevSecOps
• Requirements, benefits, and approaches to DevSecOps for application security

Additionally, we expect to share more information in the months to come about technology integrations that will help New Relic customers and SDA participants efficiently prioritize and remediate vulnerabilities. This will include using FOSSA and New Relic to tie build-time and run-time insights together.

We look forward to working with our SDA partners to progress toward our joint vision of making developer-centric security more attainable. 

For more information on the Security Developer Alliance, please visit New Relic’s website. Or, to learn more about getting started with FOSSA, please reach out to our team.

Sentry is a leader in application performance and error monitoring. Over four million developers and 90,000 organizations monitor the health of their applications using the organization’s products. 

The company has grown and evolved quite a bit since it was launched as an open source side project in 2008, but its open source origins are still apparent today. 

Sentry is a vocal proponent of open source sustainability — a philosophy that includes providing financial support to open source projects and maintainers as well as using open source responsibly. Not only does Sentry fund (to the tune of over $500,000 in 2023 alone) the open source community, but it’s developed and implemented a sophisticated program to track and ensure compliance with software licensing requirements. 

The company’s license compliance program includes a mix of policies, processes, and automation — in the form of FOSSA’s open source management platform. 

“We’re very developer-focused here,” says Gavin Zee, Sentry’s Head of Commercial Transactions. “Our No. 1 goal in running license compliance is to not block our developers and keep things running quickly and smoothly as much as possible. For us, that means automating — and it means automating with FOSSA.”

“The key factors in choosing FOSSA were the policy customization options in addition to the fact that the UI is intuitive and easy for us to use. We’ve now been using FOSSA for several years, and what’s also stood out beyond its features has been the support we’ve gotten from the team.” 

Inside Open Source License Compliance at Sentry

Sentry views open source license compliance as vital to promoting open source sustainability, and it has made significant investments to develop the tooling and processes to manage compliance continuously.

The company’s legal team works closely with its open source program office (and Head of Open Source Chad Whitacre) to draft policies — which are then implemented in FOSSA — concerning open source licenses that can and can’t be included in the products it ships. These policies are based on an approve/flag/deny system:

• Approve: Permissive licenses such as Apache 2.0 and MIT are always allowed in Sentry’s products. FOSSA never creates a ticket or breaks a build for a license on the “Approve” list.
• Flag: Newer or less common licenses that aren’t on Sentry’s “Approve” or “Deny” lists are flagged for further review. 
• Deny: Certain strong copyleft licenses are never allowed in Sentry’s distributed products. FOSSA will break the build and create an issue ticket if it detects a license on Sentry’s “Deny” list. 

Sentry automates the application of these policies by building them in FOSSA, which integrates directly with the company’s CI/CD pipeline. This automation allows Sentry to have confidence that it’s only shipping code with in-policy licenses. It also frees Sentry’s engineers from tracking their licenses in spreadsheets or with other manual processes.

“FOSSA is in our CI/CD and automatically runs license checks,” Zee says. “Every license it detects on our ‘Approve’ list passes right through. If FOSSA detects a license that’s flagged for further review, there’s a quick way for us to triage, review, and clear it with a Slack channel we maintain.”

Managing IP Risks from Source Available Licenses

Source available licenses are similar to open source licenses in that they make source code available, but they differ in that source available does put certain restrictions on using that code. In contrast, open source might place conditions (e.g. providing attribution), but never requirements.

The new Functional Source License (FSL), which Sentry created to provide greater standardization to the source available space, is an example of a source available license. So, too, is the Business Source License (BSL).

The growing popularity of source available licenses means that in-house legal teams, OSPOs, and engineering organizations will be well-served to be mindful of the IP considerations around using source available code — just like they would open source.

Sentry’s software license compliance program accounts for source available in addition to open source. For one, the company’s approve/deny/flag policies cover popular source available licenses. Additionally, since FOSSA detects source available licenses (in addition to open source), Sentry is able to automate the implementation of those policies.

Ultimately, Sentry takes a similar approach to managing source available licenses as it does copyleft open source licenses.

“With source available, it’s important to do the same analysis that you would for weak or strong copyleft,” Zee says. “That means understanding the requirements of the underlying license and knowing what your use cases are and whether your use cases will trigger any of the obligations or violate any of the obligations.”

Sentry and Software Licensing: Learn More

This blog is based on a webinar that Sentry’s Head of Commercial Transactions Gavin Zee and Head of Open Source Chad Whitacre conducted with FOSSA. For a deeper dive into the organization’s software licensing philosophy, we’d recommend you view the on-demand recording.

In addition to guidance on managing compliance with open source and source available licenses, the webinar offers a behind-the-scenes look at how (and why) Sentry created the new Functional Source License.

SPDX 3.0 — a new version of the widely used SPDX bill of materials specification — was released on April 17, and it includes several significant changes from the prior v2.3.

These include the introduction of new “profiles,” which aim to better serve specific SBOM use cases like open source license compliance and security as well as emerging scenarios like AI and data. Profiles can also be used to provide more transparency into the software build process. Additionally, SPDX 3.0 documents have a different structure with more built-in flexibility than the current 2.3.

“SPDX 3.0 is a major upgrade to the specification,” SPDX tech team co-lead Gary O’Neall told FOSSA during a recent webinar. “Some of the drivers and enhancements you’ll find are in areas like simplification — we’ve gotten feedback that if all someone cares about is security, they don’t want to have to learn all the licensing information. If all they care about is licensing, they don’t want to learn about security. So we’re introducing the concept of profiles.

“We’re also making some changes to make SPDX a lot more flexible. The biggest is that you no longer need to wrap everything around a document. What this enables is if you want to make a database of SBOM elements available over the internet, and you want to update them in almost real-time, you can set that up and comply with the SPDX specification. You can go all the way down to the very individual file or even just the individual relationship and make that available. And the standard has all of the linkages in there and the verification information to make that work. So it can be a lot more flexible, especially for online data access.”

Editor’s Note: This blog was originally published in July 2023, based on SPDX tech co-lead Gary O’Neall’s webinar with FOSSA in addition to two other recent presentations: Gary’s session at Open Source Summit North America 2023 and an OpenChain webinar with Alexios Zavras, SPDX Outreach Team Chair.

The post was updated on April 17, 2024, following the official release of SPDX 3.0

SPDX 3.0 Profiles

From open source license compliance to security and plenty in between, there are a wide (and growing) variety of common SBOM use cases. Of course, not every organization or team will have the same purpose for creating or consuming an SPDX document.

For example, an in-house legal team may care a lot more about licensing than the nuances of an AI model. A security team will likely be particularly interested in vulnerability exploitability information like that in VEX. And so on and forth.

Profiles allow software suppliers to produce simpler and more tailored SPDX SBOMs for the use cases they and their customers care about most.

There are five new profiles in SPDX 3.0:

Licensing: This profile includes many of the licensing-related data fields from the prior SPDX 2.3, but with a few adjustments. For example, the SPDX 3.0 licensing profile adds a “custom exceptions” data field. (License exceptions “grant an exception to a license condition or additional permissions beyond those granted in a license.” The prior SPDX 2.3 has a defined exception list.)

Notably, there are a few versions of licensing profiles in SPDX 3.0. The Licensing Profile "defines a minimum set of license information to facilitate compliance with typical license use cases." Additional licensing metadata can be found in the "Simple Licensing" and "Expanded Licensing" profiles.

Security: The security profile includes fields to link to external security documents like CSAF (Common Security Advisory Framework (CSAF) and CVEs. The profile also adds the ability to embed certain minimum elements to convey security information, such as VEX (Vulnerability Exploitability eXchange) status justifications (i.e. if a product is deemed to be not affected by a vulnerability, an explanation of why that is the case). It also supports vulnerability assessments like EPSS, CVSS, and SSVC.

Build profile: This includes data fields related to the software build. It covers data like the build start time, end time, environment, and type (tools or infrastructure the build was invoked on). The build profile provides the necessary information to verify the software build provenance and ensure that the provided software is what it claims to be.

AI: The AI profile captures metadata related to the "outputs of the AI development process, such as software packages, models, and datasets.” Examples of new data fields available in the AI profile are:

• UseSensitivePersonalInformation: If personal information (such as biometric or address data) is used to train an AI model or during the inference
• InformationAboutApplication: A data field used to describe how the model is used in software, such as "pre-processing steps, third-party APIs, and other pertinent details"
• EnergyConsumption: This field describes any number of resources used, including (but not limited to) computational resources used, training time, type and quantity of processing units, and more

Dataset Profile: As the name suggests, this profile is intended to communicate information about datasets. The profile includes fields like “Dataset Type” (such as images, text, or multi-modal), “Dataset Size” (measured in bytes), and “Dataset Availability” (whether the dataset is available for public download or gated behind a form) among others.

Other Changes in SPDX 3.0

Although the addition of new profiles is one of the highlights of SPDX 3.0, it’s not the only change from SPDX 2.3. Here’s a look at some of the other major differences.

Document Structure

The introduction of new profiles in SPDX 3.0 coincides with a new required data field that communicates which profiles your SBOM describes.

SPDX 3.0 is structured in such a way that these new profiles are stacked on top of the SPDX Core Model — which includes foundational data fields like document creation information — and, in many cases, the SPDX Software Profile. (The Software Profile includes familiar data fields like package version, package URL, declared license, and concluded license, among others.)

SPDX 3.0 documents must include the Core Model and will likely include the software profile, but the other use case-specific profiles are optional. In other words, an SPDX 3.0 SBOM will be structured along the lines of:

• Core Model: Required
• Software Profile: Not required, but recommended for the vast majority of SBOMs
• Other Profiles: Use as needed

Relationships

SPDX relationships are a way of describing how elements relate to each other. For example, one package might be a dependency of another package.

In SPDX 2.3, an element (a package, file, or snippet) contains a list of relationships to other elements. If you want to add, remove, or modify a relationship, you have to create a new version of the element. Also, the relationships and the element containing the relationship must be included in the same SPDX document.

In SPDX 3.0, the relationship will be its own element rather than a property of another element. This allows you to add new relationships without having to replace the original elements. You can also create a new, separate “document” which introduces new relationships between previously defined elements — a common scenario when additional analysis is done for an existing SBOM.

Creator Information, Name Change, and More

SPDX 2.3's "creator" data field communicated the person, organization, or tool used to produce the bill of materials. In SPDX 3.0, that has been replaced by "createdBy" and "createdUsing" properties. The "createdBy" field describes the person or organization producing the bill of materials, while the "createdUsing" field communicates the tool used to create the BOM. (The "createdBy" field is required in SPDX 3.0.)

Another change is that the full name of the SPDX specification has changed to System Packet Data Exchange (which speaks to the growing number of use cases the standard supports). It was formerly Software Data Package Exchange.

For a more full list of changes in SPDX 3.0, we recommend you visit the specification's annex on the topic.

Beyond SPDX 3.0

Work on SPDX 3.0 didn't prevent the SPDX community from planning future improvements to the specification. This includes working groups dedicated to medical devices and services.

SPDX tech team co-lead Gary O’Neall discussed these groups’ progress and goals in our recent webinar.

“If you think about software that’s being used in medical devices, you want to make sure it’s safe,” O’Neall said. “This goes beyond the build and security environment that we’re doing in 3.0. If you want a medical device to be safe, with its software, you need to know what hardware it runs on and what the configuration is for the hardware, so we have some work going on in that area as well.

“And then one of the groups I’m leading is SPDX for services. This is based on a CISA group for service transparency. We’re basically taking the work that they’ve provided and making sure that if you’re using SaaS you can basically get a service BOM of the information and be able to use it to make sure you can trust the service provider that’s in there.”

For more information on the SPDX SBOM format — and for step-by-step guidance on generating an SPDX SBOM with FOSSA’s free product — check out our complete overview of the standard.

On April 9, 2024, the OWASP CycloneDX project announced the release of version 1.6 of their industry-leading bill of materials specification as well as several new or updated best practices documents for practitioners. As with many prior releases, CycloneDX 1.6 continues to expand its support for a wide range of supply chain risk management activities beyond only software bill of materials (SBOMs). 

As a reminder, CycloneDX is one of the two primary SBOM options available to organizations seeking to comply with U.S. Executive Order 14028 and other supporting frameworks requiring software component transparency. In the past, CycloneDX has added hardware bill of materials (HBOM), VEX and VDR support for vulnerability reporting, SaaSBOM to describe services and APIs, OBOM or Operational BOM to describe application configurations, and much more.

In this latest release, CycloneDX sets the stage for the specification to begin the process for standardization through Ecma TC54 and adds additional capabilities for Cryptographic BOM, Machine Learning BOM enhancements, and Attestation support. 

We will get into those features below, but before we do, it’s important to understand the state of these SBOM specifications. CycloneDX previously received pushback from some in industry due to the lack of governance in their process and the rapid speed at which they have expanded the format. The schema for CycloneDX has grown quite large (at 5673 lines in the 1.6 JSON schema), but, likewise, so has the utility of the project. And, Ecma TC54 adoption now gives CycloneDX the ability to align more closely with SPDX from a standards maturity standpoint while still retaining all the amazing work that has gone into it so far.

Cryptographic BOM (CBOM)

Initially developed by IBM Research — and not to be confused with a Configurable BOM or a Cybersecurity BOM (we sure do love our BOM acronyms!) — CBOMs capture cryptographic assets. These include cryptographic algorithms, protocols, certificates, and other cryptographic metadata, including implementation details and lifecycle status. As a fully featured inventory of this information, CBOM allows development and cybersecurity teams to understand the specifics of how cryptography is used in an application and where weaknesses that can lead to security breaches might occur. 

As an example, if we look back to some of the TLS-related weaknesses in the past, capturing this information could have allowed for much faster remediation of issues such as Heartbleed, where sensitive data could be disclosed through abuse of vulnerable ciphers. And, as we collectively move toward advances in quantum-resistant cryptography, this creates opportunities to establish assurance practices aligned with NIST-approved ciphers for more robust cryptography.

Furthermore, recent guidance from the White House and CISA that have advocated for moving to quantum-resistant cryptography, such as M-23-02 and CISA’s Post Quantum Cryptography Initiative, are well supported by this approach. This marks the first instance of a structured and machine-readable inventory of cryptographic data, and since it is captured in the SBOM, creates the opportunity for correlation to software, services, vulnerabilities, and any other object that CycloneDX natively supports.

CycloneDX Attestations (CDXA)

Continuing with the list of major improvements for software supply chain assurance is the addition of CycloneDX Attestations, or CDXA, in CycloneDX 1.6. Long seen as the perfect marriage with SBOM by many, there was never a standardized and uniform way to represent this information in a single format. Attestations provide the ability to state conformance with regulatory requirements using the concept of “compliance as code,” and perhaps more importantly, claims about the security processes employed in the pipeline supported by evidence and digitally signed for authenticity.

This creates the ability to support multiple regulatory requirements, such as: 

• The NIST Secure Software Development Framework (SSDF) associated with EO 14028 
• Self-attestation requirements required through the CISA Repository for Software Attestations and Artifacts (RSAA) 
• Google’s Supply Chain Levels for Security Artifacts (SLSA) attestations 
• Many others!

Machine Learning BOM (MLBOM) Enhancements

Building on MLBOM in CycloneDX 1.5, which added the ability to capture information about ML and AI models and supporting metadata, 1.6 further enhances these capabilities. Version 1.5 already supported an inventory of machine learning models, their intended use, any parent models, limitations, and ethical considerations, as well as the hardware, software, and libraries needed to run the model. Adding environmental factors such as energy consumption and CO2 emissions into MLBOM allows for continued ecological practices for AI in an era where this technology is beginning to outpace energy consumption demand models for the grid.

CycloneDX Authoritative Guides

In addition to all the new features in CycloneDX 1.6, the CDX project released three comprehensive documents: a second-edition update to the Authoritative Guide on SBOM that was released with version 1.5, and two new documents. 

One is the accompanying CycloneDX Authoritative Guide to CBOM, which includes detailed information on the data model, use cases, and multiple examples of how to capture cryptographic data in a CBOM. The second is a very similar companion document, CycloneDX Authoritative Guide to Attestations. 

With these two new documents, users of the CycloneDX specification will have concrete references for how to produce BOMs that convey this information and develop their own standards for inclusion into CDXA. The documents also provide valuable guidance for SBOM management vendors such as FOSSA. 

As always, FOSSA will continue to cover the latest developments in the SBOM world on our blog, so stay tuned. And, if your organization is looking for support automating any part of the SBOM lifecycle (generation, ingestion, analysis, distribution, VEX, and so on), please reach out to the FOSSA team.

On Friday, March 29, a Microsoft developer revealed a major vulnerability impacting XZ Utils, a popular collection of lossless data compression tools and libraries.

The vulnerability was later confirmed by Red Hat and assigned CVE-2024-3094. It was given a CVSS severity score of 10.0, the highest possible. 

CVE-2024-3094 is considered such a serious threat because it allows for potential remote code execution, giving attackers the ability to run malicious software, access sensitive data, or gain control over the affected systems from anywhere in the world. 

If there is a piece of good news related to the exploit, it’s that the vulnerability was likely caught before doing widespread harm. Although XZ Utils is used across the Linux world, the vulnerability impacts only XZ Utils versions 5.6.0 and 5.6.1. And, as of this writing, CVE-2024-3094 is only confirmed to impact Fedora Rawhide, Fedora Linux 40, Debian (testing, unstable, and experimental distributions, versions ranging from 5.5.1alpha-0.1 up to and including 5.6.1-1), Arch Linux, Kali Linux, openSUSE Tumbleweed, and openSUSE MicroOS. 

The recommended mitigation is to immediately downgrade to a safe version, such as 5.4.6 Stable. Additionally, since vulnerable versions of XZ Utils have been distributed in the Linux ecosystems mentioned above, you should follow the applicable vendor guidance for reverting and/or upgrading Linux distributions.

In this blog, we’ll discuss the nature of the XZ Utils vulnerability, the unusual way it was discovered, and best practices for remediating the issue.

CVE-2024-3094 Background and Discovery

News of the XZ Utils vulnerability first came to light in an Openwall thread from Microsoft developer Andres Freund. 

Freund posted that he observed degraded performance related to part of Debian sid installations. Specifically, SSH logins a) consumed more CPU than expected, and b) caused valgrind errors. 

These issues led Freund to investigate. At first, he thought Debian’s package may have been compromised. However, further exploration led Frend to conclude that the issue was actually with the upstream XZ repo and tarballs.

It also soon became clear that CVE-2024-3094 was no ordinary software supply chain attack. Rather, it was the result of a sophisticated, multi-year process that culminated in a bad actor — perhaps/probably a state-sponsored one — becoming a trusted contributor to XZ Utils and inserting a backdoor.

In November 2021, GitHub user Jia Tan (“JiaT75”) made what appears to be their first commit to an open source project. In 2022, Tan submitted a patch to the XZ Utils mailing list; several sockpuppet accounts responded to Tan’s submission pressuring the original XZ Utils project maintainer to add co-maintainers. (The intent of these efforts was seemingly to convince the original maintainer to add Tan to the project.) 

In the months that followed, Tan continued to contribute to XZ Utils, gaining trust and stature. This ultimately resulted in Tan being able to create and release compromised tarballs in XZ Utils 5.6.0 and 5.6.1.

How the XZ Utils Vulnerability Works

The XZ Utils vulnerability introduces a backdoor that allows an attacker to send hidden commands via sshd when establishing an SSH connection. By providing a specific private key (known only to the attacker), arbitrary commands can be sent to the affected system prior to the authentication step, enabling unauthenticated remote code execution.

Here’s a summary of requirements to be affected by the malicious code:

1. Using a .deb or .rpm based distro that uses glibc
   a. amd64/x86_64 based architecture
2. 5.6.0 or 5.6.1 of xz or liblzma installed
3. Publicly accessible sshd (although privately accessible may be vulnerable)

Here’s a summary of how the attack works on an affected system:

1. Backdoor Establishment: The backdoor is put in place, having been intricately compiled from various test files, which were disguised as legitimate inputs and embedded within the build process through a complex scheme of scripts and modified configuration files. This setup ensures the backdoor is activated, listening for incoming SSH connections.

2. Authentication Process: When a client tries to authenticate, it sends its public key to the server as part of the standard SSH handshake, initiating the authentication dialogue.

3. Interception by Malicious Code: At this juncture, the maliciously inserted code that has taken over the RSA_public_decrypt function springs into action. This function, meant for validating RSA signatures, is now repurposed to analyze the data received during the handshake.

4. Revealing Hidden Commands: The tampered function decrypts certain parts of the incoming authentication data, unveiling hidden instructions that were embedded within what is typically a secure RSA signature process.

5. Signature Authentication: The decrypted data is subjected to a verification process to authenticate its origin. This step ensures that only instructions from the attackers, who have the required private key, are accepted and processed further.

6. Command Execution: Upon successful verification indicating that the instructions originate from the attackers, these instructions are executed on the server. This critical step allows the attackers to perform unauthorized actions on the system without completing the standard authentication protocol.

7. Seamless Fallback: If the incoming data does not conform to the attackers' specifications or fails the verification stage, the backdoor reverts to the legitimate functionality of the RSA_public_decrypt function. This behavior ensures the backdoor remains hidden during regular SSH operations, maintaining the appearance of normalcy.

Finding and Fixing the XZ Utils Vulnerability

As discussed, thanks to Andres Freund’s timely discovery, the XZ Utils vulnerability appears to impact only a handful of distributions. It’s highly recommended to a) downgrade to a safe version of XZ Utils, and/or b) follow vendor guidance for mitigating the vulnerability in:

• Fedora Rawhide and Fedora Linux 40 
• Arch Linux
• Kali Linux
• openSUSE Tumbleweed and openSUSE MicroOS
• Certain testing, unstable, and experimental distributions of Debian

FOSSA customers can quickly verify whether they are using the vulnerable packages anywhere in their organization by navigating to Package Index and searching for CVE-2024-3094. Any impacted packages, projects, and teams will be returned in the search results.

The FOSSA product and engineering teams have been hard at work shipping new features and enhancements to help you mitigate open source risk and enhance software transparency. 

Collectively, the latest FOSSA updates enable a new level of visibility across your organization’s open source software supply chain. Our recent updates allow you to:

• Quickly find new zero-day vulnerabilities with FOSSA’s Package Index
• See your risk profile and track remediation progress with the new issue overview dashboard
• Proactively secure your open source supply chain with FOSSA Quality
• Enhance software transparency with the ability to ingest SPDX SBOMs 
• Resolve issues faster with more dependency information at your fingertips 

Quickly Find New Zero-Day Vulnerabilities With Package Index

You can now find zero-day vulnerabilities anywhere across your organization in minutes instead of weeks. Package Index is a centralized, comprehensive inventory — a single source cataloging every package used in every project across your organization. You can search by either package name or CVE ID to quickly identify which projects use the vulnerable components across your organization. 

Read the blog to learn more about Package Index

See Your Risk Profile and Track Remediation Progress With the Issue Overview Dashboard

The issue overview dashboard is a single place to quickly see outstanding security, licensing, and quality issues across your entire environment. The dashboard also allows you to track the progress of your remediation efforts; it can be viewed on a team level or a project level in addition to the default organization-level view.

Read the blog to learn more about the issue overview dashboard

Proactively Secure Your Open Source Supply Chain With FOSSA Quality

Go beyond just vulnerability data with package health signals that enable you to maintain a proactive security posture. FOSSA Quality allows you to keep abandoned packages, outdated packages, empty packages, and native code out of your software supply chain. You can also use FOSSA Quality to allow or deny the use of certain packages across your organization or just for certain projects. 

Read the blog to learn more about FOSSA Quality

FOSSA Adds Support for SPDX SBOM Imports

FOSSA now supports importing SBOMs in SPDX in addition to CycloneDX, making it easier than ever to get the software transparency you need. This enhancement will make it simple to analyze SBOMs from internal teams or third-party suppliers, regardless of the format they choose. 

Sign up or sign in to your FOSSA account to import your SBOM.

Resolve Issues Faster With More Dependency Information at Your Fingertips

Dependencies in the FOSSA UI have a new look and feel, surfacing more actionable information than ever before. You can use the dependency page to see all dependencies included in a given project, to determine exactly how a dependency has been included in a project, and to find dependency metadata quickly.

Read the docs to learn more about the dependencies UI in FOSSA

Getting Started With FOSSA

These latest enhancements make it easier than ever to drive software transparency and mitigate risk in your open source software. For more information about getting started with these features, current customers can view our documentation or reach out to customer-success@fossa.com. 

Not a current FOSSA customer? Schedule a demo to see how FOSSA can help enhance your software transparency and mitigate your open source risk.

You’ve likely been hearing about software bill of materials (SBOMs) over the last few years along with the importance of software transparency for vulnerability management, licensing risk, and other use cases. 

At some point, though, you may have started to explore generating and/or consuming SBOMs — and quickly realized things were a bit more complex than you had initially thought.

One of the biggest areas of confusion revolves around SBOM formats and specifications, such as CycloneDX and SPDX, that are used to create and share SBOM information. 

In its simplest form, an SBOM needs to convey a set of basic metadata about the software it describes. These baseline data fields are frequently referred to as the “Minimum Elements” of an SBOM. (Organizations that sell into federal government agencies or are otherwise regulated by certain federal government agencies are required to produce SBOMs that include these elements. Other organizations may not be bound by the same requirements, but it’s still a best practice and industry standard to do so.)

The minimum data fields are as follows:

• Supplier Name
• Component Name
• Version of the Component
• Other Unique Identifiers
• Dependency Relationship
• Author of SBOM Data
• Timestamp

The reality is that unless you are concerned with the regulatory compliance of your SBOM such as government procurement or FDA requirements, you can still derive value from even a partial SBOM. It’s also noteworthy that these seven fields can be expanded on with additional references, cryptographic hashes and other information useful for supply chain use cases. The minimum elements are just a starting point.

But does it matter whether you use SPDX, CycloneDX, or another specification? We will get to that in just a few moments, but let’s first explore what these specifications are.

SPDX

SPDX, or Software Package Data Exchange, is an open standard for communicating licensing and SBOM minimum elements as described above. It’s the only specification that is recognized as an ISO standard in the form of ISO/IEC 5962:2021, which describes the state of SPDX in version 2.2.1. As such, SPDX is the only SBOM specification that has undergone this rigorous standards development process, but it’s also important to note that this space is evolving rapidly, far more quickly than standards development can keep pace with.

SPDX is also the oldest of these SBOM formats, and in its early days, it was largely intended for open source licensing use cases. In fact, SPDX has been around since at least 2011, far longer than many have been talking about SBOM for cybersecurity. 

The latest published version is 2.3, which was released in 2022 after a very minor update in 2.2.2. Again, both of these are more recent than the ISO standard version, and SPDX 3.0 is in a prerelease state which makes major breaking changes to the data specification. This will dramatically improve the state of the industry, including such concepts as profiles across Licensing, Security, Build, Usage, AI, and Dataset use cases, along with more flexibility in relationship modeling, additional simplicity, and promotion of PURL (Package URL), which will help improve SBOM accuracy and data quality by standardizing component naming).

So, who uses SPDX? Well, lots of people do! In fact, even CycloneDX uses SPDX for software licensing; but the licensing definitions and identifiers come from SPDX. This is what SPDX was purpose-built for. As such, it should come as no surprise that many large software companies such as Microsoft and Google prefer SPDX due to the ease of working with software licensing information and the maturity of an ISO standard. This is also why the Linux Foundation has taken over governance of the project, and, as such, SPDX is well-respected by many in the open source ecosystem. 

SPDX supports a wide range of data formats such as tag/value (.spdx), JSON (.spdx.json), YAML (.spdx.yml), RDF/xml (spdx.rdf) and spreadsheets (.xlsx). The SPDX team also has an online tool to make it easy to work with the various formats and convert as needed for your use case.

CycloneDX

Another specification you have likely heard a lot about in recent years is CycloneDX. It too, is an open format, though only recently moving into a formal standards adoption process through ECMA TC54, which is also adopting many other sibling projects that are important for supply chain transparency use cases such as PURL. CycloneDX also supports several data formats such as XML, JSON, and protocol buffer, all of which can be easily transformed into CSV formats if you are accustomed to spreadsheets.

CycloneDX is currently on version 1.5, but new versions are released frequently, and with a much wider array of use cases and BOM (bill of materials) types than what is seen within SPDX. As an OWASP project, it should come as no surprise that CycloneDX is aligned much more closely with cybersecurity use cases, and as such, sees increased adoption with many cybersecurity tool providers and vendors. 

The team behind CycloneDX is also responsible for Dependency Track, Software Component Verification Standard, the BOM Maturity Model, Common Lifecycle Enumeration, and of course the many open source and commercial tools that implement the CycloneDX specification. 

As the BOM conversation evolves, CycloneDX has evolved as well to support VEX (which we will discuss more in a moment), HBOM for hardware components, Cryptographic BOM to describe algorithms and ciphers, SaaSBOM which describes APIs and services, OBOM for configuration data, and MLBOM for machine learning models. CycloneDX also has attestation support in its short-term roadmap.

SBOM Format Comparison

Now that we have an overview of the SBOM specifications and formats, how do we use them and what are the primary differences in the minimum elements and verbiage in each? We will focus on CycloneDX 1.5 and SPDX 2.3 for this comparison.

Due in part to these differences, in some cases, translating formats may create a scenario we refer to as “lossy.” This refers to cases where the source SBOM contains data that is not supported in the destination format, and, as such, this information can get lost in translation. This is also one reason why you might sometimes see a value of ‘NOASSERTION’, especially with SPDX, as it’s telling you that we tried, but can’t answer this question.

As an example, consider unique identifiers. If your source SBOM was in CycloneDX and had a PURL reference, it wouldn’t be supported in the corresponding section in SPDX 2.3. You’d have to use the ‘ExternalRef’ field in SPDX instead, (PURL has been supported as an external reference in SPDX starting with 2.2). We have certainly seen ‘PackageDownloadLocation’ used as well, which is not what this field is supposed to be used for. Typically, this should be where the direct download points to. As you might imagine, this ambiguity creates situations where not all tools will handle translation in the same way. Consistency becomes extremely important, or you might miss a critical piece of information. In this case, the lack of a PURL might mean that you miss a vulnerable component.

Converting between SPDX and CycloneDX (and guarding against data accuracy issues) is one area where certain SBOM management tools like FOSSA can help. We'll discuss more specifics later in this post.

Other SBOM-Related Formats

Although SPDX and CycloneDX are the two full-stack SBOM formats commonly used today, you may come across a few other SBOM-adjacent specifications. Here’s a brief overview of two of them: Software Identification (SWID) as well as a newer concept used in vulnerability use cases, called VEX. 

VEX, as you will see, also has a few different formats as well. However, it's important to note that VEX documents can be and often are created and distributed independently of an SBOM. SWID can theoretically as well, but this isn't as common.

SWID

In the early days of the U.S. government's work to promote SBOMs, SWID, or SWID Tag, was discussed as an alternative to the other SBOM specifications. U.S. Executive Order 14028, “Improving the Nation’s Cybersecurity,” was the landmark policy document that drove SBOM to prominence and recognized the National Telecommunication and Information Administration (NTIA) as the authoritative organization to define the minimum elements and other deliverables within the EO. All three formats, SPDX, CycloneDX and SWID were recognized as SBOM formats in these initial drafts.

SWID is seen today as less of an SBOM format and more of a software descriptor, and according to NIST, is seen as one possible successor to the beleaguered CPE naming standard. The reason why CPE has become so problematic is two-fold. One, these CPE values are manually assigned, and as such suffer from inconsistency. Secondly, CPE is focused on product-level naming, but very few software components are featured in the National Vulnerability Database, so relying on a CPE to describe a vulnerability in a software component will not be very reliable.

While we have not seen anyone use SWID as an SBOM format, it does have a role to play. Much of the industry’s current focus is on managing the risk of open-source dependencies, and approaches such as PURL are well-supported by package managers to do this work. But SWID solves the challenge around software naming when the software package is not publicly known or distributed, such as in the case of proprietary software. 

The reason why SWID is not used for SBOM is that it is not really an SBOM format. It describes key characteristics of software such as the software name, version, suppliers and other metadata. It also provides some useful context for supply chain concepts such as pedigree in the form of patch metadata. But the data format itself is not conducive to the concept of nested layers of software components and their dependency relationships, otherwise known as transitive dependencies.

VEX

Any discussion on SBOM formats will naturally migrate to a conversation around VEX as well. VEX, or Vulnerability Exploitability eXchange, is a concept that sprang from the early NTIA meetings where SBOM was discussed for vulnerability management scenarios. The idea was that an SBOM can tell you where software might be vulnerable with a moderate degree of confidence, but a VEX document functions as a sort of reverse attestation, indicating why the software is not vulnerable, or rather, not affected by the vulnerability. This helps to prioritize your efforts so you are only working on the issues that create real risk for your organization or your customers. 

VEX is also supported in many formats, including CycloneDX, CSAF, and OpenVEX. Some of these formats are quite old and predate the concept of VEX entirely, while others have entered our parlance in just the last couple of years. By and large, support for VEX formats is mostly focused on creating them as part of a manual vulnerability triage process, or consuming them to inform your vulnerability program. You can think of them as a companion document to your SBOM, enriching the information your SBOM provides.

What you should primarily focus on, though, is what a VEX document says. Contrary to the name, VEX is not a statement of exploitability or known exploitation. Rather, it refers to whether the software is affected by a corresponding vulnerability. 

There may be many reasons why a vulnerable component does not affect the software with its corresponding vulnerability. It might not be reachable code, and only included but not used. It might be mitigated through configuration. It might even be fixed in such a way that the supplier did what is called a backport, where they addressed the vulnerability but did not update the software component version. And software versions are how we identify vulnerabilities from an SBOM. The VEX is a form of attestation that the supplier typically provides with the outcome of their triage of the vulnerability, and states if they will fix the issue or not.

Another consideration when looking at VEX is that while an SBOM is a static document, a VEX should not be. In other words, you need an SBOM for every new release of the software, but until a new version of the software is released, it will not change. The SBOM states what was in the software when it was released. It does not track ongoing status until there is a new version. 

A VEX document, on the other hand, is a statement about the status of a vulnerability, and status can change frequently as new information is discovered about the vulnerability or details about the affected nature of the vulnerability are uncovered or disproven by the supplier. CVSS scores can change, impacts might change, the specific conditions that must be in place for vulnerability exploitation might change as we learn more about how the software is abused. Even more frequently than any of this, are the exploitability indicators about a vulnerability that are a direct reflection on the ever-changing threat landscape. This is why the Exploit Prediction Scoring System (EPSS) data feeds change on a daily basis. All of this is to say that VEX is a living, breathing — and, yes, dynamic — piece of content.

Final Notes

As you may have surmised, we have several formats to contend with to operationalize SBOMs. It can be challenging enough when you are a software producer, but at least you can somewhat standardize on your approach. But when you are a consumer and are dealing with hundreds, or even thousands, of software products in your organization, you may have many different types of documents to consume in varying states of maturity. The format you use probably matters much less than whether your SBOM tools effectively support the formats you need to ingest and analyze, unless you plan on spending all day manually reviewing XML and JSON documents.

The good news is we are here to help simplify the process, no matter what your role is. If you need to convert from SPDX to CycloneDX, migrate versions, work with XML instead of JSON, or produce a specific format for a downstream consumer, having robust SBOM management tools can help you get back to business quickly. Feel free to get in touch with the FOSSA team for more information.

Securing your code can be messy work. Security teams are working across multiple repositories that contain layers upon layers of dependencies, each with their own potential vulnerabilities and open source license obligations. It can be easy to get lost in the daily work of remediating issues across your repos, making it difficult to see the overall state of your software supply chain — and to understand the progress of your remediation efforts.

That’s why we created the issue overview dashboard: a single place to quickly see outstanding security, licensing, and quality issues across your entire environment, as well as issues you have already fixed or ignored. With issue overview, you now have a view of risk across your entire organization, and an easy way to demonstrate the impact of your remediation efforts.

Risk Monitoring at the Organizational Level

The issue overview dashboard provides an easy way to track and understand software supply chain risks across your entire organization, enabling:

• Instant Visibility: Gain immediate insight into security, licensing, and quality risks across your software supply chain. You can quickly see how many total issues you have, as well as how many of these are active versus remediated.
• Trend Analysis: Leverage customizable date ranges to observe how your risk profile is evolving over time. See how many issues are being remediated over time, as well as how many are being ignored. 
• Risk Detailing: Understand the details of your risk profile across your organization. Issue overview includes granular breakdowns of vulnerability severity, license issue types, and quality issues — so you can quickly get a sense for which issues are most common across your software supply chain. 
• Data Export: Easily export issue overview data to create your own visualizations or run your own custom analysis.

Filtered Views for Deeper Insights

Issue overview also includes filtered views, enabling you to see risk profiles and remediation trends at different levels of your organization and across projects. 

You can filter by custom labels to get a view of the data as it pertains to specific project tags. For instance, you could filter to see only issues in production, or only critical issues. You can also filter by team, enabling visibility into the health and status of each individual team’s projects. 

Show Your Work

The issue overview dashboard allows you to quickly see (and share) the number of issues your team has remediated over time. This can provide quick insight into the momentum and impact of your remediation efforts.

The dashboard also shows ignored issues, which are driven by policies and rules you have set up in FOSSA. These rules free your team from the redundant work of vetting and clearing the same issue across multiple projects or package versions, allowing them to focus on more important priorities. See our blog on reducing alert fatigue with auto-ignore rules to see how this works. 

Getting Started with Issue Overview

Current FOSSA premium customers can find the issue overview dashboard by navigating to ‘Reports’ in the top navigation bar in the FOSSA UI.

If you aren’t yet a FOSSA customer and are interested in gaining visibility into risks and remediation across your software supply chain, getting started is straightforward. You can sign up for a FOSSA premium account (recommended for smaller organizations) for immediate access to this feature, or request a demo (recommended for larger organizations) to get an in-depth look at how FOSSA can help mitigate risks across your software supply chain. 

The issue overview dashboard is another step in support of our mission to help companies embrace open source software and drive transparency across their software supply chains. It adds an additional layer of visibility and enables security teams to clearly demonstrate the impact of their remediation efforts.

Standard code scanners can help spot vulnerabilities and open source licensing issues, but this alone doesn’t tell the whole story when it comes to software supply chain risk. It’s also important to understand the health and quality of the open source components in your projects. But defining the health and quality of these packages — and understanding why it matters — isn’t straightforward.

Think of package health as an ecosystem influenced by factors like how well the package is maintained and how up-to-date it is. Packages that lag in maintenance or are versions behind can turn into potential security risks down the line — risks that aren’t immediately apparent if you’re only focusing on current vulnerabilities. To truly gauge the quality of your open source components, you must look at a range of indicators that, together, give a clearer picture of their overall health.

To help solve this problem, we recently launched FOSSA Quality. This tool digs deeper than typical surface-level checks, delivering visibility into the real health of your open source components. But it doesn’t stop at visibility. FOSSA Quality enables you to set policies and enforce rules around these signals so you can keep your software supply chain healthy without adding manual effort. 

Proactive Health Monitoring

At its core, FOSSA Quality serves as a proactive health monitor for your open source software supply chain. By evaluating multiple health indicators, it identifies components that could compromise your project's security in the future. This allows your team to prioritize updates and replacements before vulnerabilities arise.

FOSSA Quality enables visibility into:

• Abandoned packages: These are packages that haven't seen any activity from maintainers in at least two years. Identifying abandoned packages is crucial because they may not receive fixes for bugs or newly discovered vulnerabilities.
• Outdated packages: These are packages that lag several versions behind the most current release. You can set specific thresholds to flag these packages. Outdated packages are an issue because they might miss critical security patches or feature improvements. 
• Empty packages: These are packages with no runnable code, potentially indicating issues like faulty publication or name squatting (which can lead to dependency confusion attacks). Since they offer no functionality, empty packages serve only as potential liabilities. 
• Native code: This feature identifies packages that include compiled executable files. While native code is not inherently risky, it can obscure the package's intent and functionality. Binaries might conceal harmful code that remains undetected without specialized analysis.

Additionally, FOSSA Quality makes it possible for you to proactively block specific packages from use, keeping them out of your production environments.

Streamlined Policy Enforcement

FOSSA Quality goes beyond just monitoring; it empowers teams to enforce health and security standards across their projects. With customizable policy settings, you can automatically block or allow packages based on their health signals. This not only reduces the manual workload but ensures consistency in how open source components are evaluated and integrated into your projects.

Integrating with Your Workflows

FOSSA Quality is built to seamlessly integrate into your existing development and security workflows. Whether you're reviewing a single project or managing a portfolio of software, Quality enables you to make open source health a central part of your development lifecycle without adding overhead or complexity.

To learn more about Quality signals and how to integrate them into your workflow, check out our documentation.

Getting Started

If you’re new to FOSSA and eager to elevate your software's security and overall integrity, getting started is straightforward. You can sign up for a FOSSA premium account (recommended for smaller organizations) for immediate access to this feature, or request a demo (recommended for larger organizations) to get an in-depth look. 

FOSSA Quality is another step in support of our mission to help companies embrace open source software and improve the integrity of their software supply chains. It adds an additional layer of visibility and control, assuring your software supply chain is not only free of known vulnerabilities but also healthy for the long term.

The healthcare industry has been hit hard by cyber incidents in recent years, including a number that have impacted medical devices. Against this backdrop, the U.S. government passed new cybersecurity requirements that took effect in 2023 — including a mandate to produce SBOMs (software bill of materials) — for medical devices.

The new cybersecurity requirements apply to multiple types of premarket submissions — 510(k), 513, 515(c), 515(f), and 520(m) — and, broadly, they include three main focus areas:

• Provide an SBOM that inventories commercial, open source, and off-the-shelf software  
• Submit a plan for monitoring, remediating, and disclosing postmarket vulnerabilities and exploits  
• Create and maintain processes to provide a “reasonable assurance that the device and related systems are cybersecure” 
  • Plus, make updates and patches available postmarket 

Notably, starting on Oct. 1, 2023, the FDA was given the authority to refuse to accept premarket submissions that don’t include comprehensive and accurate cyber information, including SBOMs. 

Although, as mentioned, medical device manufacturers must include a range of documentation and information in their premarket submission, this blog will focus mostly on the SBOM requirements. (For reference, these can be found in the “Risk Management - Software Bill of Materials (SBOM) and Related Information” section of the premarket eSTAR.) We’ll break down the scope of the FDA’s requirements, how SBOMs (and SBOM-related information) should be structured, and how FOSSA can help manufacturers fulfill SBOM requirements.

Scope of the FDA’s SBOM Requirements

Whether a medical device is subject to the FDA’s SBOM requirements depends on the a) type of device and b) the premarket review submission date. 

Types of Medical Devices

The new FDA cybersecurity requirements apply only to “cyber devices.” The FDA defines a “cyber device” as one that:

1. Includes software validated, installed, or authorized by the sponsor as a device or in a device
2. Has the ability to connect to the internet; and 
3. Contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. 

Medical device manufacturers that are unclear whether their products are considered cyber devices are encouraged to contact the FDA for clarification.

Submission Timing

The FDA SBOM requirements apply to medical device applications submitted to the FDA on or after March 29, 2023. Additionally, if manufacturers of devices that gained premarket approval before March 29 make changes that require a new premarket submission, the new submission must include the required SBOM (and SBOM-related information).

Pillars of the FDA’s SBOM Requirements

Medical device manufacturers must provide the following types of SBOM artifacts and/or assessments to earn premarket approval.

1. The SBOM itself 
2. Support information (e.g. current level of support and support end date) for all software components identified in the SBOM
3. An assessment of vulnerabilities in the software components identified in the SBOM — plus any controls or mitigation steps to address those vulnerabilities

SBOM Structure and Requirements

The FDA requires SBOMs to be generated in a format and structure that aligns with the NTIA’s (the U.S. Government’s National Telecommunications and Information Administration) minimum elements.

This means, as a starting point, SBOMs must be produced and transmitted in a machine-readable format (like SPDX or CycloneDX). Additionally, they must include the following data fields:

• Supplier name
• Component name
• Version of the component
• Other unique identifiers (e.g. CPE or PURL)
• Dependency relationship (e.g. Component X may be a dependency of Component Y)
• Author of SBOM data
• Timestamp (e.g. date and time when the SBOM was generated)

Component Support Information

In addition to submitting a machine-readable SBOM with the data fields described above, medical device manufacturers must also communicate information about how the software components in their medical devices are supported. Two types of support information must be provided:

1. Level of support from the component manufacturer (as defined by the type of monitoring and maintenance): whether it’s actively maintained, no longer maintained, or abandoned
2. The component’s end-of-support date 

Notably, support information must be provided for all types of components identified in your SBOM, including open source. This may be challenging since open source components infrequently include detailed support information; it may need to be inferred based on registry updates or commit history. If you are unable to communicate support information for a particular component, the FDA asks that you provide a justification explaining why. 

It’s also important to note that this support information can be transmitted in two ways:

1. It be embedded directly into the SBOM that’s submitted for premarket review
2. It can be included in a separate document

Component Vulnerability Information

The other category of required SBOM-related information is a vulnerability assessment. 

This starts with a listing of all known vulnerabilities — e.g. those in CISA’s KEV (Known Exploitability Vulnerabilities) Catalog — plus an explanation of how the manufacturer discovered said vulnerabilities. (The reason manufacturers are asked to communicate how they identified vulnerabilities is so the FDA can evaluate whether “the assessment methods were sufficiently robust.” The FDA wants to make sure manufacturers have the context they need to have confidence in a fix when a vulnerability is identified.)

In addition to a list of known vulnerabilities and information about how they were discovered, medical device manufacturers should provide:

• An evaluation of the identified known vulnerabilities, “including device and system impacts”
• Controls in place to address the vulnerability; if there are compensating controls, those should be “described in an appropriate level of detail”

It’s important to note that, although a list of all identified vulnerabilities must be provided, it is not necessary that your submission be free of all identified vulnerabilities. Rather, you must be able to reasonably defend your security posture via means such as lack of exploitability or compensating controls. 

SBOMs and the FDA’s Postmarket Requirements

In contrast to the premarket submission, the FDA doesn’t have specific SBOM requirements that impact medical devices once they’re on the market. However, that doesn’t mean manufacturers should view SBOMs as solely a premarket initiative. 

On the contrary, SBOMs can play an important role in several postmarket processes. 

For example, medical device manufacturers are required to disclose vulnerabilities to customers and address them in a timely manner. Maintaining an up-to-date SBOM makes it easier to determine whether a device is impacted by new vulnerabilities (and then make the proper fix if it is).

For example, oftentimes a new vulnerability may appear to impact your submission; however, after an internal investigation, you may determine that the CVE as used in your device is not exploitable. Maintaining an accurate SBOM with proper VEX (Vulnerability Exploitability eXchange) statements will expedite relaying this information to your customers.  

The FDA will also continuously monitor your SBOMs for new vulnerabilities. Ensuring you have continuous vulnerability management tied directly to your submitted SBOM will allow you to preempt any FDA findings with your internal, and thus more accurate, assessments.   

Additionally, it’s not always a matter of regulatory compliance per se, but there’s a growing trend among security-conscious customers to require SBOMs as a condition of purchase. Some customers may also require manufacturers to provide access to the latest SBOM version(s) on a continuous basis and/or VEX information. I suspect SBOMs with accurate VEX or other means to communicate vulnerability status will be a requirement from nearly all major hospitals in the coming years.   

How FOSSA Can Help Fulfill the FDA’s SBOM Requirements

FOSSA is a leading SBOM management provider, and we’re actively supporting medical device manufacturers as they navigate the FDA’s premarket review. 

Here are some of the ways we help manufacturers fulfill the FDA’s requirements for SBOMs and SBOM-related information:

1. You can use our platform to generate a machine-readable SBOM (in CycloneDX and/or SPDX) that includes the NTIA-required minimum elements
2. FOSSA provides a complete inventory of known vulnerabilities in your software, including contextual information (like CVE score and recommended fix); this informs the required vulnerability assessment document
3. FOSSA allows you to codify internal assessments as NTIA-compliant VEX statuses and justifications, enabling automated VEX generation and communication of exploitability 
4. FOSSA ingests third-party SBOMs (and consolidates SBOM data from all your SBOMs), which helps manufacturers stay on top of vulnerabilities from not only first-party, but also third-party software supply chain risks
5. FOSSA analyzes open source components' level of support to determine abandoned or actively maintained components
6. FOSSA provides a global package inventory to search across all first- or third-party SBOMs and components, enabling impact assessment as new high-priority vulnerabilities are introduced postmarket. 

Feel free to reach out to our team if you have any questions about FOSSA or if you’d like to get started with a trial of our SBOM management solution.

Picture this: a new zero-day vulnerability has just been announced, sending ripples through the tech community. Your team is on the front line, tasked with a mission — find and fix this vulnerability across your organization. The first step? Pinpoint where this vulnerable package lurks. Traditional methods turn this into an odyssey — a fragmented, painstaking journey from one development team to another, inquiring, investigating, checking. The process is fragmented, slow, and inaccurate. 

For instance, in the wake of the Log4j vulnerability, many companies found themselves scrambling to figure out where Log4j was being used in their organization. They created war rooms and spent weeks collaborating with engineering leaders to find and fix the vulnerability.   

But it doesn’t have to be this way. Imagine a centralized, comprehensive inventory — a single source cataloging every package used in every project across your organization. With such a tool, the search for a specific package name or vulnerability becomes swift and simple. 

This vision is now a reality with FOSSA’s recently released Package Index. Designed for these critical moments, Package Index offers unparalleled visibility into your software supply chain, making it quick and easy to find any package or vulnerability across all projects in your organization.

How Package Index Enables Global Visibility

The discovery and management of packages and vulnerabilities across the entire organization has traditionally been difficult and time-consuming. FOSSA’s Package Index simplifies this, enabling several key benefits:

1. Comprehensive Overview of All Packages: Package Index creates a complete, detailed inventory of every package used across your organization’s projects. This is more than just a list; it's a dynamic, searchable database. Security teams can now instantly access a full record of packages, along with their versions, dependencies, and associated vulnerabilities. This level of detail is crucial for understanding the security and compliance status of your software assets.

2. Rapid Response to New Vulnerabilities: When new vulnerabilities are disclosed, Package Index allows for immediate, organization-wide searches using either package name or CVE (Common Vulnerabilities and Exposures) number. Security teams can quickly identify which projects are using the vulnerable package and assess the potential impact. For example, Package Index can be used to find which projects in your organization may be using Apache Log4j. This capability dramatically shortens the time from vulnerability disclosure to mitigation, a critical factor in managing security risks effectively.

3. Block Packages Globally: With Package Index, it’s now possible to enforce package policies on a global scale within your organization. Security teams can block specific versions of a package, and this decision can be automatically applied across all projects. This ensures uniform compliance and security standards, streamlining policy enforcement and reducing the risk of inconsistencies or oversights.

“Package Index is super useful when customers are inquiring about a specific package or CVE. It’s really easy for our security team to use FOSSA to search for a specific CVE or package and get a very quick answer before going into the technical nitty-gritty of the CVE”

-Valentina Ditoiu, Senior Security Program Manager at UIPath

Get Started with Package Index

Current FOSSA customers can leverage Package Index in their workflow today. 

If you aren’t yet a FOSSA customer and are interested in Package Index, getting started is straightforward. You can sign up for a FOSSA premium account (recommended for smaller organizations) for immediate access to this feature, or request a demo (recommended for larger organizations) to get an in-depth look at how Package Index can help make your license compliance and security efforts more effective and efficient.

With the addition of Package Index, we are excited to continue enabling organizations in their use of secure and compliant open-source software.

Last month, the Enduring Security Framework (ESF), a working group that includes representatives from multiple U.S. government agencies (NSA, ODNI, and CISA) along with private sector partners, released a new document designed to help organizations jumpstart their SBOM programs and effectively manage risks related to open source software.

 “Securing the Software Supply Chain: Recommended Practices for Managing Open-Source Software and Software Bill of Materials” includes a range of guidance for both software developers and consumers. The report has four main sections:  

• Open Source Software Management 
• Creating and Maintaining a Company Internal Secure Open Source Repository  
• Maintenance, Support, and Crisis Management
• SBOM Creation, Validation, and Artifacts

The document builds on the U.S. federal government’s landmark 2021 cybersecurity executive order and the ESF’s software supply chain security best practices guides, which you can find at the bottom of this press release. 

In this blog, we’ll highlight four of our primary takeaways from the new OSS and SBOM management document, along with an analysis of why we think each is important. Please note that we don’t intend this article to be a comprehensive overview of the ESF’s recommendations; rather, we’re highlighting a few sections and takeaways that we view as particularly relevant to FOSSA users.

1. License Compliance is a Mission-Critical Part of Effective Open Source Management

As the report notes (in Section 5.1.2), SBOMs were conceived with open source license compliance as a primary use case. In fact, the SPDX bill of materials specification was originally announced as part of the Linux Foundation’s Open Compliance Program. Today, of course, many organizations utilize SBOMs for security and regulatory compliance reasons, but this shift hasn’t reduced the importance of open source license compliance.

On the contrary, enterprises of all types continue to rely heavily on open source to fuel application development, and organizations need to have a plan in place to maintain an inventory of their licenses and continuous compliance with licensing requirements — or risk the legal, reputational, and financial exposure that can come with non-compliance.

The report does highlight (Section 2.2.1) that managing compliance activities “may be a lot for individual programmers to track” (given the large volume of open source in most applications), but “organizations can provide tools to make this consideration easy or transparent for the humans at keyboards.” 

Our view is that automating license scanning and detection, attribution notice creation, and the implementation of license approve/deny policies are among the most important activities for enabling compliance at scale.

2. Customize SBOMs for Your Use Cases and Consumers

There are a lot of factors that contribute to SBOM usability. For starters, a high-quality SBOM needs to have accurate and up-to-date information, and it should include sufficient metadata to comprehensively describe the component. (The NTIA’s minimum required elements are a good place to start.)

But, as the report notes in Section 2.4, in cases where you intend your SBOM to be ingested by a third party, it’s also important that “care should be taken to ensure SBOMs are provided in a format that can be processed by their consumers without the loss of integrity…”

Section 5.1.1 echoes that guidance: “When creating an SBOM, consideration should be given on who is going to consume the SBOM and what formats are acceptable.”

In practice, the focus on making SBOMs usable for consumers starts with generating your SBOM in a machine-readable format (SPDX or CycloneDX). 

Another important consideration is customizing SBOM metadata to support its primary use case. For example, if you are producing an SBOM for a government agency, you must include the NTIA-required elements. If the SBOM consumer is an organization preparing for technical due diligence, you should include licensing fields. If security is a consideration, consider embedding (or linking to) VEX (Vulnerability Exploitability eXchange) documents with accurate state and justifications. And so on and so forth. 

The big-picture takeaway is that there’s no single SBOM format or standardized set of data fields that will be most useful to 100% of consumers, so it’s important to gather that information before generating and transmitting your bill of materials.

3. Go Beyond CVSS Scores to Prioritize Vulnerabilities

Traditionally, CVSS (Common Vulnerability Scoring System) has been the go-to for assessing and prioritizing open source vulnerabilities. The idea was that the higher the CVSS score, the greater the risk and the more urgent the remediation. 

However, CVSS isn’t the be-all, end-all. Although it communicates vulnerability severity, it doesn’t account for direct or indirect exploitability. Just because a vulnerability could have devastating effects doesn’t mean it’s actually likely to be exploited or is even accessible given the context of the vulnerable application. This is why relying too heavily on CVSS can lead to false positives and overload security teams with CVE alerts.

So, while CVSS is still an important part of vulnerability management programs, it’s best to include other inputs as well. Section 3.2 of the report highlights other frameworks worth using, such as the EPSS Scoring System; EPSS measures how likely it is that a specific vulnerability will be exploited in the wild, a dynamic determination given the persistence and ingenuity of threat actors.

4. Start Thinking About VEX

VEX (short for Vulnerability Exploitability eXchange) is the subject of frequent discussion in the report — it’s mentioned 61 times in total. Similar to EPSS, VEX is a potentially valuable tool in helping organizations understand whether vulnerabilities in their software are actually exploitable. However, VEX and EPSS differ in that VEX data is provided by the software supplier and based on internal inputs, while EPSS is a data model based on external factors. 

As such, VEX holds particular promise in helping SBOM consumers understand the security risks they’re inheriting from software suppliers. In other words, VEX could be key to unlocking many mission-critical SBOM security use cases. 

In a VEX document, the software supplier will annotate a particular vulnerability with information to help the consumer understand exploitability. VEX data fields include whether a product is affected by a vulnerability (“Status or State”), why the product is or isn’t affected (“Justification”), a detailed response to contextualize the justification (“Description”), and how to mitigate the vulnerability if the product is affected (“Recommendation”), among others.

The ESF guidance explains (Section 5.1.3) that “VEX provides additional context which may reduce the number of ‘false positive’ vulnerabilities that a vulnerability scanning (tool) would report against an SBOM due to the specific package instance.”

One of the challenges organizations seeking to adopt VEX currently face is that, as a relatively new standard, there’s still work to be done around standardization (e.g. which data fields to include in a VEX document) and automation (e.g. given the complex nature of modern applications, managing VEX with manual processes isn’t scalable). 

Despite these current barriers, it’s increasingly clear that security teams will be well served to start thinking about how to integrate VEX into their SBOMs (and develop processes for requesting suppliers to do the same). 

Section 5.1.3 of the report includes an example of how this might be done.

ESF Recommendations: The Bottom Line

The ESF’s report is a timely document that deals with several challenging and complex areas related to managing SBOMs and reducing the risks that can come from using open source software. I hope this article gives FOSSA users (and open source management/SBOM teams) a feel for the report and its focus areas, but I do encourage you to consider reviewing the document for a deeper dive.

Additionally, for more insights on these topics, consider checking out the following on-demand webinars:

• The Dos and Don'ts of Using SBOMs for Security
• Generating, Importing, and Managing SBOMs with FOSSA
• When "Open Source" Isn't Open Source

If there have been no recent code changes to your repository, you might assume that building an application is a static, reproducible process. But in modern applications that depend heavily on open source packages, this is not true. Package versions are constantly changing, often introducing unexpected risks or vulnerabilities and sometimes even new licenses. 

FOSSA monitors these changes, identifying any new licensing issues or security risks in each package revision. This enables teams to adopt a posture of proactive, continuous management of their open source software. But for teams with a large number of repositories and projects, it has the potential to create redundant alerts related to the same underlying issue. 

To help solve this problem, FOSSA recently launched auto-ignore rules, a feature designed to significantly streamline license compliance and vulnerability remediation. By creating a rule just once, you can apply it across other projects or future versions of a given package. This approach not only minimizes the need to resolve the same issue in multiple places but also dramatically reduces the number of open issues and the time spent on them, decreasing alert fatigue for your team.

This feature isn't just about reducing the number of alerts; it's about creating an intelligent system that remembers your decisions and applies them across your projects and future package versions.

How Auto-Ignore Rules Reduce Re-Work

FOSSA's new auto-ignore feature saves time in multiple scenarios:

1. Applying decisions to future revisions: Auto-ignore rules eliminate duplicative work by applying your decisions from one revision to future revisions. Typically, open source licenses change infrequently — you shouldn’t have to continuously resolve the same licensing issues on every revision. For example, once your team approves the license for a particular package version, auto-ignore rules can extend this acceptance to future versions of the package, as long as the license remains unchanged. This means your team won't be bogged down by alerts for the same licensing issue every time the package is updated — a significant step toward efficient license compliance management.
2. Applying decisions to all projects that share the same policy: Another key advantage is the application of auto-ignore rules across projects with shared policies. For instance, if your team determines that a specific issue is irrelevant for any SaaS application, you can apply an auto-ignore rule across all projects governed by your SaaS application policy. This ensures that all similar projects benefit from your vetting efforts, avoiding the need to resolve the same issue repeatedly across multiple projects.
3. Applying decisions from a project to its release group: Similarly, if you’ve ignored an issue for an individual project, you can now also apply that decision to the release that contains that revision of the package. 
4. Applying decisions globally: If you’ve made a decision about a particular package issue, you can also apply it to all projects globally.

A User-Friendly Experience for Enhanced Efficiency

Designed with a focus on user experience, auto-ignore rules are integrated seamlessly into your existing FOSSA workflow. When ignoring an issue, simply select where else this rule should apply, and a new auto-ignore rule will be created. 

FOSSA is the only license compliance solution that remembers what decisions you’ve made and applies them to other projects, so you don’t have to resolve the same issue in multiple places. 

Take the Next Step Toward Effective OSS Management

Current FOSSA customers can leverage auto-ignore rules in their workflow today. You can reference our documentation for more information. 

If you aren’t yet a FOSSA customer and are interested in auto-ignore rules, getting started is straightforward. You can sign up for a FOSSA premium account (recommended for smaller organizations) for immediate access to this feature, or request a demo (recommended for larger organizations) to get an in-depth look at how auto-ignore rules can help make your license compliance and security efforts more effective and efficient.

With the addition of auto-ignore rules, we are excited to continue enabling teams to focus on what truly matters for security and license compliance in their organizations.

Earlier this week, researchers from Ruhr University Bochum in Germany announced the discovery of a new vulnerability impacting the popular SSH protocol. The attack is named Terrapin, and it’s been assigned CVE-2023-48795. 

SSH (Secure Shell Protocol) is a cryptographic network protocol that enables secure communication over an unsecured network. It’s a versatile and widely adopted protocol that’s used in countless applications and computing environments.

Terrapin is a man-in-the-middle attack; the flaw allows an attacker to corrupt data being transmitted. This can result in a loss of information or bypass critical security controls such as keystroke timing protections or SHA-2 cryptographic hash requirements, allowing the threat actor to downgrade to SHA-1. Doing so opens up the possibility of other attacks on downstream applications, components, or environments that use SSH. ​​These associated vulnerabilities have been assigned CVE-2023-46445 (Rogue Extension Negotiation Attack in AsyncSSH) and CVE-2023-46446 (Rogue Session Attack in AsyncSSH).

There’s not necessarily a one-size-fits-all remediation for the Terrapin attack. As the Ruhr University researchers explain:

“Due to the widespread adoption of affected cipher modes, patching Terrapin (CVE-2023-48795) is notoriously difficult. To make matters worse, "strict kex" requires both peers, client and server, to support it in order to take effect. A wide variety of SSH implementations started adopting "strict kex" since public disclosure.”

With that said, the Ruhr University researchers have created a vulnerability scanner that you can use to see if your SSH server or client is susceptible. (They’ve also published a list that includes some affected SSH implementations and safe versions.)

Additionally, FOSSA Vulnerability Management subscribers can use our product to locate the CVE(s) in your codebase. You can do this by navigating to the “Packages” tab in the UI and entering the CVE numbers in the “Select a CVE” bar on the bottom-right side of the page. (We've also included a brief video demonstration at the bottom of this article.)

Vulnerability Impact and Significance

How concerned should you be about this vulnerability? While this will vary across organizations and implementations, in general, there is currently little reason to be overly alarmed. Here's why:

• Limited Impact: Terrapin can delete consecutive portions of encrypted messages, which in isolation will typically result in a stuck connection. Some of the most serious impacts identified are in downstream applications implementing SSH, such as AsyncSSH. An attacker may be able to disable certain keylogging obfuscation features, enabling them to conduct a keylogging attack; or, worst case, a threat actor can sign a victim's client into another account without the victim noticing, enabling phishing attacks.
• Difficult to exploit: An active man-in-the-middle attacker and specific encryption modes are prerequisites for the exploit. Intercepting SSH traffic requires a detailed understanding of a target's environment, limiting real-world applicability.

In short, Terrapin is a concern, but not a reason to panic.

Additional Resources: Understanding and Mitigating Terrapin

The Ruhr University researchers who announced the vulnerability have also published several valuable resources for those concerned about their exposure. These include:

Vulnerability scanner: A tool that can be used to determine if you’re vulnerable to the attack.

FAQ: Guidance on how organizations should prioritize remediation, how the attack works, which implementations are vulnerable, and more.

Patches: A list of affected versions and implementations (and the safe, patched versions).

Additionally, FOSSA Vulnerability Management users can reference the video below for guidance on locating the Terrapin CVEs. If you aren't currently a FOSSA user but would like to become one, please reach out to our team.

SCA (Software Composition Analysis) and SAST (Static Application Security Testing) tools both play important roles in secure application development, but there are notable differences between them. 

The biggest is that SCA tools focus on open source dependencies and their associated risks, while SAST tools focus on your proprietary code — e.g., the custom code your developers write or maintain, including how an open source component is used in proprietary code. 

As such, SAST provides a different perspective on vulnerabilities or weaknesses than SCA. Where SAST would tell you, “Your code has improper input validation,” SCA would tell you, “The code (OSS) your code is using has improper input validation.” In other words: The tools surface similar vulnerabilities, yet on dramatically different attack surfaces. 

Another significant difference is SCA has multiple use cases beyond vulnerability management, including SBOM management and open source license compliance. 

For these reasons, SCA and SAST are considered complementary: SAST tests your code and coding practices, while SCA tests your third-party code. 

In this blog, we’ll explain how both SCA and SAST work, the important differences between them, and how the tools can work together to strengthen security.

SCA, Explained

SCA tools analyze, inventory, and manage open source dependencies, their licenses, and their vulnerabilities. SCA works by scanning software applications to identify the third-party components and libraries they depend on. SCA tools can integrate with various development and CI/CD tools to automate the analysis as part of the software development process.

SCA supports several distinct use cases:

Open source license compliance: SCA tools report a list of open source licenses (and their associated dependencies) when scanning code. Some SCA tools (like FOSSA) will also list the obligations that your licenses carry — and even offer functionality to help achieve compliance, such as automating license notice creation. Additionally, SCA tools with strong policy engines can be configured to block builds if an out-of-policy license is detected. 

SBOM generation: Creating a software component inventory is a fundamental SCA capability, so it shouldn’t be a surprise that many SCA tools also support SBOM generation. For example, organizations can use FOSSA’s SCA offering to generate SBOMs in both the SPDX and CycloneDX formats, with a range of customization options. Some SCA tools also support third-party SBOM ingestion and management.

Open source vulnerability management: Beyond providing an inventory of known vulnerabilities (CVEs), SCA can help with prioritization and remediation. For example, FOSSA will show the CVSS and EPSS scores for a given vulnerability to support prioritization, and we’ll also report the fix and code path to help with remediation.

SAST, Explained

SAST is used to analyze an application’s source code, bytecode, or binary code for security vulnerabilities — without executing the program. SAST tends to be used very early in the software development lifecycle (such as in the development phase), which helps developers and security teams address possible security issues before deploying an application.

SAST identifies potential vulnerabilities by using predefined rulesets or security patterns. These rulesets are created based on known security best practices and common coding mistakes that may lead to security issues, including SQL injection, cross-site scripting (XSS), buffer overflows, and other security vulnerabilities. In practice, these vulnerabilities result in threat actors escalating authorized privileges, accessing restricted data, or executing malicious code. 

SAST utilizes several techniques to identify vulnerabilities, such as:

• Data flow analysis: This tracks how data moves through the application. It includes control flow analysis (to understand the order in which different parts of the code are executed) and code path analysis (understanding conditional statements, loops, and different execution paths).
• Taint analysis: This tracks the flow of untrusted or tainted data through the application. If user input is not properly sanitized or validated, it can be considered tainted, and the tool traces its path through the code to identify potential security risks.

Key Differences Between SCA and SAST

As we’ve discussed, although SCA and SAST both support security use cases, there are significant differences between the two tools. Here are some of the biggest.

1. SCA is used to identify open source dependencies. SAST is used to analyze proprietary or first-party code.
2. SAST tools do require access to source code, while SCA tools may not.
3. SCA supports open source license compliance and SBOM use cases, while SAST does not.
4. When SCA surfaces a vulnerability, the remediation is often upgrading (or replacing) an open source component. With SAST, the remediation is generally to modify the actual application code. 
5. SAST tends to be used earlier in the SDLC than SCA, in the development phase rather than the build phase.

Despite these differences, it is worth noting that a majority of vulnerabilities reported by SCA tools are the direct result of "SAST" scans on the source of an open source dependency. So, essentially, most open source vulnerabilities are SAST results run against that proprietary or open source code that have been published in a public database (such as MITRE, NIST, GitHub advisory, and so forth).

SCA and SAST: The Bottom Line

Although SAST and SCA work differently and have different purposes, they’re both important parts of managing security risks for modern applications. As such, many organizations benefit from using both tools. This is often done via integration into your CI/CD pipeline, which ensures that security assessments are conducted automatically with every code commit and deployment, providing timely feedback to developers.

With SCA and SAST in place — along with other testing tools and the right people and processes — organizations can strengthen their defenses against a range of security and open source license compliance risks.

For more information on FOSSA’s SCA tool and how it works, we recommend visiting our SCA product page.