# About security
# Security terms
Here we explain common security terms that are used in our tool.
Common Vulnerability Enumeration - 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 - An open framework for describing the severity of vulnerabilities, where each vulnerability is given a score between 0 and 10, 10 being critical.
Common Weakness Enumeration - 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 this: "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 - This is a naming scheme for IT systems, software, and packages. An example of a CPE string for the React framework, version 16, is
National Vulnerability Database - 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.
# 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, C# Announcement, FriendsOfPHP's security advisories, Go Vulnerability Database, PyPA Python Advisory Database, GitHub Issues, GitHub Security Advisory, mailing lists, 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 CI/CD integrations (recommended), manual uploads 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!
Read more about solving vulnerabilities automatically through pull requests/merge requests or manually.
# Vulnerable functionality feature
Vulnerable Functionality is currently in alpha. Results may be less accurate than expected, and not all types of projects are yet supported.
Solving every vulnerability in one's project can be both time-consuming and cause unforeseen challenges. Debricked is aiming to help you with both of these aspects. You may have already learned how simple it can be to solve a vulnerability with Debricked. What if we could save you even more time and resources? Here we are introducing Debricked's vulnerable functionality feature.
# Vulnerable Functionality in short
Just because you are using a package with a vulnerability does not necessarily mean you are affected by the vulnerability in question, that requires actually using the vulnerable parts. By using Debricked's Vulnerable Functionality feature you can quickly assess whether or not you are, significantly speeding up triage of vulnerabilities.
This feature is visible when browsing a specific repository as shown below, highlighted in yellow. Due to the not all users having this feature enabled and it not being applicable to all users this column is hidden by default, to enable it select it as shown below.
# Tech stacks supported
Currently, this feature is only supported for Java Maven projects using GitHub actions. We have plans to add support for other integrations as well as for other languages and dependency management systems.