Best practices for driving developer adoption of security tools and processes

It is broadly accepted that the way to scale application security in modern organizations is to embed it directly into the development workflows as a natural part of the agile process and DevOps pipeline. This is much easier said than done, though, and it brings many challenges in terms of acceptance and adoption from developers and development teams. This white paper summarizes our learnings from discussions with a variety of organizations that have DevSecOps programs at varying stages of maturity. The common theme among all the individuals and groups we talked about was their want for development teams to adopt secure development practices as part of their workflows.

It’s important to note that no two groups we spoke with do things the same way. It’s equally important to say that what works well in one organization may well not work as well in another, since there are so many different factors that could influence the success of these practices. It’s key for you, the reader, to identify practices and approaches within this paper that you feel would work best for your organization, culture, and teams.

Developer security requires culture, process, and tooling

Culture

1. Be empathetic to your development teams

• Understand their general appetite for change.

• Learn which teams and projects are likely to implement modern technology and development processes, as well as which are resistant to change.

• Determine how well project ownership and responsibility is defined.

• Understand team capacity for delivery, as well as other tasks, such as performance, reliability, etc.

2. Embrace top-down business security prioritization

• Make it clear when prioritization comes from the business.

• Security teams must help development teams address the business’s security prioritization, rather than adding more to their plate.

3. Enable developer-security collaboration

• Consider a security champions program or a security guild to make it easy to collaborate.

• Work with developers to build trust, rather than relying on fear to get things done.

• Build shared programs and have common goals that security and development work towards.

• Identify ownership in development teams so that security teams can be relevant with requests.

4. Educate to enable secure development

• Educate teams before rolling out programs.

• Recognize that certain education isn’t relevant to all teams.

• Train teams on the specific vulnerabilities that affect them using previous incidents as examples.

• Track education via scorecards.

• Gamify education when possible.

5. Rewards and recognition

• Call out individuals for their achievements and security improvements

• Highlight team successes, and program adoptions to show their progression and encourage other rollouts.

• Make sure the engineering leadership team is giving recognition and showing security is important to the teams

• Offer swag, gifts, travel to security conferences, etc. to help build awareness.

Process

1. Include developers in process-changing decisions

• Understand how development teams are integrating security practices into their pipeline today, and try to match their workflows.

• When new security rules or processes are made, work with development teams to set thresholds and working practices.

• Make sure education and awareness is shared around any process change — well in advance — including blogs, documentation, and learning hubs.

2. Make the right path the easy path

• Don’t overcomplicate processes. Work with the development team to keep it simple.

• Make sure you have good documentation of how other teams work and how activities should be done.

• Provide paved road options for developers to be able to make the right decision by default.

• Integrate processes into their existing workflow rather than trying to create new workflows.

• Make sure processes (and tools) focus on solutions, not problems.

3. Create visibility and transparency across teams

• Scorecards are a great way to report progress and status of your security to the organization.

• Teams should be accountable to the scorecard results and prioritize security based on their health and their plans.

• Lean on developer values and gamification to bring work into sprints, using scorecard data as justification.

4. Speed of rollout

• Identify teams that are more adaptable and open to introducing new security programs.

• Roll out to those teams first, initially as a low touch, visibility, approach.

• Add secure development activities to development workflows focusing on the security of their incremental application changes first.

• Ramp up guardrails at the speed that the teams can consume change without overwhelming them.

• Identify more teams to roll out to after the early-adoption teams have shown value.

• Use best practices identified during the initial rollout to drive adoption.

Tooling

1. Embrace developer tooling

• Developer security tools need great self-serve usage, including easy onboarding, intuitive workflows, and clear documentation.

• Tools must integrate into existing workflows, including IDE, Git, and pipelines.

• Tools must have rich APIs and be automation-friendly.

• Look for tools with wide adoption by the open source and the security communities.

• Try to pick a tool that covers the whole application, including first-party code, third-party libraries, containers, IaC, etc.

• Tools should focus on fix and remediation over find and report.

2. Don’t overwhelm developers

• When introducing tooling to an organization or team, use it for visibility initially.

• Over time, dial up the rules and guardrails through policies to improve the secure development process.

• Back up any tooling changes with awareness, communication, reasoning, good process documentation, and education.

• Focus tooling on new code delivery first, followed by backlog issues to reduce load on developers.

3. Automate everything

• Integration into a workflow needs to be automated and done in the right place based on the team.

• As well as the testing in the workflow, look at other hooks where tools can be connected (ticketing, reporting, alerting, etc.).

• Be able to pull reporting data from your tooling, preferably from an API to populate your existing dashboards and scorecards.