Bad software keeps cyber security companies in business

Coming from Enterprise Infrastructure World here, so take what I have to say in that context.

This post focuses more on hard-coded credentials, which are absolutely a problem, but seemingly glosses over the difficulty of programmatic secrets management in an organization. Sure, GitHub secrets are perfectly functional…until they end up hard-coding themselves into your pipeline on accident, at which point you get to spend a lot of time and money setting up HashiCorp Vault or similar. That goes great until human error meets the complexity of modern security software and development best practices, at which point human error wins again.

I would argue it’s not merely bad software from non-security companies, but also bad software calling from inside the house (said security companies). Bad agents that hoover up CPU cycles, feature overlap tangling themselves into knots with other programs, and products so complicated that nobody short of a mathematician and Cybersecurity expert could ever hope to comprehend what the various toggles and options are for, or whether it was deployed properly and securely.

Over on Mastodon, I gave a shoutout to the ACME-bot team for actually meaningfully advancing the state of security by making PKI as easy as 1-2-3 for most deployments; this is the security model we should be championing if we want a more secure environment. We need to promote simplicity and security over complexity and legacy support, or we’re forever going to be chasing down human error.

I sometimes joke that although I started life in real-time safety critical systems (compiler design, DoD Ada) I quickly switched to cyber security once I realised how hard that was and that most software was garbage and therefore improving the security of it would be like “shooting fish in a barrel”. Joking aside, complexity has increased, size has increased, the number of abstraction layers and the sophistication of those abstractions has increased, the degree of interconnectedness has increased. Not always with good reason. Now I tend to ask the question “How can we do this with less?”

I don't think it is hard to argue that it is less "bad software" and more "increasingly connected software environments" that is the driver here.

People have this odd framing where software mistakes are more basic and common than any other type of building. If you were able to do a similar audit for anything, you would see a growing number of seemingly basic things that are done wrong.

Which isn't to say that we shouldn't do what we can to make things better, of course. It would be nice if we weren't trying to connect more and more of our systems together, though.

I think of it more like, Cyber Security Companies' bad software keeps them in business. See e.g. this post on Dan Abramov's "Overreacted" blog: https://overreacted.io/npm-audit-broken-by-design/

Great post! I really enjoyed reading this, and can deeply relate to this on a personal level having worked in the developer security field for over a decade now (Stormpath -> Okta -> Snyk).

The only thing I have to add is that this same concept applies to just about everything -- it isn't just a cybersecurity industry problem.

- Bad writing keeps Grammarly in business - Developers doing a bad job at confirming to a codebase's style guidelines causes code linters and formatters to stick around pervasively - Bad authentication and authorization practices keeps Okta/Auth0 in business - ... <the list goes on and on>

Funny, it also keeps my consulting business in business. I really should send some of the larger megaconsulting businesses, especially the off shore ones that cost a fraction of normal market rates, a fruit basket some time.

As security tester I don't understand how hard is most basic authorization and access control be in systems. Do developers actually need my time to check if you can access something either unauthenticated or with different user. And then update something that I shouldn't even be able to... I admit what request updates is step forward, but still something that should be automatically thought about.

Or is it just move fast and leave things broken mindset?

Is it really that bad software is bad, or that just like building a house, you need a team of different specialists to make your software? If you hire one person to build you an entire house from scratch, you're probably going to have issues somehow somewhere.

Funny, it also keeps all compliance and standards folks in business.

_Useless complexity_ (aka everything must be a service@scale even if it's not necessary at all) keeps cyber security companies in business.