While 84% of developers told GitLab they’re releasing code faster than ever before, recent supply chain attacks demonstrate the rampant security risk in modern applications. While DevOps has allowed for more innovation, better features, and expanded product marketplaces, in some organizations, it has come at the cost of security.
In leadership meetings, adding security to DevOps processes is presented as an easy fix. Just bolt on some security reviews at the end, and you’re all set. But development and security teams balk at this idea. Introducing security controls means longer release times, comprehensive code reviews, and tedious testing processes. In the same GitLab survey, testing was the number one bottleneck listed by developers, and security testing can seriously exacerbate this issue.
These complaints aren’t without merit. Tacking security measures on to the end of your DevOps cycle will hurt your release times and require significant rework. But a true DevSecOps approach, one that harmonizes development, security, and operations teams to address security challenges from the start, will benefit development teams and their organizations in many ways – even beyond the improved security of systems, tools, and products.
If your organization is considering a DevSecOps approach or has just begun implementing one, this blog is here to show you some of the less obvious benefits of a DevSecOps model and how it can support the teams involved in your development process. And if you’d like to read more about these benefits and how you can apply DevSecOps principles across your business, check out our white paper "Extrapolating DevSecOps: Principles to Apply across Your Organization."
1. Reduced Friction
In 2019, communication and collaboration were cited as the top skills needed by security, development, and operations professionals. This need isn’t unique to this field – communication issues plague many business areas – but poor communication has a huge impact in DevOps. Miscommunication can lead to failed projects, missed deadlines, bad design, and major security issues. For this reason, DevOps has adopted three core tenets – Flow, Feedback, and Continuous Learning – to improve communication. These tenets are also at the heart of DevSecOps.
Feedback is at the core of Focal Point’s approach to DevSecOps. When helping our clients build DevSecOps programs, one of the first concepts we establish is the feedback loop. These loops collect input from everyone involved in the DevSecOps process. Feedback mechanisms can include surveys, communication channels, and regular checkpoints to identify challenges, implement solutions, and improve long-term effectiveness.
You’re probably tired of hearing us talk about Security Champions Programs, but we cannot stress how important these are to improving communication. These programs set up security representatives in each development team to serve as liaisons between Security and Development. They identify security opportunities, report on security challenges, and help build solutions. These representatives are pivotal in establishing a partnership and clear communication channel between teams.
Improving communication is key to reducing friction across Development, Security, and Operations. By adopting a DevSecOps approach that promotes strong communication, all three teams will see improved success across development projects.
2. Continuous Improvement
Failure should not only be an option in Development, but it should be a key component of the process. Failure is key to innovation, and DevSecOps embraces failure. Sure, failed deployments, production outages, and data breaches can be very expensive failures. But the key to avoiding these disasters is allowing space for testing and failing in the development process.
A DevSecOps approach creates space for mistakes and reinforces the need to learn from them. First, testing processes and tools should be identified and implemented at the start. When testing uncovers issues along the way, teams should be given ample time to learn from these challenges and innovate. Threat modeling exercises are another good way to predict failures and give teams a chance to adapt their products before it’s too late.
Outside of product failures, it’s also important to reflect on process failures. What pain points need to be addressed? What led to a missed deadline? Using your feedback mechanisms, identify development process failures and work with Dev, Sec, and Ops to learn from them and improve the process going forward. This is how you build a sustainable DevSecOps program.
3. Shared Responsibility
Nearly 40% of developers feel they are fully responsible for security; however, more than 30% of security teams say they alone are responsible for it. Either way, many security and development teams feel like they’re shouldering this burden alone. In reality, security can only be achieved if both teams share the responsibility for it.
A DevSecOps approach gives both security and development teams a stake in security, uniting their goals. Security has become a much higher priority for product users, and therefore, a defining characteristic of a good feature. This means secure features are now a higher priority for developers, and security teams now have a role to play in developing high-quality products.
By expanding the definition of “high quality” to include security, DevSecOps places the responsibility of security on both Development and Security. When a security vulnerability is uncovered, Development should hold themselves accountable for not considering it. In the same way, security teams should be responsible for finding practical, effective security measures that don’t limit functionality or hamper user experience. When goals are shared and both teams are making valuable contributions, Development and Security can view each other as partners, which opens up new opportunities to enhance product quality.
4. Streamlined Processes
Speed will always be a top priority for development teams. To truly unite your security and development teams, you need to find a way to preserve speed while securing processes. Organizations that add security on at the end of development processes will not be able to support security at speed, but a DevSecOps approach weaves security into development without crippling the rate of release.
First, security measures must be integrated into development processes from the start, a concept referred to as “shifting left.” This shift left is critical to preserving the rate of development. Involving Security at the start of the development lifecycle sets clear expectations, avoids security issues, and streamlines efforts. Waiting to integrate security until the end of a project results in missed deadlines and more work.
Second, Security must set reasonable expectations. For example, a development team has implemented a CI/CD pipeline, but Security’s SAST tool is identifying hundreds of findings every time it runs. The development team does not have time to stop and address all these findings, so it ignores all of them and presses forward. But Security wants to halt production to address these issues. Ultimately nothing is done, and during testing, urgent security issues are identified that must be addressed, pushing back the release date.
Instead, Security must focus on the goals of the project and the problems they are trying to solve. This will allow them to identify the most urgent issues and threats that may impact the product. Going back to our example, Security can funnel only high or critical vulnerabilities to Development to work on, rather than working to solve every single issue before taking the next step. This allows for progress while also addressing security issues.
The keys to preserving speed when integrating security are to set clear goals, involve Security at the start of a project, and have reasonable expectations. With these things in mind, Development can maintain their timelines while producing secure products.
5. Smooth Change Processes
Change is not just inevitable, it’s a good thing. Change is often a sign of progress, of evolution, of growth. But for developers, change can mean a lot of work, especially if they aren’t using a DevSecOps approach. If a feature is ready to launch, but Security uncovers issues during testing that require changes, then deadlines are shot and a hefty amount of rework could be required.
DevSecOps promotes regular feedback, teamwork, shared responsibility, and continuous improvement – concepts that reduce the burden of change if integrated well. Clear feedback channels, frequent communication, and strong relationships among Sec, Dev, and Ops streamline change processes, ensuring everyone is informed, knows their role, and is ready to act. This doesn’t mean you should eliminate change management processes and Change Approval Boards (CAB) but think through the key blockers in those processes and how to revise the approach to reduce organizational friction with minimal risk introduction.
The principle of continuous improvement is critical to a smooth change process. DevSecOps provides space for learning from mistakes and making changes based on lessons learned. Adopting a mindset that embraces change and sees it as something valuable will help teams work together to execute changes efficiently.
6. Improved Confidence
One of the greatest benefits of DevSecOps is greater confidence in your products, as well as the tools, people, and processes supporting development. With a DevSecOps approach, the products and applications your organization builds will be higher quality and more secure. Your organization can rest assured that its products meet the highest standard.
In addition, you can have greater confidence in the strength of your development program. If you’re following a DevSecOps approach, it means your teams are united, working together to build the best products. They’re actively communicating and providing feedback, ensuring issues are addressed and timelines are met. It means you have smart processes and strategies in place to streamline development and maintain speed without sacrificing security. Above all, it means each individual in your organization is working towards advancing your whole organization rather than just their specific silo.
Conclusion
Adopting a DevSecOps approach allows you to focus on what you do best – making great products – because the tools, processes, and people supporting your development program are aligned. Product development can take center stage, rather than operational struggles, security issues, and developer complaints.
For organizations considering DevSecOps adoption or just getting started with it, these benefits show that DevSecOps has a greater impact than just securing products. It improves teamwork, it builds better products, and it provides value to the entire business. Using this list of benefits, you can build a more strategic business case as you work to integrate DevSecOps, showing leadership and stakeholders the value it can bring to every area of your organization. By demonstrating the value of DevSecOps, you should see more buy-in and an increase in the success and ROI of your DevSecOps investment. Adopting DevSecOps takes some work, but it is well worth the effort. Take the plunge today.
To learn more about the benefits of DevSecOps and how to apply its concepts across your organization, download our white paper “Extrapolating DevSecOps: Principles to Apply across Your Organization.”
Want more DevSecOps insights in your inbox?
Subscribe to Focal Point's Risk Rundown below - a once-a-month newsletter with templates, webinars, interesting white papers, and news you may have missed. Thousands of your colleagues and competitors have signed up! You can unsubscribe at any time.
