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.
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.
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.
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:
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:
Prevent accidental exposure of sensitive credentials
Quickly identify and remediate any secrets found in your build logs
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, here: https://github.com/apps/stepsecurity-actions-security
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.
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.
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.
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:
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:
Prevent accidental exposure of sensitive credentials
Quickly identify and remediate any secrets found in your build logs
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, here: https://github.com/apps/stepsecurity-actions-security