How to profit from Vulnerability Lake?

The idea of the Vulnerability Lake is to provide a useful source of information about known vulnerabilities. Since 2020 many organisations - meanwhile over 300 - joined their strengths under the lead of the NIST to improve public knowledge about known vulnerabilities as official CNAs, CVE numbering authorities. These are organisations owning a certain range of CVEs where they can assign numbers to issues concerning their products. 

TrustSource currently is in the process of also getting a CNA registration to allow smaller companies to register known vulnerabilities in their software, so that reporting of CVEs could be done through TrustSource directly. This will simplify the CSAF-reporting required as part of the CRA.

So far the NVD, through formerly MITRE, meanwhile CISA, collect and curate the information supplied and offers this collection as data feed and API. Since a while we use this data stream in combination with other sources to assess your components for vulnerabilities. Given you have not blocked email form TrustSource, you might already have received emails whenever a new vulnerability enters that is affecting any of your projects components. See Vulnerability Alert for more details. 

Through our "Vulnerability Lake" we provide this data as a public source. You may use it to search for specific components versions, or providers. We support different types of search:

• Simple name search
• Expert search
• CVE search
• CWE search
• Subscriptions 

Simple Search

The simple search allows you to search for simple string. This may be useful, if you do not have much details about the implementation or the origin of a component or the component has a significant name. 

In the above sample you see the search for the string "wildfly" and the corresponding results. The results provide you a good insight onboard the matching issue. See how many findings there are. Some address more detailed components of the wildfly server, e.g. elytron, core or openssl. But then we also have general issues, an handful from redhat (redhat:wildfly) - the umbrella organisation - and an obscure "wildfly:wildfly" issue. 

However, with the string search you may get an idea of what else to look for or why a particular CVE may be in the database but has not been associated with the component you are looking for.

PRACTICAL HINT

We like to use the simple search to identify keys to watch for the subscriptions (see below). It will show you the list of available keys. Clicking on a key will switch to the Expert search, where you may narrow down by adding a version. Here you also see the "subscribe" button. This buttom allows you to add a key to the list of watched products. This is very useful, if your product uses additional infrastructure such as middleware, e.g. mongo or tomcat. 

Expert Search 

The Expert search is, what we use to identify matchings. Here you have the option, to search for specific versions of components. After importing the vulnerability feeds, we decompose the association information and make use of the given version ranges. This prevents us from assigning older CVEs to current versions. The Expert Search can profit from this.

The two images above and below show the difference of results when entering "redhat:keycloak" or "redhat:keycloak:22.1". While the first returns 76 findings - all that we have in the database associated to the organisation-product combination - the second only returns 3 findings for the version 22.1. The main version 22 still has 5 CVEs associated. Thus, you may see how relevant version information is for precise vulnerability association. 

CVE Search

We also support the search by CVE. Sometimes it is of interest to get more details on a specific CVE. Select the "Find CVE" search, to enter a CVE ID and learn more about the details of the CVE. You may have a look at the CPE data, the common platform enumeration, representing the given association information, the severity represented by the base score or further references. 

All these information can be used to get a better picture of whether the CVE really is of impact to your implementation. You may access this information directly from the Vulnerability Report, so that impact assessment will be simplified. 

A great tool to support impact estimation will be the attack vector. This is the combination of capital letters directly below the weakness information. The attack vector describes the requirements for the attacker to benefit from the vulnerability. The abbreviations mean:

• AV - Attack Vector:
  tells in what relation the attacker needs to be to the component to exploit the vulnerability. N stands for network, thus it indicates the attacker may exploit the vulnerability over the network.  Alternatives are the need to have access to the system, etc. 
• AC - Attack Complexity:
  The sort of skillset required to execute the vulnerability. The higher the complexity, the more unlikely the attack. 
• PR - Privileges Required:
  Identifies whether the attacker in addition will require already provided privileges to make 
• UI - User Interaction:
  Indicates, whether the exploitation will require a user acting or it can be executed programmatically, e.g. through a remote call.
• S - Scope:
  Helps to understand whether the impact will reach beyond the impacted component or remains local. U stands for unchanged.  
• I - Integrity: 
  Indicates the impact on integrity under successful exploitation.
• A - Availability:
  Measures the impact on the availability of the impacted system/component. H indicates "high".

You may find mir details on attack vectors and how to interpret them at FIRST - here a link to the spec in v3.1, which is the currently most commonly used version, while v4 already is released.

CWE Search

The Common Weakness Enumeration (CWE) is an identification for the weakness resulting from the vulnerability. The CWE details are more kind of static and will be more familiar to you as you continue to work with the vulnerabilities. The good thing is, that many clever people already have spent a lot of time elaborating all sorts of weaknesses and potential damages that may result from them. The CWE collection is a state of knowledge, that may be used to help you identify the impacts of a given vulnerability. Each vulnerability has one or more CWEs assigned (see above). By clicking on the CWE-link or by entering the CWE number in the CWE search, you may lookup the details.

While the CVE only provides the code of the enumeration, the search results will give you all the details of the weakness. Besides a nice name, you will find a description, consequences or more details on the impact that weakness may have and, in general, some information of potential mitigations. 

Subscriptions

The "subscriptions" section provides you with the option to receive personal vulnerability alerts when a specific component you add to the subscription list, will get a vulnerability assigned. You may use a simple keyword or a specific `org:component:version` string. 

In the example above there are two external components in the list, one with two different keys. Especially for 3rd party products such as runtimes, which most likely will not appear in your SBOMs, we highly recommend to subscribe here or add them directly as "module" to your project. This will help you to keep your application clean from vulnerabilities.

PLEASE NOTE: If you have disabled receiving messages from TrustSource, you will not receive such alerts. To check the status, please go to your profile (click on the person symbol in the upper left corner to enter your personal settings). There you have control over your communication preferences.

API Access

However, probably the most important might be that you may call the data through an API. This will allow you to check for vulnerability information in an automated way. You will find the details in the API spec. 

Please see also the Management of Vulnerabilities article for further information on how to analyse the impact of particular CVEs.