Bridgecrewio Checkov Action

The integration of security into the infrastructure-as-code (IaC) pipeline represents a fundamental shift toward DevSecOps, ensuring that cloud environments are secure by design rather than as an afterthought. The bridgecrewio checkov action serves as a critical mechanism in this process, providing a static code analysis tool that allows developers to identify misconfigurations, vulnerabilities, and license compliance issues before a single resource is provisioned in a cloud environment. By shifting security "left," this action enables the detection of risks during the build phase, effectively preventing insecure configurations from ever reaching production.

This action is not limited to a single provider or language. It leverages graph-based scanning to analyze a vast array of IaC frameworks, including Terraform, Terraform plans, CloudFormation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfiles, Serverless, and ARM Templates. The utility of this tool extends beyond simple scanning; it powers the Bridgecrew platform, a developer-first ecosystem designed to codify and streamline cloud security throughout the entire development lifecycle. Through the use of this GitHub Action, organizations can automate the enforcement of security policies, ensuring that every commit and pull request adheres to a predefined security baseline.

Functional Capabilities and Scanning Scope

The bridgecrewio checkov action is engineered to perform deep static analysis on a diverse set of infrastructure definitions. Its primary objective is to prevent cloud misconfigurations during build time, which significantly reduces the attack surface of the resulting cloud deployment.

The action scans the following specific frameworks and formats:

• Terraform and Terraform plan files.
• CloudFormation templates.
• AWS SAM (Serverless Application Model) templates.
• Kubernetes manifests.
• Helm charts.
• Kustomize configurations.
• Dockerfiles.
• Serverless framework configurations.
• ARM (Azure Resource Manager) Templates.

The impact of this wide-ranging support is that a single pipeline step can validate an entire heterogeneous cloud stack, regardless of whether the organization uses a mix of Kubernetes for orchestration and Terraform for foundational networking. Contextually, this means the tool acts as a universal policy engine, mapping disparate IaC syntaxes to a unified set of security and compliance checks.

GitHub Actions Workflow Integration

Integrating Checkov into GitHub Actions allows for the automation of security policies during pull request reviews and as part of the general build process. This prevents the merging of code that violates security policies, effectively creating a quality gate for infrastructure changes.

Workflow Configuration and Triggers

A typical workflow for the checkov action is defined in a YAML file located within the .github/workflows directory of a repository. The workflow can be configured to trigger based on several events:

• Push events: Specifically targeting the main or master branches.
• Pull request events: Triggered when a PR is opened or updated against the main or master branches.
• Workflow dispatch: Allowing users to manually trigger the scan from the GitHub Actions tab.

For a standard implementation, the job requires specific permissions to function correctly:

• contents: read: Necessary for the actions/checkout step to fetch the source code from the repository.
• security-events: write: Required for the github/codeql-action/upload-sarif action to upload scan results.
• actions: read: This is specifically required for private repositories to allow the SARIF upload action to retrieve the status of the action run.

Step-by-Step Execution Flow

The execution of the Checkov action generally follows a structured sequence of steps within a GitHub job.

1. Checkout Code: The process begins with actions/checkout@v3, which clones the repository into the $GITHUB_WORKSPACE directory.
2. Environment Setup: In some configurations, a Python environment is explicitly set up using actions/setup-python@v4 (e.g., using Python 3.9), although the pre-made action often handles its own environment.
3. Running Checkov: The bridgecrewio/checkov-action is invoked. This step can be customized using various input parameters to define the scope and output of the scan.
4. Result Upload: If the sarif output format is chosen, the results are uploaded via github/codeql-action/upload-sarif@v2 to integrate the findings directly into the GitHub Security tab.

Technical Configuration Parameters

The bridgecrewio/checkov-action provides several input parameters that allow users to fine-tune the scanning process.

The impact of the output_format parameter is significant; choosing sarif allows for the generation of a results.sarif file, which GitHub consumes to create rich annotations on the "Summary" page and within the code view. This transforms a raw log file into an interactive security report.

Implementation Examples

Depending on the goal—whether it is a simple CLI check or a full integration with the Bridgecrew platform—the workflow configuration varies.

Basic Marketplace Implementation

For a basic setup using the marketplace action, the following configuration can be used:

yaml name: Checkov on: push: branches: - master jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Set up Python 3.9 uses: actions/setup-python@v4 with: python-version: 3.9 - name: Test with Checkov id: checkov uses: bridgecrewio/checkov-action@master with: directory: example/examplea framework: terraform

Advanced Integration with SARIF and Bridgecrew

For organizations requiring deeper visibility and centralized management, the integration includes API keys and SARIF uploads:

```yaml
name: checkov
on:
push:
branches: [ "main", "master" ]
pullrequest:
branches: [ "main", "master" ]
workflowdispatch:

jobs:
scan:
permissions:
contents: read
security-events: write
actions: read
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Checkov GitHub Action
uses: bridgecrewio/checkov-action@v12
with:
outputformat: cli,sarif
outputfile_path: console,results.sarif
- name: Upload SARIF file
uses: github/codeql-action/upload-sarif@v2
if: always()
```

In this scenario, the if: always() condition is critical. Because GitHub by default stops executing subsequent steps when a previous step fails, and Checkov is designed to fail the build when vulnerabilities are found, the upload step must be forced to run to ensure the security findings are recorded.

Bridgecrew Platform Synchronization

The Checkov action can be linked to the Bridgecrew platform to provide a centralized dashboard for remediation and review. This requires a specific setup process:

• API Key Generation: Users must visit the GitHub Actions integration page within the Bridgecrew platform, name the key (e.g., gh_action), and create it.
• Secret Storage: The generated API token must be stored in the GitHub Secrets store as an environment variable (e.g., BC_API_KEY).
• Workflow Application: The bridgecrew-action is used with the api-key parameter.

yaml - name: Run Bridgecrew id: Bridgecrew uses: bridgecrewio/bridgecrew-action@master with: api-key: ${{ secrets.BC_API_KEY }} directory: terraform/

This synchronization allows the action to not only block builds based on policy violations but also to send the results to Bridgecrew for further remediation steps, moving the workflow from simple detection to active management.

Advanced Usage and Troubleshooting

Scanning Terraform Plans

A common requirement is to scan the output of a terraform plan rather than just the static .tf files. This is necessary because certain values are only known after the plan is executed.

One method to achieve this involves generating a binary plan file and then directing Checkov to analyze it:

bash run-all plan -out=tfplan.binary -no-color --terragrunt-non-interactive

When configuring the action for this purpose, users have noted that Checkov should be executed in the specific directory where the plan resides to ensure the files are correctly located. An example of the resulting JSON output for a scan (where no resources were found or failed) is as follows:

json { "passed": 0, "failed": 0, "skipped": 0, "parsing_errors": 0, "resource_count": 0, "checkov_version": "2.0.706" }

Local Installation and Environment Requirements

While the GitHub Action is the primary method for automation, Checkov can be installed locally for development purposes.

For Alpine Linux:

bash pip3 install --upgrade pip && pip3 install --upgrade setuptools pip3 install checkov

For Ubuntu 18.04 LTS:

bash pip3 install checkov

Note that Ubuntu 18.04 ships with Python 3.6, which is a requirement for the environment in which the tool operates.

Analysis of Security Impact and Workflow Efficiency

The implementation of the bridgecrewio checkov action transforms the security posture of an organization by automating the "audit" phase of the software development lifecycle. Instead of relying on a manual security review at the end of a project, the action provides continuous feedback.

The use of SARIF (Static Analysis Results Interchange Format) is particularly impactful. By converting CLI output into SARIF, security vulnerabilities are mapped directly to the line of code causing the issue. This reduces the "mean time to remediate" (MTTR) because developers do not need to search through logs to find the offending resource; they are notified directly within the GitHub PR interface.

Furthermore, the ability to block builds based on policy violations ensures that no "critical" or "high" severity misconfigurations reach the cloud environment. This creates a hard stop for insecure code, effectively enforcing organizational compliance standards automatically.

The synergy between the open-source Checkov scanner and the Bridgecrew platform creates a loop of continuous improvement. The scanner detects the issue in the pipeline, and the platform provides the context and potential fixes to resolve it, which are then committed back to the code and verified by the next scan action.

Sources

1. HashiCorp Discuss
2. Checkov Action GitHub Repository
3. Bridgecrew AWS Workshop
4. Checkov Integrations Guide
5. Docker Hub - Bridgecrew Checkov