SLSA Source Requirements

What SLSA source requirements are meant to protect

SLSA source requirements exist to preserve the trustworthiness of source code before it is built. They focus on whether the source history is traceable, whether changes can be attributed to an authenticated actor, and whether the revision record is complete enough to spot tampering.

That makes the source stage more than a storage problem. It becomes a provenance problem, where the organization must be able to show what changed, who approved it, and whether the current source tree reflects an auditable path rather than an unexplained rewrite. The broader SLSA model is defined at SLSA.

Practically, these requirements are strongest when applied to repositories that feed release pipelines, shared libraries, and code that can be modified by many contributors. They are meant to reduce the chance that a malicious or accidental source change silently reaches downstream build and release stages.

Core controls behind source integrity

The most important control idea is that source should be reconstructable. Retained revisions, protected branches, and durable history make it possible to compare what is in the repository today with prior states, rather than relying on memory or informal review notes.

Authenticated change attribution matters because source integrity depends on knowing which actor introduced a change. If commits, merge requests, or approved updates cannot be tied to a verified contributor or automation path, it becomes much harder to distinguish legitimate maintenance from unauthorized alteration.

Review discipline is the other major mechanism. A review step does not guarantee correctness, but it raises the cost of stealthy source tampering and creates a second set of eyes before changes reach the protected branch. Source requirements are therefore as much about process integrity as they are about code storage.

These controls align closely with broader software assurance practices, especially where organizations are trying to keep source history, author identity, and approval evidence intact. Open source supply chain programs often treat this as a foundational layer, which is why the topic also sits naturally alongside OpenSSF.

Why source requirements matter in the supply chain

Source is upstream of the build. If a repository can be altered without detection, every later artifact inherits that uncertainty. That is why SLSA source requirements are a supply-chain control, not just a repository hygiene checklist.

The value is provenance. Strong source controls let downstream consumers ask whether an artifact came from a known source state, through a known review path, and from a known set of contributors. Without that lineage, even a correctly signed build can still originate from compromised source.

This is where traceability becomes operationally important. Teams that can retain revision history, review records, and author attribution are better positioned to investigate unexpected releases, disputed commits, or emergency fixes that bypass the usual process. For practitioners, the source history is often the first evidence set to inspect when a software trust issue appears.

Where SLSA source requirements are often weakest

Source requirements tend to fail when organizations treat repository controls as administrative convenience rather than trust controls. The common failure pattern is a gap between what the team believes was reviewed and what the repository can actually prove.

That gap appears in force-pushed history, unaudited direct commits, weak branch protection, unclear ownership, and review paths that can be bypassed under pressure. It also appears when source changes are handled in tools or forks that do not preserve a reliable audit trail back to the protected source of truth.

At scale, the problem is usually not one catastrophic weakness but a collection of small exceptions. Each exception weakens the chain of custody for source, and the combined effect is that no one can say with confidence which changes were truly reviewed before release.

Risk and Threat Considerations

SLSA source requirements reduce the chance of source tampering, but they also expose how fragile repository trust can be when review paths, history retention, or author attribution are incomplete. If those controls are weak, an attacker or insider can hide malicious code in a normal-looking change stream and make later investigation much harder.

Failure mechanism: The failure is usually loss of provenance, for example rewritten history, unreviewed commits, spoofed attribution, or a bypassed approval path that leaves no trustworthy evidence of how source changed.

Impact: The result can be unauthorized source modification, delayed detection, untrusted releases, and a much weaker ability to prove whether downstream artifacts were built from legitimate code.

Practitioner Guidance

What to watch for: Treat any repository workflow that cannot answer who changed what, when, and under which approval path as a source-integrity issue, not a convenience issue. If the team cannot reconstruct revision lineage quickly, the source controls are not strong enough for a supply-chain-sensitive codebase.

Governance implication: Ownership should sit with the team that can enforce branch protection, review discipline, and revision retention consistently across the repositories that matter most to release integrity.

Related resources from NHI Mgmt Group

• How should security teams implement SLSA source requirements across the software development lifecycle?
• How do organisations balance broad source connectivity with strict isolation requirements in air-gapped data governance architectures?
• Why do source distributions used as build requirements increase supply chain risk for Python installs?
• Why is DevOps such a significant source of NHI risk?