Add maintainer ownership, governance, roadmap, ecosystem and adoption documentation, release and security processes, Dependabot, structured adoption reporting, and automated maintainer-health checks.
1.6 KiB
Security Policy
Supported versions
| Version | Status |
|---|---|
| 0.8.x | Maintained preview |
| 0.7.x and earlier | Not supported |
Security fixes are prioritized for the current maintained release line. Users should update to the latest available patch before reporting an issue that may already be resolved.
Reporting a security issue
Use GitHub private vulnerability reporting when available. Do not publish exploitable details in a public Issue before the maintainer has reviewed the report.
Include:
- Affected version or commit SHA
- Reproduction steps
- Observed and expected behavior
- Security impact
- Minimal test case or sanitized fixture
- Suggested mitigation when known
Do not include credentials, personal information, private model links, or production data.
The primary maintainer aims to acknowledge a complete private report within 72 hours. This is an operational target, not a service-level guarantee.
Project security principles
- Project bundles must not contain API keys or credentials.
- Imported manifests must be validated before use.
- External JSON must remain declarative data.
- File operations must remain inside approved project directories.
- Audit-chain, package-integrity, and revision checks must fail safely.
- Release packages must be reproducible and validated before publication.
- GitHub Actions dependencies are reviewed through Dependabot updates.
Security boundaries
External models, operating systems, FFmpeg builds, ComfyUI installations, and third-party custom nodes have their own security boundaries. Integrity hashes detect changes but do not provide authorization or sandbox untrusted software.