Over the last ten years, DevOps has revolutionized the way software is written and deployed, introducing agile techniques that cut down on development cycles, which has led to faster and more stable releases and more closely aligned applications with business objectives. Increasingly, similar techniques are being used by a new method of software development, DevSecOps, to build security into every phase of the development process, ensuring the highest degree of security while encouraging innovation and rapid software delivery.
DevSecOps is new enough that plenty of companies might not know how to get started with it. And even companies that have already begun can use help. If you’re just dipping your toes in the water or want to get even more out of your current DevSecOps use, check out these five tips, learned on the front lines of leading development teams – and avoid some missteps!
Tip #1: Understand DevSecOps Basics
Let’s start with a brief look at how DevSecOps changes the way software is written. Traditionally, a development team writes applications without a focus on security. They deliver the application to the business operations team, which updates the software and make sure it fits into the company’s security business model. This can mean lots of patches, lots of rewrites, lots of delays — and possibly, insecure software. DevSecOps originated by needing to merge development with the operations team and is built around the concept that security is a shared responsibility.
DevSecOps streamlines the process and eliminates the handoffs, aligning teams around shared goals. The development team collaborates with business operations and builds the security model into software from the very beginning. That way, the operations team doesn’t have to apply and reapply patches with every new build. Security is baked right into applications from the beginning. That means more secure applications, more agility and faster updates.
Tip #2: Use a Soft Sell to Get Buy-In
DevSecOps requires buy-in throughout an organization. Before you can put it into effect, you’ll need to convince departments and executives to participate. You don’t need to use a hard sell. Start the conversation from a risk-based perspective. Ask people, “What happens if we don’t do this? What are the consequences?” Explain that not moving to DevSecOps can hold up the delivery of software because you’re being forced to address security flaws too late in the development process. And, of course, you can point out the dangers to the business if a flaw makes its way into your company’s software and is exploited. It is very important that initiatives such as this are supported at every level.
Tip #3: Get Everyone to Truly Commit to DevSecOps
Getting buy-in is one thing, but getting people and teams to truly commit to a new culture and new way of doing things is another one. So, don’t accept passive buy-in. Make sure that everyone, up through senior management, is committed to embedding security controls and processes into the software workflow. You’ll need to get teams and the entire business itself to commit to a culture of continuous security monitoring, automation and detection. A side benefit: this helps enable a culture of continuous learning as well!
Tip #4: Start with a Targeted Rollout
Don’t expect DevSecOps to be adopted overnight, and don’t bite off more than you can chew. Start with an overall assessment of the risks you need to address. Then, fix the most important risk by inserting automated security tools into the development pipeline to address it. After you’ve done that, ask the team which risk should be addressed next. That kind of collaboration helps get the entire team on board. Keep working incrementally through all your security risks this way. Incremental improvements are a known benefit of any agile organization, and this is no different. You’re not going to succeed if you try to boil the ocean in one day.
Tip #5 Measure Your Progress
To be successful with DevSecOps, you need to constantly measure your progress towards three goals, not making the goals competing but understanding how these goals impact the entire delivery. The entire team needs to be measured against the goals of speed of delivery, uptime and stability, and the overall organizational risk. The success of these goals impacts the ability of the team to continue to deliver software.
How you measure this will depend on your organization and the tools you have available. But you most likely will want to include unit tests, code style tests, a vulnerability test and static code analyzers. They should be integrated into your DevSecOps pipeline. Generate reports using them. Make sure the reports are carefully read, reviewed and the insights gained by them are used to advise teams on what they need to do to improve. Remember, reports which are not reviewed and used toward continuous improvement are probably not much use at all.
Follow these five tips, and your company will get the most out of DevSecOps. You’ll cut the chances of mistakes, misadministration and misconfiguration. You’ll also reduce the need for security architects to run through manual configuration of security consoles, and free up the team to build applications that are innovative, secure and delivered quickly.
If you found this information useful, you may also enjoy:
We encourage you to share your thoughts on your favorite social platform.