GitHub Actions – How to Use It for Security and Compliance Needs
Last Updated on March 4, 2024
First of all, let’s clarify what GitHub Actions actually is and what it has to do with our topic. In short, it is a feature 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 allows 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. Or let’s check 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
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 more jobs and, 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 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 executable shell script or action, which is a custom application that performs a frequently repeated task.
The whole concept of GitHub Actions looks like the following graphic:
Risks and security
Compliance and Auditing
For many different reasons, companies take measures to increase the level of security, and also regularly check this level. In addition, certain standards are introduced and audits are carried out, both internal and carried out by external companies. In many companies, such audits are enforced by law or agreements with clients, and this is also a very serious topic, going beyond the usual common-sense care for your own safety.
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 a lot of rotation in the company 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 nice tools that can be used as GitHub Action on compliance needs. I mean the so-called dependency graph and Dependabot alerts. The dependency graph shows two things related to our repository:
- dependencies – the ecosystems and packages it depends on
- dependents – the repositories and packages that depend on it
The important information 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, works like that: 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, according to our needs and internal compliance rules. But I suggest using the already existing ones, which is also recommended by GitHub itself. 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 secrets 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 conclusion 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.
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 tries to protect our secrets inside the workflows, however, it is not impossible to expose them if we define our own script. So be careful and double-check manually created scripts before you will add them into 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 “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 disable GitHub Actions at all. Of course, only assuming you don’t use them and don’t plan on doing so. Then it will allow us to protect ourselves from accidentally or maliciously defining and launching an action that we do not want.
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.
Secondly, which is obvious, make sure your repository is properly backed up. Basically, I could start this article with this sentence, because the backup is the basis of all security standards, but I will end with this reminder. Remember, that at the end of the day, it is up to us and our work to make sure our applications are safe.
