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.
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
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}
I was thinking about allowing a URL directly. In any event, to find things, a URL is pretty helpful most of the time.
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.