DevSecOps is a goal with many benefits. At its best, it makes better use of existing team members and their authentic skills, resulting in increased productivity and greater speed – not to mention better software security.
At its worst, the shifting responsibilities are met with half-baked processes, uncommitted or unprepared team members, and a fragmented software security process.
Seeing DevSecOps as a practice, not a destination, may help organizations shift left patiently, working through culture changes and process iterations at a pace that is comfortable and organic. I know it’s difficult to be patient with the process when you desperately need the speed and benefits of secure applications. Today, I thought I’d share four pieces of advice about DevSecOps that you might not hear from industry leaders, vendors or colleagues.
1. Don’t mistake speed for success
Successful DevSecOps transformation means striking the right balance within your organization. You might be able to deploy to production quickly, but security could be lacking. Or making that release date could fry your team. Don’t be in too much of a hurry to see speed — it will come eventually.
Instead, focus on making timely updates to your applications that are both secure and relevant to your end users, at a cadence that is comfortable for your organization. That’s how you can take a step in the right direction towards a fully automated DevSecOps success.
2. You can’t flip a switch and get DevSecOps
Some materials you read make a DevSecOps shift sound easy. It’s not. It requires a cultural change that can be very, very (can I say very again?) difficult for organizations that were founded with a different mission, culture and values. You’ll need this new, modern cultural foundation because you’re going to build your whole DevSecOps “house” on top, and you don’t want cracks to appear at the foundational level. After all, when under pressure your organization will inevitably be tested by deadlines to deliver new software.
The necessary mindsets for DevSecOps can’t be bought — they must be developed. This includes building unity, collaboration, open communication and feedback across the team, along with fostering a willingness to listen and an acceptance of trial and error.
3. There’s a difference between a timeline and a deadline
You might be anxious to improve development speed but avoid the temptation to cry “fire” unless it’s real. Timelines are ideal. Deadlines can indicate significant stress and negative team impact and you will eventually sound like the boy who cried wolf if you use deadlines every single time a minute task needs completion.
Try to operate in a world of timelines and include milestones for other aspects of the development pipeline too. If you can create a team spirit where transparency reigns supreme and there’s room for flexibility, that will allow DevSecOps to move at its authentic pace.
4. You can see quick ROI if you look for it.
I like to set realistic expectations, so I tell my customers, “don’t expect to see the big wins early on.” DevSecOps reduces costs through automation, which can take time. However, you can see return on investment (ROI) through a lens of defect discovery. Here’s a breakdown of how:
- An issue found in the requisition stage of development might take two hours to resolve. If left undiscovered, the same bug or defect caught in beta could take eight times more time to identify and fix. Adopting DevSecOps shortens feedback loops, quickly eliminating those late finds that can cost time and money – and that is a quick win you can show to leadership.
DevSecOps is a practice that demands patience to discover the tools, workflows, feedback mechanisms and pace that work for you. It’s a big technology shift that requires organizations to focus on people. We all need a bit of advice now and then, so remember that there’s no magic bullet. And be sure to celebrate incremental progress along the way.
Hayden Smith is a senior engineer with Anchore, a software container security company. Currently, Smith leads developer projects across the Defense Department (DoD) and numerous federal agencies to help government organizations adopt DevSecOps best practices. His work includes building and automating Platform One, a collection of hardened and approved containers for use across agencies.
This post was originally published on December 21, 2021.