DevSecOps integrates security throughout the IT lifecycle, rather than making it a distinct process. Creating a DevSecOps culture is foundational to any DevSecOps transformation. Regardless of what a tools vendor’s sales rep tells you, you can’t buy DevSecOps. It takes work to prepare your developers, security, and ops teams for alternative ways of working after your move to DevSecOps.
It’s easy just to pay lip service to corporate culture, unfortunately. Part of managing change during your first steps into DevSecOps is giving your organization’s front-line people the coaching and mentoring necessary for the transition to the improved security DevSecOps offers.
At its core, DevSecOps is a people game because people shoulder most of the weight of the changes to their workflows and how they do their work. Change can hit your employees and contractors differently. The remote working model that many businesses and government agencies adopted early in the pandemic requires more empathy and care to communicate with team members and stakeholders than ever before.
Challenges to seeding a DevSecOps culture
Seeding a DevSecOps culture isn’t without its challenges, and not all the hurdles are technical.
There can sometimes be a blame-game culture between developers and security teams. This is especially true if your teams are moving to DevSecOps from DevOps because wounds from those transitions can still feel fresh.
Another challenge is not balancing priorities between developers, security, and the business. Such a balancing act requires participation from your leadership team and the people doing the work.
Automation brings a degree of worry for some employees during the move from DevOps to DevSecOps. Developers, security specialists, testers, and even technical writers may harbor fears that automation can take their jobs.
The list of challenges to DevSecOps culture continues. Your leaders and senior team members must pay close attention to how DevSecOps affects your workforce by encouraging direct feedback about changes and learning from their experience and expertise during your transformation.
Five tips for seeding your DevSecOps culture
Seeding your DevSecOps culture requires you to step back and change the thinking and approaches your teams and stakeholders take to security in the software development cycle. Here are five tips:
1. Start thinking about security first across your organization
The first step to creating a DevSecOps culture is to think “security first” across your entire organization, not just in your IT organization. There’s more to this approach than mandatory online security awareness training acted out by dinner theater actors.
Instead, it’s about:
- Involving security with project planning from day one rather than making it an afterthought.
- Using your managers and internal communications channels to communicate security issues affecting your organization on a person-to-person level.
- Making security part of your project kickoffs and charters on projects of all sizes.
- Capturing security metrics from your DevSecOps projects and including them as part of project reporting.
Another step to thinking about security across your organization is offering employees transparency after encountering a security breach or attack. Your DevSecOps team should share their lessons learned and what mitigation steps they are taking to resolve the compromise. This step becomes doubly important if the mitigation changes how employees perform their job duties.
2. Consciously improve your security posture
Your security posture has a direct correlation with your DevSecOps culture. The more tweaks and additions you make to your security posture across your toolchains, development, and production environments, the more collaboration and communications you’ll have with your stakeholders and teams. Be sure to keep people as a priority in each step of improving your security posture.
An organization’s security posture:
- Shifts security left into the design and subsequent development and build phases.
- Introduces a shared responsibility workload with tight integration into the build and production phases.
- Creates a collaborative environment and tools for sharing security knowledge among teams.
3. Empower your development and operations teams
Micromanagement in all shapes and sizes is anathema to DevSecOps. You want to empower your teams with training, education, processes, and tools to make their jobs easier. The first step for empowering a DevSecOps team is to create clear and open communication and collaboration channels among development, operations, and security.
It takes more than just putting more meetings on a calendar to accomplish this feat. Here are some tips:
- Invest in security training for your development teams to skill them in secure coding practices.
- Build advocacy for DevSecOps at the team level. The DevSecOps advocate doesn’t need to be a manager or team lead. It doesn’t have to be a formal job title. The best candidates are senior developers who have the respect of their team members and those who work on your security teams. Give your advocate a voice in the state of DevSecOps inside your organization.
- Arm your team leads and senior developers with decision-making responsibilities to take action when issues occur during the build, testing, and production phases. The longer your team has to wait for approval from the management layers above them, the longer security issues will persist in development and production.
- Equip your teams with the tools, content, and processes to maintain DevOps velocity. You want this team to provide transparency into the DevSecOps transformation, so be open to their communications and outreach strategy suggestions.
Empowering the team takes on new meaning in the remote-work era, whether or not you had remote teams prior. Remote work can democratize DevSecOps team member roles, as work schedules may alter because of personal circumstances. Empowerment strategies to employ include:
- Creating runbooks (or how-to guides) for your primary DevOps tools
- Training remote team members
Empowerment over this information means giving your teams the space and time to iterate on runbooks and training through the lessons they learn developing, operating, and securing your applications. All runbooks should be accessible in Ansible or a similar open source tool to any teams needing them. The training could be internal brown bag lunches or online vendor training.
4. Avoid added complexity
Unnecessary complexity and corporate dysfunction often seem to go hand in hand. Be wary of adding additional steps to your DevSecOps transformation. Work is challenging enough, and there are no awards for complexity.
Here are some tips for avoiding complexity:
- Purge intentional complexity from your development culture at all levels through iterating on processes and being ruthless when weeding out micromanagers, unnatural dependencies, and silos amongst your people.
- Document your processes and tools with an eye for simplicity.
- Provide training on your DevSecOps tools and processes as part of onboarding new developers.
5. Sell the culture shift to your developers and stakeholders
While education and outreach are essential in times of transformation, nothing beats sitting down and talking with developers, security specialists, and sysadmins one-on-one while working to shift your culture to DevSecOps.
Often traditional change management drags a negative connotation with it for developers, so go the direct, nontraditional route to sell the culture shift, and don’t try to shoehorn it through normal corporate channels.
Seeding a DevSecOps culture doesn’t start with technology and security. Instead, it begins with preparing your processes and people for the DevOps-to-DevSecOps transformation your organization is about to undertake. When the people who do the work are onboard with DevSecOps, you’ve broken one of the most formidable obstacles to a DevSecOps transformation. In future articles, I’ll describe how to foster a DevSecOps culture at the executive level and build support for the transition across the organization.
This article was originally published on Red Hat’s Enable Architect site on August 18, 2022. The site ceased publication in April 2023.
Will Kelly is a technology industry writer and marketer. Medium is home to his personal writing. He’s written for TechTarget, InfoWorld, and others. His career includes stints in technical writing, training, and marketing. Follow him on Twitter :@willkelly.