SBOM tab: add match condition filtering

[reh-sfl]

Fixes # by...

Changes proposed in this pull request:

SBOM tab: add match condition filtering

Status

• READY
• HOLD
• WIP (Work-In-Progress)

How to verify this change

1. Open the web dashboard, go to SBOM tab.
2. Enter cvss >= 9 in Match condition then click Apply.
3. Click Show Vulnerabilities for one package.
4. Confirm only vulnerabilities for that package satisfying cvss >= 9 are displayed.

The PR supports the following conditions, the same as those supported in the reports and CI mode:

cvss_min >= 7
epss >= 50%
effort < 3600
effort_min <= 1800
effort_max >= 7200
fixed
ignored
affected
pending
new
not fixed
cvss >= 7 and pending
cvss >= 9 or epss >= 50%
id == CVE-2014-6271

A zero-result condition is valid. For example:

cvss > 11

This also supports nested Condition

((cvss >= 9.0 or (cvss >= 7.0 and epss >= 30%)) and (pending or affected))

When you input invalid Conditions you will get an error:

unknown == 2
true == true == true
true == true and
cvss > CVE-TEST-0001

Finally, click Reset Filters and confirm the condition and filtered results are cleared.

Pull Request Checklist

Please review and check all that apply before submitting your PR:

• The code compiles and passes all tests
• All new and existing tests are passing
• Documentation has been updated (if applicable)
• Code follows project style guidelines
• No sensitive information is included
• Linked relevant issues (if any)
• Added necessary reviewers

[ValentinBoudevinSFL]

The feature is well covered, but it currently introduces a high-cost server evaluation path, accepts undocumented ordering literals, and can display stale asynchronous results. These issues should be addressed before merge.

[ValentinBoudevinSFL]

The condition is parsed again for every item because parser.evaluate(condition, ...) receives the source string inside the loop. At the permitted 50,000 items and 1,000-character conditions, one request can trigger tens of millions of parsing operations and become a CPU DoS vector. Parse and validate the expression once, then evaluate the parsed representation for each item's data.

[ValentinBoudevinSFL]

Ordering comparisons pass unknown_as_literal=True, so an unknown RHS is accepted whenever the left value is also orderable as a string (for example, id > TYPO performs a lexical comparison). This contradicts the documented rule that literals are only allowed with ==/!= and can hide typos. Evaluate ordered RHS expressions without unknown_as_literal.

[ValentinBoudevinSFL]

An in-flight evaluation can restore stale results after vulnerabilities changes: the effect clears the IDs, but the old request later resolves and calls setMatchingVulnerabilityIds. Multiple requests can also complete out of order because Enter remains active while the Apply button is disabled. Track a request generation or use an AbortController, and ignore results when the vulnerability snapshot or latest request has changed.

[ValentinBoudevinSFL]

Great design, but cvss condition doesn't seem to work.

[ValentinBoudevinSFL]

The filtering flow is mostly coherent, but drill-down filters can become stale after vulnerability data refreshes.

[ValentinBoudevinSFL]

The matching-ID snapshot remains stored after drilling down, while TablePackages is unmounted. A subsequent vulnerability refresh therefore leaves TableVulnerabilities filtering fresh data with stale IDs. Clear filterVulnerabilityIds when the vulnerability snapshot or scope changes.

[ValentinBoudevinSFL]

The feature looks good to me (cvss works now).

But the frontend need to receive some clarity:

1- Search Syntax is only applicable to the search bar, should stay next to it
2- Add another information mark next to match condition to provide some explanations
3- We need to find a way to make obvious the fact the Apply button is only for Match Condition and not the search bar

[ValentinBoudevinSFL]

Frontend looks good
Match condition field looks good

But, it doesn't respect dod with "Dod: We have an efficiant way to get all remaining assessments to do based on a generic condition"
After this match condition entered I should get a new column, or something else, to get the quantity of Vulnerabilities per package which match this condition.
Right now, it only get rid of the packages which doesn't have a vulnerability which respect it

[reh-sfl]

@ValentinBoudevinSFL I added an small design change to the existing Vulnerabilities to indicate a match condition count, details shown when you hover.

[ValentinBoudevin]

LGTM can you just remove the column "remaining pending vulnerabilities"