Use DevSecOps to Collaborate and Automate at the DoD

The Defense Department’s (DoD) release of the reference design for the DoD Enterprise DevSecOps Initiative aims to help DoD break free of the slow waterfall process of software development it has traditionally used. Waterfall typically addresses security only as an afterthought. The new approach will help the department keep pace with both the fast-moving world of software development and the ever-shifting cybersecurity landscape.

With continuous delivery, rapid prototyping, and constant testing and feedback, DevSecOps can give the military services and DoD components the tools they need when they need them. But adopting that faster, collaborative model is easier said than done. It requires a cultural change within DoD, in addition to the contributions of many groups, including traditionally siloed stakeholders, such as developers, security team members, procurement offices, and end users. It also means shifting to a methodology of continuous integration, testing, monitoring, security and delivery that marks a significant change from traditional methods.

The DoD Enterprise DevSecOps Initiative spells out its goals clearly: “The main characteristic of DevSecOps is to automate, monitor, and apply security at all phases of the software lifecycle: plan, develop, build, test, release, deliver, deploy, operate and monitor.”

Not surprisingly, many of the best practices of DevSecOps map to those goals:

Automation

A key element of DevSecOps is automation. GitLab automates the continuous integration and delivery pipeline with features including Auto DevSecOps, which handles manual configuration work, such as security auditing and vulnerability testing. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) scans show results directly in the merge request, and dependency scanning and container scanning publish their results in both the merge request and pipeline views.

Collaboration

One of the guiding principles of DevSecOps is that everyone is responsible for security. DevSecOps.org’s manifesto stresses open contributions and collaboration, sharing information such as threat intelligence, putting results over checklists, and trusting data security and data science over doubts and fears — all of which require open communication.

Continuous Everything

Continuous testing is a part of any Agile development methodology. DevSecOps testing should cover a full range of areas, including front-end, back-end, application programming interfaces, databases and passive security testing. Continuous integration tools can help automate security checks. Finally, everything is continuous with DevSecOps, including delivery, version control, monitoring and remediation.

Simplify

A common refrain in DevSecOps is to keep code simple, since needlessly complex code works against security and efficiency. Developers can apply a coding standard to keep their code simple, enhancing collaboration with other developers who can easily understand their code at a glance.

Choosing the right tools

The General Services Administration (GSA)’s guide to Building a DevSecOps Culture notes several key metrics to ensure continuous development, threat detection, and release cycles. It includes measuring deployment frequency; lead time; detection of threats, security defects, and flaws; mean time to repair; and mean time to recovery. It also cites threat modeling, code reviews, and red teaming as keys to detecting security issues.

This article is an excerpt from GovLoop’s recent report, “The Right Application Platform Can Help DoD Develop Its DevSecOps Culture.” Download the full report to explore an overview of DevSecOps’ use and perception in government here.