There's a whole line of security thinking that is hard to understand from an open source perspective. I struggle to give it a charitable interpretation, but wou

There's a whole line of security thinking that is hard to understand from an open source perspective. I struggle to give it a charitable interpretation, but would say it tries to ensure code provenance and traceability of changes back to design requirements. I think this comes from a bureaucratic need to manage risk and liability concerns when the reality is that you can't really prove most code is correct or fit for purpose. When I am being more cynical, I'd say it is a form of regulatory capture. It creates moats where you cannot hope to compete and be in compliance as a small organization or loose federation of hobbyists. You need big budget, big organization scale to possibly deliver on all the process requirements alongside actual software development. And, I think there is a feedback loop where vendors of enterprise software security tooling are successfully warping the idea of what best practices and due diligence look like, so managers and compliance officers keep thinking they have to shovel more layers onto this to protect themselves.