Closed tristanlatr closed 4 years ago
The table value is one thing. What would be your expectation for the exit codes? In our scenario we alarm on the exit codes.
I think the exit code should only count actually vulnerable plugins, so if the plugin version could not be determined, that would not affect the exit code
Sorry I didn't how exit code where linked to vulnerabilities. I think the exit code should be 12, like outdated. You could change the documentation to say :
Outdated or potentially vulnerable => 12
I don't think this is useful. Think of an automatic scan that runs every day.
Let's assume, you have a plugin for which the version cannot be detected. The scan result will yield a exit code of 12 even thought there's nothing you can do fix it. In the long term, you will start to ignore the scan results and probably miss a real vulnerability.
I guess, I need to think about this some further. I will check this during the week-end.
I've decided to introduce a new exit code "14". Even though this might break current applications, because the exit state contract changes, I think it 's unreasonable to use the same exit code for two different things. Especially because the communicate different meanings. Please check against master, if this suits you and comment or close the issue accordingly.
@tristanlatr Have you had the chance to check the change?
When a plugin version could not be detected, all known vulnerabilities are listed in json data. These vulnerabilities are only potential and the plug in might not be actually vulnerable. The table should say "Potentially vulnerable" as a result I think.