Making the Switch from DevOps to DevSecOps

DevOps became part of the fashionable lexicon for software development a few years ago. The government, at least here and there, has adopted the concept enthusiastically. More recently and with growing urgency, the syllable “Sec” – for security – has joined the DevOps concept. Many federal IT shops call it DevSecOps.

But what exactly is DevOps? This contraction of development operations has no single precise definition, but it applies to an approach of small, functional increments, released at short intervals to production in a condensed process of compile-test-debug-and-certify.

Some practitioners call it the “pipeline” approach. DevOps usually goes along with agile methodology, but the two are not the same.

For federal agencies, no less than for large corporations, the caveat has always been, “Will this block of code work interoperably with my existing applications? Will it not break anything and execute properly with production data?” No matter how software is developed by or for the government, it must carry that surety before it received ATO, or authority to operate, in a system of record.

Luckily a number of development environments, proprietary and open source, include tools to automate much of the code and interoperability checking, enabling the pipeline to really flow.

Agencies have several reasons to want to use DevOps and DevSecOps. Nearly every federal entity has legacy code it wants to modernize, if only to save the maintenance costs and difficulties of maintaining legacy code. Some have a pressing need for new applications – plenty of federal processes remain paper-based! And still, others are wanting to deploy digital services to the public. This last class of application often requires the use of legacy data, which adds the requirement to build application programming interfaces. And in all cases, there is the need to have applications that run in both on-premise data centers and commercial clouds.

Ensuring security is built into DevOp-derived functions adds a few requirements. The toolset should accommodate controls specified by the National Institute of Standards and Technology documents. Ideally, it automates the function of ensuring that open-sourced elements are the latest versions with all of the security updates. And it should check for compatibility with controls already built into the functions the new code will be integrated. You can’t have an efficient DevSecOps pipeline if the Sec components shunt otherwise finished code to a siding.

Put another way, in the DevSecOps model the security gets treated as integrally as all of the over code quality checks.

A final and crucial element in any DevSecOps endeavor is the team – not just of the coders and QC people, but also of the program owners and users. The team also includes the cybersecurity people. Each constituent knows what it needs. The earlier in the development process its requirements are expressed, the more surely the right elements will get baked into the resulting software.

As the experts put it, you always want the software to keep moving right towards completion, not backward towards rework for functionality, interoperability or security.