Building an IaC security and governance program step-by-step

What are your infrastructure security goals?

What policies do you want to enforce, and how?

Where should you enforce infrastructure policies?

  • What triggers a CI/CD build?
  • Do your current automated quality assurance efforts run continuously on every new pull request and commit?
  • Do more time-consuming tests such as integration tests run on less-than-continuous intervals such as nightly or only on branches following specific naming conventions?
  • Are developers testing their work locally before committing?
  • How many CI/CD pipelines are in use?

Approach #1: CI/CD pipeline

Approach #2: Version control system

  • PR annotations: Start simple by choosing the path of least resistance. Using a standard webhook or API interface, you can start by scanning every PR and annotating its results with concrete secure coding advice. The benefit of the annotation is that it’s frictionless. Developers can choose to adopt or ignore it — little frustration, but on the other hand, not a lot of governance.
  • Checks: With the addition of native CI to most git platforms, you can also always incorporate a standard CI pipeline in git. The main benefit is to include a CI-like scan as part of each individual PR. It surfaces the same kind of output in an earlier stage and enables developers to react before actually failing building in the pipeline.

How should you enforce security output?

  • Approval rules: With a VCS, you can define how many approvals, and a pull request needs before it can be merged. Some even let you select which specific users those should be.
  • Code owners: If you have admin access to your main repo, consider using CODEOWNERS parameters to define a stricter approval protocol for more sensitive files.




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store