GitHub Actions runs untrusted code in a privileged environment. Compromised workflows, dependencies, and build tools can steal source code/credentials, tamper source code, and build artifacts during the build.

Lack of Runtime Visibility: Enterprises don't have any runtime visibility for their GitHub Actions workflow runs. Traditional CDR/EDR tools fail to work with GitHub Actions runners. 

Larger Attack Surface for Self-Hosted Runners: Self-hosted runners increase the attack surface drastically as enterprises are responsible for managing the underlying infrastructure as well. 

Lack of Network Egress Filtering: GitHub Actions runners don't have any built-in network egress filtering, allowing workflows to make outbound calls to all endpoints on the internet. Malicious actors use this capability to steal secrets (e.g., the Codecov breach) and source code from the enterprise GitHub Actions environment.

Lack of Source Code and Build Integrity: Malicious actors can maliciously tamper source code files on the runner server before a production build is created to inject their backdoor (e.g., the SolarWinds breach).

StepSecurity Harden-Runner is a purpose-built network and runtime security solution for GitHub Actions

Contextualized Security Observability: StepSecurity provides contextualized runtime security insights correlated with each step of the workflow.

Supported on GitHub-Hosted and Self-Hosted Runners: Works seamlessly on GitHub-Hosted, Actions Runner Controller (ARC), and self-hosted Virtual Machine (VM) Runners

Network Egress filtering: Enterprises specify an allowed list of endpoints for each workflow job or runner cluster. Harden-Runner blocks network traffic to all other endpoints.

Detect Source Code Tampering on Runner: StepSecurity monitors all file events and flag suspicious source code and build overwrite events.

Anomaly Detection: Harden-Runner creates a Machine Learning (ML) model for each workflow run based on historical data and flags any deviations from it.

GitHub Actions has 20,000+ third-party Actions in the marketplace. Enterprises face several challenges regarding the use of third-party GitHub Actions.

Lack of visibility: Tracking all third-party GitHub Actions in use is cumbersome and time-consuming.

Lack of Maintenance and Security Controls: Many third-party Actions are not regularly maintained and fall short in implementing fundamental security best practices. No standard objective way to measure the security posture of a third-party GitHub Action.

Dilemma for Security Teams: Confronted with a risky third-party Action, security teams usually have two choices:
1. Approve it and accept the associated risks.
2. Reject it, leading to potential conflict with developers and decreased productivity.
Neither option aligns well with the needs of an enterprise.

Manual Review and Forking: The security team is tasked with manually reviewing the Action. This is time-consuming, especially if forking the repository becomes necessary.

Maintenance of Forked Actions: Forked Actions require ongoing maintenance, such as updating dependencies and synchronizing with the upstream repository for new features or bug fixes. This maintenance effort escalates as more Actions are adopted.

StepSecurity Actions governance empowers enterprises to take control of third-party Actions

Visibility: StepSecurity discovers all Actions in use across your GitHub organization.

Measure Risk: StepSecurity provides a risk score for each GitHub Action based on security best practices.

Managed and Maintained Third-Party Actions: StepSecurity is responsible for managing and maintaining third-party Actions for enterprise customers. We apply rigorous security best practices and ensure the Action remains in good standing.

Secure and Reliable: Developers can confidently use StepSecurity Maintained Actions, assured of their safety and reliability. These Actions meet high-security standards, significantly reducing risks.