VRT entry for source code disclosure?See original GitHub issue
I’d like to propose a new entry to the VRT regarding source code disclosure. I’m thinking, for example, of scenarios where
/.git folders are left accessible on the server, allowing an attacker to download the entire source code.
These 2 VRT entries are similar/related: P1 > Sensitive Data Exposure > Critically Sensitive Data > Password Disclosure P1 > Sensitive Data Exposure > Critically Sensitive Data > Private API Keys
In many cases, disclosure of the full source code will lead to at least one of the above disclosures, but not necessarily. Even if there are no passwords or private API keys in the source code, the impact is still quite high.
I’d therefore propose something like: P1 > Sensitive Data Exposure > Critically Sensitive Data > Source Code
My only concern is that this wording might lead researchers to think, that companies’ public Github repositories, for example, are in scope - not the intention. Open for discussion!
- Created 6 years ago
- Comments:25 (13 by maintainers)
Top GitHub Comments
Hi @CarlosSimas28, I was personally hesitant to mark it as a “straight” P1, too. However, I think it can be argued that many other entries that are currently marked with a specific priority are also, if you think about it, “Varies”. Case in point:
- P1 > Sensitive Data Exposure > Critically Sensitive Data > Private API Keys
An API key disclosure by itself will also always vary in impact, depending on what service the API key is for, what level of access it has, etc. I would argue that compared to an API key disclosure, a source code disclosure will have more impact to a company. API keys can be rotated, but a loss of intellectual property in the form of source code is not reversible. In any case, I think this situation is common enough that there should be a VRT entry, and if we cannot come to agreement on priority, then having it as “Varies” is better than no entry. 😃
Sensitive Data Exposure has been the entry of choice for this type of issues,
Sensitive Data Exposure > Critically Sensitive Data would work too. We don’t see any significant benefit of adding a designated varies entry at the moment