Title: ERC_7731__Vulnerability_and_Exposure_Identifier
Category: ERCs

Author: dimitrysc
Date: 2024-07-08T13:16:00.650Z

Currently, there is no clear, common language to specify vulnerabilities in crypto. Ethical hackers often refer to vulnerabilities using a combination of “Protocol Name + Exploit,” which can be very confusing, especially when multiple attacks occur on the same protocol.
To reduce communication costs between protocol developers and ethical hackers and build on the security practices of Web2, we propose the VE (Vulnerability and Exposure) identifier. This EIP allows any organization or individual to maintain its own VE on-chain, standardizing the language used to describe and report vulnerabilities.


github.com/ethereum/ERCs








Add ERC: Vulnerability and Exposure Identifier


master ← SecurFi:master



          opened 09:31AM - 30 Jun 24 UTC




            dimitrysuen
          



+182
-0






To address the absence of a standardized reference method for vulnerabilities an…d to reduce communication costs between protocol developers and ethical hackers, this ERC proposes a rule for creating unique identifiers for vulnerabilities. The aim is to establish a common language in these scenarios.

Author: chaals
Date: 2024-08-08T07:50:59.745Z

I like this.
I’m editor of the EEA EthTrust Security Levels spec, a maintained specification of known vulnerabilities for Solidity Smart Contracts. In that spec we currently use a URL to identify each vulnerability. That means we don’t have a mapping that would readily fit the veId field (and consequently nor the refVeId), which isn’t geared for a URL.
We could edit our spec to add a numeric identifier to each entry, enabling something like “ethtrust-2024-0043”, but I wonder if you would instead consider changing the reqiurements to allow a valid URL as a veId. Most descriptions of security vulnerabilities (e.g. CVE) have a URL because they are actually published as web content, and having that would (IMHO) enable simpler lookup than having to go through some mapping table.
I can make a PR against the current draft to clarify, if that helps

Author: dimitrysc
Date: 2024-08-15T19:07:50.216Z

Hey Chaals,
Regarding your mention of “allow a valid URL as a veId” - are you referring to a link to a requirement or a newly discovered vulnerability?
We prefer using veId for a couple of reasons:

ethtrust-2024-0043 is much easier to read and reference than a URL.
URLs can become outdated over time. We believe that using IPFS to store vulnerability details is a better approach. The content-addressing feature ensures that the content retrieved using the reportCid is always complete and not tampered with.
Some security teams might only manage internal veIds and not publish URLs.

I had an idea about the URL format: perhaps we could have a fixed URL pattern or method that allows users to derive the corresponding vulnerability URL from the veId, such as following the fixed URL pattern:
https://entethalliance.github.io/eta-registry/ve/{veId}

Author: chaals
Date: 2024-08-19T11:38:24.619Z

I was thinking about allowing a URL directly. In any event, to find things, a URL is pretty helpful most of the time.



 dimitrysc:

I had an idea about the URL format: perhaps we could have a fixed URL pattern or method that allows users to derive the corresponding vulnerability URL from the veId, such as following the fixed URL pattern:
https://entethalliance.github.io/eta-registry/ve/{veId}


Hmmm. URLs sometimes change, but well-maintained systems make sure that’s a unicorn event. And unfortunately IPFS can also lose content over time.
There is a standard way of putting things in well-known URLs defined by RFC 8615 - RFC 8615 - Well-Known Uniform Resource Identifiers (URIs) - so if we are going to make a pattern, that’s probably good to follow. Note that it means registering a service name, but that’s fairly simple, and a common thing to do in standards work.

Author: SamWilsn
Date: 2024-08-29T15:36:04.514Z

Why not get CVEs directly? What’s the advantage of maintaining a parallel registry?