All Collections
Invalid vulnerabilities and false positives
Invalid vulnerabilities and false positives

How invalid vulnerabilities relate to the identification of false positives

Jaime Vasconcelos avatar
Written by Jaime Vasconcelos
Updated over a week ago

In security scans, Probely puts a great effort into avoiding false positives because they bring a costly overhead of manual analysis and resolution of vulnerabilities.

When Probely finds a vulnerability, a finding is created as "Not fixed". This state can change automatically or manually, as explained in the finding states article.

If a user manually changes the state to "Invalid", it means the vulnerability does not exist and is a candidate for a false positive.

This triggers Probely to proceed with further investigation to confirm it:

  • If it is effectively a false positive, Probely improves the identification of vulnerabilities so that it is no longer reported.

  • If not, Probely contacts the user to explain how the vulnerability can be exploited.

In some situations, a finding should not be considered a false positive (i.e., "Invalid") and should be accepted in the specific context instead.

For example, if a target uses Cloudflare with Transport Layer Security (TLS) 1.2 with the default configuration, the weak cipher suites enabled vulnerability is reported by the scanner due to the existence of the Cipher Block Chaining (CBC) weak cipher.

However, using TLS 1.2 may be acceptable to support a broader range of users for business reasons.

In this case, consider changing the state of the finding to "Accept risk".

Read more about how to change the state in actions on vulnerabilities.

Did this answer your question?