DEVOPSdigest

Organizations of all sizes are under constant pressure to increase innovation and speed up the delivery of new capabilities. In response, many decide to "adopt DevOps" to assist them in increasing flexibility and efficiency. The highest performing organizations realize that this is not just about using specific tools or combining historically separate development and operations teams; it requires real investment in changing their culture and their practices, ultimately aligning the entire team around the singular goal of delivering new features and stability.

Cybersecurity risk is another pressure that should have organizations rethinking their culture. Attack surfaces have been increasing as organizations continue to shift work toward cloud services and other methods of eliminating traditional network security boundaries. Additionally, while information breaches have always had the possibility of significant reputation damage and legal liability, the stakes are even higher now with government-imposed penalties under laws such as the EU's General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA). With both the possibility of an attack and the potential damage being higher than ever, there is no better time than now for organizations to start developing additional security capability.

The logical extension of the DevOps cultural shift to address this need is DevSecOps: incorporating security throughout the delivery lifecycle rather than treating it as a separate, and potentially optional, concern. A mature DevOps culture should already be integrating security as part of the organization's framework for delivering software. In practice, however, it seems to be frequently overlooked. If it takes an additional nudge to transform again from DevOps to DevSecOps to make sure that security is included, I'll certainly take that now over never.

Let's dig deeper into some benefits of adopting DevSecOps culture and practices.

First, by including security in the very early phases of a project, the team can make better security choices during requirements planning or design reviews. Security errors, like other kinds of software system defects, are much cheaper to fix when identified early. It is far less time-consuming to address a poor design than it is to implement that design and be forced to retrofit a security fix onto it later. Similarly, it can be helpful for someone with a security mindset to be involved in the decision-making process when new components are being evaluated for purchase, to ensure that the proposed components will be able to meet the project's long-term security needs. Anything that a team can do to shift security left in their project lifecycle will be helpful in reducing costs to the organization.

Development and operations teams also often view their security counterparts as adversaries, despite working for the same organization on presumably the same goals. Developers build new and innovative stuff; operators make sure that stuff runs well. It can seem like the security team is just there to make these things harder for everyone. In a DevSecOps culture, by working more closely together while keeping the project's business goal in mind, the team will build a shared understanding of the challenges and motivations of each role. Developing this intra-team empathy can be very helpful in reducing stress and increasing job satisfaction, which ultimately results in a more productive staff and less turnover.

Security is also often a short-staffed role, which means that there typically are tough choices made about which projects get any of the security personnel's precious time. Organizations that adopt a DevSecOps approach may find that everybody else on the team starts to develop their own security toolkit. This can significantly increase the effective bandwidth of your limited security staff because you end up with a lot more people with the knowledge and the interest to participate in the security conversation.

Security testing has also historically added significant time to a schedule because it is traditionally a manual effort. Adding security tasks into a DevOps culture would then seem to be working against the goal of and reducing the effort it takes to release updates and new features. Operations teams moving to a DevOps culture faced a similar challenge when so many servers and applications were manually deployed. The solution for operations teams was to work toward automating these tasks to reduce the friction of software deployment. This automation eventually helped reduce cycle times.

Some types of security testing are also easily automated and much of it can be done in parallel with other project tasks. Static analysis security testing (SAST) can be run while code is being developed. You can also run automated dynamic analysis security testing (DAST) scans against applications in test or staging environments. You can even write automated tests for the security configuration of the infrastructure itself. While these automated scans will not replace all types of security testing that you may want to do, the effort does two things: 1) it improves the timeliness of feedback from security, and 2) it frees security staff up to tackle the harder problems. Furthermore, by automating these tasks, you also avoid inflating the schedule, continuing the focus on reducing cycle times.

Organizations can see a variety of benefits when adopting DevSecOps culture, practices, and integrating security early and throughout the project lifecycle. Businesses that successfully transform from DevOps to DevSecOps will see advantages such as a reduction of security-related rework, as well as find an increase in employee engagement with an improved security posture without impacting team agility and flexibility.