An open source maintainer can answer a vendor security questionnaire with public evidence instead of bespoke paperwork. Publish a security policy, point to your repository settings and release process, keep one reusable answers file, and say plainly what you do not promise. If a company wants more, ask it to contribute time or funding.
Why are maintainers getting questionnaires?
Companies that depend on a package are often asked by their own customers and auditors to show they manage supplier risk. The easy way to do that is to send a form to the maintainer. The form was written for a commercial vendor with a sales team, a legal department and an SLA. A volunteer with a licence file has none of those.
Start from a clear position. Most open source licences supply the software as is, with no warranty. You are not a vendor to the company that downloaded your code, and a questionnaire does not change that. You can still choose to help, and a good set of public answers is the cheapest way to do it.
What public evidence can replace a form?
Build an answers page once. Most of the questions map to things you can show without writing new prose.
- How do people report a vulnerability? GitHub documents adding a security policy: a SECURITY.md file that states supported versions and how to report. Link to it.
- Is code reviewed? Point to your branch protection and review settings.
- Are dependencies pinned and updated? Point to your lockfile and update automation.
- Do CI tokens have limited permissions? Point to the workflow permissions in your pipeline files.
- Are releases signed? State what you do, or say you do not.
The OpenSSF Scorecard tool runs automated checks on a public repository, including Pinned-Dependencies, Token-Permissions, Security-Policy, Signed-Releases, Branch-Protection and Code-Review, and prints a score with reasons. A published scorecard result gives a requester neutral, repeatable evidence. Treat the score as a conversation starter, not a grade you are obliged to defend.
How do you answer questions you cannot or will not meet?
Be literal. "Do you have a 24 hour incident response SLA?" The accurate answer is no, with what you do instead: security reports go to a private channel and get triaged when a maintainer is available. A false yes creates real exposure for you and for the asker. A calm no, plus the evidence of your process, is more useful to a risk reviewer than a form full of ticked boxes.
Questions about certifications, insurance, background checks, data centres and penetration tests usually do not apply to a code repository. Say "not applicable, this is a public source repository" and move on.
When should you ask for something back?
If a company needs custom attestations, a call, a signed document or a response deadline, that is consulting work. Offer the choices: use the public page, sponsor the project, or hire a maintainer. Many organisations already have a budget line for exactly this. A short, friendly template helps you apply the same rule to everyone.
How do you keep this from eating your week?
Keep a single file in a docs folder with your standard answers, dated and versioned. Update it when your process changes. Reply to every request with a link, and keep a short log of who asked, so you can see whether one company is sending the same form repeatedly.
If a request carries a link, an attachment or a login prompt from an address you do not know, check that it is real before you open it. Fake questionnaires are a way to get maintainers to run something or hand over credentials.
What to do
- Add a SECURITY.md that says how to report and what to expect.
- Run the Scorecard on your repository and fix the checks that are cheap to fix.
- Write an answers page with evidence links and honest gaps.
- Make a reply template: link, scope statement, and what extra support costs.
- Verify unknown senders before opening files or links.
- Review your own dependencies before you answer questions about them. Safeguard's free scan at gold.safeguard.sh/scan covers up to 100 dependencies.
Quick check
Do I have to complete a vendor questionnaire for a company that uses my library?
No. Open source licences generally provide the software as is. You can offer public evidence as a courtesy, and ask for sponsorship if they want more.
What is the most useful single file to publish?
A SECURITY.md that states how to report a vulnerability and which versions you support.
Sources
- GitHub Docs: Adding a security policy to your repository
- OpenSSF Scorecard repository
- OpenSSF Scorecard checks
Last reviewed: 18 October 2026.
