4 ms·
I always lobby actively for golang because of this. Golang is a "batteries included" language ecosystem, where golang.org/x is the package that implements almos
by cookiengineer 3y ago
I always lobby actively for golang because of this. Golang is a "batteries included" language ecosystem, where golang.org/x is the package that implements almost all RFCs you could ever think of.
In most industries that I worked in, management folks do not understand how graciously they have fucked up for politicians to care about something unmeasurable as cyber security.
A lot of developers I have spoken with think that workflow patterns like Test Driven or Domain Driven Design will make their code inherently more secure. Even when you point out absolute rookie mistakes like missing sanitization of user input they're always smart-assing you about how this will never affect anything that they built. If you then point out RCEs in libraries they keep reintroducing for whatever opinionated reasons they deflect the blame upon the random guy on the internet that built this library on the weekend.
I am glad the US made the first move after the pipeline incident, and I am glad that government projects started with SBOMs. Why? Because it showed up how little companies know about their risk management of operational dependencies.
It's easy to blame the log4j maintainer, but it isn't easy to blame the guy for a mistake that he made more than 20 years ago, and fixed it meanwhile while already documenting it. Because that is totally upon software/development managers and the total lack of quality assurances and testing in their workflows.
And that is talking only about something as easily fixable as a java dependency in your xml file.
Imagine how messed up security could be if there's a babel library affected, and joyent would not hard-fork it to force-fix it for everyone. There's no way to guarantee anything in npm, by nature of the pre/post hooks in its package manifest format.
- fallingknife 3y ago> 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 agoI 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.