Vulnerability attribution support in CEL Policy

[VinodAnandan]

Vulnerability attribution-based CEL policy is a way to automate the handling of vulnerabilities based on the source that reports them and related attributes. This can be useful for reducing the number of false positives and ensuring that only the most serious vulnerabilities are investigated.

In this example, the policy would automatically suppress a vulnerability if it is only reported by one source and not by the other three sources (OSV, SNYK, and Github). This is because it is possible that the vulnerability is not actually a real problem, or that it is a false positive. By suppressing these vulnerabilities, we can save time and resources.

Conversely, the policy would automatically escalate a vulnerability if it is reported by multiple sources. This is because it is more likely that the vulnerability is real if it is seen by multiple sources. By escalating these vulnerabilities, we can ensure that they are investigated promptly.

This type of policy can be helpful for security teams that are overwhelmed with a large number of vulnerabilities. By automating the handling of some of these vulnerabilities, security teams can focus their resources on the most critical threats.

[skhokhlov]

I love this feature, it can dramatically decrease number of false positives. But also I see a case that some security team can identify vulnerability, and it is not available from other sources yet. In this case there will be a gap

[mehab]

Your point seems valid to me @skhokhlov . It seems though that we could have this policy include a time factor on it so that it is more accurate and also helps sources that have found the problem first like you mentioned.
In that approach we could automate the suppression of vulnerabilities that have been reported by only one source, say for example, for a month.
On the other hand if there is a vulnerability that was just reported by Snyk yesterday then this could continue to be highlighted on the system as, lets say, "in triage" status until it is either confirmed that it is a real issue (and found first by Snyk) and then we do not suppress it. Else, if it continues to be flagged only by Snyk for a whole month and might be a false positive in this case, we can suppress it automatically.

This period of how long a vulnerability is pointed by a single source only until we mark it as false positive can be user configurable to the time period of his choice.