4 ms·

When we review vulnerabilities in our dependencies we classify their likelihood of being exploited, and their potential impact on the business if they were expl

When we review vulnerabilities in our dependencies we classify their likelihood of being exploited, and their potential impact on the business if they were exploited. Based on these we have a matrix that outputs an overall low/medium/high risk and that lets us prioritise reporting and fixing on medium/high issues. Works well for us. YMMV. (Making something up here) CVE: OpenSSL: RSA is broken Likelihood of exploitation: high Impact on our business: none. We migrated off RSA years ago. Overall risk: Low

WrtCdEvrydy 6y ago
Yeah, we've had this as well... for example, if you're running a certain version of node, you might have a CVE on the crypto module but if your API just accepts some data, processes some data and writes it to a local file without using crypto... are you really vulnerable?
- Sebb767 6y ago
  It depends. Of course, if i.e. a malicious ciphertext can do an RCE, the app right now is not vulnerable. But at some point you might let the user backup his encrypted data and restore it. You colleague knows you already have the code, it's only decrypting the data, you checked it for security, what could go wrong? Of course, you shouldn't panic just because this issue exists, especially if you know it does not affect you right now. But leaving this unattended, especially without the huge exclaimer that you can not accept untrusted ciphertext, can easily come back to bite you. Maybe it was exactly what caused this (theoretical) issue in the first place.
thaeli 6y ago
An overall risk of "low" is incorrect here. The risk is "none" because it's not applicable to your environment. Or do you consider "low" a won't fix / not applicable categorization?
- yardstick 6y ago
  Could use none. Low because if something changes elsewhere and we inadvertently start using RSA by accident, for example. But yeah if it’s not med/high it’s not necessary to fix. Maybe some mitigation where appropriate.

WrtCdEvrydy 6y ago

Yeah, we've had this as well... for example, if you're running a certain version of node, you might have a CVE on the crypto module but if your API just accepts some data, processes some data and writes it to a local file without using crypto... are you really vulnerable?

Sebb767 6y ago
It depends. Of course, if i.e. a malicious ciphertext can do an RCE, the app right now is not vulnerable. But at some point you might let the user backup his encrypted data and restore it. You colleague knows you already have the code, it's only decrypting the data, you checked it for security, what could go wrong? Of course, you shouldn't panic just because this issue exists, especially if you know it does not affect you right now. But leaving this unattended, especially without the huge exclaimer that you can not accept untrusted ciphertext, can easily come back to bite you. Maybe it was exactly what caused this (theoretical) issue in the first place.

thaeli 6y ago

An overall risk of "low" is incorrect here. The risk is "none" because it's not applicable to your environment. Or do you consider "low" a won't fix / not applicable categorization?

yardstick 6y ago
Could use none. Low because if something changes elsewhere and we inadvertently start using RSA by accident, for example. But yeah if it’s not med/high it’s not necessary to fix. Maybe some mitigation where appropriate.