# 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`](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`](https://github.com/oaslananka/kicad-mcp-pro/blob/main/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-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-integrity.md), [`release-signing.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`](../development/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`](../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`](https://github.com/oaslananka/kicad-mcp-pro/blob/main/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`](release-security.md) passes or that any exception is documented in the release notes and tracked as an issue.
