Data sources

Explore this section to discover the trusted sources of data.

Everything in this modern world begins with data! And so does Debricked.

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. Here, Debricked uses the state-of-the-art 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, e.g. by CI/CD integrations (recommended), manual uploads, and our API.

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 our own internal format and is sent to our 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 gap in 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.