Request: SBOM analysis for components installed/configured during GitHub Actions jobs

[mcandre]

Select Topic Area

General

Body

Very many engineers neglect to track 100% of development environments with SCA-friendly IaC package management files.

Dependabot is nice, but we should also scan GitHub Actions CI/CD ephemeral environments for known risky files and risky configurations applied.

For example, a GitHub Actions job that installs Apache 1.0 via wget/curl commands, will have latent CVE's that Dependabot does not account for.

SBOM collection should occur at least after the last provisioning GitHub Actions step that triggers a pass/fail status for the job, and probably after every single step, in order to identify vulnerabilities in components that are installed/configured for only a portion of the lifetime of the job. Results should be signaled back to repository owners independent of whether the job passes or fails.

Perhaps some OS distribution package manager SCA tools can assist with SBOM collection. But naturally, other components will not be installed as OS distribution packages, requiring Dependabot-like scans of the live runner file system trees (most mounts).

Whatever VM or container technologies are involved in GitHub runners, these images should be scanned on a regular, recurring schedule. Don't assume that projects with low activity are secure; CVE reports tend to arrive much later, and apply most to stale repos whose jobs haven't run in a long time. Low activity projects accrue the most (latent) CVE's as time marches on.

As a workaround, track Python ecosystem components with Snyk compatible requirements.txt files. Track Haskell components like ShellCheck with Snyk compatible Cabal files. Track JVM components with Gradle files. Track JS/altJS implemented tools with NPM or Yarn files. Track Rust components with Cargo files. Track Go components with go.mod files. However, that often significantly slows down jobs. And like most package managers, Conan was never designed to manage CLI dev tools, just libraries. The current security situation relies on the user to become familiar with source code level attributes of each of their development tools. In practice, we're not familiar. We install things and run them, and assume they're secure.

This kind of security knowledge gap is not unique to GitHub Actions, but pervasive across the CI/CD ecosystem. People forget that arbitrary curl/wget/Invoke-WebRequest/etc. commands don't get scanned, without significant, opt-in user effort. In other words, nothing gets scanned.

The user should familiarize with the primary programming language(s) involved in each of their tools, and rewrite provisioning steps to deepen integration with standard, SCA compatible package manager configuration files.