The FOSSA product and engineering teams have been hard at work building and shipping new features (and making upgrades to existing features) to improve your experience with our platform. Here's a look at several new capabilities, along with context on why and how you can use them.
Spotlight Feature
Software Bill of Materials (SBOM) Enhancements
FOSSA’s SBOM functionality makes it easy for security and legal teams to get a precise, accurate inventory of their first- and third-party codebases.
FOSSA’s SBOM solution provides users with the following features:
- Broad language coverage
- An SBOM tool purpose-built for developers and security practitioners — with an easy-to-use CLI
- A precise inventory of all first- and third-party code dependencies to an unlimited depth. Users can generate an SBOM for any prior version of their software, not just the current one
- An accurate list of vulnerabilities across first and third-party codebases and whether there is a fix available
- The ability to import third-party SBOMs (CycloneDX only at this time)
- Audit-grade reports in structured SBOM formats:
- CycloneDX (XML, JSON)
- SPDX (tag value, JSON)
- Audit-grade reports in other file formats:
- HTML
- Markdown
- JSON
- CSV
- Plain Text
- The ability to choose attributes that go into each SBOM report
- Most up-to-date SBOM with each version scan and the ability to generate a report of previous versions
Other Recently Released Features
Users who want to connect to on-premises VCS to run the “Quick Import” function can now use the FOSSA Broker — a bridge between the FOSSA service and on-prem VCS. This allows users to scan Git repositories without having to send source code to FOSSA.
Users who wish to persist an “ignore” decision across packages can now create auto-ignore rules. Auto Ignore can be applied at the project, policy, or global levels and can be set to ignore a specific version or all versions of a package across a project or all projects. This feature reduces noise in the scan results set and eliminates the rework of continually ignoring packages that don’t have a negative impact on the codebase.
When prioritizing licensing issues, users can now filter issues based on whether the license in question was found as the “Declared” license of the package or whether it was “Discovered” in the package. Many customers want to start with the “Declared” licenses to start triaging/resolving licensing issues since they represent the package author’s licensing intent for the package. These filter settings can also be used to create new policies.
Filter combinations can be named and persisted through “Saved Filters.” Beyond issue prioritization, Saved Filters can be used for blocking CI. For example, a user might only want to block CI when the vulnerabilities in a project are of a certain severity (critical/high), found in a direct dependency, and have a fix available. This feature helps users create filters unique to their specific risk profile and apply those filters so they focus on what’s important.
- Discrete ticket creation. This feature enables users to create individual tickets for each issue, allowing issues to be parsed and assigned more easily.
- Default JIRA project by issue type. This allows users to select a default Jira project for each FOSSA issue type: Licensing, Security, or Quality. For example, for Project XYZ and issue type Licensing, a default Jira is automatically assigned when a ticket is created. This helps with issue triage across teams and streamlines issue-handling protocols.
- Jira “Closed” status improvements. Users can now specify which “Closed” statuses are set to “Ignore” in the FOSSA tool. Previously, all “Closed” status tickets in Jira were set to ”Ignore." Allowing users to make their own determination of what “Closed” status Jira issues should be set to “Ignored” gives them greater fidelity into issue management.
Please reach out to your customer success contact or email support@fossa.com if you have questions or would like guidance using the features discussed in this article.
