fix: Avoid FPs for Symfony Contracts as framework

[sigv]

Description of Change

Symfony Contracts are being matched as Symphony framework. However, they are different projects with independent versioning schemes. For example, CVE-2022-23601 for Symfony is resolved in versions 5.3.15, 5.4.4 and 6.0.4. However, Contracts project's latest version is v3.5.2.

Related issues

• fixes [FP]: Symfony Contracts are matched as Symfony framework #7545
• relates to Significant Increase in Loose CPE Matches After Upgrading from v11.1.0 to v12.1.0 #7444
• caused by fix: add product evidence as vendor to reduce FN #7295

Have test cases been added to cover the new functionality?

no

[chadlwilson]

Pro tip in case you’re not aware: if you branch from and PR to the file within the generatedSuppressions branch the suppression can be made available independent of an ODC release.

[sigv]

Pro tip in case you’re not aware: if you branch from and PR to the file within the generatedSuppressions branch the suppression can be made available independent of an ODC release.

Thank you, will keep that in mind!

[sigv]

@chadlwilson, does generatedSuppressions get pulled into main prior to release, to keep the bundled file up-to-date, or what is the standard flow for it?

I see gh-pages branch's suppressions/publishedSuppressions.xml gets updated from generatedSuppressions branch... but there seems to be divergence between what is in main and what is in generatedSuppressions 🤔

[chadlwilson]

Not via automation. It augments what’s in main for anyway that has not disabled use of hosted suppressions.

They are essentially two different data sources.

Hosted suppressions are auto-released any time a suppression is merged from the automated FP issue workflows (for which there is not one for php, but is for maven, gradle, dotnet, etc).

[chadlwilson]

The problem is that the hosted suppression changes can be used by all versions, yet changes to bundled only by those on latest release. People keep reporting FPs until they update to a given version which is a pain to keep track of as a project collaborator or even as user who is trying to minimize their own suppressions (which in many ends can require time limits and discussions with internal bureaucracy).

In my personal view there should be no bundled suppressions and everything should be done in the hosted suppressions, but that’s not a discussion I’ve seen had anywhere (or one I’ve brought up).

The two data sources right now create a risk of conflicting rules and too many combinations to think about when you contemplate all the various historical bundled suppressions that exist. Makes it difficult to investigate false negatives, inefficient suppressions etc.

[sigv]

This feels worth discussing as a future improvement, and I can understand the idea of shifting towards "hosted suppressions only". So I'm opening #7547 to make sure this is logged as a potential enhancement.