Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
GitHub Actions can automate several common security and compliance tasks, even if your CI/CD pipeline is managed by another tool.
When thinking about automating developer workflows, the first things that come to mind for most are traditional CI/CD tasks: build, test, and deploy. However, many other common tasks can benefit from automation outside of traditional deployment pipelines.
GitHub Actions can automate several common security and compliance tasks, which can be adopted in any GitHub repository, even if your CI/CD pipeline is managed by another tool.
Many organizations must regularly provide their auditors and control partners with evidence demonstrating which people have access to what resources. As the number of repositories grows regularly, gathering this information can be a challenge. Thankfully, there’s a GitHub Action that can automate this process for you.
The org-audit-action can be configured to output a .csv and .json file detailing, for every repository in every organization in your enterprise to include:
You can view a brief demonstration of this action from a GitHub Demo Days, here.
GitHub provides a number of useful security features out of the box: Dependabot alerts notify repository owners of vulnerabilities in their open source dependencies and automatically open pull requests to update them. The dependency graph contains license information for open source packages. Additionally, GitHub code scanning will alert users when they have written insecure code.
With all that information available, it can be useful to set a security policy for Dependabot alerts, license compliance, and code scanning, then check each repository against that policy. The ghascompliance action lets you do just that.
Policies can be codified for Dependabot, secret scanning, and code scanning alerts, as well as for open source software (OSS) license usage. This lets organizations define their risk threshold for each alert and define times to remediate for each alert severity.
A detailed overview on how to implement the tool is available in the action’s marketplace listing. You can also find a quick implementation focused on OSS license policy, which was highlighted as part of a GitHub Demo Days, here.
Many regulated organizations must enforce end-to-end traceability for all changes deployed to production. While the implementation specifics vary from place to place and tool to tool, they each demonstrate a traceable relationship between a requirement, the code changes implementing the requirement, the required human and automated approval steps, and the eventual deployment to production.
This kind of end-to-end traceability can be accomplished with GitHub Actions. The short-lived, narrowly-scoped feature branching workflows advocated by the GitHub flow are ideal for this type of workflow. Many organizations follow a pattern of generating a branch for each requirement, using a standard syntax that includes a reference to the requirement’s unique identifier. The create-issue-branch action can be used to create these branches directly from a GitHub issue. Options are available to:
This video demonstrates an implementation of create-issue-branch that triggers when an issue is assigned, opens a draft pull request, and passes a custom comment with a link to open the branch in the GitHub web editor.
Pull requests are the organizing constructs that link to all other parts of a development workflow: issues, code review, CI/CD, etc. This makes them ideal for demonstrating complete traceability.
If every change must be linked to a requirement, every pull request must have a linked issue. The create-issue-branch workflow, above, will automatically link a pull request to the issue, but it doesn’t enforce such a linkage. Thankfully, there’s the verify-linked-issue action. When configured to run on the pull_request event, it will create a check that fails unless the pull request is linked to an issue. Setting it as a required check in a branch protection rule will enforce the check and prohibit merging pull requests that aren’t linked to an issue.
The Actions workflows highlighted here can be used to create secure, compliant workflows in GitHub. They represent a small fraction of the many useful automations available from the GitHub Marketplace.
If you have questions about how to get started, be sure to check out the Quickstart and Learn GitHub Actions sections of our documentation, the Actions section of Github.community, and our guide on security hardening for GitHub Actions.
