Which Build Threat corresponds to "pwn request"

[fproulx-boostsecurity]

I'm trying to fit classic "pwn request" in an existing Build Threat (https://slsa.dev/spec/v1.0/threats#e-compromise-build-process) and it's not 100% clear in which one it neatly fits in.

It clearly falls under (E) Compromise build process, but the detailed threat scenarios do not really cover the classic attack sequence: Public GitHub Repo, Repo Uses GitHub Actions, Threat Actor forks repo, Workflow triggers on pull_request_target event, Workflow checks out untrusted code from fork, Workflow has either Injection or uses a compiler / linter / test tool that is known to consume source files in a way that can influence build behavior (i.e. "Living Off The Pipeline")

In the 1.1 (or Draft), I see (D) External build parameters which has Build from unofficial parameters which mentions "injection", but that still does not talk about Pull Requests from forks, nor does not cover the "execution influenced via untrusted code checkout"

[fproulx-boostsecurity]

I could find a discussion between @MarkLodato and @mattmoor that mentioned pull_request / pull_request_target (#188) and that was put on the back burner it seems

[mattmoor]

I think the key thing is that pull_request_target can still be misused to activate unreviewed code, so it isn't a silver bullet.

At you are well aware, this is unfortunately extremely nuanced (to the point that I basically wholly discourage the use of pull_request_target because it's effectively impossible to "hold safely").

[fproulx-boostsecurity]

It is possible to use it safely, but it comes with great responsibility, break up of workflow into multiple jobs isolating the dangerous parts, making it have zero access (least privilege setting of GITHUB TOKEN for each job, no secret ), pipe and filter of risky job output to next stage etc.

In any case, SLSA should clearly document those threat because it’s still very much prevalent and there are much less obvious scenarios

[mattmoor]

“Effectively” is very load bearing in my statement.

The level of awareness is exceptionally (I’d say prohibitively) high

[fproulx-boostsecurity]

The fact remains that the same idea applies across to Gitlab pipelines, Azure Devops, Circleci , Openshift they all have this privileged mode which is risky.

[trishankatdatadog]

Looks like some of the TODOs for mitigating some attacks in v1.1.

I just don't think we're there yet to be able to say anything precise enough for this. The way I see it, SLSA is about using in-toto attestations to concretely address some attacks. We only prescribe one attestation today (build provenance), and how can it be used to address this attack? Also, like Matt says, the mitigation is nuanced (and specific to GitHub anyway).

[fproulx-boostsecurity]

I understand that, on a technical level, the scope of SLSA focuses on attestation and build provenance. However, the fact remains that, to this day, it serves as the most trustworthy, generic threat model for software supply chain security across an average SDLC.

I agree with Matt that doing this well is challenging, and any guidance is highly dependent on implementation and platform specifics. However, the general concept of a "pwn request" in the context of open-source projects hosted on public source control (not limited to GitHub) that accept contributions and trigger linting or tests on these contributions is not platform-specific.

Platforms like GitHub, GitLab, Azure DevOps, Bitbucket, etc., all support forks and can trigger their own built-in builds (or external ones, as a side effect).

Returning to my original question: does this scenario fit under "Compromise build process" or "External build parameters"? I'm certainly not suggesting that SLSA should include an extensive list of platform-specific nuances. Instead, I’m simply looking to capture this generic threat in an agnostic manner.

There are already plenty of resources (shameless plug for our own) that cover implementation-specific nuances.

[trishankatdatadog]

Returning to my original question: does this scenario fit under "Compromise build process" or "External build parameters"? I'm certainly not suggesting that SLSA should include an extensive list of platform-specific nuances. Instead, I’m simply looking to capture this generic threat in an agnostic manner.

Great points, and make sense. To me, I think "pwn request" falls more under "External build parameters". WDYT?

[fproulx-boostsecurity]

Yes. If we think of “injection” that’s clear, if we think of untrusted code from the head of the fork as external build “parameter” bit of a stretch but it’s an input fed to say “npm install” leading to RCE