Appearance
CI/CD Pipeline Overview
Purpose
This document describes the GitHub Actions CI/CD pipeline used to manage infrastructure deployments across all Terraform repositories. The pipeline enforces code quality, security scanning, and compliance checks before any infrastructure changes are applied.
Repositories
The pipeline runs across five repositories. Infrastructure repos use identical pipeline structure; application and ops repos have additional workflow types.
| Repository | Environment | Pipeline Type |
|---|---|---|
azure-infra | Azure primary environment (US West 2) | Terraform fmt → Checkov → Trivy → plan → apply |
aws-infra | AWS disaster recovery environment (US West 2) | Terraform fmt → Checkov → Trivy → plan → apply |
azure-dde-infra | Azure DDE environment (US West 2) | Terraform fmt → Checkov → Trivy → plan → apply |
ops-automation | Security agents, compliance pipelines, audit scripts | Build → test → Docker build → Container App deploy |
bedrock-hub | SecOps platform (FastAPI, PostgreSQL) | Build → test → Container App deploy |
Pipeline Trigger
The pipeline operates in two phases:
Phase 1: Security Scanning (Pull Request)
When a pull request is opened against main, the following scans run automatically:
- Checkov HIPAA Scanning — scans all Terraform code for HIPAA compliance violations
- Trivy Scanning — scans for container and configuration vulnerabilities
These scans must pass before the PR can be merged. Results are posted as PR comments on failure.
Phase 2: Infrastructure Deployment (Push to Main)
When a PR is merged to main, the deployment pipeline runs automatically:
- Terraform Format Check
- Terraform Validate
- Terraform Plan
- Terraform Apply (
-auto-approve)
Important: Apply runs automatically after merge with no manual approval gate between plan and apply. The security scanning in Phase 1 is the primary gate — once code passes scanning and is merged, it deploys automatically.
Each repository has per-environment deploy workflows that trigger only when files in that environment's directory change (e.g., changes to prod/** trigger the prod deploy workflow).
Pipeline Stages
The pipeline runs the following stages in order. If any stage fails, subsequent stages do not run.
1. Terraform Format & Validate
bash
terraform fmt -check
terraform validateEnsures all Terraform code is correctly formatted and syntactically valid before any scanning or planning occurs. This catches typos, missing brackets, and malformed resource blocks early.
2. Checkov HIPAA Scanning
bash
checkov -d . --framework terraformScans all Terraform code for HIPAA compliance violations before a plan is generated. Checkov is used specifically for infrastructure-as-code compliance scanning due to its built-in HIPAA policy checks. Any high-severity findings will fail the pipeline.
See Checkov HIPAA Scanning for details on which policies are enforced and how to handle findings.
3. Trivy Scanning
bash
trivy config .Trivy is used for container image vulnerability scanning. It is scoped to container workloads and runs separately from Checkov to keep infrastructure and container scanning concerns distinct.
4. Terraform Plan
bash
terraform planGenerates an execution plan showing exactly what changes will be made to infrastructure. The plan runs as part of the deploy pipeline after merge to main. Plan output is visible in the GitHub Actions workflow logs.
5. Terraform Apply
bash
terraform apply -auto-approveApplies the planned changes after the PR is approved and merged. Apply only runs after all previous stages have passed successfully.
Authentication
The pipeline authenticates to Azure and AWS using OIDC (OpenID Connect) federated identity credentials via GitHub Actions. No long-lived credentials are stored in GitHub secrets.
- Azure: OIDC trust relationship between GitHub Actions and an Entra ID app registration (separate app per repo/tenant)
- AWS: OIDC trust relationship between GitHub Actions and an IAM role in the management account
Local development uses Azure CLI authentication, which is separate from the pipeline's OIDC flow. See OIDC Authentication for the complete trust inventory — all app registrations, IAM roles, and subject claim values.
Change Management Integration
Every PR merge triggers a POST to /api/changes in the SecOps platform, creating a change management ticket automatically. SecurityAgent checks for open CM tickets before raising incidents — an approved CM within a 2-hour window suppresses related alerts from the same deployment window. This provides an audit trail of all infrastructure changes and prevents false-positive security alerts during planned deployments.
Tool Summary
| Tool | Purpose | Scope |
|---|---|---|
| Checkov | HIPAA compliance scanning | Terraform / IaC |
| Trivy | Vulnerability scanning | Container images |
| Terraform fmt/validate | Code quality | All Terraform code |
| GitHub Actions | Pipeline orchestration | All repos |
Document History
| Date | Change | Author |
|---|---|---|
| April 2026 | Added ops-automation and bedrock-hub to repos table; updated OIDC section to link to oidc-authentication.md; added Change Management Integration section | Kobe |
| March 2026 | Updated pipeline trigger description to reflect two-phase execution, corrected region references, removed false plan-on-PR claim | Rory |
| February 2026 | Initial draft | Rory |