Securing Workflows in CD Pipelines

Supply chain security measures also apply to controls during the CD process. The following are some due dilligence measures that should be used during CD. These measures can be implemented by defining verification policies for allowing or disallowing an artifact for deployment

Table of contents

DEPLOY-REQ-1

• For code is already in the repository and ready to be deployed, a security scanning sub-feature should be invoked to detect the presence of secrets in the code, such as keys and access tokens. In many instances, the repository should be scanned for the presence of secrets, evenbefore being populated with code, since their presence in a repository can mean that the credentials are already leaked, depending on the repository’s visibility
• Defining custom patterns for secret scanning enables entire git history on all branches present in your GitHub repository to be scannedto detect custom pattern secret
• Defining a custom pattern for an organiation enbales any secrets in repositories in your organization, including their entire Git history on all branches
• Secret scanning alerts are shown in the Security and Quality tab of the repository, so that deployment can be blocked until the alerts are resolved
  • Use REST API to check unresolved alerts in workflow
• Validate checks help you prioritize which secrets to remediate first by verifying whether a detected secret is still active.
• Deployment target commit and build artifacts should be scanned
  • Gitleaks can scan history, current commit, and build artifact
  • Artifact scanning is required, since a build could inadvertently include embedded credentials, debug dumps, certificates, and .env files.
• repository should be scanned even before being populated with code means when new repository is created
  • Secret protection applied
  • Check for existing branch and history
  • Original repository scan before migration/import

DEPLOY_REQ-2

• Before merging pull requests, it should be possible to view the details of any vulnerable versions through a form of dependency review
• Dependency Review can be used only when dependency graph is enabled
• Dependency review action enables vulnerable versions of dependencies introduced by package version changes in purll request to be scanned and warns you about the associated security vulnerabilities
  • Dependency review workflow is recommended to be added to organization policy
• Enforce merge gate in the rule set(Require status checks to pass -> Dependency review)

DEPLOY_REQ-3

• If a secure build environment and assoicated process have been established, it should be possible to specify that the artifact(i.e., container image) being deployed must have been generated by that build process in order to be cleared for deployment

Using artifact attestations and reusable workflows

• Integrating resuable workflow with artifact attestation enable build provenance to be intensified
• Define approved build process
  • Configuring your build
    • Building with a resuable workflow: Take your build steps and move them into a reusable workflow
    • Building with artifact attestations
  • Verifying artifact attestations built with a resualbe workflow
    • gh attestation verify
  • It is highly recommended to use a central reusable workflow and pin it to a commit SHA

DEPLOY_REQ-4

• There should be evidence that the container image was scanned for vulnerabilities and attested for vulnerability findings.
• An important factor in vulnerability scans is the time when it was run.
• Since tools used to scan artifacts are continuously updated to detect new and emerging vulnerabilities, more recent scan results are more likely to be accurate and provide better assurance than results from the past.
• This technique enalbes DevOps teams to implement a proactive container security posture by ensuring that only verified container images are admitted into the environment and remain trusted during runtime.
• Specifically, it should be possible to allow or block image deployment based on organization-defined policies

Kubernets Policy Controlloer

• Sigstore Policy Controller verifies image signatures and attestations, and allows or denies Kubernetes admissions by applying CUE or Rego policies to the attestations.

Workflow

Container image build
↓
Generate an immutable image digest
↓
Scan the image identified by that digest with a vulnerability scanner
↓
Record the scanner version, vulnerability database version, scan time, and results in JSON format
↓
Generate and sign a vulnerability attestation
↓
Store the image and attestation in the registry
↓
At deployment time, verify the signature, digest, scan freshness, and vulnerability policy compliance
↓
Allow or block the deployment
↓
Continuously update the runtime trust status through periodic rescanning

Example

• Image digest: Verify that the scanned image is the same image being deployed
• Scanner version: Identify which scanning engine was used
• Vulnerability DB update time: Verify that an up-to-date vulnerability database was used
• Scan completion time: Determine how old the scan results are
• Severity outputs: Apply the organization’s vulnerability policy
• Full report digest: Verify that the detailed scan results have not been modified
• Workflow identity: Verify that the attestation was generated by an approved scanner workflow

{
  "schemaVersion": "1.0",
  "scanner": {
    "name": "trivy",
    "version": "0.70.0",
    "databaseUpdatedAt": "2026-07-26T08:40:00Z",
    "binarySha256": "..."
  },
  "invocation": {
    "workflowRef": "example/platform-workflows/.github/workflows/scan-image.yml@refs/heads/main",
    "workflowSha": "...",
    "runId": "123456789"
  },
  "image": {
    "name": "ghcr.io/example/payment-service",
    "digest": "sha256:..."
  },
  "metadata": {
    "scanStartedOn": "2026-07-26T09:00:00Z",
    "scanFinishedOn": "2026-07-26T09:01:20Z"
  },
  "summary": {
    "critical": 0,
    "high": 0,
    "medium": 11,
    "low": 32,
    "unknown": 0
  },
  "policy": {
    "id": "production-container-vulnerability-v3",
    "decision": "allow"
  },
  "report": {
    "format": "trivy-json",
    "sha256": "..."
  }
}

DEPLOY_REQ-5

• The release build scripts should be periodically checked for malicious code. Specific tasks to be performed include:
  • A container image should be scanned for vulnerabilities as soon as it is built, even before it is pushed to a registry. The early scanning feature can also be built into local workflows
  • The tools used to interact with repositories that contain container images and language packages should be capable of integration with CD tools, thus making all activities an integral part of automated CD pipelines.
• Scope of Release build script : Script injections

.github/workflows/**
.github/actions/**
ci/**
scripts/build.sh
scripts/release.sh
Makefile
Dockerfile*
docker/**
Taskfile.yml
build.gradle / pom.xml
package scripts
Packer/Terraform runner definitions
OPA/Rego policy

• How to protect Build Script
  • CODEOWNERS
  • Static scanning
  • Periodic build-script scanning workflow
• OPA scan the release script and image workflow