In my previous post, I covered how you can secure your CI/CD pipeline with Tracee from potentially malicious code executions. We’re now releasing Tracee GitHub Action, which makes using Tracee a plug-n-play experience and doesn’t require any prior knowledge of eBPF or Docker. We’re also introducing a new capability to profile the normal behavior of workloads to automatically detect any unexpected code execution drifts in your pipeline. In this post, I will show how to use Tracee GitHub Action and share a demo that can come in handy when building and securing your own pipelines.
Making shift-left security accessible to everyone
Tracee, Aqua’s open source runtime security tool, can also be used in CI/CD pipelines to detect malicious activity and prevent supply chain and CI poisoning attacks like the one that happened using the Codecov integration. Running Tracee in the pipeline allows you to detect malicious or suspicious activity during the build, thereby helping you secure your applications early in the development lifecycle.
Now we’re introducing Tracee GitHub Action, which makes this process even easier. Before, you had to manually run Tracee in the pipeline as a Docker container and choose specific configuration options, e.g., volume mounts, running in privileged mode, and others. Furthermore, checking for malicious activity in the pipeline required a user intervention and manual inspection of logs. With this in mind, we decided to write a GitHub Action for Tracee to make the user experience as seamless as possible.
Let’s dive in and take a look at a demo project that makes use of Tracee Action.
Tracee Action Example
Tracee Action Example is a simple repo created to demonstrate how you can set up Tracee Action in your existing pipeline. In a nutshell, it has the following GitHub Action workflow setup:
As you can see, we have four easy steps in this pipeline:
- Checkout the repo as a git repository.
- Start Tracee execution. This runs Tracee in the background.
- Execute a sequence of commands to simulate a pipeline step. In this case, we run a sleep and curl within the GitHub Action.
- Finally, we check for the results of the execution.
Tracee now automatically configures itself to run with the correct permissions and volume mounts behind the scenes. Furthermore, it also bootstraps a tracee.profile, which represents the last expected runtime profile of all programs that were known to Tracee to execute within the GitHub pipeline environment. Upon the first invocation of Tracee Action, a tracee.profile is created and submitted to the repo under use as a Pull Request to the default branch.
A tracee.profile file is a JSON object. A detailed example is as follows:
As our pipeline runs nothing but a simple sleep and curl through bash, we see four programs being executed. The syntax of the profile file is as follows:
| Field | Description |
mount_ns |
Mount Namespace of the process that ran |
/path/to/process |
File path and name of the process that ran |
time_stamp |
Creation UNIX timestamp of the process that ran |
times |
Number of times the program was executed |
file_hash |
A SHA256 checksum of the process binary |
This bootstrapped profile would constitute a baseline for our example pipeline. Since it is the first time we run Tracee with the demo project, Tracee will automatically send a Pull Request to the default branch of the repo.
Once the baseline is established, the maintainer of the repo can choose to merge this Pull Request in. The tracee.profile will then be checked into the top level of the GitHub repo.
Automatic tracking and updates
After the repo has a baseline profile established and checked in, Tracee profile will be compared to this baseline each time the pipeline is run. This will alert if any program that was not expected to run was found during the execution of the pipeline. As we saw in the Codecov breach, maintainers of the repos were unaware of the program executions that were happening within their pipelines.
By running in the background as a GitHub Action, Tracee can keep track of what happens in your pipeline and report the updates back. You don’t need to monitor logs anymore to know what’s going on in your pipeline – you can be informed via Pull Requests to your repo to see changes as they happen.
In the example project case, we’ve chosen to run the Tracee GitHub Action on each Pull Request that gets created. Let’s see how it looks.
Step 1: New contributor creates a simple PR
This triggers Tracee GitHub Action to run and start profiling. In this case, the user has hijacked one of the remotely fetched artifacts to execute a crypto miner within the pipeline.
Step 2: Build fails because of unexpected code execution
Tracee GitHub Action fails the pipeline because of the difference observed between the baseline and running an unexpected program.
Step 3: Report any differences observed
Tracee Action creates a Pull Request against the repository with the observed execution profile.
It is important to note that failing the build and creating a Pull Request are optional configuration options available for Tracee GitHub Action. By default, Tracee GitHub Action will run in monitor-only mode, which will only show the differences observed (if any) in your CI pipeline logs.
Available today
As the number of CI workloads increases, it is crucial to embed security into your development lifecycle right from the start. The new Tracee GitHub Action can help you “shift left” and secure your applications at build by detecting malicious activity in the CI pipeline in real time.
Tracee GitHub Action is available today as an open source repo. You can find Tracee in our GitHub repository.
