Security Requirements¶
This page defines the security requirements KiCad MCP Pro is expected to meet before a production release. It is intentionally specific enough to use as OpenSSF Silver evidence and as a review checklist for changes that affect MCP tools, filesystem access, KiCad automation, packaging, or release workflows.
Scope¶
The requirements apply to:
- the Python MCP server;
- the npm wrapper and protocol schema packages;
- Docker images and GUI bundles;
- ChatGPT Apps SDK and other integration surfaces;
- GitHub Actions workflows that build, test, publish, attest, or deploy artifacts.
Requirements¶
| ID | Requirement | Evidence and enforcement |
|---|---|---|
| SR-1 | Tool calls that can read, write, export, delete, or mutate KiCad project data must be explicit, documented, and routed through typed tool surfaces. | Tool metadata, generated tool reference, tests, and destructive-operation review in the PR template. |
| SR-2 | User-provided filesystem paths must be canonicalized, bounded to configured workspaces, and protected against traversal, symlink escape, and unsafe extension use. | input-validation.md, CodeQL, unit tests, and SafeFsPath-style validation in integration code. |
| SR-3 | Secrets, private board files, customer logs, generated manufacturing outputs, and credentials must not be committed or attached to public reports. | SECURITY.md, issue templates, Gitleaks, .gitignore, and CI secret scanning. |
| SR-4 | Release artifacts must be generated by GitHub Actions from the canonical repository, not from a maintainer workstation. | release-security.md, release workflows, protected environments, and release-please. |
| SR-5 | Public releases must provide verification evidence appropriate to the artifact class: checksums, SBOMs, provenance attestations, package-manager provenance, or Sigstore/cosign signatures. | release-integrity.md, release-signing.md, and publish workflows. |
| SR-6 | External dependencies must be declared, updated through reviewable dependency changes, monitored for vulnerabilities, and installed with lockfiles, hashes, or digest pinning where practical. | dependency-management.md, dependency audit scripts, Dependabot, pinned Actions, and digest-pinned containers. |
| SR-7 | CI/CD workflows must minimize permissions, pin third-party Actions to full commit SHAs, avoid untrusted secret exposure, and sanitize user-controlled workflow metadata. | ../workflow-security.md, scripts/check_workflow_security.py, and CI checks. |
| SR-8 | Security-sensitive defects must be reported privately, triaged within documented response targets, fixed through protected CI, and disclosed through an advisory or release note when appropriate. | SECURITY.md and GitHub private vulnerability reporting. |
| SR-9 | Documentation must distinguish verified behavior from heuristics and must not overclaim professional EDA sign-off authority. | README, generated tool docs, release checklist, and PR safety checklist. |
| SR-10 | Telemetry, external network use, and credentialed integrations must be opt-in and documented. | Privacy policy, configuration docs, and agent security docs. |
Review triggers¶
A change requires explicit security review when it touches any of the following:
- workspace or path resolution;
- archive extraction, file import, or generated artifact export;
- subprocess execution or KiCad CLI invocation;
- network listeners, HTTP transport, or MCP client integration;
- GitHub Actions permissions, package publishing, attestations, or credentials;
- dependency update policy, lockfiles, Docker base images, or package manager behavior;
- destructive or irreversible KiCad project operations.
Release gate¶
Before a production release, maintainers must verify that the release checklist in release-security.md passes or that any exception is documented in the release notes and tracked as an issue.