## 5 Filtering and Searching for Information  
As described in earlier chapters, the VARIoT database contains data in a standardized structure gathered from differing sources. Unfortunately, discrepancies in the quality of the source data have resulted in data inconsistencies. To overcome this, we have developed a series of complex queries using Elasticsearch DSL (domain-specific language). To make it more user-friendly, a decision was made to implement an intermediary service that would simplify access to the data. The main requirements were speed and simplicity of implementation, ease of documentation and maintenance, and familiarity with the programming language. The major challenge was to deal with inconsistencies in descriptions of relevant hardware and software names and versions stored in the database. Our goal was to enable stakeholders to search data based on different sets of parameters, especially focusing on software and hardware version ranges, and to provide them with the means of searching similar and/or related exploits and vulnerabilities. To achieve said goals, we selected the Python programming language for its versatility and the FastAPI web framework for its asynchronous capabilities and simplicity in building robust, scalable APIs. The API exposes five endpoints for vulnerabilities and exploits each of them. Two endpoints are intended for pagination functionality, and another set offers different types of searches, such as using VARIoT ID, CVE ID, and full-text. However, the most crucial feature of the API comes with the two filtering endpoints that enable users to specify parameters such as model, vendor, version, date range, CVSS score range, CVSS vector string, or date of last update. In addition, the user can decide whether the API should return only entries with a CVE ID and CVSS score assigned or whether entries without these attributes should also be retrieved. A distinguishing characteristic of the VARIoT API is the ability to return entries that are similar and related to the ones found. Similar entries are entries associated with similar products, vendors, or vulnerability types. For this purpose, API uses the k-nearest  
Figure 10: Timeline of information about vulnerability CVE-2019-20499—command injection vulnerability in D-Link DWL-2600 AP. Yellow box is a highlighted earliest release date of exploit for this vulnerability. Black boxes are labels of release dates of other exploits. Green ones represents timestamps of vulnerability’s description release (darker ones) and updates (lighter ones). Red and pink labels refer to update dates of exploit and vulnerability entries in VARIoT databaseneighbour search algorithm provided by Elasticsearch. The algorithm finds the k nearest vectors to a query vector, as measured by a similarity metric. Entries are compared based on the description field value. As the algorithm requires vectorized data, we tested the following solutions mapping descriptions to vectors: all-mpnet-base-v2 [49], nmlm-en-dim128 [50], autotokenizer from Mistral 7B [45] and TfidfVectorizer [51]. All-mpnet-base-v2 gave the best results and, therefore, was used to create a separate Elasticsearch index storing vectors associated with individual vulnerability and exploit database entries. While searching for vulnerabilities or exploits, the user can indicate if he wants the API to return similar entries. If so, after gathering all the relevant database entries, the API sends an additional query to the vector index for each entry. Then, it merges both results and sends a single response to the user. On the other hand, related entries searching uses the linking of exploits with descriptions of vulnerabilities, which is described in more detail in Section 4.2. As a result, a user searching for vulnerabilities regarding a particular product can immediately receive corresponding exploits and vice versa. Figure 11 shows a diagram of the API and SocialPresenter (described in Section 5.1.1) architecture. The services are exposed through an Nginx reverse proxy.