GitHub Actions – How to Use It for Security and Compliance Needs

First of all, let’s clarify what GitHub Actions actually is and what it has to do with security and compliance. In short, it is a feature used for workflow automation. It is a continuous integration and continuous delivery platform that allows you to automate your build, test, and deployment pipeline. Like any tool of this type, it permits you to run Actions triggered by a change in the repository, for example, a merged pull request.

However, that’s not all and the possibilities are much greater here. GitHub Actions can trigger a specific workflow based on other events too. For example, every new issue can automatically add the appropriate labels. Now, let’s check out something related to the subject of compliance, such as GitHub Membership Audit Action. It is a ready-made action available in the Marketplace that allows you to audit which users have access to which repository and what permissions they have in it. Of course, we can also trigger such Actions manually, although automation is their main advantage.

GitHub Actions workflow explained

Let’s go over how it works before we move on. As I mentioned before, the basic idea is that we define an action, which is then triggered automatically based on some event in our repository. When defining our workflow, we can run one or multiple jobs and, most importantly, we can run them in sequence or in parallel. Now, let’s jump into the details. 

Each job contains one or more steps to be performed. In addition, everyone is run inside a container or their own virtual machine, the so-called runner, which is quite important from a security perspective as it allows for the isolation of operations. GitHub provides Ubuntu, Windows, or macOS runners, but you can host your own runner anytime you want to. All steps of a given job are either an executable shell script or an action, which is a custom application that performs a frequently repeated task.

The whole concept of GitHub Actions can be illustrated by the following graphic:

Risks and security

Next in line, we have risks and security in terms of GitHub Actions. As with any tool or platform, it is necessary to keep it secured. Secrets shall never be stored just as plain text in your workflow files, and scripts that are implemented shall always be verified, also make sure to have multiple code owners – the list goes on, but you get the picture. The number of incidents that affected GitHub users throughout 2023 grew by over 20% when comparing it to 2024, as outlined by the The State of DevOps Threats Report. These statistics suggest it is a good idea to improve security practices.

Compliance and Auditing

For several reasons, companies take measures to increase the level of security and then verify it regularly. In addition, certain standards are introduced and audits are carried out, both by internal and external companies. In many companies, such audits are enforced by law or agreements with clients. This is a very serious topic, going beyond the usual common-sense care for your own safety.

So, why is compliance crucial for today’s software development? Well, there are a couple of reasons: 

• Security and risk mitigation – adhering to mandated security requirements guarantees better data protection at least to the industry standard level.
• Regulatory requirements mandated by law, simply must be followed to stay compliant.
• Avoid paying fines for non-compliance.
• Compliance is great for reputation.
• Clients may simply require you to be compliant.

In the introduction, I mentioned the already existing GitHub action for auditing the membership and access rights for any repository. A very useful tool, especially if we have lots of rotation or short-term projects, access to which should only be granted temporarily. Thanks to this action, we can easily track any deviations from the expected state.

---

Ready to work with GitHub Actions? Do the next best thing and secure your code with the first professional GitHub backup.

---

Dependency graph and Dependabot

GitHub provides some other robust tools that can be used as GitHub Action for compliance needs. Namely, the dependency graph and Dependabot alerts. The former shows two things related to our repository:

• dependencies – the ecosystems and packages it depends on
• dependents – the repositories and packages that depend on it

How to use the Dependency graph and Dependabot

The important thing to note is that we must somehow inform GitHub what we treat as a dependency by placing this information in the appropriate configuration files, e.g. pom.xml for Maven, package-lock.json for NPM, and so on.

The Dependabot alerts, in turn, work as follows: GitHub has its own database of potentially vulnerable dependencies and then informs us if any dependency we use is on this list. The most common solution to this problem is to simply update such a dependency to the latest version.

As we know how it works we can now use these tools as an Action. Of course, we can define our own actions, according to our needs and internal compliance rules. However, I suggest using the existing ones, as GitHub itself recommends. We are talking about project ghascomliance, based on the MIT License. Using this solution, we can easily define a security and compliance action that will meet our expectations. The configuration file allows us to set various license conditions, Dependabot, or even secret scanning. There are many possibilities, including determining the threshold of what number of threats found (we can determine their importance) is critical for us, and what is acceptable. The most important takeaway is that with these types of tools, we can use GitHub Actions for security purposes.

We also recommend using tools like Mergify to merge dependencies updates and save time.

Dependency Review

To complete dependency management, GitHub provides another tool called Dependency Review. It allows developers to spot any insecure dependencies before adding them to their ecosystem. This feature is available for public repositories on GitHub.com and repositories owned by organizations on GitHub Enterprise Cloud with GitHub Advanced Security turned on.

Dependency Review can help you spot changes in dependencies and see how they affect security for each pull request. You will get a detailed diff in the “Files Changed” of a pull request. The tool covers aspects such as the ability to see dependencies that have been removed, added, and/or updated – including the dates. Another thing to note is that you can see the number of projects that use these components. And finally, the information related to vulnerabilities of these dependencies will also be available.

GitHub Actions workflow – best practices

I mentioned at the beginning that each GitHub Action runs on a separate virtual machine or container, which provides isolation and therefore security. However, as usual, there are no perfect solutions. For example, output logs of every action are visible to anyone with access to the repository. In general, it is not a problem, as GitHub is there to protect our secrets inside the workflows, however, it is not impossible to expose them if we define our own script. Make sure to scan for any exposed secrets, be careful, and double-check manually created scripts before you add them to your GitHub Actions workflow.

Several times I encouraged you to use ready-made solutions, i.e. the already existing Actions. Because why reinvent the wheel? Reusable components are a big time saver. But I will repeat once again the fact that there are no universal and absolutely safe solutions. Whenever we use external tools, libraries, or any other dependency, we have to be very careful and check if we can trust it. Fortunately, in the case of Actions, GitHub Marketplace helps us with this task and allows you to easily check if we can trust the creator by marking the author as a “Verified creator”. Of course, this doesn’t mean that we shouldn’t use Actions without such an annotation, but for sure it is helpful.

Another good practice is to keep your GitHub Actions up to regularly update GitHub Actions. Alternatively, you can just completely disable GitHub Actions. Of course, that is assuming you don’t use it and don’t plan on doing so. In turn, this will allow us to protect ourselves from accidentally or maliciously defining and launching an action that we do not want.

Auditing repository access

In certain situations, organizations are required to provide auditors and/or compliance teams with a transparent record of who has access to which resources across the organization. Keep in mind that with the growing number of repos, keeping up with collecting this data manually may be difficult. Thankfully, there is a solution to simplify this issue. You can take advantage of org-audit-action, which is a GitHub Action that generates .csv and .json reports. These include details regarding access to repositories throughout all organizations in an enterprise. Such reports include: which users have access, what permissions those users have, and their login, full name, and optionally SAML identity of the user. 

Traceability and issue branches

Organizations operating in highly regulated industries must implement end-to-end traceability for any changes that are being deployed to production. It’s true that specific implementation procedures may vary due to, for example, tools that are being used. However, one thing remains the same – a traceable relationship must be established between a requirement, the code changes addressing it, the necessary approval steps, and the final deployment.

Using GitHub Actions can help you automate these processes. GitHub flow allows for short-lived, focused feature branches. These align with the aforementioned end-to-end traceability requirements. A common practice in the industry is to generate a branch for each of the requirements and use a standard syntax that should include a reference to the requirement’s unique identifier. Now, the create-issue-branch action actually enables you to create branches directly from a GitHub issue. Using this functionality allows you to: 

• Set the branch name
• Trigger the workflow on issue assignment and/or on use of a slash command in a comment
• Customize the response content
• Open a draft pull request (PR) automatically linked to your issue

The need for linked issues

As you may know, pull requests are a crucial aspect, connecting different areas of the development process. This includes, among others, issues, code reviews and CI/CD. Therefore, this makes it perfectly suitable for demonstrating traceability. To put it simply, all changes must be linked to a requirement – and in turn, all PRs must have a linked issue. You can make use of verify-linked-issue action, that guarantees a PR is linked to an issue, and if it is not – it fails the check. Using this method you can prevent unlinked pull requests from any merging processes, and further support compliance with traceability standards or regulations.

An extra security measure – backup & DR

For complete security it is essential to implement a dedicated backup & DR solution across your organization. Make sure that your software covers all the tools and systems that are being used by your teams.
An efficient backup strategy should have a backup scheduler, strong encryption, replication, flexible restore and recovery options as well as support for a range of tools and platforms for backup, restore and recovery processes. Remember, you as the user are responsible for securing your accounts, according to the shared responsibility model.

Summary

Before starting to use Actions, or when we want to improve the already existing due to security and compliance reasons, there are two things to keep in mind. One is to take some GitHub Actions tutorials. GitHub itself provides nice documentation and a free course for this feature. I recommend that even if you’ve already used Actions, it’s worth refreshing and broadening your knowledge.

[FREE TRIAL] Ensure compliant GitHub backup and recovery with a 14-day trial 🚀

[CUSTOM DEMO] Let’s talk about how backup & DR software for GitHub can help you mitigate the risks