Infrastructure scanning: Build and test

In a modern DevSecOps workflow, infrastructure is defined as code (IaC) using templates like ARM, Bicep, or Terraform. Treating infrastructure as code means it should be validated and tested just like application code. Placing Infrastructure scanning in the Build and test stage allows for the automated analysis of these IaC templates. Scanners can detect misconfigurations, security risks, or non-compliance issues within the templates before they are ever used to provision resources, ensuring that the defined infrastructure is secure by design.

Static application security testing (SAST): Commit the code

Integrating SAST at the Commit the code stage provides the earliest possible automated feedback on code quality in the central repository. When a developer submits a pull request or merges code, a SAST tool can be automatically triggered. This scan analyzes the source code for security vulnerabilities before it is formally built or integrated with other components. This practice prevents security flaws from being merged into the main codebase, providing immediate feedback and reducing the cost of remediation.

Microsoft Cloud Adoption Framework for Azure, "Identify and implement DevSecOps controls": This official documentation table maps security controls to specific DevOps phases, supporting this configuration.

It explicitly lists "Use static application security testing (SAST) tools to help identify potential vulnerabilities in the source code" as a security control for the Commit phase.

It lists "Scan infrastructure as code (IaC) to identify potential cloud misconfigurations" as a control for the Build phase (which is part of "Build and test").