Share via

Security Control v3: 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 Microsoft threat modeling tool with 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 the 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.

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 at least should include following aspects:

  • Identify the upstream dependencies required at the 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 native code scanning capability to scan the source code when sourcing the code from external.
  • Use Azure 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.

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 hosting CI/CD pipelines.
  • CI/CD pipeline configuration.

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

  • Protect artifacts and 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 the similar controls to secure the Organization permission levels
  • 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, just-in-time access.
  • Remove keys, credentials, and secrets from code and scripts used in CI/CD workflow jobs and keep them in key store or Azure Key Vault.
  • If you run self-hosted build/deployment agents, follow Azure Security Benchmark controls including network security, posture and vulnerability management, and endpoint security to secure your environment.

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) is 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 so the source code can be scanned automatically in your CI/CD workflow. Azure DevOps Pipeline or GitHub can integrate tools below 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 and GitHub native secret scanning for credential scan in the source code.

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 the 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 integrate of third-party DAST tools into the CI/CD workflow.

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 Azure 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. Through custom images, Azure Resource Manager template, and/or Azure Policy guest configuration to deploy and enforce these the configuration baseline.

Guidance for Azure container services:

  • Use Azure Container Registry (ACR) to create your private container registry where a 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 Azure Container Registry for vulnerability assessment of the images in your private Azure Container Registry. In addition, you can use Azure Defender for Cloud to ingrate container images scan as part of your CI/CD workflows.

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

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 from the Azure DevOps and GitHub CI/CD work for the build, test and deployment jobs should also be monitored to identify any exception results in the CI/CD jobs.

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

Follow Azure Security Benchmark – Logging and Threat Detection as the guideline to implement your logging and monitoring controls for workload.

Implementation and additional context:

Customer Security Stakeholders (Learn more):