# How the tool works

Working with vulnerabilities, licenses and health in open source is not always so trivial, so we decided to do a high-level description of the architecture of our tool to help you more easily understand how it works and which results it generates.

# Data sources

Ah, 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, different security advisories, mailing lists, GitHub Issues, GitHub Security Advisory and more. We ping our sources every 15 minutes, giving fast and accurate data.

# Data refinement

When the data is collected we "clean up" since it is often quite messy. As our sources are a combination of structured and unstructured, data there is a lot of errors in it by default.

# An example; CVE-parsing

The largest source on vulnerabilities is the NVD database. Just like many other solutions, it is one of our primary sources. The problem with this source is that the CPEs (or products connected to vulnerabilities) are often mislabelled, and it's common to see a time-lag with up to four weeks in assigning CPEs to CVEs. Here we use our 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 we carry out 24/7 for our customers.

# Fully automated - no humans

One of the key differentiators for the Debricked's tool is that we do not use any form of manual analysis of vulnerabilities. A risky bet which took almost 5 years of R&D to pull off! But as a result, as soon a vulnerability is discovered in a data source, we index it, refine it and try to find a fix. All of this can happen within 15-30 minutes. Moreover, we constantly monitor 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 our 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 & matching

In the next step, Debricked will scan your projects for dependency files. This can be done in a variety of ways, as described further in this documentation (e.g. by manual uploads, CI/CD integrations and our API).

# What we look for

We essentially scan for any declared dependencies in files such as the famous "package.lock" file, "composer.json" and so forth. Next, this dependency file is transformed to our own internal format and is sent to our matching & rule-engine. Any indirect dependencies are also built/traversed in this process.

# Matching engine & rule engine

These are two pieces of software that A) Match your vendor and name of the dependency to our internal database, and B) Determine the likelihood of this match being correct. It is often the case that open source projects, unfortunately, have similar names, share parts of names or even have the same names but different vendors. Because of this, simple regular expressions and white/blacklists don't cut the deal. Again, we make use of modern tech such as machine-learning to determine the likelihood of the match being a true-positive or not based on our "secret sauce" algorithms which are currently being patented.

However, the accuracy of these algorithms varies depending on which language and package manager you are using. Read our benchmarks for more information on how well we support your stack. If it is not that great - be sure to let us know so that we can prioritise and boost the precision!

# Suggesting 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! Note: always check if updates introduce breaking changes before updating!