TLDR: SLSA identifies how a software was built and if it can be trusted. SBOM shows the package tree of a software.
SLSA (Supply-chain Levels for Software Artifacts)
SLSA is a security framework or a list of practices that help control tampering with software packages in a dependency tree. It provides a number of tracks and levels to determine how secure a software product is, making it useful for everyone involved in producing and consuming software.
A SLSA track focusses on a particular aspect of the supply chain such as the Source, Build or Dependencies tracks. Within a track, there exists levels of hardened security practices with higher levels providing more security guarantees. The Build track for example, verifies that the track was built as expected. It includes levels starting from L0 for "No guarantees" to L3 which corresponds to "Hardened build platform".
About Pwn Requests
A "pwn request" is a form of supply chain attack in GitHub Actions. It occurs when a priveledged workflow in a repository gets triggered by pull_request_target where it executes unreviewed code from an untrusted external pull request. pull_request_target would then have access to variables and secrets of the repo eg. GITHUB_TOKEN.
Different security levels come with different levels of risk exposure. An example is the widely reported Tanstack attack that happened on May 11th 2026. During this attack, a pull_request_target action was triggered from a fork-contributed code in the base repo. The action executed malicious code in the trusted repo. The attacker scraped the GitHub runner's memory and extracted the OIDC token to sign and produce cryptographically valid artifacts. The pnpm package store was therefore poisoned with 84 malicious packages under legitimate TanStack identity.
How the attack relates to SLSA
npm's provenance achieves a Build L2 level, which means that the build runs on a hosted platform and artifact creation is authenticated. This binds a package to its canonical source repo and build system. This protects against registering packages that have no legitimate source. Build L3 on the other hand, requires that the build platform guarantees isolation. This means that cache poisoning would not be possible since tokens and code would not persist in shared memory. With L3, builds can not influence one another and credentials are inaccessible in build steps. A Build L3 practice would have prevented the TanStack attack but so would workflow hygiene. Workflows that use pull_request_target to execute forked code should apply least-privilege permissions.
TanStack published a remediations document following this attack, that includes amongst other things, disabling the cache in the release pipeline, removing all the pull_request_target actions from their CI, enforcing 2FA and other.
SBOM (Software Bill of Materials)
One way to improve the security of the software supply chain is to use SBOMs. SBOM stands for Software Bill of Materials and it can be generated at image build time to capture the full dependency tree including the OS packages.
SBOM answers the question: what is actually running in production? It is a structured machine-readable inventory of every component library and module inside a software artifact. Where a package manifest like requirements.txt lists dependencies, an SBOM captures the resolved dependency tree after the build including system-level packages and metadata about every component's origin, version and licence.
The value of having an SBOM
When something goes wrong i.e. when an open source package gets compromised, the SBOM can be queried to identify the affected artifact. This saves time tracing the compromised package in a software.
SBOMs can be used during vulnerability scanning where new CVEs (Common Vulnerabilities Exposures) are matched against the components listed in the SBOM without having to analyse the image. Here's how an SBOM can be generated for a Docker image: