Is Debricked’s service on prem or SaaS?

Debricked is a Software as a Service (SaaS) solution currently.

What type of scanning does Debricked do?

Debricked 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. 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, Debricked can scan an SBOM if the vendor provides one.

Ultimately, the decision between manifest scanning and binary scanning depends on your workflow and objectives. At Debricked, we emphasize 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?

Debricked service 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.

Debricked has found a wrong dependency. What should I do?

If you think Debricked has identified an incorrect dependency, you can manage and override your dependency matches using our CLI.

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, Debricked 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, 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 Debricked run on a PC, or does it upload data to your servers?

There are several ways to run Debricked service.

• Manually upload your dependency files.

• Integrate Debricked service into your test pipelines through Platforms such as GirHub or GitLab.

How do you distinguish between frequent and sporadic contributors?

Debricked 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 Debricked implement to prevent and detect vulnerabilities?

Debricked 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 Debricked’s data stored?

Customer data is stored using Google Cloud Platform (GCP) as the service provider, located in Netherlands.

Where is Debricked’s office located?

Our headquarters is located at Anckargripsgatan 3, Minc, Malmö, Skåne 211 19, Sweden.

You can run Debricked in any of the following ways:

• Web: The Debricked web app enables a browser-based experience, providing all functions, including security and license scanning, automation, reporting, and more.

• CLI: The Debricked Command Line Interface 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 Debricked into your pipeline.

• API: The Debricked APIs allow you to integrate our service into your code, CI pipelines, and more.

• Browser: The 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.

Debricked helps you take full control of security, compliance, and project health with a toolkit that revolutionizes the way you use open source.

First Setup

Integrating with Debricked

Debricked's Tools

The Debricked Fundamentals - webinar recording

Check out our latest training webinar to learn the fundamentals of Debricked:

Need help getting started with Debricked? Join one of our upcoming webinars and ask questions directly to our experts.

Need more help?

If you have any additional questions feel free to contact our team. You can also join our community to stay up-to-date with everything related to Debricked and the open source universe.

When you sign up for a free account with Debricked, 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.

Debricked Premium & Enterprise accounts 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 Debricked. After you complete the process, you will have access to Debricked service with unlimited scans. To upgrade to our paid tiers with unlimited scans, click here.

For an enterprise subscription, contact our sales team at sales@debricked.com.

Debricked currently supports the tracking of C# dependencies through:

• NuGet, using .csproj, packages.lock.json and packages.config files

• 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, Debricked recommends using the packages.lock.json file. This file allows Debricked 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 technology with the Debricked CLI or by enabling repeatable package restores and then committing the generated file. When you run the resolve command, the Debricked 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. Debricked 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.

Debricked 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 for NuGet utilize native commands when resolving and include all dependencies defined with NuGet, including those managed through Central Package Management (CPM).

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

Debricked supports scanning for C# dependencies not defined in manifest files through file fingerprinting. Debricked 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.

Supported file formats and features

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

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

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

**When constructing our knowledge base, Debricked 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, Debricked specifically matches .dll files used in C# applications and .class files found within .jar files.

3. By default, Debricked has set up a number of rules to prevent unwanted licenses or dangerous vulnerabilities. Click the toggle button to disable any rule.

Debricked 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 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 technology in 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.

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 technology in our 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.

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

Debricked 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, Debricked 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.

File fingerprinting

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

Supported file formats and features

*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 used in C# and .class files found within .jar files from Java, among others.

Debricked supports tracking dependencies in CycloneDX SBOM using files in JSON and XML formats.

To ensure that Debricked identifes the SBOM files as CycloneDX SBOMs, please name them using one of the following conventions:

• .bom..json

• .*cdx.json

• .*cdx.xml

• .bom..xml

The specific features available for the SBOM will depend on the libraries included and the individual package managers used.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

Analyzing external SBOM files using Debricked - video guide

Debricked 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 Debricked CI/CD pipeline.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

There are two ways to create a Debricked account:

• Sign up with email

• Sign up using GitHub SSO

Sign up with email​​​​​​​

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:

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 Debricked, 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 Debricked 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

You can get in touch with our team through two channels:

Unable to access live chat

Debricked currently tracks PHP dependencies installed through Composer dependency manager, using either the composer.json or composer.lock files.

Debricked 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 Debricked CI/CD pipeline.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

Debricked supports tracking Go dependencies through:

• Go Modules, using go.mod files

• Go Dep, using gopkg.lok files

• Bazel, using WORKSPACE files

Go Modules

Debricked 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 technology in 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.

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.

Debricked recommends running go mod tidy to clean up unused modules before pushing the go.mod files, ensuring more accurate service results.

Bazel

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

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

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

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 Debricked 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 support@debricked.com. 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.

Debricked 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 Debricked CI/CD pipeline.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

The support for this language is currently in beta. Vulnerability results may be less accurate than normal.

Debricked 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 Debricked CI/CD pipeline.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

Debricked 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)

• file fingerprinting to detect dependencies not specified in manifest files

Debricked 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, Debricked 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 technology in 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

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

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

Debricked 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 Debricked CI/CD pipeline.

Supported file formats and features

*This is a native lock file format. Native lock file formats are the fastest formats to scan.

Debricked now tracks Python dependencies through:

• Pip (using the older requirements.txt files)

• Pipenv (using the newer Pipfile.lock files)

• 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 technology in 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:

<FILE_NAME>.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 Debricked CI/CD pipeline.

File fingerprinting

Debricked supports scanning for Python dependencies not defined in manifest files through file fingerprinting. Debricked 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.

Supported file formats and features

Apart from the various programming package management systems, Debricked 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:

• For Alpine Linux which is widely used by Docker containers, execute the following command:

To scan them for dependencies, the output file(s) should be either committed to the repository or manually uploaded.

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.

Debricked 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, Debricked will apply the fix to the main dependency file containing the direct dependency versions. Afterwards, Debricked 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, Debricked widens the scope to all CVEs that affect a specific repository. Currently, Debricked 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 Debricked is unable to detect a default branch, or the CVE exists in a branch other than the default one for that repository, Debricked 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:

Debricked'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. Debricked 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. Debricked 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.

Fully automated

What makes Debricked special is that it does not use any form of manual analysis of vulnerabilities. That is a risky bet that took almost 5 years of research and development to pull off. But as a result, as soon a vulnerability is discovered in a data source, it is indexed, refined and a fix is found. All of this can happen within 15-30 minutes. Moreover, Debricked constantly monitors for changes in data regarding this particular vulnerability. In contrast, it takes an average of 30 days for a NVD database to complement their data with more details. Sometimes it is never done if the vulnerability has low priority. The same is true for finding fixes and other details. But with Debricked, you can rest assured that the systems are working around the clock and are not introducing any noticeable lag between the vulnerability sources and your developers. Debricked is here to assist you in building the bricks of security!

Scanning the code for dependencies and matching

In the next step, Debricked 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 Debricked APIs.

What does Debricked look for?

Debricked 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 Debricked 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 Debricked 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. Debricked makes use of modern tech, such as machine learning, to determine the likelihood of the match being a true positive or not based on Debricked 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.

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

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.

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

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

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, improve your skills and stay ahead in the fast-changing world of technology.

Download PDF version

Solve vulnerabilities at scale

At Debricked, security is a top priority. The customers trust us with their software dependency data, and Debricked takes this responsibility seriously.

The task of handling data securely is based on trust, and Debricked takes several measures to earn this trust. This includes securing data at rest and in transit, being transparent in how Debricked reads repository information and separating pods.

This document serves to answer and clarify some questions that are received from customers on how and where their data is processed.

Securing data in transit

Debricked reads dependency information from your source code manager and matches the dependencies with our vulnerability, license, and health database. You can view the results in the CI/CD pipeline using the Debricked web application.

All data is transmitted in encrypted form to the database and the web application, using TLS 1.2 or higher, with ciphersuites supporting forward secrecy. When accessing the web application through a browser, HSTS (HTTP Strict Transport Security) with preload is used to ensure that no data is ever transmitted unencrypted. All communication with third-party services is also encrypted.

Data collection

Debricked collects customer data from your source code manager such as GitHub or GitLab. Debrick provides GitHub app with read and write access to the repository. The read access is required for reading metadata and dependency information. The write access is required to create pull requests for fixing vulnerabilities.

Debricked also provides a CLI (Command Line Interface), both standalone and embedded in a Docker image. The Docker image can access the repository as part of the CI/CD. Debricked will not get read permission to your complete repository.

Dependency information is sent to Debricked's servers. This holds for the GitHub app and the CLI used in the CI/CD. With the CLI, source code is never sent to Debricked. For the GitHub app, source code is only sent for package managers where this is required for building the dependency trees. Still, in all such cases, the source code is immediately deleted after the dependency tree is built.

Additionally, Debricked supports file fingerprinting for detection of dependencies. Here, Debricked uploads and saves the name, path, and size of a file, together with a hash of the file content. The files themselves are never uploaded or saved on Debricked servers.

To perform reachability analysis for vulnerabilities, call graph information will be sent to Debricked so that reachability can be visualized and assessed by the customer.

Data storage and processing

Debricked’s service is running on cloud computers hosted by GCP (Google Cloud Platform). All dependency data is stored and processed within the European Union (Netherlands).

The service, including the database, is hosted within a private network on GCP, using VPC peering. The database is not externally accessible and is deployed on two availability zones for added redundancy.

Debricked applies controlled invocation of the functionality through an authenticated API. Cloud infrastructure and direct database access are subject to the least privilege principle and are restricted to only very few employees.

The matching between dependency information and vulnerability, license, health data is performed on Kubernetes pods. When dealing with untrusted processing of dependency information, that is, functions implemented by third-party code (for example, ‘npm install’), such processing is performed in an ephemeral sandbox without multi-tenancy.

This ensures that there is no information leakage between customers as part of the processing.

Debricked also uses third parties to track and process how customers use the service. This allows Debricked to understand and optimize the service for improved customer experience. An effort is taken to anonymize possibly sensitive information. Debricked never sells any data to a third party.

Data access

From the customer’s perspective, password credentials are protected in several ways. Proactive password checking reduces the possibility of choosing weak passwords, and rate limits protect against brute-force attacks. Debricked also supports single sign-on login through GitHub and identity providers supporting the OpenID Connect protocol.

Account access in the web application supports two-factor authentication. Both email authentication and TOTP (Time-based one-time password) authentication with Google authenticator are supported.

Access is also granted through the CLI or directly through an API. Such access requires a JWT token. A long-lived refresh token with 20 years of validity can be generated and revoked in the web application or through the API using the account password. The refresh token can then be used to generate a JWT token that has about 1-hour validity.

Compliance

With many EU-based customers, Debricked aligns with the GDPR (General Data Protection Regulation) requirements. Here, transparency is key, and the Privacy Policy intends to convey all necessary information for customers to understand how Debricked treats PII (Personally Identifiable Information).

Debricked is part of OpenText Cybersecurity. The Debricked application has been certified as conforming to the ISO/IEC 27001:2013 requirements. Debricked continuously documents, updates, and assesses the internal security according to the requirements.

Debricked also has a SOC 2 report showing the compliance with the AICPA Trust Services Criteria.

Vulnerability testing and reporting

To encourage and enable third-party vulnerability reports, Debricked performs penetration tests, both in-house and by third parties, to reveal possible weaknesses in the web service and its implementation.

Debricked’s security testing also includes regular SAST and DAST scanning with professional third-party tools.

Lastly, Debricked uses Software Composition Analysis (SCA), its own Debricked SaaS application.

About Debricked

Debricked is redefining the way developers select, evaluate, use and contribute to open source software. Debricked SCA and Select makes open source security, compliance and health simple, and helps companies use more open source in an efficient manner. Since 2022, Debricked is a part of OpenText.

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. Debricked 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 indirect dependencies: The number of indirect dependencies that were imported by the dependency.

• Total vulnerabilities: The total number of vulnerabilities found (including indirect dependencies).

• Vulnerability priority: The total number of vulnerabilities where the CVSS score is critical or high.

• Review status: The total number of vulnerabilities, where the 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.

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.

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

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.

• 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 across all projects

To get an overview of all vulnerabilities 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 found in all your repositories are included.

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.

• Total indirect dependencies: The number of indirect dependencies that were imported by the dependency.

• Total vulnerabilities: The total number of vulnerabilities found (including indirect dependencies).

• Vulnerability priority: The total number of vulnerabilities where the CVSS score is critical or high.

• Review status: The total number of vulnerabilities, where the 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 and the Contributor score of this dependency.

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

Assume there is repository with huge number of vulnerabilities. It will take time to go through each one of them and potentially fix them. Debricked offers the ability to open a pull request to solve many vulnerabilities at once.

Support for Pull Requests

Currently, Debricked 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.

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.

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

Debricked 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, Debricked gets the branch ID

curl -X 'GET' \  'https://debricked.com/api/1.0/open/repository/15707/get-branches' \  -H 'accept: */*' \  -H 'Authorization: Bearer <token>

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 <token>

For Debricked 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 using the GitHub app.

• GitLab: if you have set up an integration to 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, to enable pull requests, you must provide additional credentials (as explained in the article).

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.

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.

1. Select Snooze for a set time period in the newly opened dialog and select your desired snooze period.

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

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.

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.

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.

Debricked'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, Debricked needs to understand how your open source dependencies are used. This information is collected by using Debricked'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.

How does Debricked know the vulnerable parts of libraries?

Debricked 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 Debricked'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 Debricked'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, Debricked 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.

Examples

For projects using Netty versions between 4.1.0 and 4.1.43, Debricked'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 Debricked's Reachability Analysis, this process is fully automated.

Different statuses of Debricked 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.

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

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 Debricked CLI callgraph command to your integration before running a Debricked scan. To find out more about the command and the various available flags, run:

debricked callgraph -h

When successful, the callgraph command generates a debricked-call-graph file. This file is automatically sent to Debricked 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, Debricked must also add Actions setup that can be found in the GitHub Actions repository.

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.

# GitLab CI/CD template

image: debricked/cli:2-resolution-debian

stages:
  - scan
debricked:
  stage: scan
  script:
    - debricked callgraph
    - debricked scan

Reachability Analysis is supported for all Java projects using Maven. To produce a callgraph, Debricked 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

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 Debricked CLI docker image to ensure that there is a compatible maven version included for the commands to succeed. Debricked recommendation is that you incorporate the scan and callgraph commands in your build image/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.

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.

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.

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 Debricked 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

At Debricked, 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:

Adaptive

The Adaptive Public License, or APL (APL-1.0), is a weak copyleft that is adaptable. The project owner may set up license conditions by choosing specific options from a template. Such options include patent rights, limited attribution, and to what extent changes need to be documented.

Non-copyleft

Software with a non-copyleft license is permitted to be included in products that are distributed under another license, including proprietary ones. Common non-copyleft licenses include BSD Licenses such as BSD 2-Clause "Simplified" License (BSD-2-Clause), and MIT License (MIT).

Non-free

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 is free from all obligations. That is, there is no copyright, trademark, or patent. The software may be distributed, modified, or sold without any attribution.

When working with open source, it is crucial to ensure and maintain open-source compliance, also from a commercial perspective. To help with that, Debricked 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.

License review or override

As a Repository or Company Admin (Enterprise), you can review and manually override the license found by Debricked 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.

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

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.

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 <token> \  -H 'Content-Type: application/json' \  -d '{ "useCase": 2 }'

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.

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:

If you have any further questions or need additional assistance, please refer to the SPDX documentation or contact us.

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

Project health is an important aspect to consider when selecting dependencies. But what does Project Health even entail? Debricked'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, Popularity, and Security.

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

Open Source 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 Debricked's open source select and start left - video guide

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 Debricked's open source select and start left - video guide

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:

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: https://debricked.com/en/select/package/{purl}

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 Debricked's open source select and start left - video guide

The Select Browser Extension allows you to view Debricked'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 or search for “Debricked Select” in the Chrome Web Store.

2. Click Add to Chrome.

1. Review the permissions and click Add extension.

1. On your browser, click Extensions and then the Pin emoji to pin it to your browser UI.

1. You are ready to go. Navigate to a repository or a package manager's GitHub page to see Debricked's Select Health data of the project in the popup.

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

Similar dependencies

Health metrics

Choose open source components with Debricked's open source select and start left - video guide

Open Source 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.

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, as well as edit or disable/delete the existing rules.

You can access automations for a specific repository by selecting a specific repository in the drop-down list.