## 3 Databases Creation
### Linking Exploits with Descriptions of Vulnerabilities  
Linking exploits with descriptions of vulnerabilities they abuse may help better assess the surface of possible attacks. It may give information about the target and the means of attack, including malicious payloads and a method of delivery. Such details may help protect one's infrastructure even if vulnerable software or hardware cannot be patched (for example, by deploying proper rules on firewalls or IDSs (Intrusion Detection Systems)). During our work on a system to link vulnerabilities with exploits, we encountered two significant problems. The first one is the common lack of additional information along the exploits' source code. Most exploits exist as a single file script or source code, sometimes with comments inside. Even if exploits are gathered in databases, like [[https://www.exploit-db.com/](https://www.exploit-db.com/)]([https://www.exploit-db.com/](https://www.exploit-db.com/)) (accessed on 13 October 2024), they are still presented with very little metainformation in a barely structured form, e.g., title, author, or related CVE. The vulnerable product name is only shown in the title in a human-readable format without separating vendor, product, and version data. There was a notable exception, namely exploits listed in the BID database, which provided both vulnerabilities and related exploits with external references and affected configurations. However, new entries stopped being added in July 2019, and the database is no longer available on the Internet. To overcome the problem of linking vulnerabilities with exploits, we came up with a solution based on regular expressions to find URLs in each exploit listing to create a list of potential references. Any references explicitly given by the exploit source are also added to the list. Then, we search for URLs referencing identifiers from over 40 websites listing vulnerabilities, exploits, and security advisories, such as CVE, US-CERT, Zero Day Initiative, Exploit-DB, Packetstorm, and others. If we find such an identifier in the exploit's content, we can assume it is related, and hence the list of related external identifiers is created. The same process is also done for vulnerabilities; however, in this case, there is no need to search for URLs in the descriptions since they are already available as the reference lists in the source listings. Vulnerability entries related to the given exploit can then be found using these identifiers, and we assume that a vulnerability is related if it also references at least one external identifier present in the exploit entry. An example of such extracted identifiers is presented in Table 4.  
Another problem with linking data this way is the volatility. We need to constantly monitor vulnerabilities and exploit sources, as information may be added, changed, or deleted, which may lead to changes in the links between them. Therefore, the extracted URLs and identifiers from other databases are stored together with entries from which they were extracted and are updated every time the original data are updated. We want to avoid making changes to the exploit database while updating the vulnerability database and vice versa, so the related entries lists are not stored statically in the respective databases. Instead, the list of related vulnerabilities (or exploits) is created on demand when the user retrieves information from our database. It ensures that all the information about exploits, vulnerabilities, and their relations is up-to-date. An example of such linking information is presented in Figure 6.