Scan GitHub Actions Build Logs for Secrets with StepSecurity’s New Feature

At StepSecurity, we're constantly innovating to enhance the security of your CI/CD pipelines. Today, we're excited to announce our latest feature: automated scanning of GitHub Actions build logs to detect exposed secrets.

Why This Matters

The accidental exposure of secrets in build logs is a prevalent and serious security risk. Recent incidents have highlighted the dangers of this issue across multiple cloud platforms:

1. Azure CLI Vulnerability

In July 2023, researchers at Palo Alto Networks discovered a significant vulnerability in the Azure CLI tool (CVE-2023-36052, CVSS score 8.6). When used in CI/CD pipelines, particularly in GitHub Actions, the Azure CLI was inadvertently echoing sensitive information back to build logs. This affected various Azure CLI commands and impacted multiple organizations, with vulnerability severities ranging from informative to critical.

https://www.paloaltonetworks.com/blog/prisma-cloud/secrets-leakage-user-error-azure-cli/

2. AWS and Google Cloud CLI Issues

Following the Azure CLI incident, the Orca Research team uncovered similar vulnerabilities, dubbed 'LeakyCLI', in AWS CLI and Google Cloud CLI. These tools were found to expose sensitive information, including environment variables, in build logs.  

https://orca.security/resources/blog/leakycli-aws-google-cloud-command-line-tools-can-expose-sensitive-credentials-build-logs/

These incidents underscore the critical need for robust secret detection mechanisms in CI/CD build logs.

How It Works

Our new feature seamlessly integrates with your existing GitHub Actions workflows:

1. Once a workflow completes, the StepSecurity platform automatically downloads the build logs.

2. The platform then searches for any exposed secrets within these logs.

3. If secrets are detected, the platform fails the "secrets should not be logged in the build log" control for that specific job and provides information about the type of secret, the first and last four characters of the secret (rest of it is masked), and a link to the exact line in the build log where the secret was exposed.

For our enterprise customers, we offer additional benefits:

• Instant notifications via Slack, email, or Microsoft Teams
• List of all the “Secrets in build log” detections in the dashboard

Real-World Impact

During the beta testing of this new feature, we uncovered secrets in build logs in multiple GitHub organizations. Our platform detected secrets such as a Hugging Face API secret, Hashicorp Terraform password, Slack webhook URLs etc. exposed in the build logs. These secrets could have potentially been exploited by malicious actors to access sensitive AI models, data, or incur unauthorized usage costs.

Upon discovery, we promptly notified the organizations. They quickly acknowledged the issue and remediated it, preventing any potential misuse.

These real-world examples underscore the critical importance of scanning build logs for secrets. It demonstrates how easily secrets can be accidentally exposed and the value of automated detection in maintaining security hygiene.

Hands-On Demonstration: GitHub Actions Goat

To demonstrate the effectiveness of this new feature, let's look at an example using our GitHub Actions Goat project. This deliberately vulnerable project helps security teams and developers understand and mitigate common security risks in GitHub Actions.

In this example, we've set up a workflow that simulates a common mistake: accidentally logging sensitive information. The workflow intentionally logs the private key, simulating a common mistake that could expose sensitive information.

https://github.com/step-security/github-actions-goat/blob/main/.github/workflows/secret-in-build-log.yml  

steps: 
      - uses: actions/checkout@v3 
      - name: harden-runner 
        uses: step-security/harden-runner@v2 
        with:  
          egress-policy: audit 
      - name: Extract and use GCP private key 
        env: 
          GCP_SERVICE_ACCOUNT_KEY: ${{ secrets.GCP_SERVICE_ACCOUNT_KEY }} 
        run: | 
          # Extracting the private key from the GCP service account key 
          PRIVATE_KEY=$(echo $GCP_SERVICE_ACCOUNT_KEY | jq -r '.private_key') 
          # Simulate using the private key 
          echo "Using the private key for some operation" 
          # Log the private key (simulating a mistake) 
          echo "GCP Private Key: $PRIVATE_KEY" 

‍

You can see the private key in the build log.

Our new feature scans the build logs once the workflow is complete. In this case, it detects the exposed GCP private key in the log. The scan results can be viewed in the StepSecurity platform. For this specific run, you can see the results here:  

https://app.stepsecurity.io/github/step-security/github-actions-goat/actions/runs/10068495762?jobid=27833966514&tab=controls  

This demonstration shows how easily sensitive information can be accidentally exposed in build logs and how our new feature can quickly identify such exposures, allowing for prompt remediation and preventing potential security breaches.

Get Started Today

By implementing automatic secret detection in build logs, you can:

1. Prevent accidental exposure of sensitive credentials
2. Quickly identify and remediate any secrets found in your build logs
3. Maintain compliance with security best practices and regulations

Protect your organization from the risks of exposed secrets in your CI/CD pipeline build logs. Existing StepSecurity customers can enable this feature immediately in their dashboard.  

New users can sign up for a free trial to experience the StepSecurity Platform, including this powerful new feature. Start your free trial of the StepSecurity platform now.