Scanning with Google Cloud Build

Google Cloud Build is a fully managed continuous integration and continuous delivery (CI/CD) service offered by Google Cloud Platform.

To integrate Endor Labs with Google Cloud Build:

• Authenticate to Endor Labs
• Set up Google Cloud prerequisites
• Set up repositories on Google Cloud Build
• Create Cloud Build triggers
  • Baseline scan
  • PR scan
  • Release scan
  • Example configuration file

Authenticate to Endor Labs

Generate API credentials to authenticate to Endor Labs. Configure the API key and secret in the cloudbuild.yaml file for authentication. See managing API keys for more information on generating an API key for Endor Labs.

You can enable keyless authentication to Google Cloud. See Enabling Keyless Authentication in Google Cloud for more information.

Set up Google Cloud prerequisites

Ensure the following prerequisites are in place in Google Cloud Build before integrating with Endor Labs.

• GCP Service Account: Create a service account to operate Google Cloud Build.
• APIs:
  • Enable the Google Cloud Build API.
  • Enable the Secrets Manager API.
• Secrets:
  • Create secrets in Secret Manager to store the Endor Labs API credentials: endor-api-key and endor-api-secret.
• Permissions: Grant the service account the following roles:
  • Secret Manager Secret Accessor: Allows the service account to access API credentials from Secret Manager.
  • Logging Admin: Allows the service account to write build logs to Cloud Logging.

Set up repositories on Google Cloud Build

1. Sign in to the Google Cloud Build console.
2. Navigate to Repositories.
3. Follow the instructions in Connecting GitHub Repositories to Cloud Build to add the repositories you want to scan with Cloud Build.

Create Cloud Build triggers

Triggers initiate Cloud Build for different types of scans. You can set up triggers for the following scan types:

• Baseline scan
• PR scan
• Release scan

Baseline scan

• Purpose: Scans the baseline or the default branch to identify existing security vulnerabilities. Future code and dependencies will be evaluated against this baseline.
• Trigger Type: Push to branch.
• Setup: Create a trigger for the required repository and branch, for example, main, or develop.
• Cloud Build Configuration: Create a cloudbuild.yaml file using the configuration file examples as a reference. Include this file for baseline scans in the required GitHub repository.

PR scan

• Purpose: Scans the pull requests that could include new code and dependencies for vulnerabilities and security risks. This scan compares the new code against the baseline or the default branch and raises results based on findings and admission policies.
• Trigger Type: Pull request.
• Setup: Create a trigger for the required repository and branch.
• Additional Parameters: Pass extra parameters as part of the endorctl arguments.
• Cloud Build Configuration: Create a cloudbuild.yaml file using the configuration file examples as a reference. Include this file for baseline scans in the required GitHub repository,

Release scan

• Purpose: Scans code before it lands in production or pre-production environments. This is similar to a baseline scan, however, it is triggered when you push the code to a release branch or create a new release tag.
• Trigger Type: Push to branch or push to new tag.
• Setup: Create a trigger for the release branch or tag.
• Cloud Build Configuration: Create a cloudbuild.yaml file using the configuration file examples excluding the --as-default-branch argument for release scans, and add this file to the required GitHub repository.

Example configuration file

Here is an example cloudbuild.yaml configuration file to perform a baseline scan for Java project repository.

steps:
  # Step 1: Fetch The Trigger Branch
  # This step addresses a known issue where Cloud Build renames the pulled branch to main.
  # If you are not encountering this issue with your build, you can skip this step.
  - name: 'gcr.io/cloud-builders/git'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        echo "Fetching all branches..."
        git fetch origin
        echo "Checking out branch: ${BRANCH_NAME}"
        git checkout ${BRANCH_NAME}
  # Step 2: Build With Maven
  - name: 'maven:3.8.6-openjdk-11'
    entrypoint: 'mvn'
    args: ['clean', 'install']
    id: 'Build'
  # Step 3: Install latest version of endorctl
  - name: 'maven:3.8.6-openjdk-11'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        curl https://api.endorlabs.com/download/latest/endorctl_linux_amd64 -o endorctl
        echo "$(curl -s https://api.endorlabs.com/sha/latest/endorctl_linux_amd64)  endorctl" | sha256sum -c
        chmod +x ./endorctl
        ./endorctl --version
    id: 'Install latest version of endorctl'
  # Step 4: SCA Scan With EndorLabs
  - name: 'maven:3.8.6-openjdk-11'
    entrypoint: 'bash'
    args: ["-c", "./endorctl scan -n $$ENDOR_NAMESPACE --api-key=$$ENDOR_API_CREDENTIALS_KEY --api-secret=$$ENDOR_API_CREDENTIALS_SECRET --as-default-branch=true"]
    secretEnv: ['ENDOR_API_CREDENTIALS_KEY', 'ENDOR_API_CREDENTIALS_SECRET']
    env:
      - 'ENDOR_NAMESPACE=demo'
    id: 'SCA Scan With EndorLabs'

# Fetch Endor Labs API Token and Secret From Secrets Manager
availableSecrets:
  secretManager:
  - versionName: projects/{your-project-id}/secrets/endor-api-key/versions/1
    env: 'ENDOR_API_CREDENTIALS_KEY'
  - versionName: projects/{your-project-id}/secrets/endor-api-secret/versions/1
    env: 'ENDOR_API_CREDENTIALS_SECRET'

options:
  # Choose your log configuration
  logging: 'CLOUD_LOGGING_ONLY'
  # Select a private pool if the default runners do not meet the minimum requirements.
  pool:
    name: 'projects/{your-project-id}/locations/{your_location}/workerPools/{your_worker_pool_id}'

Check the example configuration files and customize them for your requirements.

Set up branch tracking in Google Cloud Build

In Git, a detached HEAD state occurs when the repository checks out a specific commit instead of a branch reference. In this state, Git points the HEAD directly to a commit hash, without associating it with a named branch. As a result, actions performed, such as creating new commits or running automated scans, do not carry branch identity unless explicitly specified.

Proper branch context enables Endor Labs to:

• Associate scans with the correct branch
• Identify scans on the monitored default branch
• Track findings and display metrics accurately across branches

Without proper branch configuration, Endor Labs may create multiple branch entries for the same logical branch, leading to fragmented reporting and inaccurate metrics.

Google Cloud Build often checks out commits by their SHA instead of the branch name, which creates a detached HEAD state.

Use --detached-ref-name only to specify the branch name for a commit in detached HEAD state. This associates the commit with the correct branch without setting it as the default branch.

- name: 'gcr.io/cloud-builders/docker'
  entrypoint: 'bash'
  args:
    - '-c'
    - |
      endorctl scan --dependencies \
      --detached-ref-name="${BRANCH_NAME}"

Use both --detached-ref-name and --as-default-branch together when you want to associate the commit with a branch and set it as the default branch scan.

- name: 'gcr.io/cloud-builders/docker'
  entrypoint: 'bash'
  args:
    - '-c'
    - |
      endorctl scan --dependencies \
      --as-default-branch \
      --detached-ref-name="${BRANCH_NAME}"