You’re probably doing DevSecOps wrong

( © ArtemisDiana - Shutterstock)

In an ideal state, DevSecOps embeds secure development practices in a hyper-agile, continuous development environment instead of bolting security on at the end. However, implementation is rarely that ideal in practice. While the state of secure software development has evolved to keep pace with modern development practices, DevSecOps is failing to live up to its potential by virtually every objective measure.

There are a dizzying array of solutions that promise to deliver magical results through DevSecOps, so why are vulnerability counts still going up every year? Why do the same old known security issues keep getting exploited? And why are developers and security teams all frustrated with each other still? How can companies transform their DevSecOps programs to get better outcomes? 

First, let’s address a couple elephants in the room:

1. If security were purely a technical problem, we’d have fully automated it by now

Humans write code. Humans use software. And humans are highly prone to underestimate risk. Throwing more security engineers and tools at non-engineering problems isn’t working.

2. DevSecOps is popular with engineers because security teams are not 

Aligning responsibility for quality in the engineering team makes a ton of sense. A developer knows their code base, their implementation, and is highly motivated to not get paged at 2 a.m. to fix an issue. But they aren’t security experts, which often leads to incorrect risk assessments and material damage to the company or its customers when they make the wrong call that the security team has to scramble to respond to.  

3. DevSecOps looks good on paper

The DevSecOps and 'shift left' promise of efficiency and cost gains is attractive to business leaders because they see it as a way to reduce their security costs and optimize profitability. While this can indeed be true, building and maintaining effective DevSecOps processes and managing vulnerabilities is still work that must be done. Simply shifting responsibilities to existing engineering teams not only puts more work on their plate, but it results in understaffed security teams to support them, answer their questions, and enable them. In other words, while security considerations have shifted left, so have potential security challenges and blockers.

These factors create a perfect environment for an adversarial relationship between security and engineering teams, sabotaging healthy partnership. Some responsibility falls on security teams – in many instances Security is the “House of ‘No’,” overusing military metaphors to describe fighting righteous battles, rather than enabling business partners and helping them identify viable solutions. 

But some culture issues are systemic and environmental. Security teams set requirements and SLAs and interrupt engineers with unplanned, urgent priorities. Then when Engineering wants Security’s help with high-impact work like helping design a secure architecture plan, they get frustrated that they have to wait because there is a backlog of teams seeking expert security services that the security team isn’t staffed to keep up with. 

So how do these problems manifest in an ineffective DevSecOps program?

• Improved vulnerability identification capabilities are effective, but all those new bug tickets pile up faster than engineering teams can clear bug backlogs, causing a perceived innovation vs security conflict.
• Tool noise creates notification fatigue, and poor tool integration in end-to-end dev-centric solutions makes things worse. By adding inefficiency, engineering engagement on security issues drops, resulting in engineers that don’t look at security tools, but rather wait for someone in the security team to cut a ticket.
• Unrealistic expectations of software engineers to be experts at everything from security design to threat modeling to risk and vulnerability assessment creates avoidance, blame and frustration. 
• Over reliance on security tooling and automation used as financial and business rationale for under-resourcing Security teams that subsequently aren’t able to provide adequate support to engineering partners for high value security engineering work.

It doesn’t have to be this way. Let’s talk about solutions:

The fellowship of the ring was not nine elves

Security engineers can deliver great technical solutions, but there is so much more to be done in an effective security program.  A company’s security program is a portfolio of product and service offerings for internal and external customers, but security engineers aren't excited about writing user stories, building roadmaps, driving stakeholder alignment or reporting on key results to business leaders.  

So why would you task a security engineer with writing customer communications? It’s not their superpower and they don’t enjoy it. You’re sacrificing their engineering magic for a task someone else could do better.  It’s time to take a page from your partners in product engineering and diversify your security team by strategically investing in complementary capabilities such as program and product managers, tech writers and communications experts, and data analysis specialists. Properly positioned in the organization as key contributors, they’ll be force multipliers for your engineers and drive added value for the business.

Security champions is a fundamentally flawed concept

Too many companies fail to staff a program or community manager to lead and facilitate this internal community. It’s heartbreaking the number of times a security champion has told me they're set up for failure because they are expected to rubber stamp security approvals by their engineering leadership, or they have no career path except to leave the dev team to join a dedicated security organization where they will have growth opportunities.

If you’re going to run a ‘security champions’ program, commit resources to its success

Properly supported security champions have the potential to help security and engineering teams create greater impact.  This virtual team requires leadership and curation: a facilitator or community manager that creates engaging content and structure that fosters true partnership, leveraging objective data to scale the program and deliver measurable business results.

Stop letting perfect be the enemy of good

In an ideal world, DevSecOps would lead to perfect, completely secure software that never breaks and can’t be breached. But chasing an unattainable goal can often get in the way of real, tangible progress. 

Rather than an all-or-nothing approach, using good/better/best security guidance can help lead engineers to stronger security throughout the entire development process and help them learn to make better risk decisions on their own moving forward. It’s simple psychology: if you set a goal that’s impossible to attain, most people won’t even try. But if you give people options or break the larger goal down into smaller, achievable increments, teams will often work quickly to rack up the easy victories. 

Security’s job is to enable customer trust

The security team’s mission is to ensure customers can trust your company’s brand and products – securing applications and technologies is just one of the things that must be done to achieve that.  In that light, DevSecOps tools are one piece of an effective security program, but they are inadequate on their own. To solve security problems and drive customer trust in a company’s brand and products, we must look beyond technical automation to diversify security teams and redefine the cultural frameworks we operate within to be deeply focused and committed to business enablement and collaboration.  

The way we save DevSecOps is to change our roles in it.