Source Audit

What Source Audit Covers

Source audit is broader than a point-in-time code review. It examines the provenance of source code and source artefacts, the chain of changes that produced them, and the controls around who can modify, approve, and ship them. The goal is to confirm that the source being built is the source the organisation intended to trust.

That makes source audit a control over integrity, traceability, and policy compliance. In practice, it asks whether the repository history is credible, whether sensitive changes were authorised, and whether the artefact still reflects the reviewed source after commits, merges, and release processing.

Why Source Audit Matters

The value of a source audit is that it reduces the gap between “code exists” and “code is trustworthy.” A repository can be technically functional while still containing unauthorised edits, hidden dependencies, or source that does not match the release process. Audits help expose those mismatches before they become production risk.

Source audit also supports governance and licensing obligations. Organisations may need to show that their shipped software matches approved inputs, that third-party code is tracked, and that change control is defensible. For teams working with open source or regulated environments, auditability is part of the security story, not just a paperwork exercise.

What Auditors Examine

A useful source audit usually looks at commit history, branch protection, code review records, repository permissions, and the relationship between source, build inputs, and released artefacts. It may also inspect dependency declarations, generated files, and whether the build process can be reproduced from approved materials.

Where provenance matters, the review often extends beyond the code itself to the controls around it. That includes whether source changes came from trusted identities, whether sensitive paths are protected, and whether the repository contains artefacts that should have been excluded or quarantined. A review is stronger when it connects content, custody, and change history rather than treating the repository as a static file store.

How Source Audit Supports Integrity and Compliance

Source audit is most effective when it joins technical verification with policy enforcement. The review can reveal whether the codebase includes unauthorised forks, stale branches, unreviewed merges, or licence conditions that were missed during development. It also creates an evidentiary trail for internal assurance and external audit requests.

This is why source audit is closely related to software supply chain assurance. If the source cannot be tied to approved changes and controlled inputs, downstream build integrity becomes harder to defend. In mature environments, source audit helps answer a simple but critical question: can we prove that the thing we shipped came from the source we authorised?

Risk and Threat Considerations

Source audit reduces the risk that compromised, manipulated, or non-compliant source reaches production unnoticed. The main concern is not just malicious change, but also weak provenance, poor repository hygiene, or a build path that silently diverges from the reviewed source.

Failure mechanism: An attacker, insider, or faulty process can alter commits, inject code through an untrusted branch or dependency, or exploit weak change control so that the released artefact no longer matches the approved source.

Impact: The result can be backdoored software, licence or policy violations, broken traceability, and a compromised ability to prove what was actually shipped.

Practitioner Guidance

Why practitioners should care: Source audit is only useful when it is tied to a clear release decision, not treated as a one-off forensic exercise. Teams should know which repositories, artefacts, and approval paths are in scope, and what evidence is required to consider the source trustworthy.

What to watch for: Pay particular attention to unexplained history rewrites, bypassed reviews, broad write access, generated files committed as if they were hand-authored, and gaps between repository state and build output. Those are the conditions that most often weaken audit confidence.

Practitioner takeaway: A source audit should verify lineage as well as content, because integrity is established by the whole path from change request to shipped artefact.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on audit trails as their only source of truth?
• What breaks when auditors rely on sampling and spreadsheets instead of source data and audit analytics?
• What happens when repository permissioning and audit logging are too weak for open source release workflows?
• What is the difference between a vendor access log and a single source of truth for audit review?