Some checks are pending
CI — CoM Config Validation / Validate JSON Configs (push) Waiting to run
CI — CoM Config Validation / Validate YAML Configs (push) Waiting to run
CI — CoM Config Validation / Lint Shell Scripts (push) Waiting to run
CI — CoM Config Validation / Secret Detection (push) Waiting to run
CI — CoM Config Validation / Lint Markdown (push) Waiting to run
CI — CoM Config Validation / Validate CODEOWNERS (push) Waiting to run
Public, sanitized mirror of an AI orchestration command center: agents, skills, MCP servers, slash-command workflows. All infrastructure identifiers, hostnames, mesh IPs/subnets, repo paths, maintainer identity, and hardware fleet specifics scrubbed to <placeholders>; session debug logs and host-specific memory removed. No live credentials. Verified clean by automated leak sweep. See SANITIZATION.md. churchofmalware.org . authorized research only
68 lines
2.0 KiB
Markdown
68 lines
2.0 KiB
Markdown
# Security Policy — CoM Solutions
|
|
|
|
## Supported Versions
|
|
|
|
| Version | Supported |
|
|
| ------- | ------------------ |
|
|
| 1.0.x | :white_check_mark: |
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
**Do NOT open a public issue for security vulnerabilities.**
|
|
|
|
### Preferred Method
|
|
|
|
Use [GitHub Security Advisories](https://github.com/CoM-Solutions/CoM-claude-config/security/advisories/new) to report vulnerabilities privately.
|
|
|
|
### Alternative
|
|
|
|
Email: maintainer@example.com with subject line `[SECURITY] CoM-claude-config: <brief description>`
|
|
|
|
### What to Include
|
|
|
|
- Description of the vulnerability
|
|
- Steps to reproduce
|
|
- Potential impact assessment
|
|
- Suggested fix (if you have one)
|
|
|
|
### Response Timeline
|
|
|
|
- **Acknowledgment:** Within 48 hours
|
|
- **Initial Assessment:** Within 1 week
|
|
- **Fix Timeline:** Depends on severity
|
|
- Critical: 24-48 hours
|
|
- High: 1 week
|
|
- Medium: 2 weeks
|
|
- Low: Next scheduled release
|
|
|
|
### Scope
|
|
|
|
This security policy covers:
|
|
|
|
- Hook scripts that validate and gate command execution
|
|
- Permission deny lists in settings.json
|
|
- Agent permission boundaries and escalation paths
|
|
- MCP server configurations and authentication
|
|
- Constitutional governance rules
|
|
- Secret management and credential protection
|
|
- CI/CD pipeline security
|
|
|
|
### Out of Scope
|
|
|
|
- Vulnerabilities in upstream tools (Claude Code, Kilo Code, GitHub Copilot, Gemini)
|
|
- Vulnerabilities in MCP server packages themselves (report to package maintainers)
|
|
- Issues in the Syn_OS repository (use that repo's security policy)
|
|
|
|
## Security Architecture
|
|
|
|
This project implements a 4-layer defense model:
|
|
|
|
1. **Permission Deny List** — Hard blocks on destructive patterns in settings.json
|
|
2. **PreToolUse Hook** — Pattern matching against known dangerous commands
|
|
3. **Haiku Prompt Guard** — AI-powered secondary check on Bash commands
|
|
4. **PostToolUse Scan** — Downloaded file validation for obfuscated content
|
|
|
|
## Disclosure Policy
|
|
|
|
We follow coordinated disclosure. We will credit reporters in our security advisories unless anonymity is requested.
|