NIST’s new devsecops guidance to aid transition to cloud-native apps

The United States federal government, much like in industry, is moving toward cloud adoption, Devsecops and microservices-based architectures for cloud-native applications. The National Institute of Standards of Technology (NIST) is tasked with promoting innovation and providing standards and guidance to industry to facilitate best practices.

In that vein, NIST released in late September Implementation of devsecops for a Microservices-based Application with Service Mesh (800-204C), which provides comprehensive guidance for implementation of devsecops and using reference platforms to host cloud-native applications in a microservices architecture using a service mesh. The document, currently in draft form, was created in collaboration with former US Air Force Chief Software Officer Nicholas Challain and individuals from service mesh leader Tetrate.

The guidance uses the concepts of primitives, which can be thought of as building blocks for successful devsecops implementations, as they relate to devsecops. It makes the case that devsecops primitives are best suited for microservices-based applications that allow agile development. It also supports the notion that devsecops facilitates the business agility requirements demanded by cloud-native applications.

Here’s an analysis of what’s in each section of the NIST guidance.

Reference Platform for the Implementation of Devsecops Primitives           

The guidance discusses a reference platform in the context of a container orchestration and management platform. This is put into place by building on top of either physical or virtual underlying infrastructure, such as classified or disconnected austere environments (physical) or virtualized, such as cloud service provider (CSP) environments such as AWS and Azure.

The guidance also makes the case for the use of container orchestration and resource management platforms, most notably Kubernetes, which is the most popular open-source container orchestration platform. Kubernetes can deploy pods that host containerized applications on underlying physical or virtual machines. By using groups of nodes, hosting pods, Kubernetes is able to distribute workloads for microservices across the underlying infrastructure to support load balancing and scaling.

That said, the underlying Kubernetes platform is not without its own security and performance concerns. One of which is the need to be able to handle traffic splitting and routing across pods in various formats, such as round robin.

This is where service mesh software such as Istio comes into play. It facilitates much of the traffic routing and observability required by microservices based applications. The service mesh architecture consists of two primary components, a data plane and control plane. The functions they perform include secure networking, policy enforcement and observability of traffic and performance (data plane) as well as key and certification management and managing inbound and outbound connections (control plane).

Devsecops—Organizational Preparedness, Key Primitives, and Implementation

This section lays out how organizations should prepare to implement devsecops, transitioning from devops to devsecops, and what the building blocks (primitives) of devsecops are. Logically, this section likely should have come first in the document.

The guidance emphasizes the need to make a shift in organizational IT departments and workflows to help facilitate the shift to devsecops. Cross-functional teams of developers, security specialists, and IT operations experts are key to ensuring organizations achieve devsecops and break down the silos that traditionally exist.

NIST goes to great lengths to stress that there is an evolution from devops to devsecops and that devops traditionally has lacked security testing and integration of security controls as well as real-time assurance of security postures. This is an interesting assertion, considering many experts make the case that devops and devsecops should be the same thing and devops should have always included security. Does what’s in a name matter, or do the outcomes and practices matter the most?

That said, the case is made that specific key building blocks that are lacking in devops must exist for devsecops. These include integrating security testing into CI/CD pipelines, ensuring security controls of both what is going through the pipeline as well as securing the pipeline itself. and ensuring security isn’t relegated as a separate task, often seen as something that is “bolted on” at the end of a development lifecycle.

Building on the discussion of pipelines, the guidance stresses that pipelines should essentially be one job that flows throughout the various stages of building, testing, securing and delivering code and value to an organization. Depending on if the organization is implementing continuous integration, continuous delivery or continuous deployment, there may be additional manual gates between testing and deployment to production environments, as demonstrated in the images below.

NIST

CI/CD is ultimately made up of three primary stages, which are build/test, ship/package and deployment. While pipelines can facilitate CI/CD, they are made up of tasks and entities as well including setting up a source-code repository, the build process, securing that build process, the deployment environment, the delivery pipeline and lastly testing the code and executing the pipeline workflow.

While CI/CD pipelines support automation and expedited deployment, NIST stresses that humans are still involved in various capacities. This could be development teams incorporating new features, security teams performing audits, and teams designing and creating pipelines to facilitate workflows.

Automation is a key component of implementing devsecops and expedited delivery. That said, determining which activities to automate could be problematic. NIST guidance includes focusing on repetitive high-frequency tasks, compliance-oriented tasks and activities that are time-sequenced. Embracing automation in this way frees teams to focus on analytical problem solving and ingenuity rather than routine tasks and activities.

Considerations for integrating tools into the pipelines include ease of integration, accessible interfaces, and the ability to support a wide variety of back-end infrastructure components. These are necessary due to the environments in which containerized applications could be hosted and the need to be versatile and dynamic.

Implementing Devsecops Primitives for the Reference Platform

NIST’s guidance emphasizes that many CI/CD pipelines may be involved in a reference platform. These could be pipelines for application code, infrastructure as code (IaC), policy as code or observability as code. Regardless of code type, all these pipelines require securing the pipeline itself, addressing workflow models, and integrating appropriate security testing. The document lays out key aspects for the pipelines associated with each code type.

While CI/CD is often touted as improving the security of code going through, The pipeline itself must also be secured to ensure no malicious code is inserted and distributed (e.g., SolarWinds). Securing the pipeline involves authentication, logging, build reports to developers and security teams, and multi-partying signing of artifacts such as using TUF and in-toto.

NIST lays out the workflow models in CI/CD pipelines, which are push- or pull-based. It makes the case that push-based workflows can be insecure due to exposing credentials outside the deployment environment. Instead, it makes the case for the use of a GitOps style facilitated by pull-based workflows. This approach uses an operator to run in the deployment environment and pull new images into the environment when the operator observes changes at the source code management (SCM) repository. GitOps is increasingly becoming an industry standard, allowing organizations to allow the SCM to be the source of truth and lean-into features. It can also offer value such as versioning, drift control, and removing manual interactions with environments instead of leveraging a Git-driven workflow.

Security testing is critical regardless of which pipeline code you’re dealing with. NIST lays out common security testing, including static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), and software composition analysis. All these testing types are critical to drive down risk and identify concerning vulnerabilities. These scans can be looking for vulnerabilities, container image issues and compliance concerns. There is also a need to scan IaC templates for security and compliance concerns to catch them prior to getting to a runtime environment, also known as shifting security left. That said, this doesn’t negate the need to maintain visibility and awareness of runtime vulnerabilities that may occur.

NIST’s guidance discusses devsecops in the context of continuous authority to operate (cATO), which is the authorization for a system to be in production, but it is light in this area. Compliant code can be discovered and dashboards can provide runtime visibility. That said, more robust cATO guidance will likely be found in the US Department of Defense (DoD) upcoming cATO Guide, which will be more comprehensive covering authorizing platforms, teams, and processes. The DoD has also recently released a slew of devsecops documents, such as an enterprise strategy, playbook and fundamentals document.

NIST is soliciting comments on the draft SP 800-204C document, and they are due November 1.