Canada Luggage Depot - Secure SDLC
Build and CI/CD Security

11. Build and CI/CD Security #

11.1 Pipeline integrity #

Build and deployment pipelines must be defined as code and protected by strong access controls. Only authorized personnel may modify pipeline definitions, runners/agents, secrets, or environment variables. Administrative access to CI/CD must use SSO with MFA, least‑privilege roles, and change review. Build agents must run on hardened images, be patched regularly, and avoid sharing credentials across projects. Artifacts must be signed or otherwise integrity‑verified before promotion. Production deployments must originate from the pipeline; manual, out‑of‑band changes are prohibited except under documented break‑glass with post‑facto review.

11.2 Secrets management #

CI/CD must never store secrets in plaintext within pipeline definitions, job logs, or source code. Secrets (tokens, client secrets, private keys) must be injected at runtime from an approved vault/KMS, scoped to the minimal privileges needed, and rotated on a defined cadence and upon personnel changes. Pipeline logs must be scrubbed/redacted; failed jobs must not leak secrets in error messages.

11.3 Pre‑merge and pre‑release checks #

All changes must pass automated quality and security checks prior to merge and release:

  • Static code analysis (SAST) to detect insecure patterns and taint flows.

  • Software composition analysis (SCA) to identify vulnerable libraries and generate an SBOM per build.

  • Secrets scanning of source and pipeline artifacts.

  • Unit and integration tests appropriate to the change.

  • For infrastructure and containers: IaC scanning (e.g., Terraform, CloudFormation) and container image scanning prior to use.

    PENDING: SBOM format

11.4 Dynamic testing and staging validation #

Internet‑facing web and API services must undergo dynamic application security testing (DAST) against a staging environment that closely mirrors production. Critical flows (authentication, authorization, file uploads, administrative functions) must be exercised. Where automated DAST is insufficient, targeted manual testing of high‑risk endpoints must be performed. Findings must be triaged and addressed before production release per vulnerability SLAs (Section 13). PENDING: Fail‑gate thresholds for Critical/High/Medium

11.5 Artifact promotion and environments #

Build once, promote many. The exact artifact (image/bundle) that passed security checks in staging must be the one deployed to production. Environment‑specific configuration is applied via parameters or secrets, not code changes. Promotion requires evidence that the artifact hash matches the tested version and that environment checks (health probes, feature flags, WAF rules, logging routes) are in place.

11.6 Dependency and supply‑chain controls #

Pin dependency versions and verify integrity (checksums/signatures). Disallow downloads from untrusted repositories at build time; use approved mirrors/registries. Maintain allowlists for build plugins and pipeline extensions; changes require review. External services used in build (e.g., scanners, SaaS repos) must support SSO/MFA and provide audit logs upon request.

11.7 Access and change controls in CI/CD #

Require code review (at least one independent approver) before merge to protected branches. Protect main/release branches against force‑push and direct commits. Restrict who can trigger production deployments; require explicit approvals for production jobs (e.g., ISO/IT Operations gates) and enforce environment‑specific RBAC. Maintain an audit trail of who approved, who executed, what version, and when.

11.8 Logging, telemetry, and auditability #

CI/CD systems must log administrative actions, pipeline edits, job starts/stops, artifact promotions, secret reads, and deployment approvals with who/when/where/what/outcome and a correlation ID. Retain logs per the logging baseline. Where feasible, forward CI/CD security logs to the vendor SIEM and, if required, to CLD’s SIEM. PENDING: CLD SIEM forwarding decision and ingestion method; retention months

11.9 Release evidence bundle #

Each production release must attach or reference a minimal evidence bundle (see Section 6.3): SBOM, SAST/SCA/DAST summaries, secrets‑scan confirmation, IaC/container scan results (if applicable), change log, deployment and rollback plans, updated logging schema or data‑flow (if changed), and UAT sign‑off. The evidence must be accessible to CLD reviewers without vendor console access (e.g., attached to a ticket or published to a shared repository/path). PENDING: Delivery location and required format

11.10 Policy on failed gates and waivers #

Releases are blocked on unresolved Critical and High findings unless the ISO grants a waiver with specific compensating controls (e.g., WAF rule, feature flag off, narrowed scope), an owner, and an expiry date. Medium and Low findings must have a POA&M with target dates aligned to the vulnerability SLAs. Waivers must be included in the release record and reviewed at the Post‑Go‑Live review. PENDING: Final fail‑gate thresholds and waiver time limits

11.11 Exceptions #

Any deviation from this section (e.g., temporary manual deployment for an emergency hotfix) requires a documented exception with scope, rationale, risk assessment, compensating controls, owner, approval (ISO and Executive Sponsor), and expiry.