People who write infrastructure as code should learn how to grant least privilege, avoid accidental public exposure, protect state and variable files, vet modules and review plans before applying. A small mistake in a template can expose many resources at once, so review habits matter as much as syntax.
Why this is its own skill
Infrastructure code looks like ordinary code but its effects are different. A single line can make a storage bucket public or open a network port to everyone. The change applies across environments, and the error may be invisible until someone finds it.
The OWASP DevSecOps Guideline lists infrastructure as code scanning among the checks a delivery pipeline should include, which shows how established the concern is.
Six topics
- Least privilege. Every role and policy should grant what is needed and no more. Teach authors to resist wildcard permissions written to make an error disappear.
- Exposure by default. Which resources can become public, and what the safe default setting is for each. Teach a habit: after writing a resource, ask who can reach it.
- State and variable files. State can contain sensitive values. Teach where it is stored, who can read it and why it must never sit in a public place or a repository.
- Credentials in code. Credentials should be injected at run time from a managed store, not written into templates or default values.
- Modules and providers. Reused modules are third party code. Teach authors to pin versions and read what a module creates before using it.
- Plan review. Reading the plan output before applying is the last line of defence. Teach how to spot destroy actions and permission changes.
Exercises
| Exercise | Goal |
|---|---|
| Fix a template that opens a port to every address | Spot exposure |
| Tighten a policy that uses wildcards | Practise least privilege |
| Read a plan and list every security relevant change | Review habit |
| Trace where state lives in your own setup | Know the blast radius |
Use your own templates, with names changed.
Review rules that help
- Require a second person to approve changes that alter permissions or network exposure.
- Split large changes into smaller ones.
- Run a policy check before apply, and make failures explain what to fix.
Common mistakes
Copying a snippet from a forum without reading it, using one shared high privilege account for every pipeline and leaving temporary rules in place after debugging are all frequent. A short checklist at the top of the pull request template catches many of them.
Where Safeguard fits
Safeguard offers asset discovery, policies and gates, and container image scanning, which complement template review by showing what is actually running. It does not offer training courses. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is infrastructure as code scanning enough on its own?
No. It catches known misconfigurations. Authors still need to understand why a setting matters, and reviewers still need to read plans.
Who should review infrastructure changes?
At least one other person who understands the target environment, with extra scrutiny on changes to permissions and network exposure.
Sources
- OWASP DevSecOps Guideline: owasp.org/www-project-devsecops-guideline
Last reviewed: 19 October 2026.
