Practice vocabulary for compliance-as-code, policy engines in CI/CD, OPA, Checkov, Conftest, and shift-left security principles.
0 / 5 completed
1 / 5
What is 'compliance-as-code' in a DevSecOps context?
Compliance-as-code translates compliance requirements (e.g., 'all S3 buckets must have encryption enabled', 'no container should run as root') into automated policies evaluated in CI/CD pipelines and infrastructure provisioning. Policies are version-controlled, peer-reviewed, and auditable — turning compliance from a periodic manual audit into a continuous, automated check.
2 / 5
What is OPA (Open Policy Agent) and how is it used in CI/CD pipelines?
Open Policy Agent (OPA) is a CNCF project that decouples policy decision-making from application logic. Policies are written in Rego. In CI/CD, OPA evaluates structured inputs (JSON/YAML) against policies — e.g., checking Terraform plans, Kubernetes admission requests, or container configurations against organisational rules. Conftest is the CLI tool that brings OPA policy evaluation to pipeline workflows.
3 / 5
What is Checkov and what does it scan?
Checkov (by Bridgecrew/Palo Alto) scans IaC files before deployment — Terraform, CloudFormation, Kubernetes manifests, Helm charts, Dockerfiles — for security misconfigurations mapped to CIS Benchmarks, NIST, PCI DSS, and other frameworks. Running Checkov in CI catches misconfigurations like publicly accessible storage buckets, missing encryption, or overly permissive IAM roles before infrastructure is ever provisioned.
4 / 5
What is Conftest and how does it relate to OPA?
Conftest (part of the Open Policy Agent ecosystem) provides a simple CLI for evaluating configuration files against Rego policies. You write policies like 'Kubernetes Deployments must have resource limits' or 'Dockerfiles must not use the latest tag', then run conftest test in the pipeline against your manifests or configs. It bridges the gap between OPA's policy engine and everyday pipeline file testing.
5 / 5
What does 'shift-left security' mean?
Shift-left security moves security checks from the right side of the SDLC (production, post-deployment) to the left (design, development, CI pipeline). The earlier a vulnerability is found, the cheaper and faster it is to fix. Practices include developer security training, IDE security plugins, pre-commit hooks, SAST in CI, IaC scanning, and security requirements in Definition of Done. DevSecOps is the organisational model that operationalises shift-left security.