Whether your organization is moving from DevOps to DevSecOps or making the initial step from a traditional waterfall software development life cycle (SDLC) to DevSecOps, you need to account for how DevSecOps is going to change your teams.

Here are five changes your teams can expect when your organization moves to DevSecOps:

1. Security becomes part of everyone’s job.

Perhaps the most significant change that comes to DevOps teams when they take the next step in their DevOps journey to move to a DevSecOps model is that security becomes part of everyone’s job.

It starts with incorporating security from day one of the project, whether it’s a new cloud application your organization is launching or an update to an existing application. When you take this first step, security is the “Department of No” or “It’s us versus them” when seeking approvals or collaborating on resolving security issues.

Another step to security becoming part of everyone’s job is to provide security training for your developers. Training could take the form of in-house developer training in casual formats such as Lunch and Learns or more formal training classes conducted by your organization’s training department. Another option is to send your developers to a third-party training provider to get the requisite security training. Depending on your security ambitions (and budget), there is always the option to send your DevOps team members to get a DevSecOps vendor certification such as the DevSecOps Foundation certification from the DevOps Institute or the Certified DevSecOps Professional (CDP) from practical-devsecops.com.

Finally, it’s also critical to document secure coding standards for developer onboarding and their later reference to ensure security becomes a part of the developer’s job.

2. Priorities may change

Trust between your security and DevOps teams will not improve overnight. The key to building trust between these teams — traditionally at odds in some organizational environments — is about prioritizing results. Both teams need to set priorities that are best for the project delivery and the overall business. For example, some software bugs that the team may encounter during development may not be enough to halt a product release. The development and security teams

3. Instills a Fail Fast culture

Unfortunately, in some corporate cultures, even the thought of failure can paralyze software development projects or keep the teams working in an endless loop redoing work to avoid releasing a product.

When “Fail Fast” becomes part of team culture, developers identify bugs as they build. That’s a big contrast to the days when developers or QA would work on bugs during the last few days (or hours!) before product launch. DevSecOps culture enables developers to take the time to fix issues in development versus spending hours or days fixing the issue once your application is in production.

Elements of a “Fail Fast” culture include:

  • Failure becomes a learning experience for the team rather than a career-ending incident.
  • Teams document lessons learned from the failure and put in the tools and processes to ensure the failure doesn’t happen again.
  • Testing. QA and remediation are recurring aspects of the DevSecOps lifecycle enabling developers to find bugs and issues during the development lifecycle before your application hits production.
  • Ask for help becomes a rule rather than an exception, with team members not worrying about losing face to their fellow team members and management.

“Fail Fast” cultures aren’t born overnight. Creating such a culture requires management support, accompanied by building trust across the teams who work together to deliver software. Most of all, management needs to lead by example and show their teams that failure is a learning opportunity, so take the extra time to put actions behind words if you’re a manager or stakeholder.

4. Increases Transparency

DevSecOps is no place for job security through obscurity. The DevSecOps culture warrants transparency between developers, security, and operations teams during their work. Increasing transparency requires the work of everybody to open collaboration between groups.

Here are some examples of how DevSecOps increases transparency:

  • Security teams enter the DevOps lifecycle, ensuring developers, security, and operations teams see everything through the same lens while working together.
  • Teams begin to use the “same language” since they are now working together during the development lifecycle.
  • As engagement between development, security, and operations teams grows, it can finally be possible for these groups to see they are all aligned to a single goal and start dropping the “us versus them” attitude that can sometimes affect how these teams collaborate with each other.

Another element of transparency that you should monitor on your teams is engagement. Be prepared to work with teams and staff who might have been working in silos either deliberately or through no fault of their own.

5. Treat Metrics as your Missing DevOps Team Member

Tools across the DevSecOps toolchain are chock full of data for teams and their stakeholders to track. DevSecOps culture enables teams to tell their data-driven story to internal stakeholders such as executives and project sponsors.

Some metrics to consider capturing during your delivery lifecycle include:

  • Reduced Total Security Tickets Opened
  • Discovery of Preproduction Vulnerabilities
  • Reduced Time-to-Remediate
  • Reducing Failed Security Tests
  • Percentage of Security Audits Passed

When choosing DevSecOps tools, make sure that analytics and reporting tools are prominent in your requirements.  Also, be prepared to iterate on metrics and reporting as you and your stakeholders learn more about your organization’s reporting capabilities and needs.

DevSecOps and Other Business Units

Also, keep in mind that many of the changes that DevSecOps demands of development and operations teams also trickle out to the business units that sit around the periphery of software development projects. For example, business stakeholders will have to factor more security requirements into their project requirements. Your executives have the opportunity to tap into more backend data from your DevSecOps toolchain and view actionable data through dashboards that your teams can set up and configure.

DevSecOps also provides your compliance auditors with new options for tapping into security and application data that would have required extra efforts in the days of waterfall software development.

Final thoughts: Building the Better DevSecOps Team

Setting up a DevSecOps team for success isn’t about just throwing some security tools into your existing DevOps toolchain and considering it done. It’s about cultural transformation and transparency. The first employees to feel that change will be in your development, operations, and security groups. These are also the team members you need to buy in on your DevSecOps vision.