3 ms·
Something I thought about is because you're representing vulnerability disclosures on the blockchain you can cryptographically prove when bugs were first brough
by Uptrenda 10y ago
Something I thought about is because you're representing vulnerability disclosures on the blockchain you can cryptographically prove when bugs were first brought up and when they were fixed.
So re: forcing the vendor to patch software.
When the contract is formed the vendor can specify a section for collateral that he gets back progressively from good behavior (I.E. fast patches.) If the vendor fails to continually patch software within an acceptable time-frame, the smart contract can be made to automatically use some of the vendors collateral to hire security auditors (or donate the money to a pre-defined DAO for researchers.)
This thus signals to customers that vendors are willing to stand behind a certain level of quality assurance for the patch release cycle. Whether or not a vendor will abide by this - I have no idea. But it may be that in the future good researchers will only want to work with vendors whose responsibilities within the industry are represented by a smart contract that will protect them from bad experiences. So vendors may end up being brought on board with this too.
I'm not sure what you mean by the attack issue, by the way. You can specify within the contract a reasonable time-frame for exploits to have been disclosed before they were revealed to give the vendor time to patch any problems. Obviously any researchers who want to work on that software will have to agree to the terms of the smart contract before they start. So everybody is in agreement with disclosure time-frames, payment rates, etc.
Thanks for the awesome feedback :)
By the way, you just gave me another idea. Originally the section for private exploit markets was more focused on the deep web. But it just occurred to me that there is actually a legitimate reason to use zero-knowledge proofs in this protocol for the bug bounties. Namely that the existing model depends on having to wait for an exploit to be fixed before a researcher is paid and they might not want to wait for that.
So to prove to the network that an exploit works without disclosing it (and thus frustrating the vendor) you use a zero-knowledge proofs. Thus the network can validate that the exploit works without getting access to it so that the payment can be released earlier even before the vendor has finished the patch.