Welcome to my new series: Pragmatic AppSec. It aims to provide security professionals at organisations that are AppSec curious with the necessary information to kickstart a program.

AppSec, whilst being extremely effective is frequently deprioritised, the success of it at an organisation is frequently dependent upon a single engineers willingness to drive it. It’s important to note that this series is based off my own experience and every business is different. The aim is to make this as agnostic as possible because AppSec is for everyone that has an App. I’ve been at large companies, medium companies and very small companies and have seen and implemented various versions of this. You will see me frequently talk about discovering business needs and appetites, this is an important aspect of any cybersecurity program: your solution needs to be right-sized to risk, resource and scale.

There is no specific profile of what makes a good Appsec engineer or leader. What you’ve done in the past just determines how much work you’ll need to do to give people the right information and support. That being said there are a few stereotypical archetypes within the Appsec sphere. I’ve outlined these below for posterity.

The former pentester: a lot of people in the field have worked in offensive security. This history shows in the way that they approach solving application security problems. I’d argue this strain of thinking dominates Appsec, sometimes to its detriment.

The compliance person: There is strain of compliance framework driven approaches to AppSec. This attracts a compliance centric archetype to the role. Again this background shows in the way the program runs and problems are solved.

There is nothing inherently right or wrong with these archetypes and their approaches will suit different businesses differently.

Fun fact: I don’t come from either of these backgrounds and a lot of the best Application security engineers I’ve met don’t either. To reflect this I figured I’d do my least favourite thing and talk about myself.

What is my background?

That’s a bit of a weird one, I started by studying tech at university and spent some time writing software. I very quickly discovered that I did not want to do that and ran to Systems Administration. This changed very early onto my career into DevOps and SRE and Security kind of just led from there.

The common thread woven throughout this is that I’ve spent a lot of time being close to engineers. DevOps and SRE was all about the product and engineering interface and Developer efficiency was my aim. My early security roles were all about securing developers either through building a product for them or working as a security engineer within Developer Platforms teams. Engineers productivity and safety was the ultimate deliverable for those roles.

As you will soon see successful Application Security requires working closely and considerately with engineers. Their productivity is the primary currency (aside from dollars) that we spend when we add security to a process.

Part 1 of this series looks at creating a common understanding of not only what AppSec is, but the establishment of an underlying map that helps guide you towards success. It’s not the most practical of the series but is certainly one of the most important. We are establishing the common language a.k.a the lingua franca of AppSec.

AppSec, rightly or wrongly, means a lot of different things to different people and that’s great! But for a program to work we need a common definition. Security historically was an afterthought, we built software and then worried about security. This is generally regarded as a bad idea, software is a brittle and fickle entity that will happily work its way around any badly structured controls. As the concept of SaaS became the predominate form of software consumption we quickly discovered through black eyes and breaches that we needed to change how we approached software security. Application Security or AppSec arose to fill this need.

If you asked most people what AppSec is the answer you will get is something along the lines of:

Application security is the practice of protecting software applications throughout their lifecycle by identifying, fixing and preventing security vulnerabilities through secure coding practices, automated testing tools, security reviews and runtime protection.

This is a great description of the kinds of tools and processes that are involved in an AppSec program but I would argue it really misses the crux of AppSec. Culture

I like to define AppSec as:

Application Security (AppSec) is the practice of empowering engineering teams to build secure software through architectural guidance and frictionless, well-integrated tooling that enhance delivery velocity rather than impede it. AppSec prioritises secure architecture and design guidance over tooling alone, with tools serving to support and execute that guidance effectively. Success depends on cultivating a security-conscious culture and communicating meaningful metrics tailored to both engineering teams (actionable technical insights) and management (business risk and program effectiveness).

Yeah, it’s a mouthful. I promise I will explain it better in the future.

Now this definition might raise eyebrows, for starters, shift-left happened and we are still dealing with the side effects of that. Why are we focussing on developers? Shift-left and historical approaches like it made a series of mistakes when attempting to involve developers into the security cycle; for starters developers are not security people. The approach I advocate for in the above definition and this series corrects these mistakes by ensuring that responsibility still lies with the AppSec function.

We are engineers as well and therefore need to be at the centre or at the very least operating within the confines of the engineering function at an organisation. Our aim is not to make security developers responsibility, rather we seek to encourage them to build in a manner that is inherently secure. This aim is achieved through guidance, involvement, understanding and consideration.

Whenever your thinking about how to approach this:

At the core of any AppSec program you should have three core aims/principles/objectives/goals whatever floats your boat. I’ve created the following acronym as a memorisation method.

Mould, Advise, Publicise - M.A.P

Each of these objectives sustain and nurture each other and will enable you to achieve whatever security/risk aims your company has.

What does this look like in practice? A virtuous cycle of success

Moulding a culture helps you identify opportunities to advise, these give you success to publicise which then encourages further cultural improvements. The self-sustaining nature of this cycle creates a positive feedback loop that ultimately drives you towards a successful AppSec program.

AppSec Engineer Billie has identified that we have a series of vulnerabilities within container images at the organisation that are persisting across multiple sprints. Billie has invested a lot of time with Engineering Team A.

Through conversations and pair coding sessions she has identified that the reason they struggle to patch vulnerabilities in their containers is because they are just too complex. Billie has provided the engineers with a safe space to talk about frustrations and can readily map her needs to theirs.

Billie offers to help them build better containers, focussing on the developer experience in communications. “Let’s make these easier for your team to iterate on these so that you can test our new versions of X language”

Through iteration and work (yes she might be actually helping make a container) Billie has helped produced a container that not only aids the developers in their aims but also reduces the attack surface and vulnerability numbers substantially.

This is communicated to engineering leadership as a win for developer productivity, to security leadership as a win for security and to engineers as a win for making their job easier.

Engineering Team B enjoying the benefits of Engineering Team A’s new containers, reaches out to Billie and asks her to help them with their build pipeline. Billie has identified that vulnerabilities within CI/CD are not being readily maintained.

And so on…

Thus the virtuous cycle sustains

Alright that’s enough for now

In future posts we will examine each of these pillars in detail and look at how we can build them out but for now keep this model in mind as we delve deeper into this.

Thanks for reading