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.
The idea with multi-cycle memory was to create a special challenge for myself. Also I thought about using the same technique would be useful if I later on wanted to have mul / div in hardware, which would take a couple of cycles too.
I'll think about sharing the code. Large code parts - while working - did not pass my quality bar, since I did not have enough time to clean and refactor while learning. But maybe that's fine. Hmm.
I always wanted to understand how a CPU works, how it transitions from one instruction to the next and makes a computer work. So I thought: let's implement one and run a C program on it.
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...