Building trust: The path to true security synergy between AppSec and developers

A version of this article appeared in Cyber Defense Magazine. It has been updated and syndicated here.

A relationship that is built on the shaky foundations of mistrust is, well, best approached with low expectations. Sadly, this can be the state of the working relationship between developers and the AppSec team within an organization. Generally frosty and marred by a tendency to get in each other’s way, the situation is not ideal and leads to poor outcomes in a world of high-risk dependencies on technology.

Developers thrive on problem-solving, building features, and showing creativity in their work. AppSec, on the other hand, has the unenviable task of finding security bugs in their code, bouncing it back for fixes, and providing audits and reports that spoil the shine on the engineer’s pet projects. It’s not fair to put the blame solely on developers -- security is not their priority or part of their KPIs -- nor can the overworked AppSec team be penalized for simply doing their job. However, for cybersecurity best practices, and better security outcomes at the organizational level, they really need to start playing nice.

And it all starts with trust.

AppSec’s “bad guy” image stands in the way of DevSecOps harmony.

If your only interactions with someone come when they are pointing out where you’ve gone wrong, chances are good that their input won’t be looked upon favorably.

Rarely seen unless there is a problem, the negative connotations of the security team’s presence tend to cause some friction. The relationship has been fractured for quite some time, with developers seeing the AppSec team as blockers to their creativity, process, and punctual shipping of features, while AppSec grows very weary of continually pointing out common security bugs that have existed (as has their remedy) for decades.

With increasingly impossible deadlines, under-resourced teams, and a strong desire to avoid rework, developers would often wait until the last possible moment to ship their code, making the window of opportunity for AppSec review and intervention as small as possible. A dysfunctional process, and it has an unacceptable impact of increasing cybersecurity risk to the organization.

For security specialists, it’s a case of “don’t shoot the messenger” - after all, their job is to find bugs and report them so they can be remediated - nothing personal. The sticking point is that they can often make recommendations that are not the best fit for the company’s technology stack, so can be seen as largely unhelpful in the bigger picture of in-house software development.

The notion of AppSec as the villain is counterintuitive for most development methodologies, but for DevSecOps, it’s a disaster. The gold standard has moved well beyond Waterfall, Agile, and even DevOps, into a process that sees security as a shared responsibility from the very beginning of the SDLC as vital.

For DevSecOps to work, software engineers need to be given a reason to care about security, and that comes from understanding why it’s so important for them to do their part in securing the world’s software. Security specialists who make the effort to extend the olive branch, work with development managers to meet the team’s needs, and take on more of a mentoring role in nurturing security awareness tend to see long-term benefits from their efforts… and they spend slightly less time tearing their hair out over yet another XSS error.

Developers need to be enabled to deliver better secure coding outcomes.

When it comes to learning secure coding during tertiary education, for many engineers, it’s non-existent. And it’s not because they were all busy playing beer pong and WoW - it’s simply not part of most computer science and IT degrees.

To that end, on-the-job training is often the first exposure a developer will get to the art of software security, and it rarely sets their world on fire. Hours of boring videos are a common training method, as are “tick-the-box” compliance exercises that are far too infrequent to have any real impact on teaching developers how to code securely, or make any headway in reducing common vulnerabilities in an organization’s software.

Both the AppSec team and the development cohort are crazy-busy, so any training should be meaningful, engaging, and hands-on. Speaking from a development background, we love to solve problems and get on the tools, so most static training just passes us by while we concentrate on something more pressing (or, let’s be honest, interesting).

AppSec specialists are in a place of influence, and they can forge a long-term, win-win situation by advocating for developers’ best interests. Seeking out viable training that is job-relevant, and delivered in their preferred languages and frameworks, is a huge step towards shifting the needle and inspiring a grassroots, positive security culture within an organization. We have tried the same thing for decades, and clearly, the “one size fits all” training approach doesn’t work. By helping to deliver the right tools and knowledge to developers, they can successfully upskill in secure coding, act with a heightened sense of security awareness, and produce a higher standard of code.

Efforts to get on the same page must come from both sides.

It’s easy for people with different goals to misunderstand each other, or, at worst, become somewhat distrustful. AppSec has the goal of keeping up with the onslaught of code being churned out, and finding any security issues that may lead to data being compromised, unauthorized access, and malicious attacks that have the potential to destroy positive customer sentiment for years.

Developers, among other things, build features to deadline. They are tasked with making software functional and beautiful, and being the creators of unique digital experiences that keep customers loyal. They’ve already got a lot to juggle, and pitching them a curveball in the shape of responsibility for security is a daunting prospect. It’s seen as AppSec’s problem to secure the code, and while that was somewhat achievable in the 90s (you know, before our cars could be hacked, and our entire lives could be carried around in a pocket supercomputer called a smartphone) there is simply too much code and not enough people to run it through the security gauntlet.

With a healthy dose of empathy, plus the enablement to make security a priority from the very beginning of the software creation process, AppSec and developers can see ways to align their goals. After all, a positive security culture depends on it, and security-aware developers are the secret ingredient to stopping common vulnerabilities, even with an ever-widening cybersecurity skills shortage.

Mutual respect for time has immense benefits.

Like I said before, everyone is super-busy when it comes to making magic (a.k.a. amazing software) happen. Developers will need allocated work time to do viable, hands-on training that builds their secure coding skills, and any training program should be hyper-relevant by design.

AppSec has their time wasted by fixing the same OWASP Top 10 vulnerabilities over and over again, and developers have theirs whittled away with low-engagement exercises that reinforce the idea in their minds that security is a chore.

Curated learning experiences are vital, and they help to cut to the chase through contextual, bite-sized delivery of relevant training, right at the moment it is needed.

By curating a custom secure coding course that is tailored to desired outcomes and in-house learning pathways, the developer’s time and workflow is being respected, while at the same time working towards a measurable reduction of vulnerabilities and cybersecurity risks for the business. It is a quick win in the quest to end soft rivalries, and move forward into the cybersecurity wild west as a united front.

Secure Code Warrior’s latest contextual learning feature, Courses, is available now.

‍