Vulnerability Indexing & Assessment Logs (VIAL)

Try it out!


In 2016, there was some dissatisfaction within the cybersecurity community with the drawn-out nature of the CVE allocation and publishing systems. This led to community-led proposals for CVE alternatives including the Openwall Vulnerability Entries (OVE) and the now-abandoned Distributed Weakness Filing (DWF) systems.

Both of the above systems aimed to address the speed of Mitre's assignment and verification process: OVE did so by making it extremely cheap to publish an entry (clicking a button would generate a unique identifier without human intervention) but risked introducing spam and invalid vulnerabilities into its network - DWF attempted to address these issues by having distributed verification entities which would be closer to the vulnerability (i.e, working as a maintainer or having extensive subject knowledge), and introduced a twist in its protocol by suggesting that the vulnerability entries' database could be hosted on a blockchain.

Neither of these alternatives to CVE found widespread adoption and subsequently faded from public view (or merged with vulnerability database aggregation projects like Google's OSV 'database for open-source').
Over half a decade later, I stumbled upon the original LWN post and was intrigued by the idea of having a vulnerability tracking system that would both reduce reliance on individual providers such as Mitre (CVEs) and GitHub (GHSAs) and the minimize any incongruity that attempts to interoperate with more than one of those systems have been found to introduce, so I decided to make my own vulnerability tracking system that would be capable of linking to existing providers' records whilst maintaining an independent copy of records that could be modified, updated, or corrected with ease.

System Structure

At the core of VIAL is a HTTP API written in Python 3. This API has endpoints for adding, publishing, modifying, and viewing specific vulnerability entries as and when the user requests such an action (either through a web interface or by sending HTTP requests to the API).

A major goal of this project was to minimize the cost and dependencies required to operate VIAL in its entirety over a long term (due to how frequently alternatives such as DWF were seen to be abandoned). To that extent, the user-facing aspects of the Web UI (viewing and enumerating entries) are able to function independently of the Rest API through the techniques outlined below.

Adding a New Entry

When a new vulnerability needs to be added to the database, the following occurs:

This process is essentially language agnostic (but was implemented in Python 3) and essentially all of the key steps above could be emulated with a bash script or your favourite API testing tool.

bash dig Retrieving VIA entries via Linux terminal
$ dig -t TXT ; <<>> DiG <<>> -t txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10463 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; ANSWER SECTION: 300 IN TXT "bafkreicgoaz2sfvy4yfcqfg5olwaic5kswvpcxuha7l4laevi6scp4w4zq" $ ipfs cat bafkreicgoaz2sfvy4yfcqfg5olwaic5kswvpcxuha7l4laevi6scp4w4zq { "VIA-1": { "cid": "bafkreihc2qfourone4ofe5m4lqc6c36xfmehd54mu6x5ckrjcemjnrfzyy", "status": "PUBLISHED", "key": "53514d6d5f2d3445766c432d3568425a706f6b425a3166636c47706a46737250532d5642426d424c4a30733d" } }

Publishing an Entry

In order to publish an entry, the symmetric key used to encrypt the entry's JSON is simply attached to its listing in the entrylist which is reuploaded and pinned.

Browsing/Viewing Entries

Despite it being possible to view entries using the API outlined in the previous sections, doing so would mean that a server/device would need to be running 24/7 to serve such information which isn't ideal. To get around this issue, the viewing/browsing webpages have their own JavaScript code that handles manually retrieving, parsing, displaying, and interacting with VIA entries via the IPFS network without hosting a own backend server.

The client-side JavaScript is only half of the solution as IPFS can only guarantee data's presence when it is 'pinned', and therefore a pinning service (PiƱata) and IPFS gateway (the official gateway between the typical HTTP internet and the IPFS network) was used.
As a result of this setup, it's also possible to view unpublished entries by including the hex decryption key in the view.html url, meaning that it's possible for an entry to be viewed by specific people via a 'magic link' containing the decryption key and VIA ID.

Final Notes

While I haven't released the source code to the backend system publicly, the viewing and browsing frontend is available for public use at The information provided in this post should be enough for anyone interested to develop their own version.
Additionally, it is worth noting that in an attempt to mitigate any ciphertext size-based attacks, the API appends a CSPRNG-generated number of space characters into the JSON of all VIA entries, meaning that any attempts to derive information about the plaintext's key fields based on the ciphertext block size should be invalidated due to cryptographic implementation's block rounding combined with this additional 'postfix' protection.