Application Security Through the Lens of Developer Experience

To a varying degree, most companies are competing on their ability to deliver business value through software and technology. Producing software faster and with higher quality leads to more value delivered. It’s as simple as that, and security teams must embrace this reality to be successful and to enable the business.?

If you follow the market for developer tools or the growth of central engineering teams (e.g. Platform, Developer Tools, Productivity Engineering) you know every smart organization is trying to help developers get ideas to production as quickly as possible. I’ve always considered AppSec and ProdSec teams to be a variant of central engineering functions, and a recent research paper on developer experience (DevEx) presents a particularly helpful framework for thinking about how AppSec must evolve to remain effective and impactful.

The Three Core Dimensions of Developer Experience

According to the paper, DevEx “encompasses how developers feel about, think about, and value their work.” Improving DevEx will improve value delivery, and it has three primary dimensions:

• Feedback loops - Responses (e.g. build results, code reviews, test results) to developer actions that need actioning or decisioning?
• Cognitive load - The mental processing required to complete a task
• Flow state - Immersive work state where the developer is fully focused and involved

At its essence, improving DevEx involves shortening and streamlining feedback loops, minimizing cognitive load, and maximizing the time developers spend in flow state.?

Traditional AppSec is the Ultimate DevEx Anti-Pattern

AppSec teams have always meant well - we want to minimize risk to the organization and improve software quality. However, the way we’ve traditionally worked has been completely antithetical to DevEx. Think about it - PDFs full of unprioritized and unvalidated SAST, DAST, SCA, etc. security findings, vague recommendations, blocking deployments, requiring developers to leave their tools and systems to engage with security teams, overstating risk and over focusing on theoretical issues, meeting after meeting and touchpoint after touchpoint.

Sound familiar??

Modernizing AppSec with a Focus on DevEx

So, if the old ways are not aligned with DevEx, what should we be doing? Let’s use the three core dimensions of DevEx to guide us.?

Optimize feedback loops

• Minimize or remove blocking actions. Strongly consider whether you need to block builds, commits, deployments, etc. based on security findings. If you need to, make sure your developers understand the rationale ahead of time and minimize surprise.?
• Security teams must bear the burden of validating findings. Do not give your developers unvalidated vulnerabilities or findings.?
• Security teams must use the tools that developers use. Stop making developers use the security team’s tools to gain context, learn about issues, or update findings. Use the issue trackers and other systems that developers use to surface findings and track work.?

Minimize cognitive load

• Build paved roads for security solutions. Don’t make developers wonder about the right way to do things. Security teams must provide well-supported and opinionated solutions to security problems. To take this a step further - if you don’t have a well-supported solution for a security issue, this is the security team’s problem, not the developer’s.?
• Auto-remediate whenever possible. You know what’s better than notifying a developer of a critical and validated security issue? Fixing it for them. This may be through updating container or VM images or filing PRs for impacted repos.?
• Build secure by default solutions. Someone once told me “every decision is the chance to make the wrong decision.” Stop forcing developers to make choices in areas they’re not expert. Build security in and remove inessential choices.

Maximize flow state

• Automate much of the interface between security and engineering teams. Sure the human touch is nice, but does that meeting really need to happen? For regular and recurring interfaces between security and engineer, find ways to create systems and APIs to make the interactions more predictable and actionable.
• Prefer asynchronous communication methods. For any required meetings, schedule with plenty of time to plan and have well documented agendas and outcomes.?

Wrap-Up and Additional Resources

Practically, these kinds of changes to your AppSec approach do have some additional requirements. You’ll need to ensure you have engineering talent in your AppSec team, and you’re likely going to need to partner with platform and other central teams to build scalable security solutions for your developers. You also need both a mindset and planning shift - rather than throwing issues and vulnerabilities over the wall to developers you need to think about completing and facilitating the majority of remediation and improvement work within the security team so your developers can benefit from secure by default and intuitive self-service solutions.

I’ve spoken about most of these subjects previously. If you’re interested in this topic and direction, here are links to some of my relevant previous talks.?

2013 - LASCON - From Gates to Guardrails: Alternate Approaches to Product Security - moving from blocking to non-blocking AppSec, security automation to make security team’s lives easier.

2014 - Hacktivity - Building a Glass House - Optimizing for visibility and scale in AppSec.

2015 - FutureStack - Splitting The Check on Compliance and Security - Dual purposing security/audit and developer tools.?

2016 - AWS re:Invent - The Psychology of Security Automation - Using automation to improve the relationships between security and engineering teams.?

2018 - SANS Cloud Security Summit - Fast Forward: Reflecting on a Life of Watching Movies and a Career in Cybersecurity - Includes a discussion of reducing security cognitive load for developers.?

If you're interested in developer productivity, experience, and related topics, the co-author of the paper I reference, Dr. Margaret Storey, has a plethora of valuable research and insights on her website.