CISO playbook: 3 things to consider when establishing a security culture

Establishing a thriving security culture across your organization will rely heavily on your developer teams. Therefore, engaging with developers early and often while you build your security program is vital. 

In this playbook for Chief Information Security Officers (CISOs), we explore how to build a security culture across your organization by considering the following three things:

1. Dev buy-in is critical to the success of a security program.

2. The three types of dev teams (trailblazing, adopters, and inertia teams).

3. How to work with your dev teams to solve pain points (cultural, process, or tooling based).

1. Dev buy-in is critical to the success of a security program

The way to scale application security is to embed it directly into development workflows — which is much easier said than done. Inevitably, you will encounter challenges regarding accepting and adopting a security culture from developer teams because it can disrupt workflows and negatively impact their ability to meet production schedules if not added in a thoughtful, empathetic way that takes on a lot of developer feedback and considerations.

So, before rolling out an AppSec program, it’s crucial for those who interact and support the development teams to clearly understand the problems, frictions, and frustrations dev teams face. 

Then, you can set realistic expectations to determine how and where devs can change and see how you can best enable and support them — because empathy can drive alignment. 

Without empathy and an understanding of your dev teams’ processes, you will create friction and decrease the chances of dev buy-in for implementing an organization-wide security culture.

Identifying the mindset of your development teams will determine how best to collaborate with them to find common ground and goals for your AppSec program.

2. The 3 types of developer teams.

If supporting and empowering dev teams is the key to AppSec success, meeting your teams where they are is critical. And that starts with understanding what type of teams they are. 

Some development teams are attracted to the latest tech and eager to try new tools, technologies, and programming models. Other teams will adapt to new technologies or processes only once they have demonstrated the ability to relieve a pain point. And then, of course, there are the teams that avoid change because of an “if it’s not broken, don’t fix it” mindset. 

We categorize teams into: trailblazing, adopters, or inertia teams.

Trailblazing teams

Trailblazers are high-performing teams and often a minority in an organization. These teams are less likely to be overwhelmed and more likely to define standards and best practices for other teams in the org. Trailblazing teams are often the first to adopt processes and technologies because they benefit the team or delivery. 

Adopter teams

Adopter teams are usually solid delivery teams. They will adopt new processes, techniques, or technologies only once a trailblazing team has proven them in the organization. These teams typically cover the majority of the organization. 

Inertia teams

Inertia teams are the teams most resistant to change. These teams have done development their way for a long time and prefer to continue doing so because of familiarity and continuity. They are also often a minority in the organization.

3. How to work with your dev teams to solve pain points.

Developer security requires culture, process, and tooling changes to be implemented successfully. 

While no two teams are the same (even if they share a type), here are some ideas for working with (and across) your dev org to solve cultural, process-based, or tooling pain points.

Culture

Establishing the culture across your dev org will require empathy, top-down priorities, collaboration, education, and recognition.

Empathy

First, you must understand who your teams are and what their general appetite for change is. Then, understanding each team’s capacity for delivery, performance, and reliability can help you set realistic and attainable goals for your teams.

Once you know who your teams are and what they are capable of, you can determine how to define project ownership and responsibility so that your AppSec program is successful.

Top-down prioritizations

Embrace top-down business security prioritizations and be crystal clear about it. This ensures that development teams have a mandate to spend time on security issues because it's important to the business and engineering execs — instead of only addressing them when their other development work gets done, if there's still time.

Promote collaboration

Consider building a security champions program to make collaboration easier and more accessible. Do whatever you can to work with developers to build trust, rather than only relying on fear to get things done. 

Educate

It seems obvious, but we’ll say it anyway —- educate your dev teams before rolling out programs. This education may be as simple as making devs aware of changes, why they're happening, and importantly, and what impact/actions developers need to be aware of, in advance of changes being rolled out. At the same time, recognize that some education topics won’t be relevant to all teams, so make sure you are tailoring materials to teams’ needs. 

Track and gamify education (when possible) via scorecards and turn the process into something devs want to do and not just have to do. Or, as we like to say, change accountability from stick to carrot. 

Celebrate success

Highlighting individuals for achievements and security improvements or recognizing team successes is critical to building a security culture. Incentivizing with gifts and swag, or celebrating high-performing teams at monthly meetings, is a great place to start.

Across teams, it can look like this:

Process

You will need to develop new processes when establishing a security culture. When developing new processes, keep your dev teams front of mind and:

• Look for opportunities to integrate processes into existing workflows rather than trying to create new workflows. 

• Work with dev teams to set thresholds and working practices when new security rules or processes are ready for implementation. 

• Work with the development team to keep it simple and to ensure you can provide good documentation for the next team.

Across your dev org, it can look like this:

Tooling

With new processes comes new tooling. Embrace developer tooling:

• With rich, automation-friendly APIs. 

• That focuses on fixes and remediation instead of finding and reporting.

• That is widely adopted by the open source and security communities.

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

Do not overwhelm developers (we can't say this enough)! When introducing tooling to a team, start with visibility. Then, over time, dial up the rules and guardrails through policies to improve the secure development process.

Finally, automate everything. Integration into a workflow needs to be automated and done in the right place based on the team, as does testing in the workflow. Look for all the places tools can be connected, like ticketing, reporting, alerting, etc.

Across your dev org, it can look like this:

Next Steps

Snyk is a developer security platform that integrates directly into development tools, workflows, and automation pipelines. Snyk helps dev teams find, prioritize, and fix security vulnerabilities in code, dependencies, containers, infrastructure as code, and cloud environments. 

You can discover even more from our actionable playbooks on how to build or improve security adoption across your dev org. Or, book a demo with a security expert today to learn more.