Confirm the finding is real and caused by the change, decide whether it blocks, tell the contributor exactly what to fix, and escalate if the change looks deliberately harmful. Most findings on outside pull requests are honest mistakes, so the response should teach as well as gate.
Step 1: Is it real and is it new?
Open the finding. Check whether the pull request introduced it or whether it already existed on the base branch. Gating on new issues keeps contributors from being blamed for old ones. If it is old, track it separately and do not hold the pull request for it.
Step 2: How severe and reachable is it?
A vulnerable dependency that the code never calls is lower urgency than one on a live path. Reachability analysis helps here by showing whether the vulnerable function is used. A critical issue in code that runs on user input needs a block. A style warning does not.
| Finding | Typical response |
|---|---|
| New dependency with a known critical issue on a used path | Block, ask for a safe version |
| Hardcoded credential in the diff | Block, ask to remove and rotate if real |
| Change to a workflow file | Block until owner review |
| Low severity code smell | Comment, do not block |
| Pre-existing issue | Track separately |
Step 3: Tell the contributor what to do
Write the message so a newcomer can act on it. Include the file, the rule, why it matters, and a suggested fix or link. Keep a polite tone. People who got a clear note often return; people who got a red cross often do not.
A short template:
Thanks for the contribution. The dependency check flags version X of package Y, which has a known issue fixed in Z. Could you bump it to Z or later? Happy to help if the upgrade breaks something.
Step 4: Decide on follow up
- If the contributor fixes it, rerun checks. Remember required checks must pass on the latest commit.
- If they go quiet, label and close after a notice period announced in CONTRIBUTING.
- If the finding is a false positive, record the reason and tune the rule.
Step 5: Escalate on real signals
Signals worth escalating: obfuscated code, network calls to unfamiliar hosts in build scripts, edits to the workflows directory without explanation, or a package that mimics a popular name. In those cases, do not approve fork runs, and consider reporting to the package registry or the platform.
Keep a record
For projects with commercial users, a record of how findings were decided is useful. A label scheme such as security-blocked and security-accepted-risk is enough to start.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how filtering by reachability shrinks the list to what needs action.
Where Safeguard fits
Safeguard offers reachability analysis, dependency scanning and policy gates, and can propose fix pull requests when you turn that on. The free scan lets you see it on real code.
Quick check
Should every finding block an outside pull request?
No. Block on severe, new, reachable issues. Comment on the rest, so contributors stay engaged.
What if the finding existed before the pull request?
Track it separately. Gating on new issues is fairer and keeps the queue moving.
Last reviewed: 19 October 2026.
