nido-core 0.0.0-alpha.0

# Security Policy

## Supported Versions

Only the latest minor release of nido receives security fixes. Pre-1.0,
this means the latest `0.MINOR.*` only. Older minor versions are not patched.

| Version | Supported |
|---|---|
| latest `0.MINOR.x` | yes |
| anything older | no |

## Reporting a Vulnerability

**Do not file public GitHub issues for security problems.** Two reporting
channels:

1. **Preferred -- GitHub Security Advisories**: <https://github.com/nash87/nido/security/advisories/new>
2. **Email**: <fschulz0787@gmail.com> with subject `[nido security]`. PGP
   key fingerprint is published at <https://github.com/nash87.gpg>.

You will get an initial acknowledgement within 7 days. Triage and fix
timeline depends on severity:

| Severity | First response | Fix target |
|---|---|---|
| Critical (RCE, secret exfil, auth bypass) | 48h | 7 days |
| High (privilege escalation, signed-binary subversion) | 7 days | 30 days |
| Medium (DoS, info leak without secrets) | 14 days | 60 days |
| Low (defense-in-depth, hardening) | 30 days | next minor release |

We follow coordinated disclosure: a public advisory is published after a
patched release is available, crediting the reporter unless they request
anonymity.

## Scope

In scope:

- The `nido` binary and all `nido-*` library crates
- The cargo-dist release pipeline and signing
- The bundled Ansible roles, hook templates, and skills
- The MCP server exposed by `nido mcp serve`
- The OTA update mechanism (`nido self-update`)

Out of scope:

- Third-party managed CLIs (Claude Code, Codex, Kimi, Gemini) -- report to
  the respective vendor
- The user's own infrastructure that nido deploys to (Vault, Gitea,
  Kubernetes clusters)
- Vulnerabilities in dependencies -- please report upstream first; we will
  pick up the fix via dependabot / cargo-deny advisories

## Supply chain commitments

- Every release binary is signed via Sigstore (cosign + SLSA build
  provenance attestations from GitHub Actions OIDC).
- `nido self-update` verifies the cosign signature via `sigstore-rs`
  before installing. Unsigned artifacts are refused.
- crates.io publishing uses Trusted Publishing (OIDC). No
  `CARGO_REGISTRY_TOKEN` is stored in GitHub Actions secrets.
- SBOMs are generated by `cargo cyclonedx` and attached to every GitHub
  Release as `nido-<version>.cdx.json`.

## Data handling

nido is local-first and collects nothing. There is no telemetry, no
analytics, no usage tracking, and no phone-home. nido processes no
personally identifiable information (PII), and its logs contain no PII by
design. There is no server component and no account -- no data leaves the
user's machine except the network calls listed in the README "Privacy &
Data" section (LLM provider APIs the user configured, `nido self-update`,
and `nido install`). API keys the user configures stay in `.env.local`
or the OS keyring and are transmitted only to the LLM provider the user
explicitly configured.

## Cryptography and export

nido uses cryptographic signature verification (Sigstore / cosign) in
`nido self-update` and `nido install`, and as publicly available
open-source encryption source code it qualifies for the US EAR TSU
exception (15 CFR 740.13(e)) -- no export licence is required.

## Vulnerability disclosure history

None yet. v0.1.0 is the first public release.