Keep the pull request open, look up each newly added package in the Gold Open Source Chrome extension, and use the Safeguard side panel to ask questions about it. These extensions help a reviewer look things up. They do not block a merge, and the docs do not describe a pull request gate.
What do the two extensions do?
The Safeguard extension opens Safeguard's AI search page in a browser side panel. Per the docs, it adds a toolbar icon titled "Open Safeguard," you sign in inside the embedded page with your normal web session, and it declares only the sidePanel permission with no host permissions. It makes no direct API calls of its own.
The Gold Open Source extension does package lookups against the Gold directory at gold.safeguard.sh, which is free and needs no login.
The docs do not mention GitHub pull requests, so this post describes a workflow beside the pull request, not an integration with it.
What is the review workflow?
- Read the diff and find new lines in manifests: package.json, requirements files, go.mod, pom files and the like.
- For each new package, look it up with the Gold Open Source extension. Check what the page lists for it, such as known CVEs and malware flags.
- Open the Safeguard side panel and ask a plain question: is this package maintained, and does this version have known issues?
- Look at what the package is for. A date parsing library that asks for network access deserves a comment.
- Check the name carefully for typosquats, one letter off from a popular package.
- Record the result in the review, with the version you checked.
What should you be wary of?
A new package is a trust decision. The ctx incident on PyPI showed an old, dormant package published with new malicious versions after the maintainer's email domain lapsed. So a package that has been quiet for years and suddenly changes is worth a second look.
Also check transitive additions. The lockfile diff often shows many more packages than the manifest diff.
What if you want an automated gate?
Use the CLI in CI. Per the CLI docs, safeguard scan on the working tree writes findings, and a short shell step with jq can fail the build on a critical vulnerability. The extensions are for the human step, the CLI is for the automatic step. IDE extensions can show security information while code is written.
What to do
- Install both extensions from the Chrome Web Store and sign in to the Safeguard panel.
- Make "look up every new package" a line in your review checklist.
- Verify names against the official registry page, not a search result.
- Ask the Safeguard panel when the lookup page leaves a question open.
- Add the CLI gate to CI so a critical finding fails the build.
- Note the checked version in the pull request comment.
What does a good review comment look like?
Reviewers write better comments when they have a template. Something like this works:
"Added: example-lib 2.4.1. Checked on Gold: no known critical CVEs listed for this version, published by the same maintainer as the previous release, last release three weeks ago. Purpose matches the change. Lockfile adds four transitive packages, all common. Approve."
And a failing one: "Added: exampel-lib 1.0.0. Name is one letter off from example-lib, which we use elsewhere, and the project has no history. Please confirm this is the intended package."
The point is a short, factual record of what you checked and which version. Months later, when an advisory lands, the comment tells you what was known at the time. Keep comments plain and keep them attached to the pull request, not a chat that disappears.
Quick check
Do the extensions block a merge?
No. They are lookup tools in the browser. Use the CLI in CI if you want a failing check.
Do they need broad browser permissions?
Per the docs, the Safeguard extension declares only the sidePanel permission and no host permissions.
Sources
- Safeguard docs, Browser Extension
- Safeguard CLI documentation
- The Hacker News, PyPI package ctx hijacked
- Gold Open Source
Last reviewed: 18 October 2026.
