Review the files that can run code or change what you pull in, not every line. Start with build scripts, install hooks, workflow files, dependency manifests, binary files and anything that reaches the network. A sync that you merge without reading is a way for a compromised upstream to reach your product.
Why a sync deserves a review
A fork's sync pulls hundreds of commits from people you do not manage. Normally that is fine. When an upstream account is taken over, a sync is the delivery mechanism. The review is cheap compared with the cost of shipping a poisoned change, and it is one of the few controls a fork owner holds that ordinary dependency users do not, because you see the source before you build it.
Get a readable diff
Compare the old base with the new tag, and start with a summary.
git fetch upstream --tags
git diff --stat OLD_TAG NEW_TAG
git diff --name-only OLD_TAG NEW_TAG
Sort the file list by risk, as in the table, and read the high risk files in full.
| File type | Why it is risky | What to look for |
|---|---|---|
| Build and packaging scripts | Run on your build machines | New downloads, shell commands, obfuscation |
| Install or post install hooks | Run on your users' machines | Network calls, file writes outside the package |
| CI workflow files | Run with your tokens if you share them | New triggers, new secrets use, new third party actions |
| Dependency manifests and lockfiles | Change what you pull in | New packages, odd sources, changed versions |
| Binary or minified files | Cannot be reviewed as text | Why are they here, can they be rebuilt |
| Code that touches the network, files or processes | Core of most attacks | New outbound hosts, new exec calls |
Check for hidden characters
Source can contain characters that look like nothing but change meaning. See can hidden Unicode characters hide in copied code. A simple search for non printing and bidirectional control characters across the diff is worth running.
Compare to the release notes
A diff that includes large changes the notes never mention is a flag. So is a release that is a single huge commit with a vague message, or a maintainer you do not recognize landing build changes. None of these proves an attack, but each is a reason to ask upstream before merging. See signature checks before a sync.
Run, do not just read
- Build in an isolated environment with no secrets.
- Run the test suite, including your own tests for carried patches.
- Rescan dependencies and compare with the previous SBOM. New transitive packages are the thing to spot.
- Watch for changes in build behavior, such as new network traffic during the build.
Scale the effort
For a small, routine sync, a fifteen minute pass over the risky files is reasonable. For a large jump after a long gap, split the review by release so each piece is small enough to understand. This is another reason to sync often. See how often to sync a fork.
Where Safeguard fits
Safeguard's policies and gates can run on a pull request that carries the sync, checking the dependency changes it brings. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request is held until its checks pass.
Quick check
Do I need to read every changed line?
Not usually. Read the files that run code or change dependencies, and skim the rest. Split very large syncs by release.
What is the strongest warning sign?
Changes to build or install scripts that the release notes do not mention, especially from an unfamiliar contributor.
Last reviewed: 19 October 2026.
