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.
Auditing repository access
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:
- which users have access
- the permission those users have
- the user login, full name, and (optional) SAML identity of the user
You can view a brief demonstration of this action from a GitHub Demo Days, here.
Enforcing security policy
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.
Demonstrating traceability: Creating issue branches
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:
- trigger the workflow on issue assignment and/or on use of a slash command in a comment
- customize the branch name
- customize the response content
- open a draft pull request linked to the issue
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.
Demonstrating traceability: Requiring linked issues
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.
For more information
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.
Tags:
Written by
Related posts
Execute commands by sending JSON? Learn how unsafe deserialization vulnerabilities work in Ruby projects
Can an attacker execute arbitrary commands on a remote server just by sending JSON? Yes, if the running code contains unsafe deserialization vulnerabilities. But how is that possible? In this blog post, we’ll describe how unsafe deserialization vulnerabilities work and how you can detect them in Ruby projects.
10 years of the GitHub Security Bug Bounty Program
Let’s take a look at 10 key moments from the first decade of the GitHub Security Bug Bounty program.
Where does your software (really) come from?
GitHub is working with the OSS community to bring new supply chain security capabilities to the platform.