Using Evidence Platform as CI/CD Security Layer

Following the recent Trivy and LiteLLM supply chain attacks, it is a common view that we don't have a good way to protect our CI/CD layer, specifically GitHub Actions, from supply chain attacks.

Specifically, it takes a single compromised dependency downloaded on a developer machine to run scripts at installation time. Such scripts are known to steal and exfiltrate all available credentials, that may include elevated permissions to source code repositories, Kubernetes clusters, cloud provider credentials, crypto credentials, and others.

Popular open source ecosystems, including npm and pypi, are frequently used in such attacks because they are popular and because often packages are allowed to run unchecked scripts during dependency installation phase. So all it takes is to have a single compromised dependency somewhere in the supply chain and then a developer to run npm install or similar. Pavel Shukhman, CEO of Reliza, previously discussed npm specifically in relation to Shai-Hulud 2.0 attack in his blog post npm Has Become a Russian Roulette. While he listed a set of possible defences there, he admitted, that no foolproof solution currently exists.

GitHub Actions Cannot Protect Itself

GitHub Actions is arguably the most popular CI/CD platform today, in 2026. However, if a release CI/CD workflow becomes compromised, it is almost impossible to think about a control that could mitigate such compromise.

Let's consider 2 attack scenarios:

1. An attacker steals a GitHub write token from a developer machine. If that token had elevated permissions, the attacker would immediately gain full control over the GitHub repository and all associated resources. They will then be able to publish releases and propagate the attack down to the supply chain. Even if the token was only a write token, the attacker would be able to overwrite GitHub Actions CI/CD workflow scripts and use that to construct malicious releases.
2. A GitHub Actions workflow inadvertently executes malicious code that gains access to CI tokens. This can happen through a compromised dependency, or through a pull_request_target workflow misconfiguration - where a PR from a fork runs with write permissions and access to repository secrets. This is what happened in the Trivy breach: a malicious PR exploited a vulnerable pull_request_target workflow to exfiltrate secrets. The stolen credentials were then used to publish backdoored versions of the Trivy GitHub Actions, which in turn compromised downstream users - which possibly included LiteLLM, whose PyPI publishing credentials may have been stolen by the backdoored Trivy action running in LiteLLM's own CI pipeline (note that this is not confirmed, but it is a plausible scenario).

Note that in the case of stolen tokens, the attacker's window of permissions would likely be limited by the lifespan of those tokens, but this could still be enough to publish a malicious release and spread the compromise.

In both such scenarios, GitHub Actions workflow itself becomes compromised and any control within it would be ineffective.

Evidence Platform as CI/CD Security Layer

Evidence platform such as ReARM can serve as a security layer for CI/CD workflows. Evidence platform by definition creates a verifiable record of supply chain events and artifacts that are stored outside of the actual CI/CD system. Of course, an evidence platform may be subject to attack as well, but in case of compromise an attacker would need to breach both the CI/CD system and the evidence platform. Thus, such attack would be significantly more difficult to carry out. In other words, an evidence platform may be used as similar to a 2FA - it adds an additional layer of security to the CI/CD workflow.

Practical Implementation of Evidence Platform as CI/CD Security Layer

To properly protect CI/CD workflows with an evidence platform, it is important to build workflows with the principle of separation of duties. This means that different stages of the workflow should be performed by different entities, and each entity should have a different set of permissions. For example, a workflow that builds and releases a container image should have a separate stage for building the image and a separate stage for releasing the image. The building stage should have permissions to build the image, but not to release it. The releasing stage should have permissions to release the image, but not to build it. This way, if an attacker compromises one stage, they would not be able to compromise the other stage. For more details on this and other CI/CD best practices, refer to another Pavel Shukhman's post 7 Best Practices of Modern CI/CD.

We should note here that existing mitigations such as pinning GitHub Actions to specific commit SHAs (rather than mutable tags) and using short-lived OIDC tokens for authentication where possible help reduce the attack surface. However, they do not fully solve the problem:

1. SHA pinning does not protect against a compromised action at the pinned commit (or such action may still download additional unpinned dependencies at runtime, including other GitHub Actions).
2. If an attacker obtained write token to repository as in our first scenario above, they would be able to overwrite any existing SHA pinning and completely replace the workflow scripts if they wish so.
3. And OIDC tokens - while short-lived - are still accessible to any code running within the compromised workflow and can be used during their lifespan which may be sufficient to carry out an attack.

With that in mind, in 2026 we have to admit that true separation of duties requires stages to live in different repositories. That is because different workflows in the same repository may still have access to the same GitHub Actions secrets. In certain cases it is possible to limit access to sensitive tokens on a per-workflow basis, but this is more an exception than a rule.

So, to practically implement secure workflows, we need to introduce structure similar to the following:

1. CI stage that builds initial (non-release) artifacts may still belong to the main repository
2. Evidence platform that verifies the artifacts and stores them
3. Approval and/or release lifecycle rules within the evidence platform to gate the release
4. Separate CI/CD workflow in a different repository with no direct developer write access — only the evidence platform's service account has permission to trigger it (so if a developer token is compromised, the release workflow remains intact)
5. Evidence platform triggers the release workflow when release is approved
6. Release workflow itself should contain additional security checks to ensure that the release is legitimate - for example, verifying Sigstore/cosign signatures and attestations that were stored in the evidence platform during the build stage

Note that for ReARM specifically, approvals and triggering workflows is only a ReARM Pro functionality, i.e. as described here for GitHub Actions. However, even ReARM CE users can leverage GitHub Actions scheduler and use ReARM CLI to request latest release with desired lifecycle.

Summary

The described implementation mitigates attack scenarios outlined above by introducing an additional layer of security between the CI/CD system and the evidence platform. Even if the attacker compromises the initial CI/CD workflow, they would still need to compromise the evidence platform to publish a malicious release. While possible, this would require more time, and the evidence platform itself should be configured to include additional controls to flag suspicious activities - such as signature and identity verifications, SBOM diffing, and other security checks.

With the system outlined above, CI/CD system and Evidence Platform work together to create a more secure supply chain. They create a set of controls that essentially "police" each other, so that to mount a successful attack, an attacker would need to compromise both systems at the same time.