“Implementing DevSecOps for Microservices-Based Apps” NIST New Guide

The U.S. federal government, like private companies, is transitioning to cloud, Devsecops, and microservices-based architectures for cloud-native applications. The National Institute of Standards and Technology (NIST) provides standards and guidance for industry adoption of best practices and encourages innovation.
ⓒ Getty Images Bank

To this end, NIST last September announced a DevSecOps implementation for microservices-based applications using Service Mesh (800-204C). A comprehensive guide to implementing DevSecOps and using a reference platform using a service mesh to host cloud-native applications on a microservices architecture. This document, currently in draft form, was created in collaboration with former US Air Force Chief Software Officer Nicholas Chalein and service mesh leader Tetrate.

This guide used the concept of primitives, the building blocks for a successful DevSecOps implementation. DevSecOps primitives are best suited for microservices-based applications for agile development. It also supports the concept that DevSecOps facilitates the business agility requirements required for cloud-native applications. Let’s analyze the contents of each session of the NIST guide.

Reference platform for implementing DevSecOps primitives

This guide deals with the reference platform in the context of a container orchestration and management platform. Building on top of a physical or virtual-based infrastructure, for example, in a classified or disconnected rigid environment (physical) or a virtualized environment such as a cloud service provider (CSP) environment such as AWS or Azure.

The guide recommends using a container orchestration and resource management platform. One of the most popular open source container orchestration platforms is Kubernetes. Kubernetes can be deployed on physical or virtual machines based on pods that host containerized applications. By using node groups and hosting pods, Kubernetes can distribute workloads for microservices across the underlying infrastructure to support load balancing and scaling.

Of course, the Kubernetes platform also has its own security and performance concerns. One of them is to be able to handle traffic segmentation and routing across different types of pods, including round robin.

Service mesh software such as Istio is used for that very purpose. Service mesh software provides most of the traffic routing and observability required for microservices-based applications. A service mesh architecture consists of two main components: a data plane and a control plane. Both components perform functions such as secure networking, policy enforcement, traffic and performance observability (data plane), key and certificate management, and inbound/outbound connection management (control plane).

DevSecOps Organizational Preparation, Key Primitives, and Implementation

This session will cover the right way to prepare and transition from DevSecOps to DevSecOps in institutions and enterprises, and the components (Primitives) of DevSecOps. In fact, this session should appear at the very beginning of the document.

The guide highlights the need for changes to enterprise IT departments and workflows to facilitate the transition to DevSecOps. A cross-functional team of developers, security experts, and IT operations experts is essential for enterprises to achieve DevSecOps and break down traditional silos.

NIST refers to the evolution from DevOps to DevSecOps, emphasizing that DevOps traditionally lacks security testing and integration of security controls and real-time security posture checks. This is an interesting argument, given that many experts say that DevOps and DevSecOps are the same and that DevOps should always include security. The term in the name, or the result and the method, which is the most important?

Anyway, the point is that DevSecOps must have some specific core components that DevOps doesn’t have. This includes integrating security testing into the CI/CD pipeline, understanding what is going on in the pipeline, and having security controls in place to protect the pipeline itself, and ensuring that security is not relegated to a separate task. do. Security is often seen as an ‘additional’ factor at the end of the development lifecycle.

In addition to the discussion of pipelines, this guide emphasizes that pipelines should be a single task that flows through the various stages to build, test, secure code, and provide value to the enterprise. Depending on whether the enterprise implements continuous integration, continuous delivery, or continuous deployment, there may be additional manual steps between the test and production environment deployments (see figure).


CI/CD ultimately consists of three phases: build/test, delivery/package, and deployment. Pipelines can facilitate CI/CD, but tasks and entities are also what make up a pipeline, including setting up source code repositories, building processes, protecting build processes, deployment environments, delivery pipelines, and finally code testing and pipelines. Workflow execution is included.

While the CI/CD pipeline supports automation and rapid deployment, NIST emphasizes that there are still many areas of human intervention. There is a development team that introduces new features, a security team that performs audits, and a team that designs and creates pipelines to facilitate workflows.

Automation is an important component for enabling DevSecOps and Rapid Delivery. But deciding which tasks to automate can be challenging. According to the NIST guide, you should focus on high-frequency repetitive tasks, compliance-oriented tasks, and chronological activities. Adopting automation in this way allows teams to focus on solving analytical problems by reducing time wasted on routine tasks and activities.

Considerations for integrating tools into the pipeline include ease of integration, accessible interfaces, and the ability to support various backend infrastructure components. The reason for this need is the environment in which containerized applications can be hosted, and the need to be flexible and dynamic.

DevSecOps primitive implementation for reference platform

NIST’s guide highlights that a reference platform can involve many CI/CD pipelines. There may also be pipelines for application code, infrastructure as code (IaC), policies as code, or observability as code. All of these pipelines, regardless of code type, require protection for the five lines themselves, processing the workflow model, and proper integration of security tests. The documentation describes the important aspects of the pipeline associated with each type of code.

CI/CD is often said to improve the security of code, but the pipeline itself must also be protected to prevent the introduction and distribution of malicious code (SolarWinds example). Pipeline protection includes authentication, logging, build reports available to developers and security teams, and signing artifacts by multiple parties, for example using TUF and in-toto.

NIST presents a workflow model for a CI/CD pipeline that is either push- or pull-based. The guide argues that push-based workflows can be insecure because they can expose credentials outside the departmental environment. Instead, it insists on using a GitOps style that is facilitated by a pull-based workflow.

This method runs the deployment environment through an operator and pulls a new image into the environment when the operator observes a change in the Source Code Management (SCM) repository. GitOps is slowly emerging as an industry standard, enabling organizations to use and rely on SCM as a source of truth. It can also provide value such as version control, drift control, and removal of manual iterations from the environment instead of leveraging Git-based workflows.

Security testing is important no matter what pipeline you are dealing with. NIST provides static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), and software composition analysis. We present general security tests including

All of these types of tests are very important to lower your risk and identify vulnerabilities. These scans can uncover vulnerabilities, container image issues, and compliance concerns. There is also the need to check for security and compliance issues in IaC templates before they reach the runtime environment. This is called shifting security left. Of course, you need to keep an eye on and awareness of runtime vulnerabilities.

NIST’s guide discusses DevSecOps in the context of a Continuous Authority To Operate (cATO) that authorizes systems to be placed in production. Compliance code can be discovered, and dashboards can provide runtime visibility. You may find a more thorough cATO guide in the cATO guide to be released by the Department of Defense (DoD). The DoD Guide will cover platform, team and process authorization more comprehensively. The DoD has recently published several DevSecOps documents, including corporate strategy, playbooks, and groundbreaking documents.

NIST will collect comments on draft SP 800-204C document by November 1st. [email protected]

Source: ITWorld Korea by www.itworld.co.kr.

*The article has been translated based on the content of ITWorld Korea by www.itworld.co.kr. If there is any problem regarding the content, copyright, please leave a report below the article. We will try to process as quickly as possible to protect the rights of the author. Thank you very much!

*We just want readers to access information more quickly and easily with other multilingual content, instead of information only available in a certain language.

*We always respect the copyright of the content of the author and always include the original link of the source article.If the author disagrees, just leave the report below the article, the article will be edited or deleted at the request of the author. Thanks very much! Best regards!