Before depending on an open source package for something important, you can ask the maintainer seven short questions: how to report a vulnerability, who can publish, how releases are built, whether tokens are restricted, what happens if they step away, what versions get fixes, and what support you should expect. Ask politely and expect no obligation.
Set the tone first
Maintainers owe you nothing. Many are unpaid. A friendly, specific message in the issue tracker or discussions forum gets better results than a demand. Say what you plan to use the package for, and offer to contribute documentation or a fix if they point you at a gap.
Do not post security concerns about exploitable flaws in public. If you have one, use the project's private channel. GitHub documents private vulnerability reporting for public repositories, which owners and administrators can enable.
The questions
- Where should security reports go? You are checking that a private route exists. If the answer is a public issue, note the risk.
- Who can publish releases to the registry? A project with several committers but one publisher still has a single point of failure.
- How are releases built? You are listening for CI builds, provenance and trusted publishing. The npm docs describe trusted publishing as replacing long-lived tokens with short-lived credentials tied to a workflow.
- Are long-lived publish tokens disabled? npm recommends restricting traditional token publishing once trusted publishers are in place.
- What happens if you cannot continue? A named successor, a governance file or an organization behind the project are good answers. "Nothing" is honest and useful.
- Which versions get security fixes? You need to know whether you can stay on a major version.
- What can users reasonably expect? Response time, support channels and any commercial options.
How to read answers
| Answer | What it suggests |
|---|---|
| Specific, with links to docs or settings | Process exists |
| Honest "we do not do that yet" | Gap, but you can plan around it |
| Defensive or vague | Treat as higher risk |
| No answer within a few weeks | Do not rely on support |
A thin answer does not mean you must reject the project. It means your own controls carry more weight: pin versions, monitor advisories, review diffs and keep an exit plan.
Where to ask
Prefer a public discussion thread or an issue labeled as a question for non-sensitive topics. Others benefit from the answers, and you create a record you can cite in your adoption record.
Offer something back
If the project lacks a security policy, offer to draft one. GitHub documents how to add a SECURITY.md that gives supported versions and how to report a vulnerability. A small contribution turns a request into collaboration.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
Is it rude to ask about succession?
Not if you phrase it as planning. Many maintainers appreciate users who think about continuity.
What if the maintainer never replies?
Rely on your own checks and controls, and decide whether the package is still worth the risk.
Sources
- GitHub Docs: configuring private vulnerability reporting
- GitHub Docs: adding a security policy
- npm Docs: trusted publishing
Last reviewed: 19 October 2026.
