It's not only that the CVE database / process is broken, but via EO 14028 in the U.S. and CRA in Europe transparency is mandated via SBOMs. While I believe this transparency is good, it can be abused to enforce compliance-driven security: Fix all critical, high and medium CVEs within well defined time frames. PCI DSS and many other standards kind of encourage that view already today. It will then just be measurable by outside parties, which then means the limited security budget will be used to "fix" things that don't matter as much.
And I agree with you, Lars: We should be using CISA's KEV, First's EPSS and other means. But I'm not sure software customers would accept seemingly higher risk (high number of unfixed critical / high CVEs), even if the EPSS suggests overall much lower risk.
I've written in longer form at [1] about this issue.
Adobe | Product Security Engineer | San Jose or Remote USA | $129k-$235k salary + RSUs + Bonus
Are you interested in creating Security As Code content that has the potential to reach thousands of developers? We are hiring for a product security engineer that is familiar with writing custom rules for an automated code review platform that includes Static Application Security Testing (SAST) and Software Composition Analysis (SCA) scanners. If you enjoy creating developer delight while also helping to increase the overall Securability of Adobe products you might be a great fit for our team.
And I agree with you, Lars: We should be using CISA's KEV, First's EPSS and other means. But I'm not sure software customers would accept seemingly higher risk (high number of unfixed critical / high CVEs), even if the EPSS suggests overall much lower risk.
I've written in longer form at [1] about this issue.
[1] https://florian.noeding.com/2023/08/29/sofware-bill-of-mater...