The presentation with a simple diagram that combines this data with an sbom to yield "information" gives me navel gazing vibes of UML being the future of coding.
Just as architecture didn't equate to well designed and maintainable software, I fear this initiative won't fix horribly outdated and vulnerable deployments. Software life cycle, deprecation, abandonment, supply chains are mostly a process problem, standards and technology won't fix that.
In other words it doesn't force you to add an SBOM + EOX checker step to your CI pipeline. But if your compliance auditor wants you to check your dependencies, adding such a standardized step makes it easier to satisfy the auditor.
Rarely have I found that compliance to the goals was an issue in themselves. Or that making changes to tick a checkbox correlated to material improvements.
That is to say that if this leads to more efficiency and makes it easier for compliance audits and such, I fear is stream lining the least impactful part of its goals.
I am confused when I hear people say stuff like this. I guess if you turn on a tool and never look at it again, it won't result in material improvements. But complying with regulations or a particular compliance regime should _absolutely_ result in at least _some_ material improvement to your security posture. Like you can implement segregation of duties just as a checkbox, or use the requirement to revisit the way you gate changes to production, as just one example.
I am very much hoping the effort succeeds, but I am also mindful of the fact that the site to which I have linked is more successful by virtue of having better coverage.
feldrim•6h ago
rollcat•5h ago
"Oh, just write plain C". Which compiler do you mean? GCC? LLVM/clang? On top of what OS/kernel? What firmware? Etc.
Arnavion•4h ago