Welcome to my new blog, I’ve ditched a CMS and switched to a static site enjoy…

Developers suck at security, so we should reduce their involvement in the process - Security person, 2021

Also, one month later;

That DevSecOps stuff sounds tasty, we should shift security left - C-suite person, 2021

I largely imagine the transition of strategy in organisations as a series of quotes in complete contrast to each other. One technical person says something, then an executive says the opposite.

As security practitioners we have a problem and it’s a pretty bad one.

We can’t get basic shit right.

And we are really good at coming up with excuses and pointing fingers at developers or end users. This just doesn’t cut the mustard anymore.

I have the advantage of working for a company that has access to swathes of data about the basic security state for a multitude of public web applications. Without hyperbole it is abysmal, basic controls such as CSP, HSTS and even the enforcement of TLS are lacking or poorly implemented. This is purely based on OSINT. I can’t imagine what authenticated insight would reveal. Oh and the cloud makes this a thousand times worse.

I do promise however this isn’t just the standard we can’t do basic shit right whinge. We all know what we need to do, things stop us from doing it.

I am here to say I think part of the problem lies with how we interact with the development function of our own and other organisations. Security tends to be built around the concept of removing responsibility from developers, regardless of our intent. We then proceed to deride them when they make mistakes. This runs in stark contrast to the fact that our role largely exists to secure the apps they create. Without them we are nothing but an unnecessary cost centre. I’d also like to iterate this is not my view alone, other people have said this before.

What I’ve done is coin a term for it: Shitting Left - at least I think I have

You see shifting security left and integrating it early and often is important, but we actually have to do it. Unfortunately, in practice it’s become a buzzword. What we have in a reality is security teams shitting on development teams, removing tools from their purview and wondering why it’s all going wrong.

I am going to a take a medical view of the problem and diagnose, treat and prevent all in one post.

The symptoms of shitting left:

  • You’re telling your developers to fix problems, vulnerabilities, weaknesses
  • Developers aren’t identifying problems, vulnerabilities, weaknesses
  • Developers don’t have the tools to identify problems, vulnerabilities, weaknesses
  • Developers are divorced from the implementation of security technology e.g. HSTS, Encryption etc…
  • You blame the developers when things are found (hence shitting)
  • Developers are not being taught how to fix things
  • Execs say you’re shifting left whilst all of the above is present

Treatment and Prevention:

  • Consume 1x attitude adjustment when it comes to developer interaction, repeat as needed.
  • Utilise 1x development toolset, this includes committing code, understanding sprints, understanding software development practices.
  • Engage 1 or more development team as an extension of your security practice.
  • Implement 1 or more tools at all layers of the development cycle and;
  • Involve 1 or more development team in the use of aforementioned toolset.
  • Implement 1 or more guardrails to guide development team members whilst not divorcing them from the problem domain.

Contraindications for Treatment:

  • Unwillingness to change

More to come on this topic.