One of the most popular security-focused companies called Snyk is well on its way to offering additional tools which really boost global knowledge about security-related aspects. One of the services they offer is the Snyk vulnerability DB. This is a free-of-charge web service for anyone to learn more about (their) vulnerabilities. Essentially, Snyk is one of the core contributors to it, but others report vulnerabilities as well. Hosted and controlled by the experts of Snyk itself, it proves to be a valuable and wealthy source of information about well-known and lesser-known vulnerabilities. Browsing through their immense database, I became enthusiastic.
In this article, I will dig a bit deeper and share my thoughts on how to get the most out of the Snyks’ Vulnerability DB.
A quick overview
Snyk itself describes its database as The most comprehensive, accurate, and timely database for open-source vulnerabilities. It specifically focuses on open source libraries which are “free to use” for anyone. On the homepage you will find a great overview of all of the supported programming languages and technologies. These include NodeJS, Python, AWS, Go, Swift, NuGet, and Oracle just to name a few.
At the heart, you will get the option to search for a package (by its name) or CVE which impacts one or more packages. In addition to that, it shows a random list of vulnerabilities of the last week either on the application level or on the Operating System. At the bottom, you will find a list of recent vulnerabilities which are disclosed by Snyk itself. These include the name of the person/organization who discovered them.
A closer look
Let’s take a closer look at one of the vulnerabilities to reveal useful details about it. First of all, you will find useful metadata such as the disclosed data, published data, and credits as well as the Snyk ID. This makes communication about it very easy also since the ID is part of the URL which you can share easily. As of now, you can share it on Facebook, Twitter, LinkedIn or e-mail.
One of the most important aspects is the details in which package the vulnerability resides. The DB shows the package name and the version(s) which are impacted. This gives you a very quick overview to define if you need to take immediate action or not. Your SBOM (structure) is crucial to get a quick overview of the contents of your entire software system.
CVE
Every vulnerability has a (list of) CVEs in which it appears. Sometimes, there is no CVE available or you’ll only find the “new” and “severity” tag (such as “malicious”) which gives you an indication of how dangerous the vulnerability is. This expresses the category to which the vulnerability is classified and thus gives you a hint on how urgent you should take action.
CVSS
Besides severity-related information, the CVSS of each vulnerability is shown. CVSS stands for “Common Vulnerability Scoring System”. This is a method to measure the impact of a vulnerability. It uses a set of open standards to assess the vulnerability to ultimately assign a scale ranging from 0 to 10. Snyk’s database adds the following meta-data to it:
- Attack complexity: this gives an indication of how complex it is to attack a system that is exposed to the given vulnerability. The lower the score, the easier it is and the more likely it is that a hacking gains success.
- Confidentiality: this gives you an indication of what the impact is on the confidentiality of the system if an attacker exploits the vulnerability. If the score is high, you can expect a total loss of confidentiality. In the explanation, you’ll also find practical examples that help you understand this issue.
- Integrity: shows how what to expect in terms of integrity loss. An example would be the number or total amount of files that an attacker can modify (or delete) if he/she gains access to your filesystems or storage systems.
- Availability: provides (background) information on what the impact can be on the availability of your services and/or other (application) components in case the attackers launch (additional) attacks on your system. It gives you a rough idea of the seriousness of perceived downtime.
Other items which are relevant
Besides these four most important items, the following are also relevant. The attack vector (such as network or application), privileges required yes/no, and if yes, which privileges are needed. If an attacker does not need any required permissions, the risk is very high. And last but not least: user interaction shows you if any user interaction is needed. If no user interaction is required, the attacker can work “without the help of human beings”.
Snyk offers its own interpretation of the CVSS. For Operating System-related packages such as Oracle, also Oracle gives its view on the CVSS. Add to that, also NVD (National Vulnerability Database) from NIST offers their insights into it. It is wise to compare all interpretations and seek a common conclusion that is shared by all of them. This is useful to rule out discrepancies between them.
Malicious techniques
Every vulnerability contains information about the malicious techniques it uses to exploit an infected system. The following techniques highlight the key methodologies:
- Code injection: all about inserting malicious code to exploit security weaknesses to gain unauthorized access, data breaches, or execution of problematic actions.
- Data exfiltration: collection and transfer of sensitive data to systems that are under the supervision of the attacker. Leads to misuse of the data or privacy breaches. Very serious issue.
- Backdoors: getting access to the system by unauthorized entry points. These often enable data theft by means of remote controlling the system.
- Dependency confusion: swapping original packages with malicious packages right into the SDLC.
- Typosquatting: redirect unsuspecting users to fake websites or infected packages by means of registering domain names or using package names that are named almost similar to the original ones.
It is obvious that the more of these techniques are applicable to your application or infrastructure (components) the higher the risks are to get exploited.
Often you need to combine the information about the malicious techniques along with the CVSS as well as relevant background information (such as a detailed blog post about the actual context of the issues) to determine the criticality of your system.
Threat intelligence and fixes
Perhaps one of the most interesting sections of the vulnerability DB is the indication that shows IF and/or HOW you can exploit the vulnerability. You will find it in the Threat Intelligence block. If the “exploit maturity” is high, a code snippet exists to validate your source code to see what happens if you test the exploit in the way a hacker might do so.
Another key feature is the information about how to fix the packages which are affected. Sometimes the advice is to avoid any malicious instance of the package if there is no fix available. Another solution would be to upgrade the package in charge or apply a (runtime) patch to close the security gap. This gives you instant information about what you can do with it without searching the internet or other sources to take action.
Along with information on how to fix issues, you will also find more background information about the issue itself. You will also find references to external sources which explain the issue in more detail. Furthermore, some references also include an email address that you can use to seek advice.
Wrap up
There is a lot more to tell about the Vulnerability database of Snyk. In this article, you got a broad overview of the main features, the way the DB is set up, and how you can use it to your advantage. The main features were described and how you would interpret them. It’s great to have such as valuable source of information about the complex topic of application and infrastructure security. Hope you will give it a try once you encounter a new vulnerability in your source code.
