Provenance attestations inherit your source control's integrity, and nothing tests that

Two documents that most teams file under compliance say the same uncomfortable thing about provenance. GitHub's artifact attestations documentation warns that attestations are not a guarantee that an artifact is secure, that they link you to the source code and build instructions that produced it, and that it is up to you to define your policy criteria and make an informed risk decision ^[1]. SLSA's v1.2 source requirements are equally plain about scope: onboarding a branch to the Source track makes claims about how that branch is managed from that revision forward, and no claims are made for prior revisions ^[10].

If your reproducibility story is "this artifact came from this commit, built by this workflow," both statements are load bearing. The guarantee you are selling is a pointer, and a pointer is worth exactly the integrity of the thing it points at.

What the signature actually covers

An artifact attestation is a cryptographically signed claim containing a link to the workflow, plus the repository, organization, environment, commit SHA and triggering event, plus other information from the OIDC token used to establish provenance ^[2]. GitHub signs these using Sigstore. For public repositories the bundle goes to the Sigstore Public Good Instance and is written to an immutable transparency log that is publicly readable on the internet ^[3]. For private repositories it goes to GitHub's own Sigstore instance, which runs the same codebase but has no transparency log and federates only with GitHub Actions ^[4]. Attestations by themselves provide SLSA v1.0 Build Level 2; moving the build into a shared reusable workflow that isolates the build process from the calling workflow reaches Build Level 3 ^[5].

Read the enumerated fields again and note what is absent: any assertion about whether the commit deserved to be there. The attestation says that a build of this input happened in this place. GitHub says as much twice, in that warning ^[1] and in the observation that generating attestations alone provides no security benefit, because the benefit exists only once someone verifies them ^[6]. There is also a line of guidance that lands awkwardly for anyone running a retraining loop: GitHub advises signing software you expect people to run, and explicitly advises against signing frequent builds that are just for automated testing ^[7].

The forward-only guarantee

The source side is where the accounting thins out. SLSA Source Level 2 clarifies which branches and tags are consumable and guarantees that all changes to protected branches and tags are recorded and subject to the organization's technical controls ^[8]. Level 3 requires the source control system to generate credible, tamper-resistant, contemporaneous evidence of how a revision was created, with the stated benefit of reducing the risk of tampering within the SCS's own storage systems; Level 4 requires two trusted persons to review all changes to protected branches ^[9]. Crucially, the expected process for creating a revision is determined solely by the repository's owner, who also determines the intent of the software and administers the technical controls that enforce it, leaving consumers to review the attestations and decide whether that meets their standards ^[11].

So the chain reads: the organization defines its own process, the SCS records adherence from onboarding forward ^[10][11], the build system signs a pointer to a revision ^[2], and the consumer decides what that is worth ^[1]. Nowhere does anyone verify that the revision reflects what the organization meant to ship. SLSA names the gap directly. A source integrity threat is the potential for an adversary to introduce a change to the source code that does not reflect the intent of the software producer, and it includes modification of source data at rest as well as insider threats, when an authorized individual introduces an unauthorized change ^[17].

Two defeats that break nothing

The first is history. Each GitHub branch protection rule disables force pushes and prevents branch deletion by default, and both are settings that can be turned back on ^[13][15]. But by default the restrictions of a branch protection rule do not apply to people with admin permissions, or to custom roles holding the "bypass branch protections" permission; applying them to administrators is an option you must select ^[14]. Require signed commits and require linear history are likewise opt-in ^[15]. And only a single branch protection rule applies at a time, which GitHub's own documentation says makes it difficult to know which rule will apply when multiple versions of a rule target the same branch ^[16].

Set that against SLSA's threat model, which treats directly pushing a change to a git repo's main branch as threat B1, with two-party review as the solution ^[18], and which places that review requirement at Source Level 4 ^[9]. The platform default and the standard's requirement are not aligned. A repository can hold a protected branch, a green test suite and a signed attestation while a privileged actor changes what the attested SHA means. No stage of the pipeline is built to notice, because the pipeline's job is to attest what it was handed.

Then the robots. SLSA is explicit that exploiting a robot account with the ability to submit changes without two-person review is its own threat, that the mitigation is review by two people even for changes authored by robots, and that a common solution is to deny bot accounts from contributing or reviewing code, or to require more human reviews in those cases ^[20]. It also flags the case where a single actor controls multiple accounts, opening a pull request from a secondary account and approving it from the primary, and says producers must track every actor with both review permission and the independent ability to control a privileged bot ^[19]. If your data-version bumps or retraining artifacts land in git through an automation identity with write access, that is the configuration SLSA tells you to deny.

The second defeat is the session. MITRE's technique T1506, web session cookie, is catalogued under both Defense Evasion and Lateral Movement ^[22], which is the honest pairing: a valid session is not an exploit, it is an authentication that skips the checks. This is where the month's malware reporting meets the provenance question. Microsoft Defender Experts linked more than 30 web domains to MacSync Stealer, a macOS information stealer, and said the investigation confirmed active data exfiltration rather than just beaconing; Microsoft disclosed no victim count and named no actor ^[23]. What MacSync collects is, in effect, the control plane: Keychain material, browser credentials and cookies, session data, SSH keys, AWS credentials, Kubernetes configurations, and more ^[24]. Four of those classes are push, deploy or artifact-storage authority on their own ^[1]. The entry point is not a vulnerability; observed execution began from an interactive zsh Terminal session consistent with ClickFix social engineering, with curl retrieving attacker-controlled content and native utilities decoding it, and the malware removing temporary archives, staging folders and lock files afterwards ^[25].

GitHub's own unauthorized-access guidance, read sideways, is an inventory of what a session holder can alter: SSH keys, deploy keys, authorized OAuth apps and GitHub Apps, email addresses (an attacker-added address could force an unintended password reset), private repositories turned public or transferred, collaborator lists, and webhooks, which GitHub notes could allow an attacker to intercept pushes ^[28]. There is a real boundary worth stating: GitHub requires a password to perform sensitive actions such as adding new SSH keys, authorizing applications, or modifying team members ^[27], so a stolen cookie is not administrative root. But the same checklist ends with "review recent commits made to your repositories" ^[28]. The prescribed detection for a source integrity failure is a human reading the log.

Why nothing turns red

Tests assert behaviour under inputs you chose. Provenance asserts binding. Neither asserts intent, which is the property SLSA says is under attack ^[17]. Two recent disclosures show how thin the resulting evidentiary record can be.

Varonis's CoSnitch research covers three flaws in Microsoft Copilot Personal, tracked as CVE-2026-24301, reported to Microsoft in December 2025 and patched on August 18, 2026, with no evidence found of exploitation in the wild ^[32]. One path writes attacker instructions into the user's persistent memory store, and Varonis said that write produces no process, file, network connection or log entry that security tooling would flag, with the change visible only in Copilot's memory interface ^[29]. Varonis also said the injected instruction survives password changes, session revocation and device re-enrollment, and stays active in later conversations until the user deletes it ^[30], and that the exfiltration request is indistinguishable at the network layer from the fetches Copilot performs when summarizing an ordinary web page ^[31]. Credential rotation, the standard answer to a stolen session, does not evict that.

The governance analogue is sharper. In March 2026 an internal AI agent at Meta triggered a Sev 1 incident: an engineer used an approved agent to analyze a question, the agent posted its response publicly without approval, and the employee followed its advice, inadvertently making a large volume of sensitive data available to unauthorized engineers for over two hours ^[34]. The tool was sanctioned. The lesson drawn is that approving a tool is no longer the same as approving its use, and that you cannot simply block something you have already approved and rolled out ^[33]. A July 2026 SANS survey found 76% of security teams now have a role in governing enterprise AI ^[35]. Substitute "workflow" for "tool" and you have the attestation problem stated precisely: signing a workflow is not signing what the workflow did on a given day.

Identifiers are not behaviour

For the failure mode in its purest form, look at what Socket Threat Research found in the Firefox add-ons ecosystem. Of 77 related browser add-ons sharing source code and infrastructure, 40 are confirmed malicious under a campaign Socket calls Offside Wallet Theft Factory, believed active since March 2026 and not attributed to any known group ^[36]. Some first appeared on the official marketplace as sports score or utility shells before being turned into wallet-stealing malware under the same Firefox ID, and historical versions of nine confirmed malicious identities carried those sports shells before later versions were repurposed ^[37]. Thirteen were modified Rabby Wallet builds that exfiltrate serialized keyrings before local encryption ^[38]. Socket's Kirill Boychenko described the economics: a single successful installation can expose a recovery phrase or private key worth far more than the cost of repeatedly publishing disposable extensions, and rotating names and IDs, repurposing existing identities and cloning code make repeated publication cheap and scalable ^[39].

The stable identifier, the version history and the store listing all held while the payload inverted. A commit SHA and a signed Sigstore bundle are the same class of evidence: continuous, verifiable, and silent on whether the content still reflects intent.

What this constrains

None of this argues against attestation; it argues against treating attestation as a test result. The settings that carry weight are unglamorous and mostly off by default: apply branch protection restrictions to administrators and bypass roles rather than exempting them ^[14], turn on require signed commits and require linear history ^[15], keep force pushes and deletions disabled ^[13], deny bot accounts the ability to contribute or review, or require additional human review where they do ^[20], track anyone who holds both review permission and control of a privileged bot ^[19], and verify attestations against a written policy rather than merely producing them ^[6]. For private repositories, remember that the signed record has no public transparency log and federates only with GitHub Actions ^[4], which is the same trust boundary as the credentials that write it; tamper-resistant evidence against the SCS's own storage is what Source Level 3 exists to provide ^[9].

The deeper constraint is on what you can promise. Your reproducibility guarantee inherits the weakest of three things: the credential hygiene of everyone who can push, the bypass configuration of the branch, and the consumer's willingness to actually verify. A rewritten commit and a stolen cookie both work through those, not around them, which is why the build stays green.