Share via

Security Control: DevOps security

  • Article

DevOps Security covers the controls related to the security engineering and operations in the DevOps processes, including deployment of critical security checks (such as static application security testing, vulnerability management) prior to the deployment phase to ensure the security throughout the DevOps process; it also includes common topics such as threat modeling and software supply security.

DS-1: Conduct threat modeling

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
16.10, 16.14 SA-15 6.5, 12.2

Security principle: Perform threat modeling to identify the potential threats and enumerate the mitigating controls. Ensure your threat modeling serves the following purposes:

  • Secure your applications and services in the production run-time stage.
  • Secure the artifacts, underlying CI/CD pipeline and other tooling environment used for build, test, and deployment. The threat modeling at least should include the following aspects:
  • Define the security requirements of the application. Ensure these requirements are adequately addressed in the threat modeling.
  • Analyze application components, data connections and their relationship. Ensure this analysis also includes the upstream and downstream connections outside of your application scope.
  • List the potential threats and attack vectors that your application components, data connections and upstream and downstream services may be exposed to.
  • Identify the applicable security controls that can be used to mitigate the threats enumerated and identify any controls gaps (e.g., security vulnerabilities) that may require additional treatment plans.
  • Enumerate and design the controls that can mitigate the vulnerabilities identified.

Azure guidance: Use threat modeling tools such as the Microsoft threat modeling tool with the Azure threat model template embedded to drive your threat modeling process. Use the STRIDE model to enumerate the threats from both internal and external and identify the controls applicable. Ensure the threat modeling process includes the threat scenarios in the DevOps process, such as malicious code injection through an insecure artifacts repository with misconfigured access control policy.

If using a threat modeling tool is not applicable, you should, at minimum, use a questionnaire-based threat modeling process to identify the threats.

Ensure the threat modeling or analysis results are recorded and updated when there is a major security-impact change in your application or in the threat landscape.

Azure implementation and additional context:

AWS guidance: Use threat modeling tools such as the Microsoft threat modeling tool with the Azure threat model template embedded to drive your threat modeling process. Use the STRIDE model to enumerate the threats from both internal and external and identify the controls applicable. Ensure the threat modeling process includes the threat scenarios in the DevOps process, such as malicious code injection through an insecure artifacts repository with misconfigured access control policy.

If using a threat modeling tool is not applicable, you should, at minimum, use a questionnaire-based threat modeling process to identify the threats.

Ensure the threat modeling or analysis results are recorded and updated when there is a major security-impact change in your application or in the threat landscape.

AWS implementation and additional context:

GCP guidance: Use threat modeling tools such as the Microsoft threat modeling tool with the Azure threat model template embedded to drive your threat modeling process. Use the STRIDE model to enumerate the threats from both internal and external and identify the controls applicable. Ensure the threat modeling process includes the threat scenarios in the DevOps process, such as malicious code injection through an insecure artifacts repository with misconfigured access control policy.

If using a threat modeling tool is not applicable, you should, at minimum, use a questionnaire-based threat modeling process to identify the threats.

Ensure the threat modeling or analysis results are recorded and updated when there is a major security-impact change in your application or in the threat landscape.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

DS-2: Ensure software supply chain security

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
16.4, 16.6, 16.11 SA-12, SA-15 6.3, 6.5

Security principle: Ensure your enterprise’s SDLC (Software Development Lifecycle) or process include a set of security controls to govern the in-house and third-party software components (including both proprietary and open-source software) where your applications have dependencies. Define gating criteria to prevent vulnerable or malicious components being integrated and deployed into the environment.

The software supply chain security controls should at least include the following aspects:

  • Properly manage a Software Bill of Materials (SBOM) by identifying the upstream dependencies required for the service/resource development, build, integration and deployment phase.
  • Inventory and track the in-house and third-party software components for known vulnerability when there is a fix available in the upstream.
  • Assess the vulnerabilities and malware in the software components using static and dynamic application testing for unknown vulnerabilities.
  • Ensure the vulnerabilities and malware are mitigated using the appropriate approach. This may include source code local or upstream fix, feature exclusion and/or applying compensating controls if the direct mitigation is not available.

If closed source third-party components are used in your production environment, you may have limited visibility to its security posture. You should consider additional controls such as access control, network isolation and endpoint security to minimize the impact if there is a malicious activity or vulnerability associated with the component.

Azure guidance: For the GitHub platform, ensure the software supply chain security through the following capability or tools from GitHub Advanced Security or GitHub’s native feature:- Use Dependency Graph to scan, inventory and identify all your project’s dependencies and related vulnerabilities through Advisory Database.

  • Use Dependabot to ensure that the vulnerable dependency is tracked and remediated, and ensure your repository automatically keeps up with the latest releases of the packages and applications it depends on.
  • Use GitHub's native code scanning capability to scan the source code when sourcing the code externally.
  • Use Microsoft Defender for Cloud to integrate vulnerability assessment for your container image in the CI/CD workflow. For Azure DevOps, you can use third-party extensions to implement similar controls to inventory, analyze and remediate the third-party software components and their vulnerabilities.

Azure implementation and additional context:

AWS guidance: If you use AWS CI/CD platforms such as CodeCommit or CodePipeline, ensure the software supply chain security using CodeGuru Reviewer to scan the source code (for Java and Python) through the CI/CD workflows. Platforms such as CodeCommit and CodePipeline also supports third-party extensions to implement similar controls to inventory, analyze and remediate the third-party software components and their vulnerabilities.

If you manage your source code through the GitHub platform, ensure the software supply chain security through the following capability or tools from GitHub Advanced Security or GitHub’s native feature:

  • Use Dependency Graph to scan, inventory and identify all your project’s dependencies and related vulnerabilities through Advisory Database.
  • Use Dependabot to ensure that the vulnerable dependency is tracked and remediated, and ensure your repository automatically keeps up with the latest releases of the packages and applications it depends on.
  • Use GitHub's native code scanning capability to scan the source code when sourcing the code externally.
  • If applicable, use Microsoft Defender for Cloud to integrate vulnerability assessment for your container image in the CI/CD workflow.

AWS implementation and additional context:

GCP guidance: Use Software Delivery Shield to perform end-to-end software supply chain security analysis. This includes Assured OSS (Open Source Software) service for access and incorporate the OSS packages that have been verified and tested by Google, as well as validated Java and Python packages that are built using Google's secure pipelines. These packages are regularly scanned, analyzed, and tested for vulnerabilities. Such capabilities can be integrated into Google Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis as part of the CI/CD workflows.

If you manage your source code through the GitHub platform, ensure the software supply chain security through the following capability or tools from GitHub Advanced Security or GitHub’s native feature:

  • Use Dependency Graph to scan, inventory and identify all your project’s dependencies and related vulnerabilities through Advisory Database.
  • Use Dependabot to ensure that the vulnerable dependency is tracked and remediated, and ensure your repository automatically keeps up with the latest releases of the packages and applications it depends on.
  • Use GitHub's native code scanning capability to scan the source code when sourcing the code externally.
  • If applicable, use Microsoft Defender for Cloud to integrate vulnerability assessment for your container image in the CI/CD workflow.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

DS-3: Secure DevOps infrastructure

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
16.7 CM-2, CM-6, AC-2, AC-3, AC-6 2.2, 6.3, 7.1

Security principle: Ensure the DevOps infrastructure and pipeline follow security best practices across environments including your build, test, and production stages. This typically includes the security controls for following scope:

  • Artifact repositories that store source code, built packages and images, project artifacts and business data.
  • Servers, services, and tooling that host CI/CD pipelines.
  • CI/CD pipeline configuration.

Azure guidance: As part of applying the Microsoft Cloud Security Benchmark to your DevOps infrastructure security controls, prioritize the following controls:

  • Protect artifacts and the underlying environment to ensure the CI/CD pipelines don’t become avenues to insert malicious code. For example, review your CI/CD pipeline to identify any misconfiguration in core areas of Azure DevOps such as Organization, Projects, Users, Pipelines (Build & Release), Connections, and Build Agent to identify any misconfigurations such as open access, weak authentication, insecure connection setup and so on. For GitHub, use similar controls to secure the Organization permission levels.
  • Ensure your DevOps infrastructure is deployed consistently across development projects. Track compliance of your DevOps infrastructure at scale by using Microsoft Defender for Cloud (such as Compliance Dashboard, Azure Policy, Cloud Posture Management) or your own compliance monitoring tools.
  • Configure identity/role permissions and entitlement policies in Azure AD, native services, and CI/CD tools in your pipeline to ensure changes to the pipelines are authorized.
  • Avoid providing permanent “standing” privileged access to the human accounts such as developers or testers by using features such as Azure managed identifies and just-in-time access.
  • Remove keys, credentials, and secrets from code and scripts used in CI/CD workflow jobs and keep them in a key store or Azure Key Vault.
  • If you run self-hosted build/deployment agents, follow Microsoft Cloud Security Benchmark controls including network security, posture and vulnerability management, and endpoint security to secure your environment.

Note: Refer to the Logging and Threat Detection, DS-7, and the Posture and Vulnerability Management sections to use services such as Azure Monitor and Microsoft Sentinel to enable governance, compliance, operational auditing, and risk auditing for your DevOps infrastructure.

Azure implementation and additional context:

AWS guidance: As part of applying the Microsoft Cloud Security Benchmark to the security controls of your DevOps infrastructure, such as GitHub, CodeCommit, CodeArtifact, CodePipeline, CodeBuild and CodeDeploy, prioritize the following controls:

  • Refer to this guidance and the AWS Well-architected Framework security pillar to secure your DevOps environments in AWS.
  • Protect artifacts and the underlying supporting infrastructure to ensure the CI/CD pipelines don’t become avenues to insert malicious code.
  • Ensure your DevOps infrastructure is deployed and sustained consistently across development projects. Track compliance of your DevOps infrastructure at scale by using AWS Config or your own compliance check solution.
  • Use CodeArtifact to securely store and share software packages used for application development. You can use CodeArtifact with popular build tools and package managers such as Maven, Gradle, npm, yarn, pip, and twine.
  • Configure identity/role permissions and permission policies in AWS IAM, native services, and CI/CD tools in your pipeline to ensure changes to the pipelines are authorized.
  • Remove keys, credentials, and secrets from code and scripts used in CI/CD workflow jobs and keep them in key store or AWS KMS
  • If you run self-hosted build/deployment agents, follow Microsoft Cloud Security Benchmark controls including network security, posture and vulnerability management, and endpoint security to secure your environment. Use AWS Inspector for vulnerability scanning for vulnerabilities in EC2 or containerized environment as the build environment.

Note: Refer to the Logging and Threat Detection, DS-7, and the and Posture and Vulnerability Management sections to use services such as AWS CloudTrail, CloudWatch and Microsoft Sentinel to enable governance, compliance, operational auditing, and risk auditing for your DevOps infrastructure.

AWS implementation and additional context:

GCP guidance: As part of applying the Microsoft Cloud Security Benchmark to your DevOps infrastructure security controls, prioritize the following controls:

  • Protect artifacts and the underlying environment to ensure the CI/CD pipelines don’t become avenues to insert malicious code. For example, review your CI/CD pipeline to identify any misconfiguration in services such as Google Cloud Build, Cloud Deploy, Artifact Registry, Connections, and Build Agent to identify any misconfigurations such as open access, weak authentication, insecure connection setup and so on. For GitHub, use similar controls to secure the Organization permission levels.
  • Ensure your DevOps infrastructure is deployed consistently across development projects. Track compliance of your DevOps infrastructure at scale by using Google Cloud Security Command Center (such as Compliance Dashboard, Organizational Policy, Record of individual threat and Identifying misconfigurations) or your own compliance monitoring tools.
  • Configure identity/role permissions and entitlement policies in Cloud Identity/AD native services, and CI/CD tools in your pipeline to ensure changes to the pipelines are authorized.
  • Avoid providing permanent “standing” privileged access to the human accounts such as developers or testers by using features such as Google managed identifies.
  • Remove keys, credentials, and secrets from code and scripts used in CI/CD workflow jobs and keep them in a key store or Google Secret Manager.
  • If you run self-hosted build/deployment agents, follow Microsoft Cloud Security Benchmark controls including network security, posture and vulnerability management, and endpoint security to secure your environment.

Note: Refer to the Logging and Threat Detection, DS-7, and the Posture and Vulnerability Management sections to use services such as Azure Monitor and Microsoft Sentinel or Google Cloud’s operations suite and Chronicle SIEM and SOAR to enable governance, compliance, operational auditing, and risk auditing for your DevOps infrastructure.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

DS-4: Integrate static application security testing into DevOps pipeline

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
16.12 SA-11 6.3, 6.5

Security principle: Ensure static application security testing (SAST) fuzzy testing, interactive testing, mobile application testing, are part of the gating controls in the CI/CD workflow. The gating can be set based on the testing results to prevent vulnerable packages from committing into the repository, building into the packages, or deploying into the production.

Azure guidance: Integrate SAST into your pipeline (e.g., in your infrastructure as code template) so the source code can be scanned automatically in your CI/CD workflow. Azure DevOps Pipeline or GitHub can integrate the below tools and third-party SAST tools into the workflow.

  • GitHub CodeQL for source code analysis.
  • Microsoft BinSkim Binary Analyzer for Windows and *nix binary analysis.
  • Azure DevOps Credential Scanner (Microsoft Security DevOps extension) and GitHub native secret scanning for credential scan in the source code.

Azure implementation and additional context:

AWS guidance: Integrate SAST into your pipeline so the source code can be scanned automatically in your CI/CD workflow.

If using AWS CodeCommit, use AWS CodeGuru Reviewer for Python and Java source code analysis. AWS Codepipeline can also support integration of third-part SAST tools into the code deployment pipeline.

If using GitHub, the below tools and third-party SAST tools can be integrated into the workflow.

  • GitHub CodeQL for source code analysis.
  • Microsoft BinSkim Binary Analyzer for Windows and *nix binary analysis.
  • GitHub native secret scanning for credential scan in the source code.
  • AWS CodeGuru Reviewer for Python and Java source code analysis.

AWS implementation and additional context:

GCP guidance: Integrate SAST (such as Software Delivery Shield, Artifact Analysis) into your pipeline (e.g., in your infrastructure as code template) so the source code can be scanned automatically in your CI/CD workflow.

Services such as Cloud Build, Cloud Deploy, Artifact Registry support the integration with Software Delivery Shield and Artifact Analysis which can scan source code and other artifacts in the CI/CD workflow.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

DS-5: Integrate dynamic application security testing into DevOps pipeline

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
16.12 SA-11 6.3, 6.5

Security principle: Ensure dynamic application security testing (DAST) are part of the gating controls in the CI/CD workflow. The gating can be set based on the testing results to prevent vulnerability from building into the packages or deploying into the production.

Azure guidance: Integrate DAST into your pipeline so the runtime application can be tested automatically in your CI/CD workflow set in Azure DevOps or GitHub. The automated penetration testing (with manual assisted validation) should also be part of the DAST.

Azure DevOps Pipeline or GitHub supports the integration of third-party DAST tools into the CI/CD workflow.

Azure implementation and additional context:

AWS guidance: Integrate DAST into your pipeline so the runtime application can be tested automatically in your CI/CD workflow set in AWS CodePipeline or GitHub. The automated penetration testing (with manual assisted validation) should also be part of the DAST.

AWS CodePipeline or GitHub supports integration of third-party DAST tools into the CI/CD workflow.

AWS implementation and additional context:

GCP guidance: Integrate DAST (such Cloud Web Security Scanner) into your pipeline so the runtime application can be tested automatically in your CI/CD workflow set in the services such as Google Cloud Build, Cloud Deploy or GitHub. Cloud Web Security Scanner can be used to identify security vulnerability in your workload web applications hosted on App Engine, Google Kubernetes Engine (GKE), and Compute Engine. The automated penetration testing (with manual assisted validation) should also be part of the DAST.

Google Cloud Build, Google Cloud Deploy, Artifact Registry, and GitHub also support the integration of third-party DAST tools into the CI/CD workflow.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

DS-6: Enforce security of workload throughout DevOps lifecycle

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
7.5, 7.6, 7.7, 16.1, 16.7 CM-2, CM-6, AC-2, AC-3, AC-6 6.1, 6.2, 6.3

Security principle: Ensure the workload is secured throughout the entire lifecycle in development, testing, and deployment stage. Use Microsoft Cloud Security Benchmark to evaluate the controls (such as network security, identity management, privileged access and so on) that can be set as guardrails by default or shift left prior to the deployment stage. In particular, ensure the following controls are in place in your DevOps process:- Automate the deployment by using Azure or third-party tooling in the CI/CD workflow, infrastructure management (infrastructure as code), and testing to reduce human error and attack surface.

  • Ensure VMs, container images and other artifacts are secure from malicious manipulation.
  • Scan the workload artifacts (in other words, container images, dependencies, SAST and DAST scans) prior to the deployment in the CI/CD workflow
  • Deploy vulnerability assessment and threat detection capability into the production environment and continuously use these capabilities in the run-time.

Azure guidance: Guidance for Azure VMs:

  • Use Azure Shared Image Gallery to share and control access to your images by different users, service principals, or AD groups within your organization. Use Azure role-based access control (Azure RBAC) to ensure that only authorized users can access your custom images.
  • Define the secure configuration baselines for the VMs to eliminate unnecessary credentials, permissions, and packages. Deploy and enforce configuration baselines through custom images, Azure Resource Manager templates, and/or Azure Policy guest configuration.

Guidance for Azure container services:

  • Use Azure Container Registry (ACR) to create your private container registry where granular access can be restricted through Azure RBAC, so only authorized services and accounts can access the containers in the private registry.
  • Use Defender for Containers for vulnerability assessment of the images in your private Azure Container Registry. In addition, you can use Microsoft Defender for Cloud to integrate the container image scans as part of your CI/CD workflows.

For Azure serverless services, adopt similar controls to ensure security controls "shift-left" to the stage prior to deployment.

Azure implementation and additional context:

AWS guidance: Use Amazon Elastic Container Registry to share and control access to your images by different users and roles within your organization. And Use AWS IAM to ensure that only authorized users can access your custom images.

Define the secure configuration baselines for the EC2 AMI images to eliminate unnecessary credentials, permissions, and packages. Deploy and enforce configurations baselines through custom AMI images, CloudFormation templates, and/or AWS Config Rules.

Use AWS Inspector for vulnerability scanning of VM's and Containerized environments, securing them from malicious manipulation.

For AWS serverless services, use AWS CodePipeline in conjunction with AWS AppConfig to adopt similar controls to ensure security controls "shift left" to the stage prior to deployment.

AWS implementation and additional context:

GCP guidance: Google Cloud includes controls to protect your compute resources and Google Kubernetes Engine (GKE) container resources. Google includes Shielded VM, which hardens the VM instances. It provides boot security, monitors integrity, and uses the Virtual Trusted Platform Module (vTPM).

Use Google Cloud Artifact Analysis to scan vulnerabilities in container or OS images, and other type of artifacts on demand or automatically in your pipelines. Use Container Threat Detection to continuously monitor the stated of Container-Optimized OS node images. The service evaluates all changes and remote access attempts to detect runtime attacks in near-real time.

Use Artifact Registry, to set up secure private-build artifact storage to maintain control over who can access, view, or download artifacts with registry-native IAM roles and permissions, and to get consistent uptime on Google’s secure and reliable infrastructure.

For GCP serverless services, adopt similar controls to ensure security controls "shift-left" to the stage prior to deployment.

GCP implementation and additional context:

Customer security stakeholders (Learn more):

DS-7: Enable logging and monitoring in DevOps

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
8.2, 8.5, 8.9, 8.11 AU-3, AU-6, AU-12, SI-4 10.1, 10.2, 10.3, 10.6

Security principle: Ensure your logging and monitoring scope includes non-production environments and CI/CD workflow elements used in DevOps (and any other development processes). The vulnerabilities and threats targeting these environments can introduce significant risks to your production environment if they are not monitored properly. The events from the CI/CD build, test and deployment workflow should also be monitored to identify any deviations in the CI/CD workflow jobs.

Azure guidance: Enable and configure the audit logging capabilities in non-production and CI/CD tooling environments (such as Azure DevOps and GitHub) used throughout the DevOps process.

The events generated from Azure DevOps and the GitHub CI/CD workflow, including the build, test and deployment jobs, should also be monitored to identify any anomalous results.

Ingest the above logs and events into Microsoft Sentinel or other SIEM tools through a logging stream or API to ensure the security incidents are properly monitored and triaged for handling.

Azure implementation and additional context:

AWS guidance: Enable and configure AWS CloudTrail for audit logging capabilities in non-production and CI/CD tooling environments (such as AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) used throughout the DevOps process.

The events generated from the AWS CI/CD environments (such as AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) and the GitHub CI/CD workflow, including the build, test and deployment jobs, should also be monitored to identify any anomalous results.

Ingest the above logs and events into AWS CloudWatch, Microsoft Sentinel or other SIEM tools through a logging stream or API to ensure the security incidents are properly monitored and triaged for handling.

AWS implementation and additional context:

GCP guidance: Enable and configure the audit logging capabilities in non-production and CI/CD tooling environments for products such as Cloud Build, Google Cloud Deploy, Artifact Registry, and GitHub, which can be used throughout the DevOps process.

The events generated from the GCP CI/CD environments (such as Cloud Build, Google Cloud Deploy, Artifact Registry) and the GitHub CI/CD workflow, including the build, test and deployment jobs, should also be monitored to identify any anomalous results.

Ingest the above logs and events into Microsoft Sentinel, Google Cloud Security Command Center, Chronicle, or other SIEM tools through a logging stream or API to ensure the security incidents are properly monitored and triaged for handling.

GCP implementation and additional context:

Customer security stakeholders (Learn more):