Skip to main content

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:

  1. Sign in to DigiCert ONE.

  2. Navigate the Manager menu (top right) > Software Trust.

  3. Select Threat detection.

  4. Click on the scan alias to view more details.

  5. Review the following sections:

    1. Scan summary

    2. General information

    3. Licensing issues

    4. Common vulnerabilities and exposures

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 FOSSA 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 heading), and select one of the following options to download the report:

  1. Sign in to DigiCert ONE.

  2. Navigate to the Manager menu (top right) > Software Trust.

  3. Select Threat detection.

  4. Click on the scan alias to view more details.

  5. In the Scan summary section, click the Download icon.

  6. Select one of the following report types you want to download:

    1. Licensing report

    2. Vulnerability report

    3. SBOM report

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:

  1. Scroll to License issues.

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

  3. 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.

  4. 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.

    Nota

    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:

  1. Scroll to Common vulnerabilities and exposures (CVE).

  2. Click on the CVE ID to view more information about the vulnerability and identify how to resolve this issue.

  3. 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.

  4. If known solutions are available to fix the vulnerability, these are listed in the Remediation section.

    Suggerimento

    Consider reviewing our remediation options documentation if No fix available is listed in this section.

  5. 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:

    1. Click on the link in the CVE ID field.

    2. Scroll down to References to Advisories, Solutions, and Tools.

    3. 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.

In questa sezione: