Rekor is a transparency log for signed software artefacts and supply chain metadata. It records signing entries so defenders can verify what was signed and when, and detect missing or altered provenance. It is used to support auditability and reduce the risk of hidden or replaced artefacts.
What Rekor Does in a Software Supply Chain
Rekor is a transparency log for signed software artefacts and supply chain metadata. It does not replace signing or build provenance tools, it records evidence about them so defenders can later verify what was signed, by whom, and at what point in the supply chain.
That matters because a log creates an append-only reference point. If an artefact appears later without a matching entry, or if provenance details change unexpectedly, the mismatch becomes a signal that something may be missing, altered, or improperly introduced.
Why Transparency Logging Matters for Provenance
Rekor helps turn software provenance into something that can be checked, not just claimed. In practice, it supports auditability across release pipelines, dependency intake, and deployment validation, especially where organisations need evidence that an artefact was produced and signed under expected conditions.
It is useful in ecosystems where multiple parties touch the same artefact, because a signed package alone does not tell the whole story. The log helps defenders compare declared provenance against recorded events and spot gaps where a release, update, or metadata record may have been replaced or omitted.
A broader view of software supply chain security shows why provenance, signing, and verification need to work together rather than as isolated controls.
How Rekor Fits with Signing and Verification Workflows
Rekor sits alongside signing systems and verification gates, rather than acting as a standalone trust mechanism. A defender typically uses it to confirm that a signature or attestation has a corresponding recorded event, then checks whether the entry aligns with the expected source, build, and release path.
This makes it especially valuable when teams want to detect hidden substitution, replay, or provenance manipulation. The log does not guarantee that an artefact is benign, but it can expose when an artefact lacks the history it should have, or when recorded history does not match the artefact being presented.
That pattern aligns closely with SLSA, which focuses on build provenance and integrity, and with NIST SP 800-53 Rev 5 Security and Privacy Controls, where auditability, configuration integrity, and system integrity are recurring control themes.
Operational Value for Defenders and Release Owners
For practitioners, the value of Rekor is not just evidence retention, it is the ability to compare what was intended with what actually moved through the supply chain. That gives release owners, security teams, and auditors a common record when investigating software origin, release disputes, or suspected tampering.
The strongest use cases appear when the log is integrated into CI/CD, package publication, or deployment admission decisions. If verification is optional or disconnected from deployment controls, the transparency log becomes a passive archive rather than an active security control.
Teams building broader guardrails around non-human and pipeline-driven access can also map this control to OWASP Non-Human Identity Top 10, because signed artefacts, build agents, and release automation all depend on trustworthy machine-issued material.
Risk and Threat Considerations
Transparency logs reduce uncertainty, but they also become valuable targets when an attacker wants to hide provenance gaps, tamper with release records, or smuggle altered artefacts into trusted workflows. The risk is highest where defenders rely on signatures alone and do not cross-check recorded entries, because a forged or missing provenance trail can delay detection.
Failure mechanism: An attacker or compromised pipeline can replace, replay, or suppress artefacts and then exploit weak verification to make the altered item look legitimate.
Impact: Defenders may trust an unrecorded or mismatched release, which can lead to malicious code execution, undetected supply chain compromise, or loss of audit confidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Rekor supports provenance and integrity verification for software artefacts. |
| Recommendation — Adopt provenance checks that verify signed artefacts against recorded build evidence. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Rekor creates auditable records for signed artefacts and release events. |
| SI-7 — Software, Firmware, and Information Integrity | Rekor helps verify artefact integrity and detect altered provenance. | |
| Recommendation — Log release and verification events so provenance can be reconstructed during review. Use integrity checks to reject artefacts whose provenance cannot be verified. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Signed artefact pipelines depend on protected signing material and recorded provenance. |
| NHI-07 — Long-Lived Secrets | Rekor is often part of workflows that rely on rotation and short-lived trust evidence. | |
| Recommendation — Protect signing material so compromised secrets cannot create trusted artefacts. Prefer short-lived signing trust and rotate secrets used in artefact issuance. | ||
Practitioner Guidance
Why practitioners should care: Treat Rekor as part of an enforcement chain, not a passive record. Its value depends on whether release, deployment, and verification steps actually consult the log before artefacts are trusted.
What to watch for: Investigate any signed artefact that lacks an expected log entry, any entry that does not match the release metadata, and any workflow that allows exceptions without review. Those are the conditions where transparency breaks down first.
Practitioner takeaway: If the log is not checked during admission or release validation, it may document the compromise after the fact rather than prevent it.