Is there interest in performing analysis of GitHub Actions implementations, e.g. pkg:githubactions/actions/checkout@v4.1.6?
I'm interested in the same outputs: files/networks/executables the action performs as it's executing.
I'm uniquely interested in writes to the $GITHUB_ENV path (e.g. if an action modifies the PATH variable).
Shopify built a system that combines both: we set up tracee on an Actions worker, then invoke Actions-on-Actions using nektos/act pointed at a honeypot repository.
The biggest gap would be the lack of package-feeds support - since GitHub acts as the registry, detecting new versions of known Actions is trivial but detecting new Actions is ~impossible(?).
Is there interest in performing analysis of GitHub Actions implementations, e.g.
pkg:githubactions/actions/checkout@v4.1.6?I'm interested in the same outputs: files/networks/executables the action performs as it's executing. I'm uniquely interested in writes to the $GITHUB_ENV path (e.g. if an action modifies the
PATHvariable).The system could use https://github.com/nektos/act to provide an Actions-compatible sandbox to run on any compute. The system could run on Actions compute, as an instrumented workflow: https://medium.com/develeap/verifiable-github-actions-and-workflow-security-using-ebpf-an-insight-from-kubecon-2023-858567dc9a64
Shopify built a system that combines both: we set up
traceeon an Actions worker, then invoke Actions-on-Actions usingnektos/actpointed at a honeypot repository.The biggest gap would be the lack of
package-feedssupport - since GitHub acts as the registry, detecting new versions of known Actions is trivial but detecting new Actions is ~impossible(?).Related