4 ms·

> think that workflow patterns like Test Driven or Domain Driven Design will make their code inherently more secure But this is exactly the type of mistake tha

> think that workflow patterns like Test Driven or Domain Driven Design will make their code inherently more secure But this is exactly the type of mistake that government bureaucrats always make. They focus completely on procedure. There will be a whole bunch of boxes to check, including "this project uses TDD," "this project uses Domain Driven Design." Check them, and you are declared "secure." This is why such regulation will fail to provide any security, and will just slow down development. And the max government salary is around $170K, no bonus, no equity. It's not like they're going to be able to hire any competent engineers to write these rules. They even had to build the US Digital Service, which is basically a charity case (for the richest most powerful org on earth, lol) to even get their house partially in order.

cookiengineer 3y ago
I think the only way to tackle this problem in a scalable manner is if programming language maintainers offer formal verification of their programs. I don't think this will work in LLVM based compilers (due to the nature of how a backend compiler is being implemented for each platform and architecture), but maybe we should take a closer look at ADA Spark, or maybe we should try to focus our efforts on satisfiability resolvers that can point out common mistakes? Golang kind of made the right first step with their vulnerability checker that is AST aware and can point out methods and signatures that are known to be affected. There's also a lot of complexities behind decompilation aspects so I don't think C ABIs will be enough in the future, and a more data type aware format is probably needed.