Security is everybody's problem: The key to breaking the AppSec barrier.

What’s the deal with AppSec?

The inherent separation between AppSec and other factions of an organization can make effective security enablement an illustrious and flighty target. In too many organizations, security is still the elephant in the room. And it doesn’t appear to be an elephant that many folks are ready to invite to their team lunches any time soon.

Stick a label on that elephant with the phrase “SECURITY IS EVERYBODY’S PROBLEM” in big red letters and send it stampeding through the general thoroughfare of your organization. Drastic? Yes. Will it solve your problem? Well, no probably not. The point though, is that until this shift takes place, your pathway to security enablement is always going to be uphill. 

Being security-enabled ensures that security skills are developed throughout the entire technical organization, helping businesses achieve maturity in their cyber resilience to defend against cybersecurity threats. This broader approach, of collaborative learning and development, means that the onus of security is shifted from AppSec and shared amongst the businesses community. 

While there is one team responsible for the entirety of an organization’s security measures, everything that team puts forward will feel like a deliberate blockade to any goal the business wants to achieve. Until everybody works together and unites under the same goal - security enablement will remain a pipedream. 

AppSec’s biggest problem

You all know the drill. The same issues are facing AppSec teams everywhere.

There’s a skill shortage, and even if there wasn’t, it’s highly unlikely that you’d be able to just hire a whole raft of engineers to get stuck in. 

Organizations are all at varying levels of security maturity. For however many organizations there are leading the way, there’s just as many (if not more) still stuck in the mud.

Manual testing is still king. However, you simply don’t have enough time or resources to make this practicable if your company is focussed on shipping more, and shipping it faster. In addition, by the time you’ve managed to convince anybody that there’s an escalating security issue requiring their attention, the attack surface has shifted and exposed three further problems.

Developers are still producing unsecured code. The solution? Slam them with red tape and lock down environments. That leaves you with bad-tempered devs and angry execs who were only trying to meet the overall goal of increasing release velocity. In all likelihood, there’s a chance that your devs are highly intelligent folks who can write their own products. In this instance, they could simply evaluate their code themselves and ship when they think their (potentially) faulty software is ready.

The impact of evolving security maturity

Security starts out, in businesses with elementary-level security maturity, as a luxury they can ill-afford. Moving upwards toward a more teenage phase of maturity, the focus is on checking the right boxes and doing just enough to keep product moving out the doors. In high maturity organizations, security is baked right in to all of your processes.

At the top end of the scale a high security maturity enables not just a likely “shift left”, but a complete shift in priorities - from speed of deployment and development to ensuring security is an intrinsic part of the company’s products and services.

It doesn’t matter how quickly you got the product to the end user. If it isn’t secure as per the requirements of XYZ they aren’t even going to give it a second glance.

AppSec, whether from a management or engineers’ perspective, is about providing the missing link in the broken chains between teams. You’re uniquely positioned to know not only how to break things, but how to fix those broken things to make them no longer broken. This enables AppSec to act as the passionate high-school football coach - pushing the team to enable delivery of a more valuable, higher quality, more secure product quickly.

The future of AppSec

We spoke with Brandon, a career AppSec leader at Unity3d, who said very candidly that “security needs to accomplish what QA did, by becoming a complete part of the development process and software team”. He discussed the culture of security, and the importance of ease of adoption for developers with any new testing environment or process.

From his position within an organization with a high security maturity, Brandon spoke about his current focuses. These involved leveraging technology and automation to scale the impact the security team can make. 

Despite AppSec traditionally being viewed as “the guys with the red pens circling errors and saying no”, Brandon said he finds that part of his role deeply unenjoyable. If we consider him as an engineer, in the very truest sense, it makes perfect sense that his joy within the role stems from knowing how products can be broken down and put back together effectively.

He believes in a culture of openness and trust, enabling developers and engineers to perform the work they need in environments that suit them. That means no red tape, or figurative red pens. It calls for a culture that puts the responsibility of security onto everybody, in a way that enables each person to hold up their own part of the overall mantle. 

Most significantly, Brandon talked about security being a craft that requires high EQ. The more we automate tasks and allow technology to take responsibility for routine aspects of our lives, the more prevalent the interactions and relationships between security experts and engineering become.

In a move toward greater security maturity, we are probably all looking toward automation of application security as our next logical step. However, we must never forget that in order to cross the chasm toward security enablement, we have to enable the people operating the machines as well as the machines themselves.

Interviews

Emma Stocks