8 Principles for Securing DevOps

Although still in its infancy in the public sector, making the shift to DevOps methodologies is starting to catch on with many government agencies, including the U.S. Citizenship and Immigration Services, the EPA, and Nuclear Regulatory Commission.

As you may know, with DevOps, IT tasks and application deployment that would normally take months or years, now take weeks.

But Rome wasn’t built in a day.

The transition to DevOps involves the shift to a new cultural paradigm of collaboration not silos, autonomous teams with decision-making power, and a focus on quality as part of development. It’s a shift that can be hard for teams used to the waterfall approach of developing and deploying apps.

But, what if you throw security into the mix?

How do you secure your code when you’re developing at the speed of DevOps? How do you align the goals of development and ops with security? How do you build security into the pipeline? Securing DevOps isn’t a quick and easy process.

To help application developers and wider security teams understand the elements of secure DevOps, DLT’s IT security partner, Veracode, offers eight principles for securing DevOps in this Secure DevOps Survival Guide that are worth checking out.

Here’s a summary:

1. Automate Security In – Veracode recommends that IT teams build testing directly into the DevOps pipeline through automation. Fail tests as early as possible in the DevOps pipeline.

2. Integrate Application Security into the Dev Tools You Already Use – Integrate security to avoid friction. Security assessments should integrate with your IDE, build and ticketing systems to automatically test code and coordinate remediation. This ensures that security testing happens with each release and avoids the problem of leaving application security in the hands of a developer or as a late step in the process.

3. Fix Flaws as you Write Code – Give developers tools to find and fix coding errors while they write code, with immediate feedback before check-in, including developer sandboxes, “as-you-type” static testing and eLearning.

4. Build Security Champions – Most developers aren’t trained in secure coding practices. Designate developers with an interest in security as security champions. Their role is to reduce culture conflict between development and security by amplifying the security message on a peer-to-peer level.

5. Adapt to New Dev Practices and Techniques – DevOps is all about adopting to new things including containerization, microservices, continuous integration, infrastructure-as-code, new languages, new KPIs, etc.

6. Don’t Stop for False Alarms – Don’t tolerate application security solutions that have a high false alarm rate. A technology that reports too many false positives will be ignored and will fail to be adopted. This is doubly true in CI/CD, where a failed security test may stop a critical business function from being delivered to production — or a critical patch from being released. That may be tolerable if the security issue is real, but is intolerable if the finding is a false positive.

7. Extend App Security into Production – Application security shouldn’t stop after deployment. As with other aspects of DevOps, a well-engineered solution must support closed-loop feedback from production in the event of a security incident.

8. Provide Operational Visibility – Although DevOps encourages team autonomy, ops and security need visibility to measure and assess teams for compliance and risk.

Check out the guide for more insights, including a map of how to integrate security into the entire software development lifecycle.