# OpenText Fortify Software Composition Analysis (SCA) Documentation
Explore our capabilities, integrations, API, and use-cases to elevate your open-source journey.
> Fortify SCA helps you take full control of security, compliance, and project health with a toolkit that revolutionizes the way you use open source.
### First Setup
### The Fortify SCA fundamentals webinar recording
Check out our latest training webinar to learn the fundamentals of Fortify SCA:
{% embed url="" %}
Need help getting started with Fortify SCA? Join one of our [upcoming webinars](https://portal.debricked.com/events) and ask questions directly to our experts.
### Need more help?
If you have any additional questions feel free to contact[ our team](/overview/help). You can also join [our community](https://portal.debricked.com/community) to stay up-to-date with everything related to Fortify SCA and the open source universe.
# Getting started
This section is your gateway to getting started with OpenText Fortify Software Composition Analysis (Fortify SCA).
Follow these steps after [creating an account](/overview/getting-started/create-a-debricked-account) with Fortify SCA:
1. [**Set up an integration**](/tools-and-integrations/integrations)\
If you have a project's dependency file but setting up an integration is not applicable at the moment, you can [upload the dependency file manually](/product/administration/repositories/upload-a-dependency-file-manually).
2. [**Set up a license use case**](/product/license-risk-management/set-up-a-use-case)\
When you first access the license view, you will see that all repositories are marked as "Unknown" in the risk column. This is because you have not configured any use cases for your repositories yet. Defining a use case helps the tool understand how you organize the code in your repositories, which affects the risk associated with any particular license.
3. [**Set up automations**](/product/automation/create-an-automation-rule)\
The automations engine allows for rules to be triggered based on conditions. For example, a rule can fail a pipeline if it detects a new high-risk vulnerability detected, or an unwanted license.
By default, Fortify SCA has set up a number of rules to prevent unwanted licenses or dangerous vulnerabilities. Click the toggle button to disable any rule.
# Create a Fortify SCA account
Create your OpenText Fortify Software Composition Analysis account effortlessly. Follow this simple guide to set up your account quickly.
You must create a Fortify SCA account to use our service. To create a Fortify SCA account, navigate to [our website](https://debricked.com/) and click [**Start for Free**](https://debricked.com/app/en/register) or [**Log in**](https://debricked.com/app/en/login).
There are two ways to create a Fortify SCA account:
* Sign up with email
* Sign up using GitHub SSO
### **Sign up with email**
{% hint style="info" %}
This process creates a new company account. To join an existing company account, contact your company administrator for assistance.
{% endhint %}
To sign up using your email address:
1. Type your email address.
2. Read and accept the privacy policy and terms and conditions.
3. Type your details.
4. Type a secure password for your account.
### **Sign up using GitHub SSO**
You can also sign up using your GitHub account:
1. Click the **GitHub** button on the [Sign-up page](https://debricked.com/app/en/register).
2. Sign in using your GitHub credentials.
3. Next, you can either choose to connect to an organization or continue without one.
* If your company or colleagues already use Fortify SCA, join the existing organization.
* If you are the first collaborator to join or prefer to use our tool privately, you can opt to continue without connecting to an organization.
4. Choose the email address you want to use with your Fortify SCA account and enter your information.
5. Create a secure password.
* The password will not be used if you are logging in through GitHub.
* The password is used to access admin pages if you have administrative rights.
* The password is used if you use the email to log in instead of using the GitHub Single Sign-On (SSO).
### Administrator role
If you are the first collaborator to sign up in our organization or if you are not associated with any organization, you will receive admin rights. Even if you sign up using Single Sign-On (SSO), you will still need to create a password for the admin interface due to handling of sensitive information.
As an administrator, you are allowed to:
* Add, remove, or edit users
* Manage access tokens
* Change user permissions such as:
* Allow SSO
* Enforce comments when marking vulnerabilities as unaffected
* Allow users to snooze vulnerability automations
# Running Fortify SCA
Learn about all the different ways of using OpenText Fortify Software Composition Analysis.
You can run Fortify SCA in any of the following ways:
* **Web**: [The Fortify SCA web app](https://debricked.com/app/en/login) enables a browser-based experience, providing all functions, including security and license scanning, automation, reporting, and more.
* **CLI**: [The Fortify SCA Command Line Interface](/tools-and-integrations/cli/debricked-cli) enhances open-source security and license compliance for your project through the command prompt. It allows you to conduct vulnerability scans on your local machine and seamlessly integrate Fortify SCA into your pipeline.
* **API**: [The Fortify SCA APIs](/tools-and-integrations/debricked-apis) allow you to integrate our service into your code, CI pipelines, and more.
* **Browser**: [The Fortify SCA Select Browser Extension](/product/open-source-select/debricked-select-browser-extension) integrates the **Select** option directly into your browser, allowing you to examine an open-source project's health metrics and license information without leaving the page.
# Help
Here are the various ways to receive additional assistance while using OpenText Fortify Software Composition Analysis.
You can get in touch with our team through two channels:
* **Our instant live chat:** Our instant live chat is available on weekdays from 9:00 AM to 5:00 PM CET. Connect with our Fortify SCA experts, who are ready to answer any questions you may have. You can access the chat through the [Fortify SCA tool](https://debricked.com/app/en/login) or [our website](https://debricked.com/) by clicking the **Chat** button.
* **Email:** Send an email directly to . You can expect a reply from us within 1 business day.
### **Unable to access live chat**
To access our live chat or the Help widget in the tool, accept the *Support and Functional* cookies. These cookies are essential for specific support features, onboarding tools, service notifications, and more. For additional information about the cookies we use, refer to our [Privacy Policy](https://debricked.com/privacy-policy/).
# Frequently asked questions (FAQ)
Browse our FAQ section for detailed answers to common questions about using OpenText Fortify Software Composition Analysis.
### Is Fortify SCA’s service *on prem* or *SaaS*?
Fortify SCA is a Software as a Service (SaaS) solution currently.
### What type of scanning does Fortify SCA do?
Fortify SCA utilizes manifest-based scanning, which effectively identifies security issues across a wide range of file formats. While binary scanning is often considered superior due to its ability to produce fewer false positives, it can overlook critical security vulnerabilities, supply chain attacks, and [licensing problems](/product/license-risk-management). Additionally, binary scanning does not account for test and build dependencies, which can still present risks, unlike manifest-based scanning.
Manifest-based scanning identifies components listed in your dependency files, while binary scanning analyzes and fingerprints binary files. Binary scanning can be useful when source code or package managers for installing dependencies are unavailable. However, it does not include development and test dependencies, which can pose significant risks. Manifest-based scanning is more effective at identifying vulnerabilities and compliance issues, making it better suited for the developer workflow. For vendor code and C++/C scanning, Fortify SCA can [scan an SBOM](/overview/language-support/cyclonedx-sbom) if the vendor provides one.
Ultimately, the decision between manifest scanning and binary scanning depends on your workflow and objectives. At Fortify SCA, we emphasize [automation](/product/automation) and tools that enable developers to identify and resolve issues swiftly and accurately. This is why we concentrate on manifest scanning.
### How accurate is the service in finding a vulnerability?
Fortify SCA detects any open-source vulnerabilities in your repository, drawing information from various sources, including but not limited to the NVD Database, NPM, C# Announcements, FriendsOfPHP’s security advisories, the Go Vulnerability Database, the PyPA Python Advisory Database, GitHub Issues, GitHub Security Advisories, mailing lists, and more. These sources are updated every 15 minutes to ensure that we identify as many vulnerabilities as possible.
### Fortify SCA has found a wrong dependency. What should I do?
If you think Fortify SCA has identified an incorrect dependency, you can [manage and override your dependency matches using our CLI](/tools-and-integrations/cli/debricked-cli/file-fingerprinting#manage-or-override-results).
### What is meant by “increased computation” for enterprise customers?
Increased computation is when the number of available workers is increased to allow scanning more number of files simultaneously. This greatly enhances the scan speed for enterprise customers.
### To what extent can root fixes break the code?
When root fixes cause issues in the code, you should manually update the dependencies. There is always a risk of breaking changes when updating these dependencies, and the extent of that risk varies with each update. While the risk is not inherently greater with root fixes than with indirect fixes, Fortify SCA ensures that dependency tree is not compromised by introducing a version of a dependency incompatible with its upstream dependencies.
### How long do I need to wait to before requesting a second password reset?
You must wait one hour before you can request a second password reset.
### Is there a way to restrict what repositories certain users can see?
[Role Based Access Control](/product/administration/users/role-based-access-control-enterprise), which is an Enterprise feature, enables granting and enforcing access to functionalities and integrated repositories by assigning predefined roles to users.
### Is it possible to extract a pie chart or other visualization of the identified licenses and dependencies?
You can export licenses, including both licenses and dependencies, in an Excel format, which allows you to create a pie chart. Alternatively, use the API for assistance.
### What do we classify as a “scan”?
When a developer commits code, the code is scanned irrespective of the size of the committed changes
### Does Fortify SCA run on a PC, or does it upload data to your servers?
There are several ways to run Fortify SCA.
* Manually upload your dependency files.
* Integrate Fortify SCA into your test pipelines through platforms such as GitHub or GitLab.
### How do you distinguish between frequent and sporadic contributors?
Fortify SCA examines averages and reviews the list of committers on a monthly basis. As many businesses have a certain number of "non-developer" committers for a limited time, the customers are expected to determine the actual number of contributing developers and incorporate the information into the contract.
### What measures does Fortify SCA implement to prevent and detect vulnerabilities?
Fortify SCA implements the following measures to prevent and detect vulnerabilities:
* Use own service to find known vulnerabilities in dependencies
* Conduct third-party penetration tests
* Continuously run own penetration tests internally
### Where is Fortify SCA’s data stored?
Customer data is stored using Google Cloud Platform (GCP) as the service provider, located in Netherlands.
# Upgrade your account
Enhance your OpenText Fortify Software Composition Analysis experience by learning how to upgrade your account.
When you sign up for a free account with Fortify SCA, you will receive 1,000 initial scan credits to use at your convenience, with no expiration date. After using your initial credits, you will receive an additional 100 free scan credits added to your account on the 1st of each month.
[Fortify SCA Premium & Enterprise accounts](https://debricked.com/pricing/) give you access to a range of premium features, including unlimited scans.
To upgrade your account, click **Upgrade to premium** in the left-side menu and follow the prompts. You must specify the number of developers who will be contributing to the repositories integrated with Fortify SCA. After you complete the process, you will have access to Fortify SCA with unlimited scans. To upgrade to our [paid tiers](https://debricked.com/pricing/) with unlimited scans, [click here](https://debricked.com/app/en/login?billingModal=enterprise,free).
> For an enterprise subscription, contact our sales team at [sales@debricked.com](mailto:support@debricked.com).
# Get help in Fortify SCA
Here are the different ways of getting more help while using OpenText Fortify Software Composition Analysis.
You can access our help center by clicking the **Help** button at the right bottom of the screen.
* **Interactive tutorials** explain the vulnerabilities and assist you in setting up integrations and license-related automations
* Access to our **Docs** enable you to find answers to your questions through the search bar
* **Our Instant live chat** is open weekdays from 9:00 to 17:00 CET and connects you with Fortify SCA experts ready to answer any of your questions
In case you want to get in contact with our support team through a different channel, you can also e-mail directly to . You can expect a reply within 1 business day.
### **Unable to access the help widget**
To get access to live chat or the Help widget in the tool, onboarding tools, or service notices, you must accept the Support and Functional cookies. For more information about these cookies, see the [**Privacy Policy**](https://debricked.com/privacy-policy/).
# Language support
See the full list of the languages and package managers currently supported by OpenText Fortify Software Composition Analysis.
Fortify SCA now supports a broad array of programming languages and package managers, allowing you to scan your code in your native language. Here is the complete list of languages and their level of support:
### Supported file formats and features
Following is the complete list of supporting languages, including root dependencies, indirect dependencies, security scanning, and license scanning.
Language
Package manager
Supported file formats
Dependency trees
Root fix
Pull Request
Reachability Analysis
High Performance Scan
C#
Nuget
.csproj
true
true
false
false
Yes
C#
Nuget
package.lock.json
true
true
false
false
Yes*
C#
Nuget
packages.config
true
false
false
false
Yes
C#
Packet
paket.lock
false
false
false
false
Yes*
C#
-
fingerprinted files (.dll, .nupkg and more**)
false
false
false
false
-
CycloneDX SBOM
-
bom.json
true
false
false
false
Yes*
CycloneDX SBOM
-
bom.xml
true
false
false
false
Yes*
Go
Bazel
WORKSPACE
true
true
false
false
-
Go
Bazel
install.json
true
true
false
false
Yes*
Go
Go Modules
go.mod
true
true
false
false
Yes
Go
Go Dep
gopkg.lock
false
false
false
false
Yes*
Java / Kotlin
Gradle
build.gradle
true
true
false
true
Yes
Java / Kotlin
Gradle
build.gradle.kts
true
true
false
true
Yes
Java / Kotlin
Maven
pom.xml
true
true
false
true
Yes
Java / Kotlin
Bazel
WORKSPACE
true
true
false
true
-
Java / Kotlin
Bazel
install.json
true
true
false
true
-
Java / Kotlin
-
fingerprinted files (.jar, .war, pom.xml and more*)
false
false
false
false
-
JavaScript
NPM
package.json
true
true
true
false
Yes
JavaScript
NPM
package.lock.json
true
true
true
false
Yes*
JavaScript
Yarn
package.json
true
true
true
false
Yes
JavaScript
Yarn
yarn.lock
true
true
true
false
Yes*
JavaScript
Bower
bower.json
true
false
false
false
Yes
JavaScript
pnpm
package.json
true
true
true
false
Yes
JavaScript
pnpm
pnpm-lock.yaml
true
true
true
false
Yes*
JavaScript
-
fingerprinted files (.js, .ts and more**)
false
false
false
false
-
Objective-C
CocoaPods
podfile.lock
false
false
false
false
Yes*
PHP
Composer
composer.json
true
false
false
false
Yes
PHP
Composer
composer.lock
true
false
false
false
Yes*
Python
Pip
requirements.txt
true
false
false
false
Yes
Python
Pipenv
Pipfile
false
false
false
false
-
Python
Pipenv
Pipfile.lock
false
false
false
false
-
Python
UV
pyproject.toml
true
false
false
false
Yes
Python
UV
uv.lock
true
false
false
false
Yes*
Python
poetry
pyproject.toml
true
false
false
false
Yes
Python
poetry
poetry.lock
true
false
false
false
Yes*
Python
-
fingerprinted files (.py, .txt, .sh, .c, .egg, .h and more**)
false
false
false
false
-
Ruby
RubyGems
Gemfile.lock
false
false
false
false
Yes*
Rust
Cargo
Cargo.lock
false
false
false
false
Yes*
Swift
CocoaPods
podfile.lock
false
false
false
false
Yes*
Scala
SBT
build.sbt
true
true
false
false
Yes
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
\*\*When constructing our knowledge base, Fortify SCA downloads files, extracts their contents, and creates fingerprints for all file content, except for a few excluded patterns. After that, fingerprints are generated for all the content within each file. For example, Fortify SCA specifically matches .dll files used in C# applications and .class files found within .jar files.
*For details on scanning Conan (C++) projects with Fortify SCA, refer to the topic* [*Scanning Conan (C++) projects*](/tips-and-tricks/workarounds/scanning-conan-c++-projects)*.*
# C# - Nuget, Paket
See a breakdown of the file formats and features supported in C#.
Fortify SCA currently supports the tracking of C# dependencies through:
* [NuGet](https://www.nuget.org/), using *.csproj*, *packages.lock.json* and *packages.config* files
* [file fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting), to find dependencies not defined in manifest-files
* Paket, using *paket.lock* file
If there is a modern NuGet project where dependencies are defined in *.csproj* files, Fortify SCA recommends using the *packages.lock.json* file. This file allows Fortify SCA to analyze the dependency tree and suggest root fixes. By default, NuGet does not generate this file, but you can create it using the [High Performance Scans](/tools-and-integrations/cli/debricked-cli/high-performance-scans) technology with the Fortify SCA CLI or by enabling [repeatable package restores](https://devblogs.microsoft.com/nuget/enable-repeatable-package-restores-using-a-lock-file/) and then committing the generated file. When you run the resolve command, the Fortify SCA CLI automatically detects all manifest files that lack the recommended lock files and generates them as needed.
In older NuGet projects, dependencies are typically stored in a *packages.config* ile. Fortify SCA recommends that users generate the necessary lock file for dependency management and root fixes using High Performance Scans with the Debricked CLI. The command *debricked resolve* will create a *packages.lock.json* style file by first translating the *packages.config* into a `.csproj` file using NuGet. From there, the lock file is generated. Once the process is complete, the *.csproj* file is deleted, leaving only the newly created lock file. To avoid potential conflicts with NuGet, the specially created NuGet lock file is named as *packages.config.nuget.debricked.lock.*
By default, in all integrations except the GitHub app, the *Debricked* scan command will automatically try to generate the necessary lock files before sending your dependency files for scanning.
Fortify SCA also supports sending only *.csproj* or *packages.config* files for scanning, but the *packages.lock.json* or *packages.config.nuget.debricked.lock* file is preferred, as it provides the most accurate tracking of dependency versions and trees, enabling root fixes.
[High Performance Scans](/tools-and-integrations/cli/debricked-cli/high-performance-scans) for NuGet utilize native commands when resolving and include all dependencies defined with NuGet, including those managed through [Central Package Management (CPM)](https://learn.microsoft.com/en-us/nuget/consume-packages/central-package-management).
If at least one of the supported files is committed to your repository, it will be automatically scanned for dependencies when you have done any of our integrations to your CI/CD pipeline.
### File fingerprinting
Fortify SCA supports scanning for C# dependencies not defined in manifest files through **file fingerprinting.** Fortify SCA database contains the hashes of *.nupkg* files as well as their unpacked contents (including .dll files) for all packages in the NuGet gallery. This is used when comparing with the contents of your application, to ensure as accurate matches as possible. For more information on file fingerprinting and how to set it up, see [file fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting).
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
Nuget
.csproj
true
true
true
true
true
true
false
false
Yes
Nuget
package.lock.json
true
true
true
true
true
true
false
false
Yes*
Nuget
packages.config
true
true
true
true
true
false
false
false
Yes
Paket
paket.lock
true
true
false
true
true
false
false
false
Yes*
-
fingerprinted files (.dll, .nupkg and more**)
true
true
false
true
true
false
false
false
-
\*This is a native lock file format. Native lock file formats are the fastest formats to scan.
\*\*When building the knowledge base, the files are downloaded, unpacked and fingerprints are created for all file contents, except for certain excluded patterns. The fingerprints are created for the contents of each file. For example, Debricked matches *.dll* files for C# and *.class* files within *.jar* files for Java, along with similar files from other programming languages.
# CycloneDX SBOM
This section provides a breakdown of the file formats and features supported in CycloneDX SBOM.
Fortify SCA supports tracking dependencies in [CycloneDX SBOM](https://cyclonedx.org/) using files in JSON and XML formats.
To ensure that Fortify SCA identifes the SBOM files as CycloneDX SBOMs, please name them using one of the following conventions:
* *.bom..json*
* *.\*cdx.json*
* *.\*cdx.xml*
* *.bom..xm*l
The specific features available for the SBOM will depend on the libraries included and the individual package managers used.
### **Supported file formats and features**
Language
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Rachability Analysis
High Performance Scan
CycloneDX SBOM
bom.json, cdx.json
true
true
true
true
true
false
false
true
Yes*
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
### Analyzing external SBOM files using Fortify SCA - video guide
{% embed url="" %}
# Dart - Pub
See the Dart Pub files supported by Fortify SCA and their scan precedence.
Fortify SCA tracks Dart dependencies managed with Pub through:
* `pubspec.yaml`, the package manifest
* `pubspec.lock`, the primary lock-file dependency source
* `pubspec.deps.json`, the complete resolved dependency graph
### Pub
Fortify SCA can scan `pubspec.lock` as a standalone file. It can also scan `pubspec.yaml` independently during manual or stateless uploads. When both files are present, Fortify SCA scans them together. This produces a flat dependency list without root or scope data.
Generate `pubspec.deps.json` before scanning to retain root and scope data:
```bash
dart pub deps --json > pubspec.deps.json
```
Commit `pubspec.deps.json` with your project files. Fortify SCA uses it instead of `pubspec.lock` when both files are present.
The generated graph includes direct, development, and transitive dependencies. It preserves parent-child relationships for dependency tracking, validation, and SBOM generation.
### Supported file formats and features
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
Pub
pubspec.yaml
true
false
false
true
true
false
false
false
Yes
Pub
pubspec.lock
true
false
false
true
true
false
false
false
Yes
Pub
pubspec.deps.json
true
true
true
true
true
false
false
false
Yes*
**\*** This is a native lock file format. Native lock file formats are the fastest formats to scan.
# Go - Go Modules, Go Dep, Bazel
This section provides a breakdown of the file formats and features supported in Go.
Fortify SCA supports tracking Go dependencies through:
* Go Modules, using *go.mod* files
* Go Dep, using *gopkg.lok* files
* Bazel, using *WORKSPACE* files
### **Go Modules**
Fortify SCA supports tracking Go dependencies using the Go Modules dependency management system and its associated go.mod file. To achieve the fastest and most accurate results, it is necessary to create a file containing the resolved dependency tree, *.gomod.debricked.lock*, before scanning.
This can be done using the [High Performance Scans](/tools-and-integrations/cli/debricked-cli/high-performance-scans) technology in [Fortify SCA CLI](/tools-and-integrations/cli/debricked-cli). If you execute the *resolve* command, the CLI automatically identifies all manifest files that lack the recommended *go.lock* files and generates them as needed.
You can manually generate the recommended file(s) by running *go mod graph* followed by *go list -m all*, and storing the outputs separated by two new lines between the sections in the *gomod.debricked.lock* file.
```bash
printf "$(go mod graph)\n\n$(go list -mod=readonly -e -m all)" > gomod.debricked.lock
```
Every *gomod.debricked.lock* must be put in the same directory as the corresponding *go.mod.*
Fortify SCA recommends running *go mod tidy* to clean up unused modules before pushing the *go.mod* files, ensuring more accurate service results.
### **Bazel**
Fortify SCA supports Go projects that utilize Bazel, scanning the *WORKSPACE* file format alongside any *Go* file formats in use. Although Bazel does not have native support for Go, support can be added using [Gazelle](https://github.com/bazelbuild/bazel-gazelle).
### **Go Dep**
Go Dep and its associated file *Gopkg.lock* is deprecated and will not get any improvements present in other formats, such as Go Modules.
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
Bazel
WORKSPACE
true
true
true
true
true
true
false
false
-
Bazel
install.json
true
true
true
true
true
true
false
false
Yes*
Go Modules
go.mod
true
true
true
true
true
true
false
false
Yes
Go Dep
gopkg.lock
true
true
false
true
true
false
false
false
Yes*
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
# Java & Kotlin - Gradle, Maven, Bazel
This section provides a breakdown of the file formats and features supported in Java/Kotlin.
Fortify SCA currently supports tracking Java or Kotlin dependencies using:
* Gradle (using *build.gradle* and *build.gradle.kts* files)
* Maven (using *pom.xml* files)
* Bazel (using *WORKSPACE* and *install.json* files)
* [File fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting) to detect dependencies not specified in manifest files
### **Gradle**
To achieve the fastest and most accurate results, create a file containing the resolved dependency tree named *.gradle.debricked.lock* before scanning.
This can be accomplished using the [High Performance Scans](/tools-and-integrations/cli/debricked-cli/high-performance-scans) technology in [OpenText Core SCA CLI](/tools-and-integrations/cli/debricked-cli). If you execute the *resolve* command, the CLI automatically identifies all manifest files that lack the recommended Gradle lock files and generates them as needed.
You can create the recommended file(s) manually by running the *Gradle dependencies* command and saving the output in a *gradle.debricked.lock* file.
```bash
gradle dependencies > gradle.debricked.lock
```
Every *gradle.debricked.lock* file should be placed in the same directory as its corresponding *build.gradle* or *build.gradle.kts* file.
### **Maven**
To achieve the fastest and most accurate results, create a file containing the resolved dependency tree named *.maven.debricked.lock* before scanning.
This can be accomplished using the [High Performance Scans](/tools-and-integrations/cli/debricked-cli/high-performance-scans) technology in our [OpenText Core SCA CLI](/tools-and-integrations/cli/debricked-cli). If you execute the *resolve* command, the CLI automatically identifies all manifest files that lack the recommended maven lock files and generates them as needed.
You can manually generate the recommended file(s) by running the **Maven dependency:tree** plugin and saving the output to a *maven.debricked.lock* file.
```bash
mvn dependency:tree -DoutputFile=maven.debricked.lock -DoutputType=tgf
```
Every *maven.debricked.lock* file should be placed in the same directory as the corresponding *pom.xml* file.
### **Bazel**
Fortify SCA supports Java projects that utilize Bazel by scanning the *WORKSPACE* file format along with any Java file formats in use. To ensure fast and accurate scans, OpenText Core SCA recommends utilizing *rules\_jvm\_external* to generate an *install.json* file, which resolves and pins all indirect dependencies in a lock file.
For more information on setting this up in your project, see [Bazel blog](https://blog.bazel.build/2019/03/31/rules-jvm-external-maven.html).
### File fingerprinting
Fortify SCA supports scanning for Java dependencies not defined in manifest-files through **file fingerprinting.** Our database contains the hashes of *.jar* and *.war* files as well as their unpacked contents for all packages in the largest maven repository. This is used when comparing with the contents of your application, to ensure as accurate matches as possible.
For more information on file fingerprinting and how to set it up, see [file fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting).
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
Gradle
build.gradle
true
true
true
true
true
true
false
true
true
Gradle
build.gradle.kts
true
true
true
true
true
true
false
true
true
Maven
pom.xml
true
true
true
true
true
true
false
true
true
Bazel
WORKSPACE
true
true
true
true
true
true
false
true
false
Bazel
install.json
true
true
true
true
true
true
false
true
false
-
fingerprinted files (.jar, .war, pom.xml and more*)
true
true
false
true
true
false
false
false
false
\*When building the knowledge base, the files are downloaded, unpacked and fingerprints are created for all file contents, except for certain excluded patterns. The fingerprints are created for the contents of each file. For example, OpenText Core SCA matches *.dll* files used in C# and *.class* files found within *.jar* files from Java, among others.
# JavaScript - NPM, Yarn, Bower, pnpm
See a breakdown of the file formats and features supported in JavaScript.
Fortify SCA now tracks JavaScript and TypeScript dependencies through:
* NPM (using *package.json* and *package-lock.json* files)
* Yarn (using *package.json* and *yarn.lock* files)
* Bower (using *bower.json* files)
* pnpm ((using *package.json* and *pnpm-lock.yaml* files)
* [file fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting) to detect dependencies not specified in manifest files
Fortify SCA recommends committing the *lock* files to achieve the most accurate tracking, as these files include the specific resolved versions of both direct and indirect dependencies. If you only commit the *package.json* file, Fortify SCA will update all dependencies to the latest available versions based on the specified version constraints.
If at least one supported file is committed to the repository, it will automatically be scanned for dependencies when you integrate with the CI/CD pipeline.
### Bower
To achieve the fastest and most accurate results, create a file containing the resolved dependency tree before scanning. This can be accomplished using the [High Performance Scans](/tools-and-integrations/cli/debricked-cli/high-performance-scans) technology in [Fortify SCA CLI](/tools-and-integrations/cli/debricked-cli). By executing the *resolve* command, the CLI automatically identifies all manifest files that lack the recommended *bower.debricked.lock* files and generates them as needed.
### File fingerprinting
Fortify SCA supports scanning for JavaScript dependencies not defined in manifest-files through **file fingerprinting.** The database contains the hashes of relevant files (including .js and .ts files) for all packages in the npm registry. This is used when comparing with the contents of your application, to ensure as accurate matches as possible.
For more information on file fingerprinting and how to set it up, see [file fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting).
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
NPM
package.json
true
true
true
true
true
true
true
false
Yes
NPM
package.lock.json
true
true
true
true
true
true
true
false
Yes*
Yarn
package.json
true
true
true
true
true
true
true
false
Yes
Yarn
yarn.lock
true
true
true
true
true
true
true
false
Yes*
Bower
bower.json
true
true
true
true
true
false
false
false
Yes
pnpm
package.json (using the attributepackageManager)
true
true
true
true
true
true
true
false
Yes
pnpm
pnpm-lock.yaml
true
true
true
true
true
true
true
false
Yes*
-
fingerprinted files (.js, .ts and more**)
true
true
false
true
true
false
false
false
-
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
# Objective-C - CocoaPods
See a breakdown of the file formats and features supported in Objective-C.
Fortify SCA now tracks Objective-C dependencies through CocoaPods using *Podfile.lock* files. If this file is committed to the repository, it will be automatically scanned for dependencies when integrated with the Fortify SCA CI/CD pipeline.
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
CocoaPods
podfile.lock
true
true
false
true
true
false
false
false
Yes*
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
# PHP - Composer
See a breakdown of the file formats and features supported in PHP.
Fortify SCA currently tracks PHP dependencies installed through Composer dependency manager, using either the *composer.json* or *composer.lock* files.
Fortify SCA recommends including the *composer.lock* file, as it contains resolved versions of both direct and indirect dependencies, leading to more accurate scan results.
The *composer.lock* file is generated whenever one of the following commands is executed:
```
composer install
composer required
composer update
```
If at least one of the supported files is committed to the repository, it will be automatically scanned for dependencies when integrated with the Fortify SCA CI/CD pipeline.
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
Composer
composer.json
true
true
true
true
true
false
false
false
Yes
Composer
composer.lock
true
true
true
true
true
false
false
false
Yes*
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
# Python - Pip, Pipenv, UV, poetry
See a breakdown of the file formats and features supported in Python.
Fortify SCA now tracks Python dependencies through:
* Pip (using the older *requirements.txt* files)
* Pipenv (using the newer *Pipfile.lock* files)
* UV (using the newer *uv.lock* files)
* poetry (using the newer *poetry.lock* files)
* [file fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting), to find dependencies not defined in manifest-files
### Pip
To achieve the fastest and most accurate results, create a file containing the resolved dependency tree before scanning. This can be accomplished using the [High Performance Scans](/tools-and-integrations/cli/debricked-cli/high-performance-scans) technology in [Fortify SCA CLI](/tools-and-integrations/cli/debricked-cli). By executing the *resolve* command, the CLI automatically identifies all manifest files that lack the recommended lock files and generates them as needed. The first part of the name is based on the name of the file it was generated from. The file naming format is as follows:
```
.pip.debricked.lock
```
Example: *.requirements.txt.pip.debricked.lock*
If at least one of the supported files is committed to the repository, it will be automatically scanned for dependencies when integrated with the Fortify SCA CI/CD pipeline.
### File fingerprinting
Fortify SCA supports scanning for Python dependencies not defined in manifest files through **file fingerprinting.** Fortify SCA database contains the hashes of .whl files as well as their unpacked contents (including .py files) for all packages in the Python package index (PyPI). This is used when comparing with the contents of your application, to ensure as accurate matches as possible.
For more information on file fingerprinting and how to set it up, see [file fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting).
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
High Performance Scan
Pip
requirements.txt
true
true
true
true
true
false
false
false
Yes
true
Pipenv
Pipfile
true
true
false
true
true
false
false
false
false
Pipenv
Pipfile.lock
true
true
false
true
true
false
false
false
Yes
true
UV
pyproject.toml
true
true
true
true
true
false
false
false
Yes
false
UV
uv.lock
true
true
true
true
true
false
false
false
Yes*
false
poetry
pyproject.toml
true
true
true
true
true
false
false
false
Yes
false
poetry
poetry.lock
true
true
true
true
true
false
false
false
Yes*
false
-
fingerprinted files (.py, .txt, .sh, .c, .egg, .h and more**)
true
true
false
true
true
false
false
false
-
false
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
High Performance Scan
Pip
requirements.txt
true
true
true
true
true
false
false
false
Yes
true
Pipenv
Pipfile
true
true
false
true
true
false
false
false
false
Pipenv
Pipfile.lock
true
true
false
true
true
false
false
false
Yes
true
UV
pyproject.toml
true
true
true
true
true
false
false
false
Yes
false
UV
uv.lock
true
true
true
true
true
false
false
false
Yes*
false
poetry
pyproject.toml
true
true
true
true
true
false
false
false
Yes
false
poetry
poetry.lock
true
true
true
true
true
false
false
false
Yes*
false
-
fingerprinted files (.py, .txt, .sh, .c, .egg, .h and more**)
true
true
false
true
true
false
false
false
-
false
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
High Performance Scan
Pip
requirements.txt
true
true
true
true
true
false
false
false
Yes
true
Pipenv
Pipfile
true
true
false
true
true
false
false
false
false
Pipenv
Pipfile.lock
true
true
false
true
true
false
false
false
Yes
true
UV
pyproject.toml
true
true
true
true
true
false
false
false
Yes
false
UV
uv.lock
true
true
true
true
true
false
false
false
Yes*
false
poetry
pyproject.toml
true
true
true
true
true
false
false
false
Yes
false
poetry
poetry.lock
true
true
true
true
true
false
false
false
Yes*
false
-
fingerprinted files (.py, .txt, .sh, .c, .egg, .h and more**)
true
true
false
true
true
false
false
false
-
false
\**This is a native lock file format. Native lock file formats are the fastest formats to scan.*
# Ruby - RubyGems
See a breakdown of the file formats and features supported in Ruby.
Fortify SCA now tracks Ruby dependencies through RubyGems, using its associated *Gemfile.lock* files. If at least one of the supported files is committed to the repository, it will be automatically scanned for dependencies when integrated with the Fortify SCA CI/CD pipeline.
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
RubyGems
Gemfile.lock
true
true
false
true
true
false
false
false
Yes*
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
# Rust - Cargo
See a breakdown of the file formats and features supported in Rust.
*The support for this language is currently in beta. Vulnerability results may be less accurate than normal.*
Fortify SCA now tracks Rust dependencies through Cargo, using its associated *Cargo.lock* files.\
\
This file is generated whenever one of the following commands is executed:
cargo build
cargo update
If the file is committed to the repository, it will be automatically scanned for dependencies when integrated with the Fortify SCA CI/CD pipeline.
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
Cargo
Cargo.lock
true
true
false
true
false
false
false
false
Yes*
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
# SPDX SBOM
Learn how Fortify SCA scans SPDX Software Bills of Materials.
Fortify SCA supports tracking dependencies and licenses in [SPDX SBOMs](https://spdx.dev/specifications/) in JSON format.
To ensure Fortify SCA scans SPDX files please, name the file with the `.spdx.json` extension.
{% hint style="info" %}
Fortify SCA currently supports SPDX JSON files. Support for additional SPDX extensions is planned.
{% endhint %}
### **Supported file formats and features**
Language
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Rachability Analysis
High Performance Scan
SPDX SBOM
spdx.json
true
true
true
true
true
false
false
true
Yes*
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
# Swift - CocoaPods
See a breakdown of the file formats and features supported in Swift.
Fortify SCA now tracks Swift dependencies through CocoaPods using *Podfile.lock* files.
If the file is committed to the repository, it will be automatically scanned for dependencies when integrated with the Fortify SCA CI/CD pipeline.
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
CocoaPods
podfile.lock
true
true
false
true
true
false
false
false
Yes*
**\***This is a native lock file format. Native lock file formats are the fastest formats to scan.
# Linux package managers
See a breakdown of the file formats and features supported in Linux.
Apart from the various programming package management systems, Fortify SCA also supports package managers for various Linux distributions, allowing you to find and monitor potential vulnerabilities of your server or Docker container.
To start tracking your server or Docker vulnerabilities, you should first execute your package manager(s) list command and redirect the output to a text file:
* For Debian, Ubuntu and most derivatives, execute the following command:
```
apt list --installed > apt.list
```
* For Alpine Linux which is widely used by Docker containers, execute the following command:
```
apk list --installed > apk.list
```
To scan them for dependencies, the output file(s) should be either committed to the repository or manually uploaded.
# Scala - SBT
This page provides a detailed overview of the file formats and features that Scala supports.
Fortify SCA now supports tracking Scala dependencies through the following methods:
* SBT, by utilizing *pom.xml* files
* [file fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting), to find dependencies not specified in manifest files
### SBT
Fortify SCA does not directly support scanning *build.sbt* files. However, SBT provides commands to generate a corresponding pom.xml file. This *pom.xml* file can be used to create a lock file, which allows Fortify SCA to analyze the complete list of direct and indirect dependencies along with their relationships.
You can do this using the High-Performance Scans technology available in [Fortify SCA CLI](/tools-and-integrations/cli/debricked-cli). By running the *resolve* command, the CLI will automatically detect any *build.sbt* files and use them to generate the needed maven dependency files. This is also run by default within the *scan* command.
You can manually create the recommended file(s) by running the following commands and saving the output into a *maven.debricked.lock* file.
```
// sbt makePomSome code
mv target/scala-*/*.pom pom.xml
mvn dependency:tree -DoutputFile=maven.debricked.lock -DoutputType=tgf
```
{% hint style="info" %}
Every *maven.debricked.lock* file should be placed in the same directory as the corresponding *pom.xml* file.
{% endhint %}
### File fingerprinting
Fortify SCA offers the capability to scan for Scala dependencies that are not specified in manifest files through file fingerprinting. The Fortify SCA database includes the hashes of .jar and .war files, along with their unpacked contents, for all packages in the largest Maven repository. This information is used to compare with the contents of your application, ensuring the most accurate matches possible.
*For more information on file fingerprinting and how to set it up, see* [*file fingerprinting*](/tools-and-integrations/cli/debricked-cli/file-fingerprinting)*.*
### **Supported file formats and features**
Package manager
Supported file formats
Root dependencies
Indirect dependencies
Dependency trees
Security scanning
License scanning
Root fix
Pull Request
Reachability Analysis
High Performance Scan
SBT
build.sbt
true
true
true
true
true
true
No
false
Yes
# Security overview
*For information about Fortify SCA security, refer to the following document.*
{% hint style="info" %}
*The content of this PDF was last updated in May 2024, and represents the status quo as of the time it was written.*
{% endhint %}
{% file src="/files/dkGl8TbEUoHJbIRNbxki" %}
# Vulnerability management
This area covers how to manage open-source vulnerabilities in your application.
# Security terms
A glossary of common security terms used in the Fortify SCA tool.
Here are some of common security terms that are used within the tool:
### **Common Vulnerability Enumeration (CVE)**
This is a vulnerability published in an open database by NVD, with an assigned vulnerability ID known as CVE ID. Examples include Heartbleed (CVE-2014-0160) and Shellshock (CVE-2014-6271).
{% embed url="" %}
### **Common Vulnerability Scoring System (CVSS)**
An open framework for describing the severity of vulnerabilities, where each vulnerability is given a score between 0 and 10, with 10 being critical.
{% embed url="" %}
### **Common Weakness Enumeration (CWE)**
This is a weakness, either in software or in hardware, that may be exploited in a specific system. The CWE list is a tree hierarchy with different levels of abstraction. An example of a CWE tree chain, from high to low abstraction, may look like:
"Improper Restriction of Operations within the Bounds of a Memory Buffer" (CWE-119) -> "Buffer Copy without Checking Size of Input" (CWE-120) -> "Stack-based Buffer Overflow" (CWE-121).
{% embed url="" %}
### **Common Platform Enumeration (CPE)**
This is a naming scheme for IT systems, software, and packages. An example of a CPE string for the React framework, version 16, is:
*cpe:2.3*:a:*facebook:react:16.0.0:\*:\*:\*:\*:\*:\*:\**.
{% embed url="" %}
### **Node Package Manager (npm)**
A package manager for JavaScript consisting of a command line client **npm**, along with an online database of packages known as the **npm registry**. npm handles local dependencies, as well as global JavaScript tools. As of 2023, npm has joined forces with GitHub.
### **National Vulnerability Database (NVD)**
An open database, managed by the U.S. government, for management of vulnerabilities. The information displayed is an aggregation of multiple sources along with a severity scoring using CVSS, the type of vulnerability as a CWE, and affected products as a CPE.
### Understanding security vulnerabilities - video series
Have a look at the online course giving you an overview of security vulnerabilities and related topics. In this series, you will learn about:
* Different types of security vulnerabilities
* How to identify and mitigate them
* Common attacks and how to protect your team from it
Whether you are a beginner or an experienced developer or a security professional, this series is designed to help you enhance your knowledge of open-source security and keep your code secure.
[**Check it out**](https://www.youtube.com/playlist?list=PLZQ5U-W8XnxMCnOWqBccsShZJxz8kV53h)**,** improve your skills and stay ahead in the fast-changing world of technology.
# Data sources
Explore this section to discover the trusted sources of data.
Fortify SCA's algorithms constantly scan various sources for information about vulnerabilities, licenses and health data. These include (but are not limited to: the NVD Database, NPM, C# Announcement, FriendsOfPHP's security advisories, Go Vulnerability Database, PyPA Python Advisory Database, GitHub Issues, GitHub Security Advisory, mailing lists, and more. Fortify SCA checks the sources every 15 minutes, giving fast and accurate data.
### **Data refinement**
When the data is collected, it is cleaned up since it is often quite messy. As the sources are a combination of structured and unstructured data, there are a lot of errors in it by default.
### **CVE-parsing**
The largest source of vulnerability data is the NVD database. The problem with this source is that the CPEs (or products connected to vulnerabilities) are often mislabelled, and it is common to see a time lag of up to four weeks in assigning CPEs to CVEs. Fortify SCA uses natural language processing to re-classify the vulnerabilities and increase the amount of correctly classified vulnerabilities and reduce that time lag to 0 days. This is one of many data-refinement activities that is carried out 24/7 for customers.
### LLM‑based vulnerability detection
When a newly published vulnerability lacks detailed analysis from the NVD or other advisory sources, the Fortify SCA LLM‑based parser immediately processes the raw description to extract the technical details required to identify affected packages and versions. This enables Fortify SCA to surface accurate insights early, even before official advisories are complete. Once those advisories are updated, Fortify SCA automatically cross‑verifies the new information with existing data and updates any fields that have changed or been added.
### **Fully automated**
What distinguishes Fortify SCA is its innovative approach to vulnerability analysis, which eliminates the need for manual assessments. The automated analysis guarantees that once a vulnerability is detected within a data source, it is indexed, refined, and a solution is generated efficiently, all within 15 to 30 minutes.
Fortify SCA provides continuous monitoring for changes related to specific vulnerabilities. Our systems operate around the clock to ensure that any detected vulnerabilities are promptly addressed by your development team, minimizing potential lag. Fortify SCA is committed to assisting you in establishing a strong and effective security framework.
### **Scanning the code for dependencies and matching**
In the next step, Fortify SCA scans your projects for dependency files. This can be done in a variety of ways, for example, by CI/CD integrations (recommended), manual uploads, and Fortify SCA APIs.
#### **What does** Fortify SCA **look for?**
Fortify SCA essentially scans for any declared dependencies in files, such as the well-known *package-lock.json*, *composer.json* and so on. Next, this dependency file is transformed into Fortify SCA's own internal format and is sent to the matching and rule engines. Any indirect dependencies are also built or traversed in this process.
#### **Matching and rule engines**
Following are the two pieces of software that:
* Match your vendor and name of the dependency to the Fortify SCA internal database
* Determine the likelihood of this match being correct
It is often the case that open-source projects have similar names, share parts of names, or even have the same names but different vendors. Hence, simple regular expressions, whitelists and blacklists are not enough. Fortify SCA makes use of modern tech, such as machine learning, to determine the likelihood of the match being a true positive or not based on Fortify SCA algorithms. The accuracy of these algorithms varies depending on the language and package manager being used.
### **A solution to your problems**
In most cases, the solution to vulnerabilities in open-source dependencies is to simply update the dependency to a later version that is not vulnerable. Often the update is easy to make, but if the ga between the versions is large enough, an update could cause breaking changes to your code. We help you figure out which version to update to by finding the smallest possible update you can do, which still fixes the vulnerability, helping you fix the problem while keeping the risk of breaking changes as low as possible.
# See your data
Learn how to find detailed information about your projects.
In order to efficiently work with vulnerabilities in your repositories, you need an overview of all repositories you have along with the vulnerabilities affecting them. Fortify SCA provides you with an overview of all your projects and their security status.
### **See all your repositories**
To get an overview of all your repositories, click **Repositories** in the left side menu.
In this view, all your repositories are shown, by default sorted by the amount of vulnerabilities, along with the data:
* Name: The name of the repository prepended with the name of the owner.
* Total vulnerabilities: The total number of vulnerabilities found (including indirect dependencies).
* Vulnerability priority: The total number of vulnerabilities where the [CVSS score](/product/vulnerability-management/security-terms) is *critical* or *high.*
* Review status: The total number of vulnerabilities, where the [review status](/product/vulnerability-management/set-a-review-status) is set to *vulnerable*, *unexamined*, *paused/snoozed*, and *unaffected.*
* Total vulnerabilities with exploits: The total amount of vulnerabilities that have at least one known exploit.
> You can export the filtered and visible repository data in the table to a CSV file. To do so, click **Export Table** located at the top-right corner of the table. *For more information, refer to the* [*Export table data*](/product/administration/repositories/export-table-data) *topic.*
### **See vulnerabilities in a specific repository**
To show all vulnerabilities in a specific repository, click the repository name. This displays a view specific for that repository.
In this view, you get detailed information regarding the vulnerabilities discovered in your repository:
* Name: The vulnerability name, which is usually a CVE identifier. Any vulnerabilities identified through the LLM-based analysis will include an ‘LLM’ tag next to the vulnerability name.
*For more information on LLM-based vulnerability detection, refer 'LLM‑based vulnerability detection' section in the* [*Data sources*](/product/vulnerability-management/data-sources) *topic.*
* Discovered: The date at which the vulnerability was discovered in your code or repository.
* CVSS: The CVSS score for this vulnerability.
* Dependencies: The dependency in which the vulnerability was discovered.
* [Review status:](/product/vulnerability-management/set-a-review-status) Indicates whether the vulnerability is known to be vulnerable, unaffected, or unexamined.
* Reachable Path: Displays if the vulnerable functionality is reachable or not through your code. This field is conditionally displayed based on whether [Reachability Analysis](/product/vulnerability-management/reachability-analysis) was run or not.
* Exploited (CISA): Determines whether the vulnerability is exploited or not, based on the CISA KEV catalog.
To see all commits related to this repository, or all related dependencies, click one of the tabs.
> You can export the filtered and visible vulnerability data in the table to a CSV file. To do so, click **Export Table** located at the top-right corner of the table. *For more information, refer to the* [*Export table data*](/product/administration/repositories/export-table-data) *topic.*
### **See information about a specific vulnerability**
To get detailed information about a specific vulnerability in a repository, click the vulnerability ID. This view contains links to advisories, such as NVD and GitHub along with a summary of the severity.
The summary contains the following information about the vulnerability:
* File(s) in which the vulnerability was found and the dependencies that introduced vulnerabilities.
* Indicates if the vulnerability is detected through LLM.
*For more information on LLM-based vulnerability detection, refer 'LLM‑based vulnerability detection' section in the* [*Data sources*](/product/vulnerability-management/data-sources) *topic.*
* Versions of vulnerable dependencies, and suggested safer alternative versions that can be used wherever possible.
* Breakdown of the CVSS scores
You will also get a list of external references that contain information about remediations, patches, real-world exploits, as well as documentation from issue trackers.
### **See all vulnerabilities and malware across all projects**
To get an overview of all vulnerabilities and malware found in all scanned repositories, click **Vulnerabilities** in the left side menu.
This view is similar to the view for a specific repository, but here all vulnerabilities and malware found in all your repositories are included.
> You can export the filtered and visible vulnerability or malware data in the table to a CSV file. To do so, click **Export Table** located at the top-right corner of the table. *For more information, refer to the* [*Export table data*](/product/administration/repositories/export-table-data) *topic.*
### **See all your dependencies**
To get an overview of all imported dependencies, including indirect dependencies, click **Dependencies** in the left side menu.
In this view, you are presented with a list of all dependencies found in all scanned repositories. It includes details such as:
* Name: The name of the dependency.
* Version status: The version used by the dependency. The valid values are 'Recent', 'Latest' and 'Outdated'.
* Recent: The dependency is not using the latest available version; however, the version in use is still considered current. Updating to the latest version is optional.
* Latest: The dependency is using the latest available version.
* Outdated: The dependency is currently using an outdated version, which may pose a risk. Updating to the latest version is recommended.
> *You can configure the outdated version threshold from Admin Tools → Company Settings.*
* Total vulnerabilities: The total number of vulnerabilities found (including indirect dependencies).
* Malware Detected: Indicates if a malware is detected in the dependency.
* Vulnerability priority: The total number of vulnerabilities where the [CVSS score](/product/vulnerability-management/security-terms) is *critical* or *high.*
* Review status: The total number of vulnerabilities, where the [review status](/product/vulnerability-management/set-a-review-status) is set to *vulnerable*, *unexamined*, *paused/snoozed*, and *unaffected*.
* Licenses: The license under which the dependency is released.
* Health Scores: The [Popularity score](/product/project-health/popularity) and the [Contributor score](/product/project-health/contributors) of this dependency.
> You can export the filtered and visible dependency data in the table to a CSV file. To do so, click **Export Table** located at the top-right corner of the table. *For more information, refer to the* [*Export table data*](/product/administration/repositories/export-table-data) *topic.*
#### Symbols
The column *Name* contains additional symbols providing you with more information:
* **?** - This is used for dependencies for which we were not able to parse the dependency tree (see [Language Suppor](/overview/language-support)[t](/overview/language-support)).
* ▼ - This is used for direct dependencies which include indirect dependencies (see section below).
* *dependency* symbol - This is used for indirect dependencies which are related to the main dependencies.
* no symbol - This is used for direct dependencies that do not include any indirect dependencies.
#### Direct or indirect dependencies
use the ▼ button next to the name of the direct dependency to see its indirect dependencies. The indirect dependencies are marked with an icon in the *Name* column to make it easier for you to differentiate them. To expand all direct dependencies in the current page, click the **Expand all/Collapse all** toggle button at the top.
### Search for dependencies
You can type the name of a package in the Search bar, to search for a specific dependency (direct or indirect), or the name of a license to see all the dependencies related to one license.
# Pull Requests (PR)
Learn about the types of Pull Requests (PR) OpenText Fortify Software Composition Analysis supports and the actions triggered when PRs are generated.
The goal of a Pull Request is to completely remove the CVE from the repository. Note that some dependency versions do not allow a safe version of the currently vulnerable dependency. Therefore, the pull request will only be generated if at least one of the affected direct dependencies has been updated to a safe version.
Fortify SCA currently supports two types of pull requests:
### **CVE-specific Pull Request**
The pull request creation depends on the nature of the dependency relations. If updating the lock file suffices to fix the vulnerable dependency, the pull request will contain the updated lock file. If an update to the direct dependency is required, Fortify SCA will apply the fix to the main dependency file containing the direct dependency versions. Afterwards, Fortify SCA will update the lock file with the new version of the direct dependency and its dependencies.
When you generate a CVE-specific pull request, the following actions are performed to your repository and dependency files:
* Generate the dependency updates in the dependency file to fix the CVE.
* Make required changes to your dependency files as stated above.
* Create a branch in the repository.
* Push the remediated dependency files.
* Create pull request to original branch.
### **Repository-specific Pull Request**
Repository-specific pull requests are a way of remediating vulnerabilities in bulk, with a single click of a button. Instead of focusing on remediating a specific CVE, Fortify SCA widens the scope to all CVEs that affect a specific repository. Currently, Fortify SCA only supports lockfile-only repository-specific pull requests. They are a quick way of making sure that your dependency files are up-to-date. These pull requests generate your lock file(s) from scratch in an attempt to update indirect dependency versions within given constraints. This will fix the majority of the CVEs in many cases. When generating a repository-specific pull request from the repository view, it will be based on the branch selected in the dropdown provided after clicking the **Generate pull request** button.
When you generate a repository-specific pull request, the following actions are performed to your repository and dependency files:
* Apply required changes to your dependency files as stated above.
* Create a branch in the repository.
* Push the remediated dependency files.
* Create pull request to original branch.
### **Lockfile-only fix**
The lockfile-only fix means that you can regenerate the lockfile in your repository and the vulnerability will be solved. You don't need to update the root dependency - rather you should reinstall the same version (for example: run yarn upgrade and get a new lock.file). This is used when the version constraints set by the root dependency allow for the safe version of the indirect dependency, but it has been a while since you did the install. Then, re-installing it will solve the problem.
### **Branch selection**
The type of pull request being generated determines what the new generated branch will be based on. If you’re generating a bulk fix from the repository view, the branch will be based on the branch selected in the drop-down provided after pressing the **Generate pull request** button. If you're instead generating a pull request from the page of a specific CVE, the chosen branch will depend on a few factors:
* If a default branch containing the CVE is detected in your repository, the pull request branch will be based on it.
* If Fortify SCA is unable to detect a default branch, or the CVE exists in a branch other than the default one for that repository, Fortify SCA will first check if the CVE exists in the main or dev branch. If not, the branch which contains the latest commit in the repository is selected.
For more information on how to solve a vulnerability using a PR in the web tool, click the below link:
{% content-ref url="/pages/0mHuADiUb6D22GNZoXgR" %}
[Solve vulnerabilities using Pull Requests (PR)](/product/vulnerability-management/pull-requests/solve-vulnerabilities-using-pull-requests-pr)
{% endcontent-ref %}
# Enable Pull Request support
Learn how to enable Pull Request support.
For Fortify SCA to be able to generate Pull Requests on your behalf, you should do some configuration based on the platform:
* GitHub: To enable pull requests, you are required to [integrate with GitHub](/tools-and-integrations/integrations/github) using the GitHub app.
* GitLab: if you have set up an[ integration to GitLab](/tools-and-integrations/integrations/gitlab), to enable merge requests, you should provide additional credentials (as explained in the article).
* Azure DevOps: if you have set up the [Azure DevOps integration](/tools-and-integrations/integrations/azure-devops), to enable pull requests, you must provide additional credentials (as explained in the article).
# Solve vulnerabilities using Pull Requests (PR)
OpenText Fortify Software Composition Analysis offers several solutions to tackle open-source vulnerabilities. Learn how to do it using Pull Requests (PR).
Assume there is repository with huge number of vulnerabilities. It will take time to go through each one of them and potentially fix them. Fortify SCA offers the ability to open a pull request to solve many vulnerabilities at once.
### **Support for Pull Requests**
Currently, Fortify SCA only supports pull requests for certain package managers and integrations using the GitHub app, GitLab or Azure DevOps. For information regarding the support of your package manager, see the [language support page](/overview/language-support).
### **Solve multiple vulnerabilities using a Pull Request**
Following are the steps for to solve multiple vulnerabilities:
1. In a repository, click **Generate pull request** to let the tool update your dependencies, solve vulnerabilities, and create a pull request.
2. Click **View generated fix** to view the pull request.
3. When the pull request is merged, you will notice a decrease in the number of vulnerabilities.
#### **Set a commit message**
Once you click the **Pull Request** button, a new modal is displayed where it is possible to set your own commit message. If you choose not to provide a message, by default the message will be "Fix CVE-XXX" or "Bulk fix vulnerabilities", depending on the type of Pull Request that is created.
### **Solve a single vulnerability using a Pull Request**
It is possible to solve a specific vulnerability in a repository using pull requests, instead of multiple CVEs at once as in the example above.
Following are the steps to solve a specific vulnerability:
1. In a repository, click the specific vulnerability you wish to remediate.
2. In the CVE view, click the **Open pull request** button. You can see the vulnerable version(s) and the proposed change.
3. Click **Confirm** to execute the changes.
{% hint style="warning" %}
If a pull-request is made, creating a new branch, this branch can be viewed in the web tool. If the pull-request is rejected and the branch is deleted, the branch can still be viewed in the UX. This is the case even after a re-scan of the repo, since the branch is still in the database. This data will be pruned only after 30 days.
{% endhint %}
# Solve vulnerabilities using Pull Requests (PR) via API
Learn how to use Pull Requests (PR) via the API.
Assume there is a repository with huge number of vulnerabilities. It will take time to go through each one of them and potentially fix them. Fortify SCA offers the ability to open a pull request where it tries to solve many vulnerabilities at once.
### Endpoints
/api/{version}/open/repository/{repositoryId}/pull-request/branch/{branchId}/{notify}/{includeUnaffected}
/api/{version}/open/repository/{repositoryId}/get-branches
Fortify SCA can generate a new bulk pull request for the repository, with ID 15707 in this case (shown in the URL). The branch ID is found using the get-branches endpoint.
Example:
First, Fortify SCA gets the branch ID
```
curl -X 'GET' \ 'https://debricked.com/api/1.0/open/repository/15707/get-branches' \ -H 'accept: */*' \ -H 'Authorization: Bearer
```
then, a new pull request is created on branch ID 2, enabling notification, not including unaffected dependencies in the PR.
```
curl -X 'GET' \ 'https://debricked.com/api/1.0/open/repository/15707/pull-request/branch/2/1/0' \ -H 'accept: */*' \ -H 'Authorization: Bearer
```
# Set a review status
Learn how to set a review status for vulnerabilities you’ve been notified about.
For each alerted vulnerability, you can assign a status. You can choose to mark the vulnerability as unaffected, or vulnerable or you can choose to snooze or pause. All the vulnerabilities have a default status of unexamined until you decide to change it.
To set a review status:
1. Go to your **Repositories** from the left side menu.
2. Click a specific repository.
3. In the **Repository** view, click a specific CVE.
4. In the **Actions** section, choose one of the following available status choices:
* **Unaffected:** You can mark the CVE as Unaffected to ignore the vulnerability.
* **Vulnerable:** You can flag a CVE as Vulnerable to ensure it is on your radar.
* **Pause rule triggering:** You can wait to take action and pause automation triggering. You can either Snooze or Pause. When you snooze the CVE, you can define a period of time (1 week, 1 month and so on). When you pause the CVE, you can pause until a new fix is available. Pausing is only supported for the Github app.
* **Unexamined:** This is the default status before choosing another one.
### **Use automation to set a review status**
The automation engine can help you remove manual work, by setting review statuses. You can use automations to flag CVEs as unaffected or vulnerable. For example, you can create a rule that when a dependency contains a vulnerability where CVSS is low (0.0-3.9), then mark the vulnerabilities as *unaffected*.
# Snooze or pause a review status
Learn how to snooze or pause a vulnerability you’ve been notified about.
You can flag a vulnerability as snoozed for a set amount of time. By doing so, the specific vulnerability will not be triggered in any automation rules for the specific repository. After the chosen snooze duration expires, your automation rules will again take the before snoozed vulnerability into account and respective actions will be triggered again.
{% hint style="info" %}
This could result in unnoticed security issues because the vulnerability will not show up in your existing automations. Therefore, use this feature only if you need to and are aware of the consequences.
{% endhint %}
### **Snooze a vulnerability for a set amount of time**
To snooze a vulnerability:
1. Go to the vulnerability page.
2. Click **Pause rule triggering** in the **Action** section.
3. Select **Snooze for a set time period** in the newly opened dialog and select your desired snooze period.
4. Click **Save** to confirm your selection and snooze the automation rules for the vulnerability.
You can see the activated snooze being shown as review status under **Action**. Snoozing the vulnerability is also reflected in the **Activity** section at the bottom of the page.
{% hint style="info" %}
Note: Setting the vulnerability to "snoozed" is only available on a per-repository basis. If you want to snooze the same vulnerability for another repository, you should repeat the same steps for that one.
{% endhint %}
Though any user is able to choose "snoozed" as review status by default, as an admin, you can disable this feature for all users in your company.
### **Manually remove a snooze from a vulnerability**
You can manually stop snoozing a vulnerability at any time before it resumes automatically:
1. Go to the vulnerability you want to resume.
2. Click **Snoozed for (time)** and confirm that you want to stop snoozing the vulnerability in the displayed dialog. Note that this will enable automation rules to be triggered for this vulnerability again.
### **Pause review status**
You can flag a vulnerability as paused in a specific repository. The vulnerability will stay paused until a fix is found, if applied, resolves the vulnerability in your repository. In that case, the paused status will be removed automatically, and the vulnerability resumes to being unexamined.
Keep in mind that the pause could potentially be indefinite when a fix is never found. It is recommended to choose a maximum pause time when setting this review status. If the pause duration expires before the fix is found, your automation rules will resume taking the vulnerability into account. This is similarl to how snoozing a vulnerability works.
### **Pause a vulnerability until a fix is available**
To pause a vulnerability until a fix is available:
1. Go to the desired repository and vulnerability to pause.
2. Select **Pause rule triggering** in the **Action** section.
3. Select **Pause until a fix is available** in the opening dialog and choose an appropriate max pause time.
4. Click **Save** to confirm your selection and pause automation rules for the vulnerability.
You can see the activated pause being shown as review status under **Action**. Pausing the vulnerability is also reflected in the **Activity** section at the bottom of the page.
{% hint style="info" %}
Note that setting the vulnerability to "paused until a fix" is available does so only for the specific repository. If you want to pause the same vulnerability for another repository, you will have to repeat the same steps for that one.
{% endhint %}
### **Manually remove a pause until a fix is available from a vulnerability**
You can manually stop pausing a vulnerability at any time before a fix is found or the max pause time has expired.
To manually remove a pause:
1. Go to the vulnerability you want to resume.
2. Click **Paused until fix** and confirm that you want to stop pausing the vulnerability in the displayed dialog. Be aware that this will enable automation rules to be triggered for this vulnerability again.
# Reachability Analysis
Here's everything you need to know about OpenText Fortify Software Composition Analysis Reachability Analysis.
{% hint style="info" %}
*Fortify SCA currently supports the Reachability Analysis feature for Java and Go.*
{% endhint %}
Fortify SCA's Reachability Analysis helps you automatically determine if a vulnerability in a library affects your project. It analyzes which parts of the library are vulnerable and checks if your code uses those parts. To do this, Fortify SCA needs to understand how your open source dependencies are used. This information is collected by using Fortify SCA's CLI tool to generate a call graph for your project. For instructions on creating the required call graph, see how to [Set up Reachability Analysis for Java](/product/vulnerability-management/reachability-analysis/set-up-reachability-analysis).
### **How does** Fortify SCA **know the vulnerable parts of libraries?**
Fortify SCA identifies vulnerable parts of libraries through the following steps:
1. **Fetch the relevant versions**: Retrieve the latest vulnerable version and the first fixed version from Fortify SCA's database.
2. **Pinpoint the smallest change**: Use information from various sources to narrow down to two specific versions — one that is vulnerable and one that is fixed. These versions can be released versions, Git tags, Git commits, or similar.
3. **Analyze code differences**: Download the code for these two versions, identify the changes between them, and translate these changes into functions, classes, and other code symbols. Store this information in Fortify SCA's database.
4. **Identify vulnerable symbols**: This process reveals which parts of the library are affected by a given vulnerability. These affected parts are known as *vulnerable symbols* for that vulnerability.
### **Am I using vulnerable parts?**
To perform the analysis, Fortify SCA needs to know which parts of a library are vulnerable and whether your code uses those parts. This is determined by generating a call graph for your program and its libraries. The call graph is then uploaded along with your dependency files and scanned for the vulnerable symbols identified in the previous step.
* **If vulnerable symbols are found**: This indicates that your code uses the parts of the library affected by the vulnerability, meaning your project is likely at risk.
* **If vulnerable symbols are not found**: This suggests that your code probably does not use the vulnerable parts and is less likely to be affected.
{% hint style="info" %}
**Important**: Call graphs do not have perfect recall or accuracy. They might include calls that cannot actually occur or miss calls that can. Therefore, even if Fortify SCA reports that you are not using the vulnerable function, you should still upgrade the dependency—though it might not need to be your highest priority.
{% endhint %}
### **Examples**
For projects using Netty versions between 4.1.0 and 4.1.43, Fortify SCA's public vulnerability database identifies the following vulnerabilities:
* CVE-2019-20444
* CVE-2019-20445
* CVE-2020-11612
However, not all of these vulnerabilities may affect your project:
* CVE-2019-20444 and CVE-2019-20445 impact the web server component of Netty.
* CVE-2020-11612 affects decompression functionality.
If your project does not use Netty for decompression, CVE-2020-11612 will not pose a risk. In this case, upgrading to version 4.1.44 instead of 4.1.46 might be sufficient. Similarly, if your project does not use the web server part of Netty, an upgrade might not be necessary at all, saving significant time and resources.\
However, it is still recommended to upgrade to a safe version, even if the priority may be lower when vulnerable symbols are not in use.\
Normally, determining this would require manual investigation, involving a deep understanding of both your project and Netty, as well as reviewing CVE specifications to find which parts of Netty are affected. With Fortify SCA's Reachability Analysis, this process is fully automated.
### **Different statuses of** Fortify SCA **Reachability Analysis**
In the tool, a vulnerability can have one of the following Reachability Analysis statuses:
* **Found**: The vulnerable functionality was detected as reachable through your code.
* **Not Found**: The vulnerable functionality was not detected as reachable through your code.
{% hint style="info" %}
**Note:** As mentioned earlier, call graphs do not have perfect recall or accuracy. It is still recommended to upgrade the dependency eventually, even if this status is shown.
{% endhint %}
* **Missing data**: There is not enough information available to determine if the vulnerable functionality is reachable.
* **Unknown**: The analysis was not run for this commit and vulnerability.
# Set up Reachability Analysis for Java
Learn how to set up Reachability Analysis for Java.
To enable Reachability Analysis for Java, you need to generate a call graph. This can be done using the [Fortify SCA CLI](/tools-and-integrations/cli/debricked-cli) `callgraph` command, which can be added to your integration, so that it is generated appropriately before making a Fortify SCA scan. To find out more about the command and the various available flags, run:
```
debricked callgraph -h
```
Reachability Analysis is supported for all Java projects using Maven. To produce a callgraph, Fortify SCA requires the compiled code for your project and access to the libraries it uses. By default, the command will attempt to do all the preparation work for the command to be successful. The success of the preparation depends on the specific project structure and configurations. In the event of failure, it is possible to configure the command not to run the preparation steps using the `--no-build` flag, and instead set it up separately before running the command.
### Set up call graph generation in your pipeline
When successful, the `callgraph` command will generate a debricked-call-graph file that is automatically picked up when running the `debricked scan` command and sent to Fortify SCA, together with the dependency files, for analysis. For many projects, it will be possible to run the default configuration of the `callgraph` command, doing the preparation steps as part of the command. In this case, all that is needed is to add running `debricked callgraph` in your configuration, before running the scan, ensuring that the scan has access to the generated call graph file. For GitHub Action integrations, there is also Actions setup that can be found in the [GitHub Actions repository](https://github.com/debricked/actions/tree/master).
If the build step of the `callgraph` command fails, or if you are already building the project in a previous stage of the pipeline, it’s highly recommended to build the project separately before running the `callgraph` command with the `—no-build` flag. Just make sure that the files resulting from the build are included in the stage where call graph generation is run.
The examples below use a Fortify SCA CLI Docker image to ensure that there is a compatible Maven version included for the commands to succeed. Fortify SCA recommends that you incorporate the `scan` and `callgraph` commands in your build image or steps whenever possible, to ensure that versions of the underlying tools correlate with your environment.
#### Example: Building the project during the callgraph command
In this example, the `callgraph` command is run with its default configuration, which builds the project and prepares the necessary files automatically before generating the call graph.
```bash
# GitLab CI/CD template
image: debricked/cli:2-resolution-debian
stages:
- scan
debricked:
stage: scan
script:
- debricked callgraph
- debricked scan
```
#### Example: Using a separate build step
The example below is using maven to build the project and generate the files needed for call graph generation. The generated files must be reachable in the stage where the `callgraph` command is run, so that it has all pre-requisites to be run successfully.
```bash
# GitLab CI/CD template
image: debricked/cli:2-resolution-debian
stages:
- build_project
- scan
scan_preparation:
stage: build_project
script:
# Build project based on the root pom.xml. If no root pom.xml is found, all pom.xml files will be built individually.
- mvn package -q -DskipTests -e
# Save class files from the target/ folder for use in the next stage.
artifacts:
expire_in: 1 day
paths:
- target/
debricked-scan:
stage: scan
script:
- debricked callgraph --no-build
- debricked scan
```
### Common issues
Multiple issues can occur when trying to generate the callgraph which prohibits success. Some common issues are:
* Unsupported Java version. If your project requires a Java version older than 11, Debricked may not be able to produce a callgraph. Debricked may also not be able to generate a callgraph if your project uses new lanugage features from a version above 21.
* Unsupported language features. Some advanced language features can make callgraph generation impossible for the tool that is used to generate the callgraphs.
# Set up Reachability Analysis for Go
Learn how to set up Reachability Analysis for Go.
Reachability Analysis is supported for all Go projects. You need the compiled code and the libraries used by your Go project to enable Reachability Analysis.
You need to generate a call graph to enable Reachability Analysis for Go. To generate a call graph, add the [Fortify SCA CLI](/tools-and-integrations/cli/debricked-cli) `callgraph` command to your integration before running a Fortify SCA scan. To find out more about the command and the various available flags, run:
```
debricked callgraph -h
```
{% hint style="info" %}
*The success of CLI call graph generation depends on the complexity of the application being analyzed. If an application contains a language feature that is not supported by the algorithm, the* `callgraph` *command fails and you cannot set up Reachability Analysis for that application.*
{% endhint %}
When successful, the `callgraph` command generates a `debricked-call-graph` file. This file is automatically sent to Fortify SCA with the dependency files for analysis, when running the debricked scan command.
### Set up call graph generation in your pipeline
For many projects, running the `callgraph` command with the default configuration might be enough to run the preparation steps. In this case, before running the `debricked scan`, to add the command to run `debricked callgraph` in your configuration to ensure that the scan has access to the generated call graph file.
For GitHub Action integrations, Fortify SCA also provides an Actions setup in the [GitHub Actions repository](https://github.com/debricked/actions/tree/master).
#### Example: Building the project during the callgraph command
In this example, the `callgraph` command is run with default configuration to build the project and prepare the necessary files automatically before generating the call graph.
```bash
# GitLab CI/CD template
image: debricked/cli:2-resolution-debian
stages:
- scan
debricked:
stage: scan
script:
- debricked callgraph
- debricked scan
```
# Solve vulnerabilities manually with root fixes
Root Fixes enable you to manually solve vulnerabilities.
{% hint style="info" %}
*Currently, this feature is available for JavaScript, Java, Go, and NuGet.*
{% endhint %}
**Root fixes** contain the first next version of the direct dependency in the dependency tree that does not contain a vulnerable version of the affected dependency. In simpler terms, a Root fix is a solution to a dependency vulnerability that starts at the root of the dependency tree.
By addressing the root cause of the vulnerability, Root fixes ensure that the entire dependency tree is updated, using the version constraints set up by its dependencies. This way of updating dependencies is generally preferred over updating the vulnerable dependency directly, as it has a much lower risk of errors and breaking changes. It also eliminates the need for manually researching the required direct dependency update, saving developers valuable time.
### **Solve a vulnerability using root fix**
1. Click **Repositories** in the left side menu and select your project. Here you can see a list with all the CVEs found.
2. Click one CVE to open the vulnerability page.
3. Go to the **Introduced through** section and select the dependency file to analyze. In some cases, the scan can find more than one dependency file within your project. You can see in green which is the closest secure version of the root package to update.
If Fortify SCA is not able to find a secure version to solve the vulnerability, the **Introduced through** section shows an *unknown.*
4. Before updating the package, keep in mind some packages might introduce breaking changes. To see if there is any risk, check the **Breaking Changes** section of the package's readme file.
5. Update the package through the package manager (in this example, using npm: *npm update hbs >= 4.1.1 )*
6. Commit and push the updates.
Once the scanning is completed, the repository should no longer have this vulnerability.
### Solve a vulnerability using root fix - video guide
{% embed url="" %}
# License risk management
Master the art of managing open source licenses with OpenText Fortify Software Composition Analysis.
When working with open source, it is crucial to ensure and maintain open-source compliance, also from a commercial perspective. To help with that, Fortify SCA provides you with a comprehensive overview of all licenses in the repositories you have integrated with us. You can find that information in different areas of the tool.
### **View all licenses**
To view licenses, click **License** tab on the left side menu. Here, you can view the list of all your licenses in alphabetical order. The screen displays the following information:
* Name: The name of license.
* License Risk - The grade of potential compliance risks involved with the specific license, assessed based on the use case chosen for the repository.
* Dependencies - The number of dependencies affected by the license.
* License family - The family to which the license belongs.
### **View all repositories affected by license**
To view all repositories affected by license, follow these steps:
1. Click **License** tab on the left side menu. Here, you can view the with a list of all your licenses in alphabetical order.
2. Click a specific license to view all repositories with that specific license. Here, you can also view the risk associated with the license within all affected repositories, as well as how many dependencies per repository are affected.
3. After you click a specific repository, the above-mentioned information can also be found in the **Licences** tab.
> You can export the filtered and visible data in the table to a CSV file. To do so, click **Export Table** located at the top-right corner of the table. *For more information, refer to the* [*Export table data*](/product/administration/repositories/export-table-data) *topic.*
### License review or override
{% hint style="info" %}
*This feature is only available for Enterprise users.*
{% endhint %}
As a Repository or Company Admin (Enterprise), you can review and manually override the license found by Fortify SCA on a dependency level.
To do so:
1. From a repository page, go to the **License** tab. Here you can view the list of all licenses detected in the repository.
2. Click **Review**. Here, you can find a list of all licenses detected and can override the data.
Depending on your needs, you can:
* Delete the license by clicking the **trashcan** icon.
* Change the detected license, by clicking **Change license** and selecting a new one from the dropdown menu
* Add license(s) by clicking the **+** button for multi-licensing.
# Licence families
Understand how OpenText Fortify Software Composition Analysis defines different open-source license families.
At Fortify SCA, we group licenses into different license families, applicable to different use cases. They are shown in one of the columns in the License view and can be used in your customized automation rules. Here’s how we categorize them:
### Proprietary
A non-free license, or proprietary license, allows the owner to restrict the use, modification, and redistribution of the software.
### **Permissive**
A permissive software license, also known as BSD-style license, is a "free software" license that, compared to copyleft, only has minimal restrictions on how to use, modify and redistribute the software. The best-known permissive licenses are BSD Licenses, Apache Licenses, such as Apache License 2.0 (Apache-2.0), and MIT License.
### **Strong copyleft**
In the family of strong copyleft licenses, regulations can be imposed on all derived works, meaning that the original creator of the works has the most rights. One of the best-known strong copyleft licenses is the GNU General Public Licenses, such as GNU General Public License v3.0 only (GPL-3.0-only). Strong copyleft licenses are also applicable to art, music, sports, photography, and video.
### **Weak copyleft**
Weak copyleft licenses refer to licenses where not all derived work inherits the copyleft license. Instead, it depends on how the work was derived. Weak copyleft licenses are mostly used for software libraries by allowing links to other libraries. Known examples of these are the Mozilla Public License 2.0 (MPL-2.0), and GNU Lesser General Public License v3.0 only (LGPL-3.0-only). The best-known products with weak copyright are Mozilla and OpenOffice.org.
### **Public domain**
Software placed in the public domain does not have a copyright, trademark, or patent. The software may be freely distributed, modified, or sold.
# License risks
See the different levels of open-source license risks.
To grade the potential compliance risks involved with different licenses, we assess them using a grading system. Keep in mind that the color grading represents the estimated amount and complexity of the compliance concerns. This does not mean that some licenses are riskier than others - if you understand all the compliance requirements of a license and are able to fulfill them, then the license is practically risk-free regardless of our grading.
The risk levels are created under the assumption that the installed dependency is not affected by external factors, including, but not limited to, interactions with other dependencies and effects of compilation. We advise you to adjust the risk levels based on your own internal policies, risk tolerance and use case.
RED
High compliance risk, not allowed
This grading is used for a license that is not allowed use, e.g. in company or project context, or for a use-case reason (such as with GPLv3 in consumer electronics) because it will likely cause a breach of the license terms, exposing you to possible legal challenges.
RED
Unknown license
This grading applies to licenses where using the code without understanding its conditions may lead to legal risks.
ORANGE
Restricted license with substantial compliance risks. Such licenses should only be allowed after getting some legal guidance and on a case-by-case basis, as the compliance considerations are generally difficult to fully comply with.
YELLOW
Approved license, with sizable compliance considerations. In such licenses the source code must be made publicly available and there are restrictions in combining with other code under a different license, as with the licenses in the Copyleft license family.
GREEN
Approved license, with few compliance considerations. In such licenses the copyright and permission notice must be maintained in distributions of code, as with most licenses of the Permissive license family.
BLUE
Non-OSS / Commercial / Proprietary license
To read more about license families, license risks, use cases, and compliance, click [blogs](/opentext-fortify-sca-blogs/blogs).
# Set up a use case
Learn how to set up a use case for your repositories.
The first time you visit the License view; you will notice that the value in the risk column is set to *Unknown* for all licenses. This is because you have not yet configured any use cases for your repositories.
To do that:
1. Go to **Repository Settings** in the left side menu.
2. Under the column *Use case,* click on **Unknown** in the row of the specific repository.
3. In the new window, select a use case and click **Save.** The license view will be updated accordingly.
# Set up a use case using API
Learn how to set up a use case for your repositories using the API.
The first time you visit the License view; you willl notice that the value in the risk column is set to *Unknown* for all licenses. This is because you have not yet configured any use cases for your repositories. You can select a use case through the API using the endpoint:
```
/api/{version}/open/repository-settings/repositories/{repositoryId}/select-use-case
```
To do so, send a JSON containing a choice of the use case, for example:
```
"useCase": 2
```
Here, the *useCase* can be one of the following integers:
* 0/null - Unknown
* 1 - Non-distributed internal
* 2 - Non-distributed public
* 3 - Distributed generic
* 4 - Distributed electronics
Here’s an example showing you how to set the use case to “Non-distributed public” for a repository with ID = 1337:
```
curl -X 'POST' \ 'https://debricked.com/api/1.0/open/repository-settings/repositories/1337/select-use-case' \ -H 'accept: */*' \ -H 'Authorization: Bearer \ -H 'Content-Type: application/json' \ -d '{ "useCase": 2 }'
```
# Proxy non-standard license identifiers
Learn how OpenText Fortify Software Composition Analysis deals with non-standard and deprecated licenses.
To ensure license compliance, we proxy non-standard license identifiers and references to SPDX identifiers and map deprecated license identifiers as accurately as possible. Below is a list of common deprecated licenses and how we proxy them:
| Full Name | Deprecated License | Proxy to |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------- |
| GNU General Public License v1.0 only | GPL-1.0 | GPL-1.0-only |
| GNU General Public License v1.0 or later | GPL-1.0+ | GPL-1.0-or-later |
| GNU General Public License v2.0 only | GPL-2.0 | GPL-2.0-only |
| GNU General Public License v2.0 or later |
GPL-2.0+ GPL 2.0+ GPL 2.0 GPL 2.0 or later GPL2 GPL2+ GPL2.0 GPL v2.0 License GPL v2.0 license. GPL version 2+ GPL+2 GPL2 License GPL2 or later GPL2.0 GPL2.0 License GPL2.0+ GPLv2 gplv2 GPL GNU v2 GPL General Public Licence v2 and later GPL (optional either v2 or any later version) GPL Lv2
| GPL-2.0-or-later |
| GNU General Public License v3.0 only |
GPL-3.0 GPL-3-0-only GPL-3.0-only” GPL-3.0 (only)
| GPL-3.0-only |
| GNU General Public License v3.0 or later |
| LGPL-2.0-or-later |
| GNU Lesser General Public License v2.1 only | LGPL-2.1 | LGPL-2.1-only |
| GNU Lesser General Public License v2.1 or later |
LGPL-2.1+ LGPL 2.1 or later LGPL, version 2.1 LGPL v 2.1 LGPL v. 2.1 LGPL v 2.1+ LGPL ver 2.1 LGPL version 2.1 LGPL version 2.1 or later LGPL version 2.1, or (at your option) any later version
| LGPL-2.1-or-later |
| GNU Lesser General Public License v3.0 only | LGPL-3.0 | LGPL-3.0-only |
| GNU Lesser General Public License v3.0 or later |
LGPL-3.0+ LGPL v3+ LGPL 3.0 or later LGPL Licence Version 3 LGPL-v3+ LGPLv3a
| LGPL-3.0-or-later |
If you have any further questions or need additional assistance, please refer to the [SPDX documentation](https://spdx.dev/) or [contact us](/overview/help).
# Malicious package detection
Detect and avoid malware
Fortify SCA identifies malicious packages in your dependencies and separates them from standard security vulnerabilities. This helps you triage intentional compromise faster and prioritize response actions across repositories.
Fortify SCA uses malware intelligence sources, including OSV, to detect known malicious packages. Finding details can include advisory references and dependency context.
#### **See repositories with malware findings**
To get an overview of repositories with malware findings, click **Repositories** in the left side menu.
In this view, Fortify SCA displays:
* Name: Repository name.
* Malware detected banner: Indicates when malware findings exist in the selected repository context.
* Malware finding count: Total malware findings detected in the repository.
* Malware Detected column: Malware indicator for repository or dependency rows.
* Review status: Current review state for findings in the repository.
> You can export the filtered and visible repository data in the table to a CSV file. To do so, click **Export Table** located at the top-right corner of the table. *For more information, refer to the* *Export table data* *topic.*
#### **See malware findings in a specific repository**
To show all malware findings in a specific repository:
1. Go to **Repositories** from the left side menu.
2. Click a specific repository.
3. In the repository view, click the **Malware** tab.
In this view, you get detailed information regarding malware findings discovered in your repository:
* Name: Malware identifier, typically a MAL ID.
* Discovered: Date when Fortify SCA detects the finding in the repository.
* Dependencies: Dependency in which Fortify SCA detects the malicious package.
* Review status: Indicates whether the finding is marked as vulnerable, unaffected, paused/snoozed, or unexamined.
*For more information on review states, refer to the* [*Set a review status*](/product/vulnerability-management/set-a-review-status) *topic.*
#### **See information about a specific malware finding**
To get detailed information about a specific malware finding in a repository, click the malware ID.
This view contains links to advisories and malware intelligence references, along with a summary of impact.
The summary contains the following information:
* Affected dependency and version details.
* Discovery metadata for the finding.
* External references related to malware analysis and remediation.
* Classification metadata, including CWE where available (for example, CWE-506).
#### **See all malware findings across all projects**
To get an overview of all malware findings across scanned repositories:
1. Click **Vulnerabilities** in the left side menu.
2. Click the **Malware** tab.
This view is similar to the malware view for a specific repository, but it includes all malware findings across all projects.
> You can export the filtered and visible vulnerability data in the table to a CSV file. To do so, click **Export Table** located at the top-right corner of the table. *For more information, refer to the* [*Export table data*](/product/administration/repositories/export-table-data) *topic.*
#### **See dependencies affected by malware**
To view impacted dependencies in repository context:
1. Go to **Repositories**.
2. Click a specific repository.
3. Click the **Dependencies** tab.
4. Review the **Malware Detected** column.
Use this view to connect malware findings directly to affected packages and prioritize remediation work.
#### **See malware entries in Vulnerability Database**
To review malware intelligence entries:
1. Open **Vulnerability Database**.
2. Click the **Malware** tab.
3. Search by malware ID or dependency.
4. Sort by **Published** to review the newest entries first.
This view helps you validate malware context and supports investigation.
#### **Use automation to respond to malware findings**
The automation engine helps you reduce manual response work by reacting immediately to malware findings.
You can configure automation rules to:
* Trigger notifications when Fortify SCA detects malware.
* Trigger webhooks for incident workflows.
* Fail pipeline checks when malware is present in a repository.
*For more information, refer to the* [*Automation*](/product/automation) *and* [*Policies*](/product/automation/policies) *topics.*
#### **Data sources for malicious package detection**
Fortify SCA continuously collects and refines malware intelligence data to identify malicious packages and map findings to dependencies.
*For more information on source processing and enrichment, refer to the* [*Data sources*](/product/vulnerability-management/data-sources) *topic.*
# Project health
Learn more about Project Health - what it is and what the different metrics mean.
Project health is an important aspect to consider when selecting dependencies. But what does Project Health even entail? Fortify SCA's Open-Source Health Metrics can help you gain an understanding of key aspects of any open-source project and make informed decisions when choosing what to bring into your codebase.
### **What is a health metric?**
A Metric is a measurement of a key aspect of an open-source project’s overall quality. For example, its contributors or its popularity. Our underlying data model aggregates data points into sub-metrics, which are then aggregated into a metric. We call these:
* Features - The lowest level datapoints
* Practices - The aggregated sub-metrics
* Metrics - The final aggregation of practices
You can think of a metric as the area that you want to investigate (for example, is the project popular? is there a healthy contributor community?), and practices as more specific questions you want answered (for example, how experienced are the contributors?), how long do contributors stay with the project?).
Between each layer, there are weights that determine the impact of any given feature on a practice, and of any given practice on a metric. You can find the data model of each metric illustrated in [Contributors](/product/project-health/contributors), [Popularity](/product/project-health/popularity), and [Security](/product/project-health/security).
# Contributors
See how we define the Contributors metric in Project Health.
Open-Source projects are affected by contributors. Theyhave the power to make a project thrive or die. When deciding what open source project to bring into your software, it is important to inspect and analyze its contributors.
Between each layer, there are weights that determine the impact of any given feature on a practice, and of any given practice on the [metric](/product/project-health#what-is-a-health-metric). You can find the data model illustrated below:
### Contributor experience
This practice describes the contributor's experience in a specific repository. Experienced contributors tend to write more efficient, more secure, and usable code, and are therefore preferred.
The following features of Contributor Experience are measured:
* Contributor Influence - How much attention the contributors attract to the repository.
* External Pull Requests Merged per Developer - The average number of pull requests merged in other projects.
### Contributor efficiency
This practice describes the contributor efficiency in a specific repository. It is measured by looking at the rate at which the contributors code, merge pull requests, and close issues.
The following features of Contributor Efficiency are measured:
* Closed Issues per Developer - The average number of issues closed per developer in the past 52 weeks.
* Pull Requests Merged per Developer -The average number of pull requests merged per developer in the past 52 weeks.
* Developer Velocity - The average coding speed of the developers. It is calculated as lines of code merged/closed per week, averaged over the past 10 weeks.
### Contributor diversity
This practice describes the diversity in the contributing community for a specific repository. It is measured by looking at the rate of new contributors, the rate of contribution per contributor, the total number of contributors, and the contributor trend.
The following features of Contributor Diversity are measured:
* Total Contributors - The total number of contributors.
* Contributor Trend - The change in contributors, averaged over 10 weeks.
* New Contributors - How many new contributors (with their first merged pull request within the past year) a repository has.
* Developers per Commit - How many developers there are per commit.
* Contribution Skew - The contribution skewness in terms of how many pull requests were contributed by one-time contributors, or a few very active contributors. The raw score is non-linear and varies between 0.5 and 1.0, where values > 0.8 mean contributions are distributed on many contributors, and scores < 0.6 mean that very few contributors developed most of the project.
### Contributor activity
This practice describes how active the contributors of a repository are. It is measured with features that analyze the current volume of commits, closed issues, pull requests, and the trend of said volume.
The following features of Contributor Activity are measured:
* Recent Commits - How many new commits have been made to the master branch within the last 10 weeks.
* Commits Trend - The linear change in commits per week for the past 21 weeks (whether it is increasing or decreasing).
* Recent Pull Requests - How many new pull requests have been made within the last 10 weeks.
* Pull Requests Trend - The linear change in pull requests per week for the past 21 weeks (whether it is increasing or decreasing).
* Recently Closed Issues -How many issues have been closed within the past 10 weeks.
* Closed Issues Trend - The linear change in closed issues per week for the past 21 weeks (whether it is increasing or decreasing).
### Core team commitment
This practice describes how committed the core team is to the project. The following features of Core Team Commitment are measured:
* Recent Core Team Commits - How many new commits the core team has contributed to the master branch within the past 10 weeks.
* Core Team Commits Trend - The linear trend of the number of commits the core team has made to the master branch in the last 21 weeks.
* Core Team Issue Closing - How many issues the core team has closed in the past 10 weeks.
* Recent Merges - How many pull requests have been merged in the past 10 weeks.
* Merges Trend - The linear change in merged pull requests per week for the past 21 weeks, that is, whether it is increasing or decreasing.
* Company Involvement - The highest ratio of commits from the same company in the past period of 21 weeks.
### Contributor longevity
This practice describes the longevity of the contributors. If the developers are contributing long-term, then it might be a sign that the project has been proven valuable.
The following features of Contributor Longevity are measured:
* Developer Lifetime - The average time a developer contributes regularly to the repository.
* Loyal Developer Commits - The number of commits made by long-term (loyal) developers.
# Popularity
See how we define the Popularity metric in Project Health.
The popularity of a repository is another crucial indicator of the health of a project. It signifies interest from both developers and users alike, pointing towards viability and continued development. \
Between each layer, there are weights that determine the impact of any given feature on a practice, and of any given practice on the [metric](/product/project-health#what-is-a-health-metric). You can find the data model illustrated below:
### Usage
This practice describes the usage of a repository among open-source users. The following features of Usage are measured:
* Total Downloads - The total number of times a repository has been downloaded through its respective package manager.
* Total Forks - The total number of times a repository has been forked.
### Developer popularity
This practice describes how popular the repository is among the developers. More popular repositories attract more and more skilled developers to contribute.
The following features of Developer Popularity are measured:
* Total Stargazers - The total number the repository has been “starred” in GitHub.
* Total Watchers - The total number of users watching this repository in GitHub. Watchers are notified about activity on the chosen repository.
* Contributor Influence - How much attention the contributors attract to the repository.
* Contributor Trend - The change in contributors, averaged over 10 weeks.
### Community activity
This practice describes how active the community of a repository is. In this case, “community” entails both contributors and users. The activity is measured with features that analyze the current volume of commits, issues, and pull requests, as well as the trend of said volume.
The following features of Community Activity are measured:
* Recent Commits - How many new commits have been made to the master branch within the last 10 weeks.
* Commits Trend - The linear change in commits per week for the past 21 weeks (whether it is increasing or decreasing).
* Recent Issues - How many new issues have been posted within the last 10 weeks.
* Issues Trend - The linear change in posted issues per week for the past 21 weeks (whether it is increasing or decreasing).
* Recent Pull Requests - How many new pull requests have been made within the last 10 weeks.
* Pull Requests Trend - The linear change in pull requests per week for the past 21 weeks (whether it is increasing or decreasing).
* Recently Closed Issues - How many issues have been closed within the past 10 weeks.
* Closed Issues Trend - The linear change in closed issues per week for the past 21 weeks (whether it is increasing or decreasing).
### Ecosystem buzz
This practice describes the buzz of a particular open-source project in different parts of the ecosystem. A higher buzz implies better support from platforms such as StackOverflow.
The following feature of Ecosystem Buzz is measured:
* Total Discussions on Stackoverflow - The total number of search hits a repository/package has on Stackoverflow.
# Security
See how we define the Security metric in Project Health.
The security of a repository is crucial in many aspects of open source, as the security of a project determines the security of your product. This metric measures both indicators of vulnerability entry risk, and past vulnerability response performance.\
Between each layer, there are weights that determine the impact of any given feature on a practice, and of any given practice on the [metric](/product/project-health#what-is-a-health-metric). You can find the data model illustrated below:
### Vulnerability response
This practice describes how fast vulnerabilities are being handled in a repository. A high score means that maintainers and contributors solve vulnerability risks in a timely manner.
The following features of Vulnerability Response are measured:
* Vulnerability Disclosure to Patch - The median number of days it takes for a vulnerability disclosed by a CNA to be patched from its disclosure. This can be inverted if the patch was released before the disclosure date.
* Vulnerability Entry to Disclosure - The number of days it takes for a vulnerability disclosed by a CNA to be discovered from when the vulnerable code was committed.
* Security Activity over Time - The security activity in a project per month for the past year (whether it is a stable activity or comes in bursts).
* Dead Issue Rate - The rate of stale or dead issues, defined as having been open for 52 weeks without being closed.
* Maintainer Responsiveness - Indicates whether maintainers (contributors with merge rights) are responding to issues in the project. If they’re not responding to any recent issues, it may indicate that the project is going “stale”.
### Vulnerability risk
This practice looks into the nature of reported vulnerabilities in the project. The following features of Vulnerability Risk are measured:
* Commits per Vulnerability - How frequently vulnerabilities are reported in relation to the project's size in commits. A higher number means vulnerabilities are less frequent.
* Vulnerability Severity - How serious the reported vulnerabilities are.
* CWE Diversity - The types of vulnerabilities being reported. Multiple vulnerabilities of the same type may indicate that the project's contributors are not learning from previous mistakes.
### Coding best practices
This practice describes how well the project contributors adhere to best practices that boost code quality, which correlates with the risk of exposure to vulnerabilities.
The following features of Coding Best Practices are measured:
* Review Comments per Pull-request - The average number of review comments a pull request has, indicating how much feedback is provided by the reviewers.
* Reviewers per Pull-request - The average number of reviewers per pull request before merge.
* Pull-request Size - The average pull request size, measured in lines of code changed in the pull requests submitted during the past 52 weeks.
* Seniority of Reviewers - How experienced the reviewers of pull requests are. Seniority is calculated as the average number of pull requests that a reviewer has on GitHub.
### Bug reporting
This practice describes the rate of bug reports in the project. The following features of Bug Reporting are measured:
* Issue Bug Saturation - The percentage of issues that are bug reports.
* Commits per Bug - The frequency of bug issues per commit made.
# Open source select
Learn how to use the Fortify SCA Open Source Select to choose the right open source project from the get-go and make the most of our metrics.
# Search projects
Learn how to search for an open source project using OpenText Fortify Software Composition Analysis Open Source Select.
Finding the right open source project to solve your specific problem can be difficult, especially when you want to make informed decisions before choosing what to bring into your codebase. [Open Source Select](https://debricked.com/select/) is Fortify SCA’s database of all open source projects available on GitHub. It enables you to search, compare and evaluate packages based on different health metrics and quality scores.
### **How do i search?**
With Open Source Select, you can search for packages, projects or functionalities and get all relevant information presented in one place. You can further refine your search using filters.
When searching, use a few good keywords describing what you're looking for. For example, try searching for “frontend graphs” if you're looking for a project to help you create nice-looking visualizations, or search for “message broker” if you're looking for data streaming projects.
### **Search on project names**
Enter the name of the project you wish to know more about and hit enter. A list of projects matching the search string fully or partially will be shown.
### **Search on project functionality**
As a developer you often know the problem you want to solve, but not necessarily all projects that exist to address that problem. Searching for the functionality that you're after helps you discover these projects.
### **Search for repositories**
Open Source Select isn't limited to packages, it is also possible to search for repositories using the *repository\_owner/repository\_name* format. Keep in mind that the results from this query can be both dependencies that are repository-only, and dependencies that have a package and hold their code in the searched repository.
### **Search using pURL standard**
It is also possible to search for dependencies using the common pURL format:
```
pkg:type/namespace/name
```
The *type* section of the pURL corresponds to the package manager used by the dependency or the version control system used (in case of repository-only dependencies).
The *namespace* is used mainly for repository-only dependencies, corresponding to the repository owner.
The *name* section corresponds to the package or repository’s name.
The pURL standard is also supported directly in the url: **
Here are some examples of pURL searches and their corresponding results:
*pkg:pypi/tensorflow* → Tensorflow
*pkg:npm/react* → React
*pkg:github/debricked/debricked-cli* → Debricked-cli
### **Refine your search using filters**
The most powerful way to search the Select database is by combining project name or project functionality searches with filters narrowing down the results to your preferences.
You can filter by:
* programming language
* package manager
* excluded licenses
### Choose open source components with Fortify SCA's Open Source Select and Start Left - video guide
{% embed url="" %}
# Compare projects
Learn how to compare open source projects using OpenText Fortify Software Composition Analysis Open Source Select.
[Open Source Select](https://debricked.com/select/) enables you to compare projects side by side and gain insight into their individual strengths and weaknesses. You can compare aspects such as security, contributor commitment, and popularity.
To compare (up to three) projects:
1. Select the projects that you want to compare by clicking the **Add to comparison** (the scale icon) button on each project's card.
2. Click **Compare selected dependencies** below the search bar.
You can also:
* Click **Quick Compare** to see a comparison between the top three search results in the search page.
* Click **Compare** next to Similar dependencies in the project page to compare those projects.
### Choose open-source components with Fortify SCA's Open Source Select and Start Left - video guide
{% embed url="" %}
# View more details
Learn how to see more details about a project in OpenText Fortify Software Composition Analysis Open Source Select.
[Open Source Select](https://debricked.com/select/) enables you to view more details of the dependency to better determine their quality and state. After clicking on a specific project, you are able to learn more from the description, Readme (fetched from the project’s GitHub repository) and external links, and dive deep into the Health metrics to truly understand the strengths and weaknesses of the dependency.
### **Similar dependencies**
To help you find new projects, we list two dependencies with similar functionality and their respective popularity and contributor scores. You can use the [**Compare**](/product/open-source-select/compare-projects) functionality to compare them to the dependency you are currently viewing.
### **Health metrics**
You can find a quick overview of the [Health Metrics](/product/project-health) on top of the page, and a comprehensive view in the metric cards below. Each metric card visualizes their practices using multiple charts. You can hover on each practice's position in the chart to see the score of that practice, and if you click on one, all of its features are shown.
### Choose open source components with Fortify SCA's Open Source Select and Start Left - video guide
{% embed url="" %}
# Start left policies
Why start over when you can Start Left?
{% hint style="info" %}
*The Start Left feature is only available for* [*Select Enterprise*](https://debricked.com/pricing/) *users. Already have an account?* [*Click here to upgrade.*](https://debricked.com/app/en/repositories?billingModal=free,enterprise)
{% endhint %}
You can use your automation policies to evaluate new packages in Open Source Select. If you are looking for a new package in Select, you can check whether or not it will trigger an automation rule using Start Left Policies.
### **Evaluate license issues using start left policies (example)**
1. Create an automation rule to evaluate the licenses family. For example, “If there is a dependency which is licensed under a strong copyleft license then fail pipeline”.
2. Go to **Open Source Select** and search for a desired package.
3. After searching for the \`node-forge\` package, you can see that the pipeline would fail if this package is included, as it is licensed under \`GLP-2.0-only\` which belongs to the "strong copyleft" licenses family.
### **Evaluate security risk packages using start left policies (example)**
1. Create an automation rule to evaluate the check the CVSS. For example, "If a dependency contains a vulnerability which has not been marked as unaffected where CVSS is at least medium (4.0-6.9)”
2. Go to **Open Source Select** and search for a desired package.
3. After searching for the \`angularjs\` package, you can see that our pipeline would trigger a warning if we included this package, due to CVE-2017-16009.
### Choose open source components with Fortify SCA's Open Source Select and Start Left - video guide
{% embed url="" %}
# Fortify SCA Select Browser Extension
Learn how to install and use the OpenText Fortify Software Composition Analysis Select Browser Extension.
{% hint style="info" %}
The browser extension is currently only available for Chrome via the Chrome Web Store. [Access it here](https://chromewebstore.google.com/detail/debricked-select-extensio/jjkjijpfchpjbhikfpliohoaokglbhmk?pli=1).
**Supported source code repositories and package registries:** [GitHub](https://github.com/), [pypi](https://pypi.org/), [nuget](https://www.nuget.org/), [npm](https://www.npmjs.com/), [maven](https://maven.com/), [golang](https://go.dev/), [RubyGems](https://rubygems.org/), [Composer](https://getcomposer.org/), [CocoaPods](https://cocoapods.org/), [Cargo](https://cargo.site/), and [Conan](https://conan.io/).
{% endhint %}
The Select Browser Extension allows you to view Fortify SCA's Health data directly on a repository or a package manager's GitHub page. The extension integrates seamlessly with your browsing experience, providing you with comprehensive insights into the project without navigating away from the site.
### Install Select Plugin to Your Browser
1. Go to [this page](https://chromewebstore.google.com/detail/opentext-core-sca-select/jjkjijpfchpjbhikfpliohoaokglbhmk?pli=1) or search for “Fortify SCA Select” in the [Chrome Web Store](https://chromewebstore.google.com/).
2. Click **Add to Chrome.**
3. Review the permissions and click **Add extension.**
4. On your browser, click **Extensions** and then the **Pin emoj**i to pin it to your browser UI.
5. You are ready to go. Navigate to a repository or a package manager's GitHub page to see Fortify SCA's Select Health data of the project in the popup.
6. If you want to see more details about the project, click **Check all metrics**. This will take you to a page in OSS providing you with a comprehensive overview of the project.
# End of Life (EOL)
Learn about the End of Life (EOL) information in Open Source Select.
[Open Source Select](https://debricked.com/select/) provides you with information about projects that have been declared as no longer being maintained or about to reach end of life. Currently, we only provide this information for NPM packages.
The different states of a project are:
* Repository archived - Indicates that the repository is already archived.
* Package deprecated - Indicates that the package is officially deprecated.
* Vendor announced - Indicates that the vendor has announced an end-of-life date after which the package or project will no longer be maintained.
{% hint style="info" %}
*The EOL announced date is based on the version of the package or project.*
{% endhint %}
# Automation
Navigate one of OpenText Fortify Software Composition Analysis’s most powerful features - the Automation engine.
In order to efficiently prevent vulnerabilities and unwanted licenses from entering your codebase, it is recommended to set up automation rules. The rules can be enforced in your pipelines, failing them or showing warnings, or set to notify relevant people, minimizing the number of vulnerabilities brought into your codebase.
You can see an overview of all automations in your organization by clicking the **Automations** on the left side menu. Here, you can [create new automation rules](/product/automation/create-an-automation-rule), as well as [edit or disable/delete](/product/automation/edit-an-automation-rule) the existing rules.
You can access automations for a specific repository by selecting a specific repository in the drop-down list.
# Create an automation rule
Learn how to create an automation rule for your repositories.
1. Go to **Automations** on the left side menu (You can also access automations for a specific repository by clicking the **Automate** button on the top right corner).
2. Click the **+New** button, then **+New rule**.
3. Select the repository(s) you want the rule to be applied to.
4. Build your if-statement:
1. Choose criteria for the rule to trigger. For example, *CVSS is at least high (7.0-8.9).* Click **AND or OR** to add a new criterion. You can select multiple criteria connected by the operators. See below for more information.
2. Choose an action to be executed when the condition is true. For example, fail pipeline. See below for more information.
5. If you do not want the rule to apply for vulnerabilities that have been marked as unaffected by you or someone on your team, leave the pre-filled checkbox in the bottom right checked.
6. Click **Generate rule** and review any warnings (if applicable). Make sure that the statement corresponds to what you were looking to achieve with your rule.
7. Click **Save.**
### Rule conditions
Rules can incorporate multiple OR and AND operators. When working with multiple criteria and operators, the following precedents are applied:
* AND conditions inherit previous IF or OR conditions
* OR conditions do not inherit the previous IF or OR condition
### Rule actions
You can select one of the following actions to be performed once a rule is triggered:
* Fail pipeline - If the rule conditions are met, your pipeline fails.
* Pipeline warning:
* GitHub - If the rule conditions are met, your pipeline passes, the pipeline check is set to neutral, and a warning is printed.
* GitLab, Bitbucket and Azure DevOps - If the rule conditions are met, your pipeline passes, and a warning is printed.
* Notification by email - If the rule conditions are met, you receive an email notification.
* Notify user groups by email - If the rule conditions are met, all users in a chosen user group receive an email notification.
* Mark as unaffected - If the rule conditions are met, the affected vulnerabilities are marked as unaffected.
* Flag as vulnerable - If the rule conditions are met, the affected vulnerabilities are marked as vulnerable.
* Trigger webhook - If the rule conditions are met, a webhook is sent.
### Missing CVSS score
Rules that use the CVSS score as one of the conditions, might not trigger for vulnerabilities that lack a CVSS score. This does not mean that the vulnerability is not severe, but that the data source lacked the CVSS score information. To account for this, you can add the statement:
*OR CVSS is missing*
Keep in mind that adding the OR statement does not take previous IF or AND statements into consideration.
### Production dependencies
{% hint style="info" %}
This option is currently supported for Javascript (Yarn, NPM), Nuget, Java (Maven, Gradle), PHP (Composer), Python (requirements.txt), and Go.
{% endhint %}
You can make your policies or automations only trigger if the related dependency is used in production, to reduce the number of false positives or very low-risk triggers. To set this up, simply add another condition to the rules you want triggered only for non-dev dependencies:
### Automation rule examples
* **Prevent new dependencies with vulnerabilities**
Imagine you have a developer branch called dev where you add new exciting features. Being security-aware, you want to fail the pipeline if a new commit introduces a new vulnerability with a severity of high or more. You also want to be notified of this incident.
* **Prevent unknown license families and GPL**
In this scenario, Fortify SCA fails the pipelines if there are dependencies with either an unknown license family, or if the dependencies have any of the GPL-2.0 and AGPL-3.0 licenses. Fortify SCA also notifies all the administrators for the company account.
# Edit an automation rule
Learn how to edit, disable, or delete your automation rules.
### Edit
To edit an existing automation rule:
1. Go to **Automations** on the left side menu.
2. Click the **…** (three dots) button on the right-hand side of the rule.
3. Select **Edit rule.** Here, you can add or remove one or multiple conditions and actions or repositories.
4. To save the changes, click **Generate rule** and then **Save.**
### Disable
To disable an existing rule:
1. Go to **Automations** on the left side menu.
2. Disable the toggle button on the right-hand side of the rule.
### Delete
To permanently delete an existing rule:
1. Go to **Automations** on the left side menu.
2. Click the **…** (three dots) button on the right-hand side of the rule.
3. Select **Delete rule.**
# Default automation rules
Find default automation rules already in place and learn how to customize or remove them.
To make things easier for you, Fortify SCA has created a set of default rules that are activated on your first scan and applicable to all of your repositories. **As an administrator**, you are also able to disable existing default rules and can assign new rules to be added to integrated repositories by default.
Keep in mind that once a rule is marked as default, it will be enabled for new repositories, even if it was disabled for existing repositories.
### Set a rule as a default rule
1. Go to **Automation** on the left side menu. Here, you can [**create new automation rules**](/product/automation/create-an-automation-rule), as well as [**edit**](/product/automation/edit-an-automation-rule) the existing rules
2. Click **Default rule.**
3. In the confirmation modal, select whether the rule should be activated for only newly integrated repositories or existing repositories as well.
4. Click **Confirm.** From now on, only newly integrated repositories will be affected by your default rule.
This can also be done when creating or editing an automation rule:
1. Click **New+** to create a rule OR **Edit rule** in an existing rule.
2. Tick the **Default rule** checkbox.
3. Click **Save**. From now on, newly integrated repositories will be affected by your default rule.
### Remove a rule as a default rule
1. Go to **Automation** on the left side menu. Here, you can [**create new automation rules**](https://portal.debricked.com/automation-46/how-do-i-create-an-automation-rule-146), as well as [**edit**](https://portal.debricked.com/automation-46/how-do-i-edit-an-automation-rule-147) the existing rules.
2. Click **Default rule.**
3. On the confirmation modal, click **Go ahead**. From now on, newly integrated repositories will no longer be affected by your default rule.
### Disable default automation rules using API
You can disable these rules through our API to create your own custom policy.
The default rules can be accessed through the endpoint:
*api/1.0/open/admin/user/default-rules-enabled*
You can check the current status of your default rules:
```
curl -X 'GET' \ 'https://debricked.com/api/1.0/open/admin/user/default-rules-enabled' \ -H 'accept: */*' \ -H 'Authorization: Bearer '
```
The response will show you “true” if the default rules are enabled and “false” if they are disabled, e.g.:
```
{ "defaultRulesEnabled": true}
```
You can change the current status using “*enabled”:true* and *“enabled”:false*. Here’s an example of how to disable it:
```
curl -X 'PATCH' \ 'https://debricked.com/api/1.0/open/admin/user/default-rules-enabled' \ -H 'accept: */*' \ -H 'Authorization: Bearer ' \ -H 'Content-Type: application/json' \ -d '{ "enabled": false}'
```
Once you disable the default rules using the API, the automation rules will not trigger when a new repository is added to your account. Remember to set up your own rules to optimize your use of the Fortify SCA tool.
# Set up webhooks
Learn how to set up and configure a webhook.
In order to send a webhook request when an automation rule is triggered, add a "trigger webhook" action to the rule and enter the URL for the webhook in the URL field. When the rule is triggered, a POST request will be sent to the given URL with JSON-encoded data about the event.
The JSON will contain the following keys:
| Key | Type | Description |
| ------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------- |
| repository | string | Name of the repository which was scanned |
| branch | string | Name of the branch which was scanned |
| commit | string | Name of the commit which was scanned |
| commitLink | string | Link to a page debricked.com, where scan results for this commit are available |
| ruleId | integer | Unique identifier for the rule that was triggered |
| ruleLink | string | Link to a page in debricked.com, where the triggered rule can be viewed or edited |
| triggeredFor | array | Array of objects, where each element describes a combination of a vulnerability and a dependency which caused the rule to trigger |
Each element of *triggeredFor* will contain the following keys:
| Key | Type | Description |
| ------------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| dependency | string | Name of the dependency which caused the rule to trigger |
| dependencyLicenses | array | Array of licenses affecting the dependency, each encoded as a string using the same name as shown in the license view |
| dependencyLink | string | Link to the dependency on debricked.com |
| cve | object / null | Information about the vulnerability which caused the rule to trigger, or null if the rule doesn't have any conditions related to vulnerabilities |
| cve.name | string | Name of the vulnerability that caused the rule to trigger |
| cve.link | strint | Link to the vulnerability on debricked.com |
| cve.cvss2 | number / null | CVSS2 score for the vulnerability, or null if not available |
| cve.cvss3 | number / null | CVSS3 score for the vulnerability, or null if not available |
### **Send a sample request**
A sample webhook request can be sent to the specified URL by clicking **Send sample request**. The *triggeredFor* array will be populated using up to three vulnerabilities that were found the last time this repository was scanned. Note that these vulnerabilities may not necessarily fulfill the conditions specified in the rule.
### **Verification secret**
To ensure that a webhook request was sent by Debricked, a key can be specified in the *verification secret* field. When a verification secret is specified, webhook requests made by this rule will include the header X-Debricked-Signature, containing an SHA256-HMAC signature generated using the webhook payload and the verification secret.
### Set up a webhook with slack through Zapier
You can use the automation engine to send notifications to Slack, with the help of middleware, e.g. Zapier. Keep in mind that this is currently only possible using the premium version of Zapier.
**To create a webhook URL:**
1. Open [Zapier](https://zapier.com/app/zaps).
2. Click **+Create Zap**.
3. Search for and select **Webhooks by Zapier**.
4. Go to the **Event** drop-down, select **Catch Hook** and click **Continue**.
5. Copy the Webhook URLI.
6. Click **Continue** and then **Test trigger**.
7. Once you have the URL, open the Debricked tool and go to **Automations** on the left-side menu.
8. You can either create a new rule or edit an existing one in the **Then** statement. Once done, add the **trigger webhook** action.
9. Paste the Webhook URL copied from Zapier into the field.
10. If needed, click **Send sample request** to test if everything works correctly.
11. Click **Generate rule** and **Save.**
### **Set up notifications in slack using webhook**
To manage your notifications in Slack:
1. Open [Zapier](https://zapier.com/app/zaps).
2. Click **Action** and select **Slack.**
3. Go to the **Event** drop-down and select the desired action. For example, **Send Channel Message**.
4. Click **Choose account** and follow the instructions on the page to connect your Slack account to Zapier.
5. Click **Set up action** and select the data that you want to send.
6. Click **Message text** and select the information to be included in the message.
7. Click **Test action**.
8. Click **Publish Zap**.
Now you are ready to receive Slack notifications from Debricked!
# Allow and deny lists for dependencies
Allow and deny lists
Allow and deny lists help you control which dependencies your organization accepts or blocks. Fortify SCA and Open Source Select use these lists in automation rules to evaluate dependencies by name, version, or package URL.
Use allow lists to approve known-good components. Use deny lists to block components that your organization does not allow.
#### **How allow and deny lists work**
Allow and deny lists contain dependency entries. Automation rules evaluate dependencies against those entries and apply the configured action.
List entries do not trigger actions by themselves. You must reference the lists from an automation rule for the lists to take effect.
#### **Supported dependency formats**
You can define dependency entries in these formats:
| Format | Example | Match behavior |
| ---------------------- | ------------------------ | ------------------------------------------------------------------ |
| PURL | `pkg:npm/lodash@4.17.21` | Matches one exact package and version |
| Name only | `lodash` | Matches all versions and package managers for that dependency name |
| Name and version | `lodash@4.17.21` | Matches one exact name and version |
| Name and version range | `lodash@>=4.0.0` | Matches versions that fall within the range |
Use PURL when you want exact package matching across ecosystems. Use name-based entries when you want broader policy coverage.
#### **Use cases**
This feature supports these governance workflows:
* Block specific components that your organization does not allow.
* Require vetted open-source dependencies in conservative environments.
* Sync component approval data from external systems.
* Reduce rule duplication by managing many components in shared lists.
# Create and manage dependency allow and deny lists
Create and manage lists
Use dependency allow and deny lists to define approved and blocked dependencies and then reference those lists in automation rules.
This topic explains how you add list entries, set dependency scope, and update lists through the API.
#### **Before you start**
Before you create dependency lists, make sure that:
* You can edit the configuration file used by your automation rules.
* You know which dependencies you want to allow or block.
* You know whether you want to evaluate direct dependencies only or direct and transitive dependencies.
#### **Create list entries**
Add dependency entries to the allow or deny section in your debricked-config.yaml configuration file.
Example configuration:
```perl
policies:
allow:
packages:
- "lodash" # Name
- "pkg:npm/lodash@4.17.21" # PURL
- "lodash=4.17.21" # Exact version
- "lodash>=4.17.21" # Single constraint
- "lodash>=4.17.21 <=5.3.4" # Range
deny:
packages:
- "n8n"
```
For more information about debricked-config.yaml configuration file, see the *Manage or override results* section in [File fingerprinting](/tools-and-integrations/cli/debricked-cli/file-fingerprinting).
A list entry can use one of these formats:
| Format | Example | Match behavior |
| ---------------------- | ------------------------ | ------------------------------------------------------------------ |
| PURL | `pkg:npm/lodash@4.17.21` | Matches one exact package and version |
| Name only | `lodash` | Matches all versions and package managers for that dependency name |
| Name and version | `lodash@4.17.21` | Matches one exact name and version |
| Name and version range | `lodash@>=4.0.0` | Matches versions that fall within the range |
Use PURL when you need exact matching. Use name-only format when you want broader coverage.
#### **Reference lists in automation rules**
After you define the lists, create automation rules that evaluate dependencies against them.
To create a rule:
1. Open **Automation**.
2. Select **Create rule**.
3. Choose a dependency condition.
4. Select whether the dependency is in an allow list or deny list.
5. Choose the target list.
6. Select the action.
7. Save the rule.
Example rule patterns:
* If dependency is in deny list, then fail the check.
* If dependency is not in allow list, then mark the repository as non-compliant.
* If dependency is in allow list, then continue the workflow.
#### **Set dependency scope**
Automation rules support two dependency scope modes:
* Direct and transitive dependencies
* Direct-only dependencies
Use direct-only dependencies when you want to control only components added directly by the project. Use direct and transitive dependencies when you want full supply chain coverage.
#### **Manage allow and deny lists through the API**
You can update dependency lists through the API when you want to sync external approval data or manage lists at scale.
A typical workflow is:
1. Export approval or block data from an external system.
2. Convert the data to a supported dependency format.
3. Update the allow or deny list through the API.
4. Run automation evaluation.
5. Review the result in Fortify SCA or Open Source Select.
This workflow supports integrations such as Sonatype Firewall approval data and other component governance systems.
#### **Use cases**
Dependency allow and deny lists support these workflows:
* Block specific components that your organization does not allow.
* Require vetted open-source dependencies in conservative environments.
* Reuse component approval data from external systems.
* Reduce rule duplication by managing many components in shared lists.
# Policies
Learn how to group your automation rules into policies for a single point of control.
Group automation rules into policies to simplify the management of these rules by providing a single point of control. This makes it easier to enable, disable, or modify multiple rules at once. Additionally, Enterprise users are able to use those policies to evaluate packages in Open Source Select with [Start Left Policies](/product/open-source-select/start-left-policies).
### View existing policies
1\. Go to **Automations** on the left side menu (you can also access automations for a specific repository by clicking **Automate** on the top right corner).\
2\. See a list of your existing policies under the tab **Policies**.\
3\. Click a specific policy to see the full list of rules that are part of it. Here, you can add new rules, enable/disable/edit them, and remove them from the policy.
### Create a new policy
1\. Go to **Automations** on the left side menu (you can also access automations for a specific repository by clicking **Automate** on the top right corner).\
2\. Click **+New**, then **Create policy.**\
3\. On the popup window add a name, repositories affected and select automation rules that should be part of your policy.\
4\. Click **Save policy.**
### Edit an existing policy
1\. Go to **Automations** on the left side menu (you can also access automations for a specific repository by clicking **Automate** on the top right corner).\
2\. Click the **Policies** tab.\
3\. Click **… (three dots)** for the specific policy and then click **Edit policy.**\
4\. On the popup window you can edit details such as the name, repositories affected and select automation rules that should be part of your policy.\
5\. Click **Save policy.**
# Monitoring
Learn how to monitor vulnerabilities in repositories that are not updated regularly.
Fortify SCA automation policies normally trigger based on pipeline events, such as committing code to a repository. When the source code is committed, a Fortify SCA scan starts and automations run. However, in some cases, you might want to use automations to check the status of a repository even if you have not made any changes to it. For example, new vulnerabilities might be discovered for dependencies in repositories that are not updated regularly. Monitoring allows you to get timely warnings about issues in such repositories by automatically and periodically checking the rules regardless of pipeline events. It is possible to configure monitored automations to either result in webhooks or emails when triggered.
To enable monitoring for a new rule, follow these steps:
1. From a repository page, go to the **Automations** tab. On the Automations page, you can view the list of automation rules created.
2. On the Automations page, click **New** -> **Add rule**. The Add a new rule page is displayed.
3. On the Add a new rule page, select the valid vulnerability or malware condition from the drop-down. The vulnerability condition must be either 'CVSS' or 'discovery date' or "vulnerability is exploited". The malware condition must be "dependency is malicious".
4. Select the valid trigger events from the drop-down. The trigger events must be either 'notify by email', 'notify user groups by email' or 'trigger webhook'.
5. Click **Enable monitoring** check box to enable the monitoring for the rule.
6. Click **Generate rule** and review any warnings (if applicable).
7. Click **Save**.
{% hint style="info" %}
When the monitoring is enabled for a rule, on the Automations page, you can view the  icon next to the rule.
{% endhint %}
To enable monitoring for an existing rule, follow these steps:
1. From a repository page, go to the **Automations** tab. On the Automations page, you can view the list of automation rules created.
2. Click the **… (three dots)** on the right-hand side of the rule.
3. Select **Edit rule.**
4. On the Edit rule page, select the valid vulnerability or malware condition from the drop-down. The vulnerability condition must be either 'CVSS' or 'discovery date' or "vulnerability is exploited". The malware condition must be "dependency is malicious".
5. Select the valid trigger events from the drop-down. The trigger events must be either 'notify by email', 'notify user groups by email' or 'trigger webhook'.
6. Click **Enable monitoring** check box to enable the monitoring for the rule.
7. Click **Generate rule** and review any warnings (if applicable).
8. Click **Save**.
To filter the rules, follow these steps:
1. From a repository page, go to the **Automations** tab. On the Automations page, you can view the list of automation rules created.
2. On the Automations page, click **filter**. The Filter by page is displayed.
3. On the Filter by page, select the appropriate values to filter the rules. You can filter the rules based on:
* Activation: The values are 'Active' and 'Inactive'.
* Action: The values are 'Fail pipeline', 'Pipeline warning', 'Notify by email', 'Mark as unaffected', 'Flag as vulnerable' and 'Trigger webhook'.
* Monitoring: The values are 'Enabled' and 'Disabled'.
* Default rules: The values are 'Default rules' and 'Non default rules'.
# Data exports
Discover the different ways of exporting data with OpenText Fortify Software Composition Analysis.
# Overview
Explore the data and snapshots you can find on the Overview page in the tool.
Clicking **Overview** on the left side menu will take you to a dashboard allowing you to get a clear overview of all vulnerabilities found in your organization.
### **Filters**
#### Repository or Branch
The data presented in the Overview can be filtered depending on your needs. The repository picker enables you to select either a specific repository/branch or all your repositories altogether. When an individual repository is selected a specific branch selector shows up to further narrow down your data. The *All repositories* view shows data from the sum of the default branches present in all repositories.
Due to limitations, it is not always possible to identify the default branch except for GitLab users. For other users, the default branch can be identified if the branch name is either master or main. An effort is still made to identify your default branch correctly. This effort consists of looking for the branch with the most activity as it is assumed that, at least over time, this is the most interesting branch to look at.
#### Time period
The Fortify SCA API allows you to see data for any given interval. Keep in mind that for the period prior to the first snapshot, the data will be padded with 0 values. Since the snapshots older than a month are pruned, the intervals beginning over 30 days ago must have a two-week range.
### Vulnerability graph
The main dashboard presents your organization’s historical data in the form of a graph. This view visualizes the total amount of vulnerabilities in selected repositories, grouped by severity. You can adjust the graph according to your needs, by changing the values in the repository/branch and time period pickers.
### License risk widget
The bottom widget presents your current licence compliance risks, grouped by risk levels: critical, high, medium, low, and unknown. Keep in mind that this widget always shows you the current data, unaffected by the time period picker. You are still able to customize it by changing the selected repository/branch.
### Fixed vulnerabilities widget
The left-side widget presents information about your recently fixed vulnerabilities, including:
* The total amount of fixed vulnerabilities.
* The number of vulnerabilities fixed over the time period selected with the picker.
* A graph visualizing your fixed vulnerabilities over a time period.
* A sorted list of fixed vulnerabilities, the vulnerabilities fixed most recently shown at the top. You can also find their severity and the date they were fixed on.
* Click the name of the vulnerability to view the Vulnerability page.
* Click the folder icon to open the repository where the vulnerability was found.
* Click **View More** to view the complete list of fixed vulnerabilities in the currently selected scope.
You can also:
* Search the list of fixed vulnerabilities.
* Customize this widget by selecting the repository or branch and time period, using the filters.
### **Snapshots**
In order to accurately represent data in the overview, Fortify SCA periodically saves snapshots of the state of users' repositories. These snapshots contain the number of unknown-, low-, high-, and critical-severity vulnerabilities in a given repository. This evaluation is based on CVSS scores, with CVSS4 always taking precedence over CVSS3 and CVSS2. When a vulnerability does not have a CVSS score, it is assigned the unknown severity. The snapshots don’t record any other details about the vulnerabilities, only the quantity. They are created once per day and are updated upon each successful scan of a repository. Keep in mind that only snapshots coupled to the branch(es) being scanned will be updated.
### **Pruning**
In order to limit the amount of data that has to be stored, Fortify SCA periodically prunes the snapshots. All Sunday snapshots are saved indefinitely, but the snapshots taken on other days are only retained for one month. That results in the resolution of the dashboard graph being drastically reduced for data older than one month.
# License export
Learn how to create a License Export.
{% hint style="info" %}
*This feature is only available for* [*SCA Premium & Enterprise*](https://debricked.com/pricing/) *users. Already have an account?* [*Click here to upgrade.*](https://debricked.com/app/en/repositories?billingModal=enterprise,free)
{% endhint %}
Knowing what kind of licenses you have imported through your dependencies is crucial, as failing to comply with open-source licenses puts you at legal risk. Fortify SCA allows you to make an export with all licenses and the affected repositories. This enables you to let relevant stakeholders get an easy overview of the state of compliance and keep track of your progress over time.
### Generate a license export
1. Click **Generate Export** on the top right corner of the page.
2. Select the scope of the export as wither global, repositories or groups.
3. Under **Export Type***,* select **License Export.**
4. Check your email for the exported data, which will be sent to you in the .xslx format. If you cannot find the email in your inbox, check the SPAM folder.
Depending on the selected scope, you might receive three different types of exported data:
#### all\_licenses.xlsx
The excel sheet is divided into three columns:
* License - The name of the license.
* Repositories - The name of the repository using that license, the latest commit hash, and the creation date of that commit.
* License family - The name of the license family.
#### licenses\_per\_repo.xlsx
The excel sheet contains the name of the repository in the first row, divided into five columns:
* Dependency - The name of the dependency.
* Dependency id - The ID number of the dependency.
* License - The name of the licenses used by the dependency.
* Version - The version of the dependency.
* Direct/Indirect - The type of the dependency, which can be listed as "D = Direct", "I = Indirect" and "? = undefined".
#### licenses.xlsx
The excel sheet contains the name of the license in the first row, divided into two columns:
* Repositories - The name of all the repositories using that license.
* Dependencies - The name of all the dependencies using that license per repository.
# Vulnerability export
Learn how to create a Vulnerability Export.
{% hint style="info" %}
*This feature is only available for* [*SCA Premium & Enterprise*](https://debricked.com/pricing/) *users. Already have an account?* [*Click here to upgrade.*](https://debricked.com/app/en/repositories?billingModal=enterprise,free)
{% endhint %}
The Vulnerability Export summarizes data about all of your projects. It shows a summary of the total number of vulnerabilities found, their classification between critical and high, and their review status.
### Generate a vulnerability export
1. Click **Generate Export** on the top right corner of the page.
2. Select the **scope** of the export as either global, repositories or groups.
3. Under **Export Type***,* select **Vulnerability Export.**
4. Click **Generate.**
5. Check your email for the exported data, which will be sent to you in the .xslx format. If you cannot find the email in your inbox, check the SPAM folder.
The exported data is divided into four columns:
* Repository - A list of all your projects.
* Total vulnerabilities - The total number of vulnerabilities found per repository.
* Vulnerability priority - The number of vulnerabilities found with a CVSS rating of high or critical.
* Review status - The current status set for each vulnerability. It can be either vulnerable, unexamined, paused snoozed or unaffected.
# SBOM export
Learn about SBOM export reports.
{% hint style="info" %}
T*his feature is only available for enterprise users. Already have an account?* [*Click here to upgrade.*](https://debricked.com/app/en/repositories?billingModal=enterprise,free)
{% endhint %}
### **Export a CycloneDX or SPDX SBOM using web tool**
{% hint style="info" %}
*Keep in mind that this feature is only available for enterprise users.*
{% endhint %}
In order to generate the CycloneDX or SPDX SBOM Export:
1. Click **Generate export** on the top right corner of the page.
2. Under **Scope**, choose one of the following options:
1. **Global export:** Export the SBOM for all repositories you have access to.
2. **Repositories:** Select specific repositories for which you want to view the data and then choose the corresponding branch. If you select multiple repositories, the **Branch** drop-down will display only the branches common to all the selected repositories.
3. **Groups:** Export the SBOM for a specific group of repositories.
3. Under **Export Type**, select **CycloneDX** or **SPDX** under **SBOM**.
4. Click **Generate.**
5. Check your email for the exported data, which will be sent to you in the .json format. If you cannot find the email in your inbox, check the spam folder.
#### **Export a CycloneDX or SPDX SBOM using web tool - video guide**
{% embed url="" %}
### **Export a CycloneDX or SPDX SBOM to email using API**
If you have already integrated your repository with Fortify SCA, you can generate a CycloneDX or SPDX SBOM by fetching your data through the API.
To use the Fortify SCA REST API, you should authenticate first.
Endpoint: /api/{1.0}/open/sbom/generate
Following is an example of a request using curl to generate an SPDX SBOM (to generate a CycloneDX SBOM use `"format": "CycloneDX"`):
```
curl -X 'POST' \
'https://debricked.com/api/1.0/open/sbom/generate' \
-H 'accept: application/json' \
-H 'Authorization: Bearer ' \
-H 'Content-Type: application/json' \
-d '{
"format": "SPDX-2.3",
"email": "user1@debricked.com",
"repositoryIds": [
1
],
"vulnerabilities": true,
"rootFixes": true,
"licenses": true,
"sendEmail": true
}'
```
You can send the following parameters in the body of the request: *commitId*, *email*, *repositoryIds*, *branch*, *locale*. You can choose to add license and vulnerability data, using *licenses: true/false* and *vulnerabilities: true/false*.
If you provide a *commitId*, the *branch* and *repositoryIds* will be ignored. If you leave the *branch* field empty, the report is generated for the identified default branch (most likely 'main' or 'master', if applicable) of the selected repository. It is also possible to create an SBOM for all repositories by not specifying any *repositoryIds*.
Once you send the request, you will receive your SBOM via email, which will be sent to you in the *.json* format. If you can’t find the email in your inbox, make sure to check the SPAM folder. If you do not provide an *email* address, the SBOM will be sent to the email of the user who created the request.
#### **Export a CycloneDX or SPDX SBOM to email using API - video guide**
{% embed url="" %}
### **Export a CycloneDX or SPDX SBOM directly from API**
It is also possible to generate a CycloneDX or SPDX SBOM and download it directly through the API.\
As part of the response of the `/api/1.0/open/sbom/generate` endpoint, a reportUuid is sent, which can be used in the `/api/1.0/open/sbom/download` endpoint.
Following is an example response from the `/api/1.0/open/sbom/generate` endpoint:
```
{
"message": "The report has started generating and can be downloaded through the 'download' endpoint once ready, by using the reportUuId stated below. Be aware that it might take some time before it's finished",
"reportUuid": "",
"notes": [
"Example note"
]
}
```
Following is an example request for the `/api/1.0/open/sbom/download` endpoint:
```
curl -X 'GET' \
'https://debricked.com/api/1.0/open/sbom/download?reportUuid=' \
-H 'accept: */*' \
-H 'Authorization: Bearer '
```
If you do not want the report to also be sent to your email, it is possible to turn this off by setting the "sendEmail" value to "false" in the `/api/1.0/open/sbom/generate` endpoint.
Click the following link for an example on exporting CycloneDX SBOM:
### [CycloneDX SBOM file example](https://github.com/debricked/blog-snippets/blob/main/example-sbom-report/SBOM_2022-12-14.json)
Click the following link to view the list of commands to create an SBOM using the CLI.
#### [Manually create an SBOM using the CLI](https://docs.debricked.com/tools-and-integrations/cli/debricked-cli#report)
#### [Automatically create an SBOM after scanning, using the CLI](https://docs.debricked.com/tools-and-integrations/cli/debricked-cli#scan)
# CycloneDX SBOM export
Learn how to create a CycloneDX SBOM Export.
{% hint style="info" %}
*This feature is only available for* [*SCA Enterprise*](https://debricked.com/pricing/) *users. Already have an account?* [*Click here to upgrade.*](https://debricked.com/app/en/repositories?billingModal=enterprise,free)
{% endhint %}
### **What is CycloneDX?**
CycloneDX, developed by the Open Web Application Security Project (OWASP), is an open common standard for communicating SBOM information, a data format.
#### Dependency relations
In the dependencies array, you can find a reference number (ref) for each component and an array of each direct dependency of that dependency (depends\_on). The roots of the relational trees will reference to the files in the project, together with the direct dependencies that it contains. By traversing the dependencies array, it is possible to build the entire dependency tree.
In example below, you can see the direct dependency *\`webpack:4.28.4\`* depending on *\`terser-webpack-plugin:1.2.1\`* which in turn depends on *\`terser:3.14.1\`.*
```
"dependencies": [
{
"ref": "e771afadf654cc12c324a0dd716518dd",
"depends_on": ["cpe:2.3::~:webpack:4.28.4:~:~:~:~:~:~:~"]
},
{
"ref": "cpe:2.3::~:webpack:4.28.4:~:~:~:~:~:~:~",
"depends_on": ["cpe:2.3::~:terser-webpack-plugin:1.2.1:~:~:~:~:~:~:~"]
},
{
"ref": "cpe:2.3::~:terser-webpack-plugin:1.2.1:~:~:~:~:~:~:~",
"depends_on": ["cpe:2.3::~:terser:3.14.1:~:~:~:~:~:~:~"]
},
{
"ref": "cpe:2.3::~:terser:3.14.1:~:~:~:~:~:~:~",
"depends_on": []
}
]
```
Here is how this would be visualised in the user interface:
#### Root fixes
Under **Recommendation,** you can find information about the first version of the specific vulnerable dependency that is safe, as well as the first version of the root or direct dependency that does not contain a vulnerable version of the indirect dependency. See example below:
```
"recommendation": "Multiple components are affected by this vulnerability.
Component: pkg:npm/async@3.2.0
Safe version: 3.2.2.
Root fixes: Update root dependency pkg:npm/htmlhint@0.14.2 to 0.16.2.
---------
Component: pkg:npm/async@2.6.0
Safe version: 2.6.4.
Root fixes: Update root dependency pkg:npm/gelf-pro@1.2.2 to 1.3.4.",
"created": "2022-04-06T17:15:00+00:00",
"published": "2022-04-06T17:15:00+00:00",
"updated": "2022-04-06T17:15:00+00:00",
"affects": [
{
"ref": "pkg:npm/async@3.2.0"
},
{
"ref": "pkg:npm/async@2.6.0"
}
],
"references": [
{
"id": "GHSA-fwr7-v2mv-hh25",
"source": {
"url": "https://github.com/advisories/GHSA-fwr7-v2mv-hh25",
"name": "GitHub"
}
}
```
# SPDX SBOM export
Learn how to create a SPDX SBOM Export.
{% hint style="info" %}
*This feature is only available for* [*SCA Enterprise*](https://debricked.com/pricing/) *users. Already have an account?* [*Click here to upgrade.*](https://debricked.com/app/en/repositories?billingModal=enterprise,free)
{% endhint %}
### **What is SPDX?**
SPDX is an open standard for communicating software bill of material information, including provenance, license, security, and other related information. SPDX reduces redundant work by providing common formats for organizations and communities to share important data, thereby streamlining and improving compliance, security, and dependability.
{% hint style="info" %}
*Unlike the CycloneDX SBOM, the SPDX SBOM does not contain vulnerability information.*
{% endhint %}
#### Dependency relations
The relationships between components are presented in the relationships array. Fortify SCA SPDX SBOMs support following two types of relationship objects:
* DESCRIBES which is used for declaring each file and dependency component in the BOM.
* DEPENDENCY\_OF which denotes a direct relationship between two components.
In the objects describing the direct dependencies of a file, the 'relatedSpdxElement' will contain the reference of that file. Relationships between dependencies will instead reference the parent dependency. By traversing the dependencies array, it is possible to build the entire dependency tree.
In the example below, you can see direct dependency *\`webpack-4.28.4\`* referenced as a dependency of a file. Component *\`terser-webpack-plugin-1.2.1\`* is in turn referenced as a dependency of *\`webpack-4.28.4\`* and lastly, *\`terser-3.14.1\`* is a dependency of *\`terser-webpack-plugin-1.2.1\`.*
```
"relationships": [
{
"spdxElementId": "SPDXRef-DOCUMENT",
"relatedSpdxElement": "SPDXRef-bda845e38ee2becb214eaa4c995d4951d755faceb38a4ef6e7092699592d7efe",
"relationshipType": "DESCRIBES"
},
{
"spdxElementId": "SPDXRef-DOCUMENT",
"relatedSpdxElement": "SPDXRef-pkg-npm-terser-3.14.1",
"relationshipType": "DESCRIBES"
},
{
"spdxElementId": "SPDXRef-DOCUMENT",
"relatedSpdxElement": "SPDXRef-pkg-npm-terser-webpack-plugin-1.2.1",
"relationshipType": "DESCRIBES"
},
{
"spdxElementId": "SPDXRef-DOCUMENT",
"relatedSpdxElement": "SPDXRef-pkg-npm-webpack-4.28.4",
"relationshipType": "DESCRIBES"
},
{
"spdxElementId": "SPDXRef-pkg-npm-terser-3.14.1",
"relatedSpdxElement": "SPDXRef-pkg-npm-terser-webpack-plugin-1.2.1",
"relationshipType": "DEPENDENCY_OF"
},
{
"spdxElementId": "SPDXRef-pkg-npm-terser-webpack-plugin-1.2.1",
"relatedSpdxElement": "SPDXRef-pkg-npm-webpack-4.28.4",
"relationshipType": "DEPENDENCY_OF"
},
{
"spdxElementId": "SPDXRef-pkg-npm-webpack-4.28.4",
"relatedSpdxElement": "SPDXRef-bda845e38ee2becb214eaa4c995d4951d755faceb38a4ef6e7092699592d7efe",
"relationshipType": "DEPENDENCY_OF"
}
],
```
Here is how this would be visualised in the user interface:
# SCA summary export (PDF)
Learn how to generate executive PDF reports from Global View.
### Overview
SCA Summary reports provide leadership-ready security summaries in PDF format.
Use them to share key security insights with stakeholders in a format that is easy to review and distribute.
{% hint style="info" %}
PDF export is currently available only for **Global export**.
{% endhint %}
### Generate an SCA summary report
To generate an SCA summary report:
1. Click **Generate Export** on the top right corner of the page.
2. Under **Scope**, select **Global export**.
3. Under **Export type**, select **SCA Summary**.
4. Click **Generate**.
5. Wait for the confirmation message.
6. Check the email connected to your OpenText Fortify SCA account.
The export starts generating immediately.
The PDF report is sent by email and may take a few minutes to arrive.
### What the report provides
The SCA summary report gives you a high-level summary of your organization’s security posture.
Use it when you need to:
* Share security status with leadership.
* Provide a concise summary for stakeholders.
* Distribute a snapshot of Global export data.
# SBOM management
Import and analyze third-party Software Bills of Materials in Fortify SCA.
Use Software Bills of Materials (SBOMs) to import, manage, and analyze third-party software. Third parties include vendors, partners, and suppliers.
{% hint style="info" %}
*This feature is only available for our* [*SCA Enterprise*](https://debricked.com/pricing/) *users. Already have an account?* [*Click here to upgrade.*](https://debricked.com/app/en/repositories?billingModal=enterprise,free)
{% endhint %}
Each organization can upload up to 15 SBOMs. The option to increase this quota will be available in a future release.
### About SBOMs
An SBOM is a structured inventory of the components in a software project. It can include component names, versions, relationships, licenses, and vulnerability data. Use the available tabs to review specific data:
* **All** tab: Lists all imported SBOMs.
* **Dependencies** tab: Shows component details.
* **Vulnerabilities** tab: Shows identified security issues.
* **Malware** tab: Shows findings.
* **Licenses** tab: Shows license information.
Use **Search by name** to locate an SBOM. Select **Import** to add an SBOM.
### Compare SBOMs with repository scanning
SBOM analysis examines supplied software inventory. Repository scanning analyzed source code and supported manifest files.
Repository scanning discovers dependencies; SBOM analysis uses data in the uploaded file.
Fortify SCA enriches imported components when identifiers are available, for example, Package URLs.
### Common use cases
Use SBOMs to:
* Review a supplier's SBOM before onboarding software.
* Verify that components meet your license policies.
* Track vulnerabilities in third-party software.
* Identify supplied software affected by malware.
### Known limitations
The quality of analysis depends on the uploaded SBOM.
* Missing data can reduce dependency, vulnerability, and license visibility.
* Fortify SCA does not analyze supplied source code.
* Results rely on uploaded data and available component enrichment.
# Import an SBOM
Import an SBOM to review its vulnerabilities and license information.
Fortify SCA parses the file and extracts component and metadata information. When an SBOM contains supported identifiers, such as Package URLs, Fortify SCA enriches matched components. Enrichment can add vulnerability and license information.
The imported SBOM is available for review in the **SBOMs** space.
{% hint style="info" %}
*This feature is only available for our* [*SCA Enterprise*](https://debricked.com/pricing/) *users. Already have an account?* [*Click here to upgrade.*](https://debricked.com/app/en/repositories?billingModal=enterprise,free)
{% endhint %}
### Supported formats
Fortify SCA supports the following SBOM formats:
* SPDX JSON (`.spdx.json`)
* CycloneDX (`.bom..json` `.*cdx.json` `.*cdx.xml` `.bom..xml`)
SPDX emphasizes license and compliance information. CycloneDX emphasizes vulnerability information.
### Import an SBOM
1. Click **Import**.
Import SBOM
2. In the **Import SBOM** dialog, drag one or more SBOM files into the upload area. Alternatively, click **Select files** and choose the files.
3. Click **Import**.
4. Wait for each file to show an **Imported** status.
* Select **View Results** to open the imported SBOM.
* Select **Cancel** to close the dialog. The imported SBOM appears in the **All** tab.
### Resolve import issues
An import can fail for these reasons:
* Invalid SBOM format
* Missing required fields
* Corrupted file
* Your organization has reached its limit of 15 uploaded SBOMs.
Review the displayed error. Then verify that the file is valid and complete. To import another SBOM after reaching the limit, delete an existing uploaded SBOM.
{% hint style="info" %}
Results depend on the quality and completeness of the uploaded SBOM. Fortify SCA does not analyze supplied source code.
{% endhint %}
# View SBOM data
Review imported SBOMs by summary, dependency, vulnerability, malware, and license data.
Review imported software inventory, security findings, and license information from the SBOMs area.
Select an imported SBOM to investigate its components and findings. Use the data tabs to focus on one record type.
### View SBOM data
Open the **All** tab to view every imported SBOM. Each row summarizes its components and findings.
Select an SBOM to open its dedicated data view. Then use these tabs:
* [Dependencies](/product/sbom-management/view-sbom-data/dependencies) lists components from imported SBOMs.
* [Vulnerabilities](/product/sbom-management/view-sbom-data/vulnerabilities) lists identified security issues.
* [Malware](/product/sbom-management/view-sbom-data/malware) lists malware findings.
* [Licenses](/product/sbom-management/view-sbom-data/licenses) lists license information.
Each tab includes a search field. Use **Filter** where available. Use the entries selector to change displayed rows.
To add an SBOM, click **Import**. See [SBOM import](/product/sbom-management/import-an-sbom) for instructions.
### View record details
Select an entry in any data tab to open its detail view.
* Select a dependency to review its component information and related findings.
* Select a vulnerability or malware finding to review affected components and severity.
* Select a license to review its risk classification and associated components.
The detail view shows information available for the selected record.
### Data sources
The SBOMs area displays uploaded data and available component enrichment.
Component names, versions, and licenses can come directly from the uploaded SBOM. OpenText Fortify Software Composition Analysis can enrich matched components.
Missing identifiers or license declarations can reduce the available information.
# All SBOMs
View a summary of imported SBOMs.
Use the **All** tab to review every imported SBOM.
Use **Search by name** to find an SBOM. Use the entries selector to change the number of displayed rows.
The **All** tab shows summary data for each imported SBOM:
* **Name** identifies the SBOM.
* **Total components** shows the number of listed components.
* **Total vulnerabilities** shows identified vulnerabilities.
* **Vulnerability priority** shows prioritized vulnerabilities.
* **Review status** shows the review state of findings.
* **Malware detected** identifies SBOMs with malware findings.
* **Total vulns with exploits** shows vulnerabilities with known exploits.
### See information about a specific SBOM
Select an SBOM to open its dedicated data view. Use the tabs to investigate its dependencies, vulnerabilities, malware findings, and licenses.
To add another SBOM, click **Import**. See [SBOM import](/product/sbom-management/import-an-sbom) for instructions.
# Dependencies
Review components across imported SBOMs.
Use the **Dependencies** tab to review components across imported SBOMs.
Use **Search by name or license** to find a component. Use the entries selector to change the number of displayed rows.
The **Dependencies** tab displays the following information:
* **Name** identifies the dependency.
* **Total components** shows the number of listed components.
* **Total vulnerabilities** shows identified vulnerabilities.
* **Vulnerability priority** shows prioritized vulnerabilities.
* **Review status** shows the review state of findings.
* **Malware detected** identifies SBOMs with malware findings.
* **Total vulns with exploits** shows vulnerabilities with known exploits.
### See information about a specific dependency
Select a dependency to open its detail view. This view shows:
* The dependency name and package manager.
* The component version and detected license.
* Health information for contributors, popularity, and security.
* The number of identified vulnerabilities.
* The SBOM containing the selected dependency.
Select the linked component name to open it in **Open Source Select**. Review the **Security** section for available security information.
# Vulnerabilities
Review vulnerabilities identified in imported SBOMs.
Use the **Vulnerabilities** tab to review security issues across imported SBOMs.
Use **Search by vulnerability name** to find a vulnerability. Select **Filter** to limit visible results.
The **Vulnerabilities** tab displays the following information:
* **Name** identifies the vulnerability.
* **Discovered** shows when the vulnerability was discovered.
* **CVSS** shows the vulnerability severity score.
* **Dependencies** lists affected components.
* **Review status** shows the review state.
* **Exploited (CISA)** shows whether CISA lists the vulnerability as exploited.
### See information about a specific vulnerability
Select a vulnerability to open its detail view. This view shows:
* The vulnerability identifier and discovery date.
* The affected dependency and package manager.
* Common Weakness Enumeration (CWE) information, when available.
* CVSS scores for each supported CVSS version.
* CISA Known Exploited Vulnerabilities (KEV) status.
Use **Set a review status for SBOM file** to select an SBOM or all SBOMs. You can flag the vulnerability as vulnerable or mark it as unaffected.
The **Vulnerable dependency** section lists dependency versions and their vulnerability status.
# Malware
Review malware findings in imported SBOMs.
Use the **Malware** tab to review malware findings across imported SBOMs.
Use **Search by name or dependency** to find a finding. Select **Filter** to limit visible results. Use the entries selector to change the number of displayed rows.
The **Malware** tab displays the following information:
* **Name** identifies the malware finding.
* **Discovered** shows when the finding was discovered.
* **CVSS** shows the severity score.
* **Dependencies** lists affected components.
* **Review status** shows the review state.
### See information about a specific malware finding
Select a malware finding to open its detail view. This view shows:
* The malware identifier.
* The publication and latest update dates.
* The affected dependency and package manager.
* The OSV advisory and its source link.
* A description of the malicious package and its impact.
Select **Show more** to read the full advisory description.
Use **Set a review status for SBOM file** to select an SBOM or all SBOMs. You can flag the finding as malicious or mark it as unaffected.
# Licenses
Review license information in imported SBOMs.
Use the **Licenses** tab to review license information across imported SBOMs.
Use **Search by license name or repository** to find a license. Use the entries selector to change the number of displayed rows.
### License information
The **Licenses** tab displays the following information:
* **Name** identifies the license.
* **License Risk** shows the license risk classification.
* **Dependencies** lists components using the license.
* **License family** shows the license family.
### See information about a specific license
Select a license to open its detail view. The **All repositories** tab lists repositories that use the license.
The table shows:
* **Repository** identifies the repository using the license.
* **License risk** shows the license risk classification for that repository.
* **Dependencies** shows the number of components using the license.
Use **Search by repository name** to find a repository. Use the entries selector to change displayed rows.
Click **Export table** to export the visible, filtered table data. Select **Generate export** to create a license export. See [License export](/product/exporting-sbom/license-export) for more information.
# Manage SBOMs
Rename, export, or delete imported SBOMs.
Maintain imported SBOM files throughout their lifecycle. Open an SBOM from the **All** tab to rename, export, or remove it.
For export instructions, see [Export an SBOM](/product/sbom-management/export-an-sbom).
### Rename an SBOM
1. Select the SBOM.
2. Select the **Edit** icon.
3. In **Change SBOM file name**, enter the new file name.
4. Select **Save**.
### Delete an SBOM
1. Select the SBOM.
2. Select the **Delete** icon.
3. In **Delete SBOM file**, confirm the file name.
4. Select **Delete**.
Select **Cancel** or close the dialog to keep the SBOM.
{% hint style="warning" %}
Deleting an SBOM permanently removes it from your organization. Export the file first if you need to retain it.
{% endhint %}
# Export an SBOM
Generate an SBOM from an imported SBOM.
Generate an SBOM file from an imported SBOM and send it to your account email address.
1. Select the SBOM.
2. Select **SBOM export**.
3. In the **Scope** section, select the export scope and SBOM file.
4. Select the required output format.
5. Select **Generate**.
The generated SBOM includes vulnerabilities and licenses identified by Fortify SCA.
{% hint style="info" %}
This export is for imported SBOMs. For repository-generated SBOM reports, see [SBOM export](/product/exporting-sbom/sbom-export).
{% endhint %}
# Administration
Here's everything an admin needs to know, from team onboarding to setting up Fortify SCA for a smooth workflow.
# Generate access token
Learn how to generate an access token.
{% hint style="info" %}
**Only users with administration rights can generate access tokens.**
{% endhint %}
Access tokens are a secure way of performing automated integrations with Fortify SCA. They are safer compared to using a username and password, and their typical use cases include GitLab, Bitbucket, and API integrations, which are not tied to a particular user, but rather to a repository or a project.
To generate a new access token:
1. Go to **Admin tools** on the left side menu.
2. Type your password to go to administrative mode.
3. In the **Access Tokens** tab, click the **+Create** button.
4. Type the description. If needed, select the **Admin** box which gives access to more actions, such as performing scans.
5. Click **Generate.**
6. Copy the generated token.
To generate a new access token for an Enterprise:
1. Go to **Admin tools** on the left side menu.
2. Type your password to go to administrative mode.
3. In the Access token tab, click the **+Create** button.
4. Type the description.
5. Select the repositories and user roles from the drop-down.
6. Click **Generate**.
7. Copy the generated token.
{% hint style="info" %}
**Save the token before closing the window as you can only view this token once.**
{% endhint %}
### Export access token details
You can export the filtered and visible access token details in the table to a CSV file. To do so, click **Export Table** located at the top-right corner of the table. *For more information, refer to the* [*Export table data*](/product/administration/repositories/export-table-data) *topic.*
### Token access scope
#### Freemium & Premium
For 'Freemium' and 'Premium' accounts, the following two access scopes are available:
* Admin tokens - Always give access to all repositories, both already existing and those created in the future.
* User tokens - When creating a token, the new token gets **User** access (equivalent to [Reviewer in RBAC](/product/administration/users/role-based-access-control-enterprise#userroles)) to every existing repository at the time of token creation.
#### Enterprise (with Role-Based Access Control (RBAC))
For Enterprise accounts, the access scope of access tokens can be configured granularly with different scopes for individual repositories. The access granted by the various scopes is equivalent to that provided by our RBAC user roles.
For repositories created or integrated after the generation of the token, access will be based on the default role, which can be configured by a company admin.
*For more information on the available user roles, their access and how to set the default role, see* [*Role-Based Access Control (Enterprise)*](/product/administration/users/role-based-access-control-enterprise)*.*
# Account
Learn how to manage your account with Fortify SCA.
# Change your password
See how to change your password.
A strong password is an easy and effective way to protect your account.
To change your password:
1. Hover on your name at the bottom of the left-side menu.
2. Click **User profile.**
3. Under Personal settings, type your new password and verify using your current one.
4. Save the changes.
# Delete your account
See how to delete your Fortify SCA account.
{% hint style="info" %}
Keep in mind that if you delete your account as the only administrator, the whole company account will also be deleted, along with all the data and other user accounts. If you want to keep the company account, make sure to give another user admin rights before deleting your own account.
{% endhint %}
In order to delete your user account:
1. Hover on your name at the bottom of the left-side menu.
2. Click **User profile.**
3. Click **Delete account** and confirm.
# Delete company account
See how to delete your Fortify SCA account.
In order to delete your company account:
1. Click **Admin tools** on the left side menu.
2. Type your password.
3. Go to the **Company settings** tab.
4. Click **Delete account** and confirm.
{% hint style="warning" %}
**This will delete your company data, including all users connected to this account.**
{% endhint %}
# Billing
Learn about billing at Fortify SCA.
# Manage contributing developers
Learn how to edit the number of contributing developers on your team.
Fortify SCA defines contributing developers as developers contributing to the repositories integrated with Fortify SCA.
In order to add more contributing developers to your subscription:
1. Go to **Billing** on the left side menu.
2. Click your subscription.
3. Click **Edit subscription** to add or remove seats.
# Manage billing frequency
Learn how to edit your billing frequency.
You can choose between two different billing periods, monthly and annual.
To change your billing frequency:
1. Go to **Billing** on the left side menu.
2. Click your subscription.
3. Click **Edit subscription**, and then click **Change.**
Note that selecting the annual payment is binding. Once you have already switched to the annual payment, it is not possible to switch back to the monthly payment until the year has passed.
# Manage payment methods
Learn how to manage your payment methods.
It is possible to add multiple credit/debit cards as payment methods. The first card you add is automatically set as the default payment method. Once another card is added, you will be able to select it as the default payment method instead.
If possible, the default card is charged first. If unable to charge the primary card, the secondary card will be used instead.
To add a new card:
1. Go to **Billing** on the left side menu.
2. Click **Payment Methods**.
3. Click **Add New**.
4. Select a method and enter the details.
# Access invoices
See how to access your invoices.
You can easily access all the past invoices for your account. To do so:
1. Go to **Billing** on the left side menu.
2. Click **Billing History** to access past invoices for your account.
# Manage your subscription
Learn how to manage your Fortify SCA subscription.
### Cancel your subscription
If you are not satisfied with the current premium offering, you can [contact us](/overview/help).
To cancel your premium subscription:
1. Go to **Billing** on the left side menu.
2. Click your subscription.
3. Click **Cancel subscription**.
4. Enter the reason (if applicable) and click **Confirm cancelation**.
### Reactivate your account
If you previously canceled a subscription, you can reactivate it with just a few clicks.\
To do so:
1. Go to **Billing** on the left side menu.
2. Click your subscription.
3. Click **Reactivate subscription.**
# Settings
Explore Settings at Fortify SCA.
# Enable and disable snoozing vulnerabilities
Learn how to enable or disable snoozing vulnerabilities.
By default, all users are able to snooze a vulnerability by changing its *Review status*. As the administrator, you are also able to disable that feature for all users in your company.
To manage the snoozing functionality for the company account:
1. Go to **Admin tools** on the left side menu.
2. Type your password to enter the administrative mode.
3. In the **User permissions** tab, toggle **Allow snooze for vulnerabilities** to enable the function and switch the toggle off to disable it.
Keep in mind that all vulnerabilities with *Review status* previously set to *Paused/Snoozed* will be set to *Unexamined* if you confirm your action.
# Supported language for Fortify SCA tool
See how to change the app language.
You can use the Fortify SCA tool in English and Swedish.
To change the language in the tool:
1. Hover on your name at the bottom of the left-side menu.
2. Click **User settings**.
3. Select your preferred language in the **Language** drop-down. Selecting **By browser** sets the language according to your browser settings. The setting will be saved automatically.
# View logged events
Learn about the events logged at Fortify SCA and how to view all of them.
{% hint style="info" %}
*Keep in mind that only users with admin rights have access to the event logs.*
{% endhint %}
To ensure transparency, Fortify SCA logs almost all events across the service.\
This enables you to track everything that happens in your company account and manage various aspects of security, performance, and transparency.
The logs can be accessed through the Fortify SCA API, using the endpoints:
```
/api/{version}/open/admin/request-logs/get-request-logs/api/{version}/open/admin/request-logs/get-events
```
To get a list of event logs, simply call the *get-request-logs* endpoint with appropriate filters. Here is an example of a simple request, fetching all events:
```
curl -X 'GET' \'https://debricked.com/api/1.0/open/admin/request-logs/get-request-logs?start=2021-05-10T15%3A52%3A01&page=1&pageSize=20' \ -H 'accept: application/json' \ -H 'Authorization: Bearer
```
In this case, a start date is specified, while the end date is not, which results in data on events from the start date, up to the current date and time. Since the endpoint is paginated, it is required to specify the pages and the page size.
Here is an example of a response:
```
{ "page": 1, "found": 2, "requestLogs": [ { "user": "tony.montana@debricked.com", "event_name": "Created pull request", "event_id": 2, "url": "https://debricked.com/vulnerability/1/repository/2/commit/3/pull-request/generate", "breadcrumbs": [], "ip_address": "256.139.13.37", "timestamp": "2021-11-06 19:45:14", "method": "GET", "status_code": 200 }, { "user": "walter.white@debricked.com", "eventName": "Visited repository page", "eventId": 44, "url": "/app/en/repository/24", "breadcrumbs": [ { "url": "../repositories", "text": "Repositories" }, { "url": "", "text": "owner/dependencies-relations-mess" } ], "ipAddress": "256.139.13.38", "timestamp": "2021-11-30T12:53:05", "method": "GET", "status_code": 200 } ]}
```
The *breadcrumbs* list all the pages the user visited while using the tool. Note that the breadcrumbs are printed in reverse chronological order, that is, the latest event first and the oldest event last. The URLs in the *breadcrumbs* are relative to the event URL.
### **Filters**
You can customize the logs by selecting additional filters, such as:
* *userEmail -* Filter events performed only by a specific user.
* *url* - Filter events only affecting a given URL. For example,
* *eventTypeId -* Filter a specific event type.
To filter the logs based on events and get a list of all event names and IDs, you can query the *get-events* endpoint:
```
curl -X 'GET' \ 'https://debricked.com/api/1.0/open/admin/request-logs/get-events' -H 'accept: application/json' \ -H 'Authorization: Bearer
```
Here is an excerpt of the response from the example:
```
[ { "eventId": 17, "eventName": "Added comment" }, { "eventId": 7, "eventName": "Added token" }, { "eventId": 16, "eventName": "Changed review status" }, { "eventId": 14, "eventName": "Changed the use case" }, { "eventId": 26, "eventName": "Changed user settings" }]
```
---
[Next Page](/llms-full.txt/1)