UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

Defense Information Systems Agency (DISA) Enterprise Development Security Operations (DevSecOps) Continuous

Compliance Monitoring (CCM) Strategy

Version 1, Release 1

30 July 2021

Developed by DISA for the DoD

iUNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

Trademark Information

Names, products, and services referenced within this document may be the trade names, trademarks, or service marks of their respective owners. References to commercial vendors and their products or services are provided strictly as a convenience to our users, and do not constitute or imply endorsement by DISA of any commercial entity, event, product, service, or enterprise.

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

TABLE OF CONTENTS

Page

1. INTRODUCTION..........................................................................11.1 A DevSecOps New World.................................................................................................1

2. OUR VISION...............................................................................23. OUR PURPOSE...........................................................................24. OUR OBJECTIVES........................................................................35. OUR STRATEGY..........................................................................3

5.1 Ensure a strong security posture for mission partners and their DevSecOps environments...............................................................................................................3

5.1.1 Compliance as Code (CaC)......................................................................................45.1.2 CaC Quality Assurance Pipeline..............................................................................5

5.2 Monitor and provide continuous compliance enforcement for all pillars (develop, build, test, deploy, run)..........................................................................................................7

5.2.1 Continuous Compliance Monitoring (CCM)...........................................................75.2.2 Continuous Authorization to Operate (cATO)........................................................9

5.3 Focus on automation and integration for DevSecOps systems.......................................105.3.1 Ways to automate...................................................................................................105.3.2 Pipelines and how they affect automation.............................................................10

5.4 Embrace and adapt new DevSecOps innovation and capability.....................................125.5 Advanced project processes and team innovation to support cutting edge initiatives....12

6. CONCLUSION...........................................................................13

iiiUNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

LIST OF FIGURES

Page

Figure 1 Mission Partner Containerized DevSecOps Example.......................................................2Figure 2 CaC File Usage Example..................................................................................................5Figure 3 DISA CaC Pipeline...........................................................................................................7Figure 4 CCM Mission Partner scan...............................................................................................9

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

LIST OF TABLES

Page

Table 1 Tool Functionality..............................................................................................................6Table 2 SD DevSecOps Tool Listing............................................................................................12

vUNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

1. INTRODUCTION

1.1 A DevSecOps New WorldThis document focuses on the DISA Enterprise DevSecOps Strategy to secure the Department of Defense (DoD) mission partners containerized environments. It is important to understand both DevSecOps and cybersecurity concepts and principles as well as have knowledge of containers and container platforms.

DevSecOps is a set of software development practices that combines software development (Dev), security (Sec), and information technology operations (Ops) to secure the outcome and shorten the development lifecycle. Software features, patches, and fixes occur more frequently and in an automated fashion. Security is applied at all phases of the software lifecycle.

DevSecOps intent is to work with the mindset that security is everyone’s responsibility and that security must be pushed throughout the build stages as far left as possible to ensure that distributing security decisions happens at scale and quickly without sacrificing development efficiency. Keys here are threefold: scale, speed and security. Scale: release to an enterprise environment with the ability to ramp up or ramp down as needed. Speed: release applications often, daily if possible, developing application updates and enhancements quickly is a foundation of DevSecOps. Security: ensure that the applications continuously meet a high standard of security posture for every release. To successfully reach these three keys, it is important that DevSecOps is coupled with Agile and cloud services. The cloud provides a baseline for development whereas the Agile framework provides the necessary process to support this style of development. This document will focus on DevSecOps and will only touch on cloud and Agile aspects.

1UNCLASSIFIED

UNCLASSIFIEDContainer Hardening Process Guide, V1R1 DISA22 June 2020 Developed by DISA for the DoD

Figure 1 Mission Partner Containerized DevSecOps Example

2. OUR VISIONDevSecOps is the industry best practice for rapid, secure software development. It is an organizational software engineering culture that focuses on unifying software development (Dev), security (Sec) and operations (Ops). The DISA DevSecOps vision is to extend the security posture for DoD enterprise applications to mission partners operating in the cloud so that they develop software faster, deliver better quality software, more secure software with less human interference. To achieve this vision, we must:

Support automation throughout build, test and deploy processes. Integrate security seamlessly into build, test and deploy processes. Produce quality compliance tools and data feeds for a strengthened security posture. Support a continuous Authority To Operate (cATO) process that can leverage current

ATO infrastructure in use today to secure environments.

3. OUR PURPOSEThe DevSecOps strategy aims to strengthen DoD DevSecOps environments by:

Providing the DoD community with security guidance and automating that guidance to seamlessly secure DevSecOps environments. STIG and STIG Automation Compliance as Code (CaC)

Continually scanning enterprise container applications for misconfigurations and vulnerabilities (deviations from ATO baseline). Continuous Compliance Monitoring (CCM)

Ensuring that mission partners are following DoD and their organizational policy with their containerized development applications. CCM Open Policy Agent (OPA)

Supporting mission partners directly with people, processes, and technology. DevSecOps guidance, installation help, direction

Strengthening partnerships with commercial vendors to increase engagement, focus, and explore opportunities in mission support and innovative solutions to DevSecOps problems. Choose the best products, remaining on the edge

2UNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

4. OUR OBJECTIVESThe objectives described in this strategy define the interrelated concepts needed to move the DISA DevSecOps from its current state to the DoD’s desired DevSecOps vision. The objectives of this DevSecOps framework are to:

Ensure a strong security posture for mission partners and their DevSecOps environments. Monitor and provide compliance enforcement for all pillars (develop, build, test, deploy,

run). Focus on automation and integration for DevSecOps systems. Embrace and adapt new DevSecOps innovation and capability.

5. OUR STRATEGY

5.1 Ensure a strong security posture for mission partners and their DevSecOps environments

Note: This document focuses on container security. It is understood that any application code or library must be scanned by static/dynamic code analysis tools and passed or have mitigated/accepted the risk prior to being integrated into a container for DoD use. If the application is already approved for use (and scanned) by IC/NSA/DoD CIO/DISA, reciprocity can take effect. This document does not describe the reciprocity process.

The top goal for the DISA’s Service Development Directorate (SD) DevSecOps team is to secure mission partner development environments automatically and easily with the same quality standards used today to safeguard enterprise systems. To do so, it is necessary to employ new technologies and processes while retaining proven approaches that have made securing DoD current systems a cornerstone. The SD DevSecOps team makes every attempt to improve security posture in the DevSecOps arena easy. Integration with existing systems such as Platform One (P1) and the team’s CaC or CCM systems need to integrate effortlessly so mission partners are not deterred from doing so.

Security starts with providing guidance and information to help mission partners configure technology to comply with DoD standards. Over the course of several years, DISA has developed technology security guidance including Security Technical Implementation Guides (STIGs) and Security Requirements Guides (SRGs); these are the reliable, defensive weapons for protecting DoD’s cyberspace.

The SD DevSecOps team improves security posture for mission partners DevSecOps systems by first providing them with STIG automation “ammunition.” Automatable STIG checks from known STIG content that can be executed in a DevSecOps environment automatically as part of a development pipeline that ensures system compliance. This STIG automation or (CaC file ammunition) can be used in a variety of different ways: through tools that scan directly and indirectly; through direct mission partner use; through direct mission partner pipeline use; and in cloud integration systems such as the SD DevSecOps CCM system.

5.1.1Compliance as Code (CaC)

3UNCLASSIFIED

UNCLASSIFIEDContainer Hardening Process Guide, V1R1 DISA22 June 2020 Developed by DISA for the DoD

The SD DevSecOps team has created CaC files from automatable STIG content. STIGs are created today using National Institute of Science and Technology (NIST) Secure Content Automation Protocol’s (SCAP) standard of eXtensible Configuration Checklist Description Format (XCCDF). This eXtensible Markup Language (XML) format allows for easy creation of STIG automation CaC files that can be ingested into various tools. In this manner CaC files can be created easily and quickly.

The CaC files currently are available in two flavors. A Chef InSpec 1 profile version that uses ruby code for the check, and a Prisma 2ruleset version that utilizes Bourne-Again Shell (BASH) script as a basis for the check. For scanning, there are other tools, however, DISA DevSecOps is using, or in the process of using, these two formats of ruby (Chef InSpec) and BASH (Prisma). Currently, files are available for download from GitLab linked to the DISA CyberExchange at https://public.cyber.mil/devsecops/.

The process to use these files is to first determine what technology is required to scan. For example, if you have a docker container that is running MongoDB 3.x with a RHEL7 instance, the MongoDB technology should be chosen with either the ruleset for Prisma or profile for InSpec check. This could be coupled with a RHEL7 check also. Both tools will check for STIG compliance with the Prisma tool checking for vulnerabilities as well.

Figure 2 CaC File Usage Example

5.1.1.1 Scanning ToolsIt is important to provide some discussion and context around tools and the decision to support these tools in the SD DevSecOps projects strategy moving forward.

1 See https://www.chef.io/products/chef-inspec for more information on CHEF InSpec Open Source Software that can be easily integrated directly into DevSecOps environments2 Prisma formerly known as Twistlock see https://www.paloaltonetworks.com/prisma/cloud for more information.

4UNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

Prisma was chosen initially due to its ability to execute a STIG custom compliance check and a vulnerability scan. Prisma requires the CaC check to be written in a BASH script as a ruleset. Aqua Security is another tool that supports STIG custom compliance checks in a BASH script while also providing vulnerability scanning. These tools can be used to perform static scanning of your docker containers and are easily integrated with the mission partners’ pipelines. As of July 2021, both of these tools can scan a container statically, but cannot scan a container at runtime.

DISA selected Chef’s InSpec Open Source Software tool because it provides custom compliance STIG checks and has the ability to perform runtime scanning. Runtime scanning is a very important piece in maintaining docker container security and preventing drift in a containerized environment. The SD DevSecOps team provides information in the DISA GitLab wiki linked to the DISA CyberExchange site on how a mission partner can accomplish this. Chef InSpec is also utilized in the SD DevSecOps CCM system discussed later in this document. Chef InSpec also provides the capability to perform overlay or wrapper checks with the CaC files. For example, if it was necessary to check MongoDB 3.x and RHEL 7 as discussed with our prior illustration, this could be done with a primary CaC profile written as a wrapper. Overlays also allow provide a mechanism to check applications in different ways. For example, Kubernetes component configurations are evaluated by inspecting the process flags of the component, but the process names vary by Kubernetes technology. In the case of a Kubespray, install the ‘Kube API Server’ configurations are evaluated in the check by inspecting the flags of the ‘kube-apiserver’ process. However, in the case of Rancher’s k3s Kubernetes distribution the ‘Kube API Server’ configurations are evaluated by checking the flags for the k3s process starting with ‘--kube-apiserver-arg=’. The InSpec profile overlay will work for both using the proper check in each case.

Using InSpec profile checks in this way provides flexibility in how systems are checked. With this flexibility, it is imperative that CaC files themselves are tested for vulnerabilities, code smells and best practices through a Quality Assurance (QA) pipeline.

Table 1 Tool FunctionalitySupports Chef InSpec Prisma Aqua Security AnchoreSTIG Compliance (CaC files) Yes Yes Yes NoCompliance runtime scanning Yes No No NoVulnerability scanning No Yes Yes YesOverlays or Wrapper Yes No No No

5.1.2CaC Quality Assurance Pipeline

The SD DevSecOps team developed a CaC quality assurance (QA) pipeline to ensure that all CaC files, whether Ruby, BASH or future file types, are developed to a standard that could be approved by DISA. Furthermore, it allows for vendors, government agencies or content

5UNCLASSIFIED

At the time of this writing Anchore has been considering creating custom checks in ruby (InSpec profile) format.

UNCLASSIFIEDContainer Hardening Process Guide, V1R1 DISA22 June 2020 Developed by DISA for the DoD

contributors to create content and allow the CaC files to be used by the general community as open source software (OSS) today. In much the same way that vendors can create STIG guidance for their own products, they can also create the automation or CaC files to go with it.

The SD DevSecOps pipeline was written utilizing GitLab Continuous Integration/Continuous Delivery (CI/CD). The CaC files are currently stored in DISA community GitLab version. Initially, Jenkins was selected for its easy integration with GitHub and its OSS main stream appeal. GitLab CI/CD was ultimately chosen over Jenkins for its pipeline capability due to the vulnerabilities that have not been addressed in Jenkins to date, which some of them have been critical3. The National Vulnerability Database (NVD) can be searched to demonstrate the medium, high and critical vulnerabilities that exist and have not been fixed. It also became apparent that dependent libraries are well over five years old in Jenkins.

The process to employ the pipeline is simple. Once a GitLab account has been created, place the CaC files into the team’s vendor identified GitLab directory. This will begin the QA pipeline process and generate a report in a fully automated fashion. The results and report will be available under the ID created in the public dashboard. The QA pipeline that leverages GitLab CI/CD performs multiple checks of the CaC files submitted to it. The process is shown in Figure 3 below.

Figure 3 DISA CaC Pipeline

The SD DevSecOps pipeline performs various checks on the CaC files submitted. It works on both InSpec profiles (Ruby) and Prisma rulesets (BASH). It performs a check, lint, execution and publish action on the CaC code. The check looks at the code for best practices and formatting. The linting stage analyzes the code for vulnerabilities, errors, and code smells. The execute stage requires a container from the content contributor so that it can be setup in the SD DevSecOps environment and tested against the SD DevSecOps team’s baseline. The execution stage

3 See nvd.nist.gov searching for Jenkins latest product version cpe:/:jenkins:jenkins:2.29

6UNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

validates that the check performs the checks as designed. Once these are executed (they are ran in parallel), the results are published to the dashboards and to a customer report.

For CaC code checks that fail, support personnel are available to help a content contributor resolve issues and bring the CaC code submitted up to DISA standards.

5.2 Monitor and provide continuous compliance enforcement for all pillars (develop, build, test, deploy, run)

5.2.1Continuous Compliance Monitoring (CCM) Continuous Compliance Monitoring (CCM) takes the CaC files that DISA has created and feeds them into tools that can scan mission partners’ environments on a continual basis. Mission partners that have containerized applications can subscribe to the DISA CCM webservice where they will automatically get their environments scanned according to STIG compliance policy. The options will be available to scan for vulnerabilities and organizational policy as well. Tools can scan on a schedule that is mission partner defined, as a container is instantiated and adhoc, if necessary.

With the five stages of DevSecOps development as shown in Figure 1, the DISA CCM team has developed integration points with the runtime stage first due to the greater impact in this pillar. Soon to follow will be integration points with other stages such as build, deploy and test. Mission partners will still utilize the same tools the CCM team uses to scan these areas as desired.

Currently, for the CCM system, DISA SD DevSecOps has developed a CCM Command and Control (C2) pod that will reach out to a mission partners pod ensuring that the mission partner has the latest CaC files necessary to scan the mission partner’s pod. If the mission partner does not have the correct CaC files, the CCM C2 pod will deliver the files to the mission partner environment prior to scanning. Any errors found are logged and alerted on, as needed. Scan results are sent back to the C2 pod so the results can be aggregated and sent to the security team, as necessary. Mission partners can be alerted to any abnormal findings from the scanning. The only requirements from the mission partners’ environment is the InSpec and Aqua Security containers are implemented and run inside the mission partners’ container pod. New pods are scanned as instantiated, and on a schedule defined by the mission partner. The environment can be scanned and alerted on vulnerabilities and organizational policy if the mission partner desires. Figure 4 shows a high-level diagram of how a DISA C2 application would interface with a mission partner’s containerized environment.

7UNCLASSIFIED

UNCLASSIFIEDContainer Hardening Process Guide, V1R1 DISA22 June 2020 Developed by DISA for the DoD

Figure 4 CCM Mission Partner scan

5.2.1.1 CCM Strategy for adoptionThe DISA DevSecOps team’s strategy for adoption is multi-faceted. It requires promotion as well as the creation of an easy and dependable system. The DISA SD DevSecOps team will follow a plan that integrates these facets into a single cohesive approach.

The technical development will operate with an infrastructure that supports multiple mission owners with varying degrees of DevSecOps containerized environments. The CCM system follows an agile (or iterative) approach building upon an initial proof of concept (PoC) until a final PoC is reached. The CCM system will be tested at multiple phases of the build process, including user testing once a stable product is obtained early on. All development and testing will be tracked following an Agile approach that utilizes Jira and Confluence for full and open team collaboration.

In parallel to technical CCM development, CaC profiles and rulesets will continue to be developed as they are critical input to the CCM process and anyone wanting to automate the compliance validation of their DevSecOps environment.

A marketing strategy will execute at the same time CCM development is taking place. Marketing to DoD agencies and components will increase as development of CCM matures. Marketing will include documents that promote the system, PoC’s with various agencies, along with video recorded demonstrations that show the CCM system’s full operation. Demonstrations at various meetings including the DevSecOps Community of Practice (CoP) will occur as frequently as possible. In addition to agency meetings, information will be shared through the DISA Dateline news feature and DISA press releases to disseminate project information. Other similar avenues will be sought out such as communication products and releases from the other DoD

8UNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

components. Commercial avenues will be researched as well such as DISA on LinkedIn4 and DISA Twitter5 (@USDISA).

5.2.2Continuous Authorization to Operate (cATO)The concept of CCM supports the desire to move to a continuous ATO. Continually feeding an ATO system provides the owners of that system, a continuous security posture status for the mission partner’s system over time. There would be no need to “check-in” on a system on a regular basis because all the security information is provided automatically in the system of record. The CCM team has reached out to various ATO systems of record (i.e. eMASS) to determine what it would take to integrate a CCM type of system.

Currently, there are three general areas of interest that require intervention prior to an integration between CCM and eMASS: 1) eMASS API updates; 2) CCM to eMASS data magnitude; and 3) frequency of update. None of these areas are problematic to correct. Based on discussions with the eMASS team, eMASS API updates could be done if the resources were provided to make the required changes. The data magnitude could be completed via a baselining model following that with a frequency update mirrored more toward baseline deltas vs an entire dataset upload. The key to make this upgrade work is to upgrade the eMASS API first and then the teams can work together to put a process in place based on scanning.

The concept of a cATO would have a magnitude of positive impacts on DISA and the DoD. Application teams would merely be able to subscribe to the DISA CCM service and pull a baseline when ready to certify their systems. From that point onward, application teams would continuously ensure that their systems are secure, notifications can be made to the authors and the security team) when updates are needed (or have occurred with full automation) due to drift from the baseline. There would be no need to re-certify any system, as results are automatically updated instantaneously to the ATO system of record. STIG guidance and vulnerabilities would be automatically validated. This approach would save immense users time and DoD resources.

The DoD CIO Defense Security/Cybersecurity Authorization Working Group (DSAWG) working group is currently working on a cATO reference document that will outline concepts of a continuous ATO. When that document is available, it will be published here first: https://dodcio.defense.gov/Library/. It is important to note that this concept is evolving and must obtain reciprocity of concepts prior to DoD wide acceptance.

4 See DISA LinkedIn at: https://www.linkedin.com/company/disa/ for more information5 See DISA on Twitter at https://twitter.com @USDISA for more information

9UNCLASSIFIED

UNCLASSIFIEDContainer Hardening Process Guide, V1R1 DISA22 June 2020 Developed by DISA for the DoD

5.3 Focus on automation and integration for DevSecOps systems

The CCM and CaC systems operate on a DISA SD owned AWS GovCloud. The system has capability to operate on any of the cloud platforms. It can scan from the AWS cloud platform to any other cloud platform if the mission partner is using a Kubernetes style of container platform.

5.3.1Ways to automate The DISA DevSecOps team automates development internally by efficient use of pipelines and by incorporating those pipelines into the integration with our mission partners. If we focus on the CaC process as discussed previously and shown in Figure 2, content contributors can create their content on their own and upload it into the SD DevSecOps GitLab CaC repository. Once there, an automatic process will instantiate tools to check, lint and test the CaC files created for DoD mission partner use. All scan results are automatically created from the pipeline and published directly for mission partner consumption. This ensures that mission partners are directly integrated into the CaC QA pipeline process, content contributors simply (or automatically) upload their content and the feedback is clear and immediate.

As part of the STIG creation process, the eXtensible Configuration Checklist Description Format (XCCDF) is created that contains the markup language for a STIG check. By using the XCCDF file plug-ins created by DISA and MITRE, the DevSecOps team automatically creates starter CaC files for the necessary check tool such as InSpec and Prisma. These plug-ins reduce the time to create the CaC check files by pre-creating the file with the rule ID stub code, where the actual check code can be added easily.

The CCM system also utilizes automation to ensure that scans are automatically taking place in the mission partner’s environment. Containers are automatically scanned prior to execution, and scanning results are automatically fed to the C2 repository. The mission partners subscribe to the DISA SD DevSecOps service and will automatically integrate with the CCM environment. Results are stored and pushed to a cATO repository so the system remains in compliance with very little to no human interference. The DevSecOps team constantly strives to automate as much as possible throughout the system, even automatically ensuring CaC files in use are automatically matched to the mission partner’s containers.

The SD DevSecOps team also uses automated cloud provisioning through infrastructure as code tools such as Ansible and Terraform. A simple way to make installing easier for mission partners is through Helm Charts. Helm Charts are Kuberentes YAML files combined into a single package that can be provided to Kuberentes mission partners. Once packaged, installing into a cluster is as simple as running a single helm install command, which streamlines deployment to mission partners’ containerized applications.

5.3.2Pipelines and how they affect automationPipelines are very important as they facilitate the automatic operation and process from building the applications to executing them. Pipelines are also very flexible in tool integration. Therefore,

10UNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

several tools can be integrated from testing and security scanning all the way to eliminating code smells. It is imperative to move security as far left as possible where flaws can be identified and remediated immediately instead of requiring patching throughout the application’s life cycle. Pipelines provide the ability to include security as far left into the build process as possible. This also ensures code is developed in a consistent, maintainable secure fashion from the very start. Adding additional security checks and quality assurance checks throughout the pipeline is icing on the cake. See Figure 1 for a descriptive image on how a pipeline takes application programming code and processes it into an application; integrating various tools to check, test and secure the application that an enterprise can use. Ultimately, human intervention only occurs at the beginning of the process.

Mission partners can use pipelines as well to automate and integrate with applications or perform all sorts of other functions for the team. From security to testing, pipelines allow for applications to be developed faster and more secure. Through the use of pipelines, this can help commercial customers produce updates and enhancements to their applications from once or twice a year to weekly or even daily in most cases. Thus, resulting in improved quality and security. One of the questions the 2020 DevSecOps Community Survey asked was, “How frequently do you deploy to production?” 55% of the respondents stated that they deployed to production at least once per week.6

5.3.2.1 Tools to support automationThe SD DevSecOps team is very skilled in cybersecurity and DevSecOps development. The team understands that developing a solution when several open source and commercial off the shelf (COTS) products are available is not a disciplined use of project resources. Initially, numerous tool evaluations took place to ensure the compatibility and scalability of tools chosen for integration in the SD DevSecOps solution that would provide the best value.

Below is a list of tools that are used for the SD DevSecOps team solution. Various products are discussed throughout this strategy document, but this list serves to quantify all tools used into a single table.

Table 2 SD DevSecOps Tool ListingVendor Tool CommentsCHEF InSpec See section 5.1.1 for more

informationPalo Alto Prisma (formerly Twistlock) See section 5.1.1 for more

informationGitLab GitLab (code storage)

GitLab CI/CD (pipeline)See section 5.1 for more information

Google KuberentesAqua Aqua Security See section 5.1.1 for more

informationSonatype Nexus Used as a container

repository6 See the Sonatype DevSecOps Community 2020 Report for more information on the practices of mature DevOps organizations.

11UNCLASSIFIED

UNCLASSIFIEDContainer Hardening Process Guide, V1R1 DISA22 June 2020 Developed by DISA for the DoD

CHEF Cookstyle Used for Ruby lintingOpen Source Software ShellCheck Used for BASH lintingElastic co Elastic Search Kibana

Elastic Search LogstashUsed for data display and logging

*Note: Some of these tools also require additional 3rd party libraries that are not included in this list. This list is not exhaustive.

5.4 Embrace and adapt new DevSecOps innovation and capabilityInnovation is part of the strategy for the DISA DevSecOps team. The team’s goal is to develop new automation, integration and improved security. Remaining highly connected to the various DoD and community organizations on the cutting edge supports this approach. Initiatives like zero trust and Artificial Intelligence (AI)/Machine Learning (ML) have been discussed and identified as objectives. AI/ML can be obtained more easily in a highly automated and integrated environment. Technology is quickly moving from physical hardware to software that allows engineers to rapidly configure, frequently perform upgrades and efficiently secure tools. Thus, making it more important than ever to move security to the beginning of the process.

5.5 Advanced project processes and team innovation to support cutting edge initiatives

To support DevSecOps and cloud application development (especially containerized applications), it is necessary to abandon traditional waterfall methods of project management and embrace an Agile philosophy. DevSecOps and Agile methodologies work together in an iterative fashion. Both support iterative automated development. Agile provides the mechanisms to support this type of efficient development through SCRUM and Kanban practices. These methods provide the process and framework to track iterations of code development and facilitate its use. Team and customer communication are enhanced with Agile, and product quality and market availability are improved. In the commercial sector, over 70% of industries have stated they use Agile compared to any other method of development/deployment practices7.

Tools used to support an Agile philosophy include products like Jira and Confluence from the Atlassian suite. Not only do these tools support methodologies such as SCRUM and Kanban, they integrate directly with DevSecOps tooling such as GitLab, Jenkins or GitHub. Having tool integration streamlines all development and prevents team members from manually sharing information as it is available to everyone simultaneously, including the product owners.

The DISA DevSecOps team continues to leverage the DI2E suite of tools. DI2E supplies many software tools in the DevSecOps supply chain. These development tools are available at no cost for any intel-related project in the DoD. DISA DevSecOps chooses to support CI/CD and source management to paid applications such as GitLab. GitLab has proved to retain a highly supported, securely postured tool. The team will continue to leverage cost-effective cutting-edge tools that are highly integrable, easy to automate and support innovative processes.

7 See the Sonatype DevSecOps Community 2020 Report for more information on the processes of mature DevOps organizations.

12UNCLASSIFIED

UNCLASSIFIEDDISA DevSecOps Enterprise Strategy, V1R1 DISA22 June 2021 Developed by DISA for the DoD

6. CONCLUSIONIn conclusion, the DISA SD DevSecOps strategy is to help the DoD DevSecOps programs develop and release software faster (at the speed of relevance), in an automated fashion (where human interaction is at a minimum), in containerized highly scalable environments where maintaining system security is better and easier than it is today. The team does this by providing the following:

STIG automation, CaC files to ensure a strong automatable security posture for mission partners.

Continuous Compliance monitoring, a solution to ensure that containerized applications for all pipeline stages remain with the highest security posture and support a continuous authority to operate with minimal human interaction.

To achieve these goals with a focus on easy integration and automation. Innovating along the way with people, processes, and technology. This includes

technologies such as zero trust, service defined networks, service mesh, artificial intelligence and machine learning. The key is speed and the willingness and ability to adapt and solve complex problems all for our mission partners.

13UNCLASSIFIED