Require a short list of checks before merge: tests pass, dependency changes are scanned, new external destinations are flagged, and edits to student record code get a second reviewer. Start with a few gates the team will accept, then tighten. A gate nobody respects is worse than none.
Why gates fit this kind of product
The NIST SSDF, SP 800-218 version 1.1, describes practices aimed at reducing vulnerabilities in released software and limiting the impact of those that remain. A pull request gate is one place where such practices become routine rather than good intentions.
For a student data app, the cost of a mistake is high and the team is usually small. Automation does the repetitive checking so reviewers can think about intent.
A starter set of gates
| Gate | What it checks | Action on failure |
|---|---|---|
| Tests | Unit and integration suite passes | Block |
| Dependency scan | New or changed packages have no serious known flaws on used code | Block or require approval |
| Lockfile check | Manifest and lockfile agree | Block |
| License check | New packages fit your allowed list | Require approval |
| New outbound domain | Code adds a call to a host you do not run | Require privacy review |
| Sensitive path review | Files that touch student records changed | Require second reviewer |
| Logging check | No student fields added to log statements | Block |
How to introduce them
- Start in report mode. Run the checks and show results without blocking for two weeks. Fix noisy rules.
- Pick two or three to enforce first. Lockfile agreement and tests are easy wins.
- Add dependency scanning with a clear threshold. Block only on findings that are serious and on code that is used, otherwise developers learn to ignore it.
- Define a fast exception route. A named approver can waive a gate with a recorded reason.
- Review gate results monthly. Which fire most? Which were waived? Adjust.
Protecting the gates themselves
Gates only help if they cannot be quietly removed. Use branch protection so checks are required, restrict who can change the workflow files, and review changes to them like code. Review CODEOWNERS so student record paths always route to the right people.
Dependency changes deserve extra care
A pull request that updates one package line can change many lockfile entries. The npm documentation says lockfile changes show up as readable diffs for that reason. Have the gate summarize which packages were added, removed, or changed, so reviewers do not need to scroll.
Try it yourself
Open the demo and watch a pull request pass through a gate. Notice what information the reviewer sees at the decision point.
Click through it at your own pace, or open it full screen.
Safeguard offers policies, gates, and guardrails for pull requests alongside dependency scanning, and the free scan shows what a first scan finds.
Quick check
Will gates slow the team down?
Slightly, at first. Report mode, a small initial set, and a fast exception route keep the cost low. Many teams find review time falls because routine checks are automated.
What should block a merge?
Start with failing tests and lockfile mismatches, then add serious findings on code that is actually used.
Sources
Last reviewed: 19 October 2026.
