ADR 004: CI/CD Quality Assurance

Status: Accepted | Date: 2026-07-11 | Review: 2027-07-11

Synopsis

• Use when: A pipeline builds, tests, packages, releases, or deploys agency software.
• Avoid when: A documentation-only repository or unreleasable prototype has an approved reduced pipeline, or CI/CD is being treated as a substitute for operational vulnerability management.
• Decision: Use repeatable, security-gated pipelines that produce immutable releases with testing, scanning, a software bill of materials, provenance, protected environments, and short-lived cloud privilege.
• Required evidence: Pipeline and branch controls, test and scan results, software bill of materials, provenance, approvals, and linked exceptions.
• Dependencies: ADR 003: HTTP API Contract Standards for applicable API testing and ADR 010: Infrastructure and Configuration as Code for infrastructure delivery.

Context

Ensure security and integrity of software artifacts that are consumed by infrastructure repositories per ADR 010. Threat actors exploit vulnerabilities in code, dependencies, container images, and exposed secrets.

Compliance Requirements:

• OWASP CI/CD Security
• ACSC Software Development Guidelines

Decision

Applicability

This ADR applies to pipelines that build, test, package, release, or deploy agency software. Controls should be proportionate to artifact type, exposure, data sensitivity, and deployment privilege. Documentation-only repositories and short-lived prototypes that cannot be released may use a reduced pipeline approved by the repository owner.

It does not mandate a CI/CD platform, cloud provider, container format, or deployment service. It controls build-time and released-artifact assurance; it does not replace deployed asset discovery, patching, endpoint application control, or operational vulnerability management.

CI/CD Pipeline Requirements

Pipeline Flow: Code Commit → Build & Test → Quality Assurance → Release

Mandatory security checks must fail the pipeline when an artifact contains an unapproved critical finding, a confirmed secret, an applicable unsupported runtime or base image, or incomplete provenance. A documented, time-bound exception is required before release when a finding cannot be remediated within the applicable agency or ACSC timeframe.

Execution Environment

• Pin a consistent local and CI toolchain. The WA Government devcontainer-base is one option.
• Define repeatable build and task commands. Docker Bake and Just are examples.
• Keep unprivileged build, test, and scan work on an agency-approved CI platform. GitHub Actions and Woodpecker CI are examples.
• Run cloud-privileged release and deployment steps only in an agency-approved trust boundary with protected environments, short-lived identity, and operations-controlled production access.

Cloud-Privileged Automation

Keep privileged steps separate from general CI where release or deployment needs cloud credentials or direct access to protected systems. Repository-hosted or self-hosted automation may be used where it meets the required trust, identity, network, approval, and audit controls.

Required controls:

• Obtain short-lived, least-privilege workload credentials at runtime; do not store long-lived cloud credentials in pipeline systems where federation or managed identity is supported
• Use dedicated, operations-managed hosts or workloads where the risk assessment requires isolation
• Limit network access to the cloud services and internal systems required for the job
• Apply strong access control, audit logging, and minimal administrative access
• Keep build, release, and deployment logs for audit and incident review
• Separate development, test, release, and production roles; developers must not use standing production deployment credentials
• Pin and verify third-party actions, dependencies, build images, and release artifacts using immutable versions and integrity information
• Generate and retain a Software Bill of Materials (SBOM) and build provenance for every released artifact
• Continuously rescan supported release artifacts and dependencies so newly disclosed vulnerabilities enter the vulnerability-management process

Official cloud-native options include:

These products are examples, not requirements. Equivalent approved services may be used when they provide the same identity, approval, integrity, and audit controls.

CI/CD Pipeline:

flowchart LR
    code[Code Commit]
    build[Build]
    scan[Scan + Analyse]
    release[Release]

    code --> build --> scan --> release

Build produces release artifacts with SBOM/provenance. Scan runs vulnerability and static analysis. Release publishes immutable artifacts consumed by ADR 010: Infrastructure as Code. Keep unprivileged build, test, and scan work on general CI, including long-running jobs. Isolate only the cloud-privileged release or deployment steps that need the stronger trust boundary.

Legacy Adoption

Existing pipelines should first inventory release paths and credentials, remove standing production credentials, and protect deployment environments. Introduce artifact integrity, security gates, SBOM/provenance, and broader testing in a risk-prioritised plan rather than blocking all legacy releases at once.

Required Evidence

• Pipeline definitions and protected-branch settings
• Scan, test, secret-detection, SBOM, and provenance results for each release
• Approval and deployment records demonstrating role and environment separation
• Linked vulnerability or exception record for any accepted finding

Exceptions

Bypassing a mandatory security gate requires compensating controls, residual risk, accountable executive approval, an expiry date, and a linked remediation plan. Emergency releases must run deferred checks immediately after deployment.

Consequences

Benefits:

• Automated security scanning and vulnerability remediation
• Standardised artifact integrity and compliance alignment
• Consistent deployment pipelines with audit trails
• Clear separation between general CI checks and cloud-privileged automation

Risks if not implemented:

• Vulnerable containers deployed to production
• Exposed secrets or excessive cloud privilege in automation systems
• Manual security processes prone to human error
• Compliance violations and audit failures

References

• ADR 003: HTTP API Contract Standards
• ADR 010: Infrastructure as Code