mobile logo

Search

The Biggest Misconception in Application Security

I’ve touched on this in previous articles, but it’s worth dedicating a little time to this misconception as it’s at the root of so many of the problems that organisations have with security and delivery. A common way to think about maintaining security while delivering software systems at pace is this.A diagram showing how not to think about application security.

Where rapid delivery of changes into production is one end of a scale, being secure is at the other end and, as an organisation, you pick where along the scale you’re comfortable according to your risk appetite. This makes intuitive sense – if your mental model of software delivery is like driving a car and you’re taking more risks with your foot down, going faster. The problem with this mental model is it’s completely wrong.

The same diagram as previously, with a big red X through it

Building software is one of the most complex human endeavours. It’s not possible to deliver applications at pace unless the software is of high quality. The slowest release cadence projects I’ve ever worked with have all been the lowest quality, worst designs and codebases and I’m sure you have the same experience. These low quality systems simply can’t be changed quickly. They will functionally fall apart if you try and everyone is, quite correctly, far too scared to try. Every change leads to unpredictable failures in an overly-complex system with:

-A big ball of mud architecture
-Incomprehensible code
-Global variables
-Specialist teams of developers, testers, architects and operations all handing off changes to each other with ill-defined responsibilities
-Poor functional decomposition You simply can’t deliver at pace unless attention to the non-functionals. Performant, interoperable, reliable, usable, maintainable and secure systems can be changed with confidence. They have:

  • A decoupled design that allows for simpler subsystems or components of the system to be changed independently
  • Code that is clear, understandable and functionally decomposed well
  • Comprehensive instrumentation giving visibility into the running system in test and production so that any aberrant behaviours are immediately seen
  • Delivery teams that are cross-functional with continuous responsibility for all aspects of the system so that quality, all quality, including security, can be assured continuously without slowdowns