Review scan results

FOSSA provides a Software Composition Analysis (SCA) tool to scan your software for open source components. FOSSA plugs into your development workflow to help your team automatically track, manage, and remediate issues with the open source you use to:

Stay compliant with software licenses and generate required attribution documents.
Enforce usage and licensing policies throughout your CI/CD workflow.
Monitor and remediate security vulnerabilities.
Flag code quality issues and outdated components proactively.

View scan

To view scan results:

Sign in to DigiCert ONE.
Navigate the Manager menu (top right) > Software Trust.
Select Threat detection.
Click on the scan alias to view more details.
Review the following sections:

Scan summary

Review the following information:

Fields	Description
Status	This status and the CI/CD status identifies if critical vulnerabilities were detected in the scan that you should resolve before releasing the software for consumption. Possible values: Fail means that critical vulnerabilities were identified. Recommendation is that you resolve these before you release your software. Pass means that no critical vulnerabilities were identified. However, non-critical (high, medium, and low) vulnerabilities could have been identified, review these results before releasing your software.
Scan alias	An alias that identifies this specific scan.
Requested by	The user that requested the scan.
Project alias	An alias that identifies which project this scan is related to.
Scanned on	The date and time of the scan.
Licensing issues	The number and severity of the license violations, compliance alerts, and vulnerabilities detected in your software. Refer to Licensing issues to review all issues found.
Common vulnerabilities and exposures	The number and severity of the vulnerabilities found in your software. Refer to Common vulnerabilities and exposures (CVE) to review all vulnerabilities found.

Download reports

When your threat detection scan completes, the following reports are automatically generated and made available here. Click on the download icon (to the right of Scan summary), and select one of the following options to download the report:

Sign in to DigiCert ONE.
Navigate to the Manager menu (top right) > Software Trust.
Select Threat detection.
Click on the scan alias to view more details.
In the Scan summary section, click the Download icon.
Select one of the following report types you want to download:
1. Licensing report
2. Vulnerability report
3. SBOM report

例 1. Licensing report

Select one of the following report formats:
1. HTML
  HTML reports are commonly chosen when the report needs to be viewed in a web browser. They can include interactive elements like hyperlinks and collapsible sections, making it easy for users to navigate and explore the report online. HTML is user-friendly and allows for the inclusion of rich content like images, charts, and tables.
2. Markdown
  Markdown reports are preferred when users want a lightweight and easily readable text format that can be easily converted to other formats. Markdown is often used by technical users or developers who want to customize or further process the report content. It's a good choice for documentation purposes and can be converted to HTML, PDF, or other formats using conversion tools.
3. PDF
  PDF reports are suitable when a fixed and consistent layout is required for printing or sharing with others. PDFs preserve the formatting, fonts, and layout of the report across different devices and platforms. They are often used for official or formal documentation and reports that need to be archived or printed.
4. CSV
  CSV reports are selected when users need the raw data in a tabular format that can be easily imported into spreadsheet software like Microsoft Excel or Google Sheets. This format is valuable when users want to perform custom data analysis, create charts, or conduct further data processing on the threat detection results.
5. Plain text
  Plain text reports are the most basic and lightweight format. They are often chosen when simplicity is the priority, and users need to view the report in a text editor or command-line interface. Plain text reports are easy to read and can be used for scripting or automated processing.

In the Report information field, select or unselect the following data to include or exclude from your report. Note: The bold checkmarks below are preselected by default but can manually be unselected.

Report information	HTML	Markdown	CSV	Plain TXT
Project declared licenses	✓	✓	✓	✓
First party licenses	✓	✓	✓	✓
Direct dependencies	✓	✓	✓	✓
Transitive dependencies	✓	✓	✓	✓
Dependency summary	✓	✓		✓
Full license list	✓	✓		✓
License file matches			✓	✓
License headers				✓
Copyrights	✓	✓		✓

In the Dependency metadata to include field, customize your report by selecting or deselecting the following metadata to include or exclude:
1. Package
2. Discovered licenses
3. Declared license
4. License header
5. Authors
6. Description
7. Package manager
8. Package home page
9. Package download URL
Select Download.

例 2. Vulnerability report

Select Download.

注意

Vulnerability reports are downloaded in PDF format.

例 3. SBOM report

Consider your organization's preferences, tooling support, and any specific requirements you may have for compatibility with other systems or standards before selecting a report format.

Select one of the following report formats:
1. SPDX
  This report format is in *.spdx format, it can be opened in an integrated development environment (IDE) or plain text editor, and is therefore more human-readable and flexible for manual review.
2. SPDX (JSON)
  This report format is structured for automation and better suited for consistent machine processing.
3. Cyclone DX (JSON)
  This report format is generally better suited for automation and integration with software tools due to its structured nature and the prevalence of JSON libraries in programming languages.
4. CycloneDX (XML)
  This report format offers a more human-readable format. If you need to review or edit the SBOM data manually, the XML format may be more convenient. CycloneDX (JSON) tends to result in smaller file sizes compared to CycloneDX (XML) because of JSON's compact nature.

Report information	SPDX	SPDX (JSON)	Cyclone DX (JSON)	CycloneDX (XML)
Project declared licenses	✓	✓	✓	✓
First party licenses	✓	✓	✓	✓
Direct dependencies	✓	✓	✓	✓
Transitive dependencies	✓	✓	✓	✓
Full license list	✓	✓	✓	✓
License file matches	✓	✓		✓
Vulnerabilities			✓	✓
Copyrights	✓	✓	✓	✓

In the Dependency metadata to include field, customize your report by selecting or deselecting the following metadata to include or exclude:
1. Package
2. Discovered licenses
3. Declared license
4. License header
5. Authors
6. Description
7. Package manager
8. Package home page
9. Package download URL
Select Download.

General information

Review the following information:

Fields	Description
Version	Version of file that was scanned. Possible values: HEAD The component identified in this field is being used directly from the latest development or master branch of its version control system (VCS) repository. VCS The component identified in this field's version information is not explicitly specified or is dynamically determined based on the latest commit or revision in the associated version control system.
Provider	The name of the vendor used to perform the Threat detection scan.
Scan ID	A unique ID assigned to this specific scan performed via Signing Manager Controller (SMCTL).
FOSSA scan URL	Click on the link in this field to view the scan in FOSSA.
Project name	The name of the project associated with this scan. Clicking on this name will open this project.
Project status	The status of the project associated with this scan. For more information refer to Project statuses.

Licensing issues

License violations, compliance alerts, and vulnerabilities found in the project

Review license issue detected

To review a license issue detected in your software:

Scroll to License issues.
Click on the Dependency name to view more information about the risk and identify how to resolve this issue.

Review the following information in the Affected dependency section to determine if you want to resolve or accept the risk associated with the license issue in your software:

Field	Description
Dependency identifier	Use this field to identify the affected dependency.
Dependency name	Refers to a recognizable and unique name assigned to the library or module that is affected by the CVE.
Dependency URL	A link to the location where a specific version of the affected software dependency can be found.
Dependency version	The version of the affected dependency.
Package manager	The package manager or dependency management system being used to manage the affected software dependency of a project.
Dependency depth	Indicates how many levels deep a specific dependency is within the hierarchy. The depth of a dependency refers to how many layers removed a dependency is from your project. Direct This is a library or component that your project explicitly includes and depends on. You specify it directly in your project's configuration or build files. Transitive When your direct dependencies have their own dependencies, those dependencies are known as transitive dependencies. These are indirectly required by your project due to the requirements of your direct dependencies. Deep A deep dependency is a transitive dependency that is several layers down in the dependency tree. It's farther removed from your direct dependencies and might have multiple layers of dependencies between it and your project.

Review License issue details

Field	Description
Issue type	This field lists the type of licensing issue identified, possible values are: Policy conflict Licensing issues that are denied. Flagged Licensing issues that have been flagged. Unlicensed Licensing issues that have been listed as unlicensed.
Flagged by policy	This field indicates that the detected license issue goes against the specific rules and criteria you've established for your project. Possible values include: Standard Bundle Distribution Recommended for software deployed on on-premises. Example: Apache Hadoop. Single-Binary Distribution Recommended for embedded software. Example: A mobile app. Website/Hosted Service Recommended for websites. Example: fossa.io. 注意 You can customize policy rules with certain conditions to only flag specific issues. Learn more.
License	The name of the license.
Description	A description of the concern regarding the license detected in your code.

Common vulnerabilities and exposures (CVE)

A vulnerability is a flaw in your system that can be exploited in a cyberattack to gain unauthorized access to or perform unauthorized actions on your system.

Common Vulnerabilities and Exposures (CVE) are publicly disclosed vulnerabilities that are assigned a severity score by the National Vulnerability Database (NVD).

Resolve vulnerabilities

To resolve your common vulnerabilities and exposures:

Scroll to Common vulnerabilities and exposures (CVE).
Click on the CVE ID to view more information about the vulnerability and identify how to resolve this issue.

Review the following information in the Affected dependency section to determine if you want to resolve or accept the risk associated with the vulnerability in your software:

Field	Description
Dependency identifier	Use this field to identify the affected dependency.
Dependency name	Refers to a recognizable and unique name assigned to the library or module that is affected by the CVE.
Dependency URL	A link to the location where a specific version of the affected software dependency can be found.
Dependency version	The version of the affected dependency.
Package manager	The package manager or dependency management system being used to manage the affected software dependency of a project.
Dependency depth	Indicates how many levels deep a specific dependency is within the hierarchy. The depth of a dependency refers to how many layers removed a dependency is from your project. Direct This is a library or component that your project explicitly includes and depends on. You specify it directly in your project's configuration or build files. Transitive When your direct dependencies have their own dependencies, those dependencies are known as transitive dependencies. These are indirectly required by your project due to the requirements of your direct dependencies. Deep A deep dependency is a transitive dependency that is several layers down in the dependency tree. It's farther removed from your direct dependencies and might have multiple layers of dependencies between it and your project.

If known solutions are available to fix the vulnerability, these are listed in the Remediation section.
提示
Consider reviewing our remediation options documentation if No fix available is listed in this section.

Vulnerability details provides information regarding how the severity of the vulnerability was calculated:

Field	Description
CWE name	Common Weakness Enumeration (CWE) is a standardized list of common software weaknesses and vulnerabilities. This field can help you understand the nature of the vulnerability and assess the potential risk associated with the vulnerability. For more information refer to CWE categories.
CVE ID	CVE ID is the unique identifier that identifies the common vulnerability and links to more information about this vulnerability in the National Vulnerability Database (NVD). To review solutions to the vulnerability provided to NVD: Click on the link in the CVE ID field. Scroll down to References to Advisories, Solutions, and Tools. Review solutions provided by different sources.
CVSS score	Score measures the threat and consequences of this vulnerability using the Common Vulnerability Scoring System (CVSS). Possible values: 0-10. Learn more about how this score was calculated.
CVSS severity	Severity measures the expected harm to your software after a successful exploit of this vulnerability. Possible values: Critical High Medium Low Informational
Description	Description provides an explanation of the vulnerability according to the NVD. This information should provide you with information regarding how to resolve the vulnerability.
Exploitability	This field provides information about the likelihood that a given vulnerability will be exploited. Possible values include: Actively exploitable The vulnerability has been well-documented and there are known and proven methods to exploit it. This implies that attackers have successfully exploited the vulnerability in the past and security professionals are generally familiar with the threat. Conceptually exploitable There is evidence or a proof of concept (PoC) demonstrating the existence of the vulnerability and that it can be exploited. However, it may not be widely or actively exploited in the real world. This indicates that the vulnerability is known, but it's not as critical or dangerous as an Actively exploitable vulnerability which is more mature. Undetermined if exploitable The exploitability of the vulnerability is not well-documented and it is unclear at this point whether or how the vulnerability can be exploited. This suggests that there is limited information available about the potential risks associated with the vulnerability.

本节内容如下: