Get in touch with vault

Make Security Go Away

Daniel Wessels
Reading Time: 4 minutes

Software builders often choose to focus on business and capability development only, leaving security of the software or system for a future date. We see today how this approach of “bolt-on later” (at best) and no security ever (at worst), is causing cybersecurity breaches. We do have to “Make Security Go Away”, but unfortunately we have done so (bolt-on later) in the wrong way and now need to retrain our software and system building practices.

The challenge is to “Make Security Go Away”, so that system engineers and software developers need not stop their business and capability development for security, but rather that it is part of their development life cycles automatically and thus happens seamlessly from their perspective.

When we look at this requirement for the first time, it may seem hard, so let’s look at how to start. For the security teams in organisations it means implementing shift left security practices and guard rails.

Shift Left and Guard Rails

Security teams need to understand that software developers are king. Developers are on the left side. A developer is most happy when they have requirements and their laptop to code. Once they have written their code on the laptop, they commit it to a source control system and wait for feedback. The quicker they get feedback, the better the developer productivity. The feedback will either result in revisiting the code committed or moving on to the next requirement.

This is thus where security needs to be applied too, on the developers laptop. The security tooling needs to be able to run on the developer’s laptop and provide feedback before it is committed to source control. Much of this will be static scanners such as SAST, vulnerability scanners, secure infrastructure as code scanners, cloud policies scanners, etc. The feedback from the tooling needs to have actionable information. Security teams have policies that need to be adhered to and the developer needs to be informed when they are hitting these guard rails and how to fix it. Too often it’s only when the developer’s code is deployed to production, where the policies are enforced for the first time, that things break and the reasons aren’t necessarily clear. In these situations both operations’ and developer’s time get absorbed in triaging what has gone wrong.

It is crucial that developers are informed of an issue as early as possible. Having to revisit code days or weeks after it was committed means additional time is taken to recall the understanding of the code. Also crucial is that the information provided is actionable. It is not good enough that they are simply provided with various lists of vulnerabilities in dependency libraries or generic guard rail messages, stating a policy has been violated. They need to be provided clear actionable information to remediate the issue. If it is not constructive information, it will eventually be regarded as unhelpful and ignored or circumvented.

Cloud Native approach

Cloud native does enable shift left and guard rails security practices to be implemented. At the core of cloud native are application programming interfaces (API). Security, operations and developers are able to commit their requirements to code. Once proven to be ready via the relevant delivery pipeline, it is deployed. APIs allow for a high level of automation of these development, testing and deployment workflows.

The security team can author the required policies to code and deploy it. Clear remediation instructions are part of the code the security author commits. A developer authors business code and scans it locally, after retrieving the latest security policies via an API.


Cloud native is an enabler to make security a seamless experience for developers. It is enabling organisations to define their security via code and provide tooling that tests these guard rails at the developer’s laptop. We can see that shift left is not just non production testing, but needs to go all the way left. We also need to have guard rails, with guide rails. 

If you would like to see an example implementation of these concepts, please share your details below and we will get back to you shortly.

Contact Information


Please also see:

Securing your Software Supply Chain

Defence in Depth

Revolutionising Australia’s Defence Supply Chain with Secure Cloud Services

Subscribe to our newsletter