Git rebase is one of the most powerful tools in modern software workflows. It keeps branches linear, removes noise from history, and makes it easier to review code. But in a world where supply chain security threats grow daily, rebase isn’t just a convenience—it’s also a risk vector if handled without care.
When you rebase, you rewrite history. Every commit gets a new hash. This makes it harder to verify provenance later using commit signatures or automated verification. If your team depends on signed commits for integrity checks, a careless rebase can strip or invalidate that trust. A malicious actor upstream could hide altered commits inside a rebase chain in a way that's harder to detect.
Supply chain security in Git starts with strict verification. Enforce GPG or SSH signing on all commits, and reject unsigned or tampered histories at merge time. Use server-side hooks or CI pipelines to run cryptographic verification after every rebase. Combine this with dependency scanning so rebased code never smuggles in unreviewed changes to critical components.