When an MCP server is open source, there is usually no vendor to complete your questionnaire, so you own the answers. Replace the vendor's responses with your own review: source check, dependency scan, tool list reading, isolation test, version pinning and a named internal owner.
The gap reviewers notice
Security questionnaires assume a counterparty. For a community server, nobody signs a data processing agreement or promises a patch window. If your company runs one against customer data, an auditor or customer will ask who is accountable. The honest answer is that you are.
This is not bad news. It means your evidence is first hand. You can read the code and watch the behaviour, which a closed service does not allow.
Replace each vendor answer with your own
| Usual vendor question | What you provide instead |
|---|---|
| How do you handle vulnerabilities? | Your dependency scan and your upgrade rule |
| Is data encrypted in transit? | Your transport config and endpoint settings |
| Who has access to our data? | Where the server runs and what it can reach |
| What is your incident process? | Your own process for the server |
| Do you have an audit report? | Not applicable, with your review as the substitute |
| What happens if you stop supporting it? | Your abandonment plan |
The last row matters most. Community projects can go quiet. The abandoned server checklist explains the options: fork with an owner, replace, or remove.
What your own review should cover
- Maintainers and activity. Who commits, how recent, how issues are handled.
- Code and tool list. The MCP tools specification suggests clients validate tool results before passing them to the model, and descriptions are text a model reads, so read them all.
- Dependencies. Inventory and scan them, then decide what to do about findings.
- Behaviour. Run it in a sandbox with network capture. The security guidance recommends restricted file system and network access for local servers.
- Credentials. Give it a narrow, short lived token and nothing else.
- Pin. Fix the version and review upgrades.
Writing the answer
"This server is open source and has no vendor. We reviewed the source, scanned its dependencies and tested it in isolation. The version is pinned, it runs with a scoped credential, and an internal owner reviews upgrades and advisories. Our abandonment plan is to fork or replace."
Do not describe the project's security as if you speak for its maintainers. State what you did.
Licences and responsibility
Open source licences usually disclaim warranty. That is a reason to be explicit about internal ownership, not a reason to skip the review. This is general information; ask counsel about specific licence terms. See answering open source licence questions.
Evidence
Your review record, dependency scan, pinned version and sandbox profile. Safeguard's SBOM and dependency scanning, reachability analysis and zero-day discovery help you keep watching the packages after approval.
Quick check
Can we ask the maintainers to fill the questionnaire?
You can ask, but do not depend on it. Volunteers may not answer, and an answer from them is not a commitment.
Is our own review enough for a customer?
It is real evidence if dated and specific. Pair it with the compensating controls, such as isolation and narrow credentials.
Sources
Last reviewed: 19 October 2026.
