|
2 | 2 |
|
3 | 3 | ## Supported Versions |
4 | 4 |
|
5 | | -Use this section to tell people about which versions of your project are |
6 | | -currently being supported with security updates. |
7 | | - |
8 | 5 | | Version | Supported | |
9 | 6 | | ------- | ------------------ | |
10 | | -| 5.1.x | :white_check_mark: | |
11 | | -| 5.0.x | :x: | |
12 | | -| 4.0.x | :white_check_mark: | |
13 | | -| < 4.0 | :x: | |
| 7 | +| 0.1.x | :white_check_mark: | |
14 | 8 |
|
15 | 9 | ## Reporting a Vulnerability |
16 | 10 |
|
17 | | -Use this section to tell people how to report a vulnerability. |
| 11 | +If you discover a security vulnerability in Conative Gating, please report it responsibly: |
| 12 | + |
| 13 | + |
| 14 | +2. **Subject**: `[SECURITY] conative-gating: Brief description` |
| 15 | +3. **Include**: |
| 16 | + - Description of the vulnerability |
| 17 | + - Steps to reproduce |
| 18 | + - Potential impact assessment |
| 19 | + - Any suggested fixes (optional) |
| 20 | + |
| 21 | +### Response Timeline |
| 22 | + |
| 23 | +- **Initial acknowledgment**: Within 48 hours |
| 24 | +- **Triage and assessment**: Within 7 days |
| 25 | +- **Fix or mitigation**: Depends on severity |
| 26 | + - Critical: Within 7 days |
| 27 | + - High: Within 30 days |
| 28 | + - Medium/Low: Next release cycle |
| 29 | + |
| 30 | +### What to Expect |
| 31 | + |
| 32 | +- We will acknowledge receipt of your report |
| 33 | +- We will investigate and keep you informed of progress |
| 34 | +- We will credit you in the security advisory (unless you prefer anonymity) |
| 35 | +- We will not take legal action against good-faith security researchers |
| 36 | + |
| 37 | +## Security Considerations |
| 38 | + |
| 39 | +### Policy Oracle |
| 40 | + |
| 41 | +The Policy Oracle performs deterministic rule checking: |
| 42 | +- File extension and content marker detection |
| 43 | +- Pattern matching for forbidden content (secrets, banned languages) |
| 44 | +- No external network calls during evaluation |
| 45 | + |
| 46 | +### SLM Evaluator (Planned) |
| 47 | + |
| 48 | +Future SLM integration will: |
| 49 | +- Run locally using llama.cpp (no external API calls) |
| 50 | +- Use quantized models for reduced attack surface |
| 51 | +- Implement input sanitization before inference |
| 52 | + |
| 53 | +### Consensus Arbiter (Planned) |
| 54 | + |
| 55 | +The Elixir arbiter will: |
| 56 | +- Use supervision trees for fault tolerance |
| 57 | +- Implement rate limiting to prevent DoS |
| 58 | +- Log all decisions for audit purposes |
| 59 | + |
| 60 | +## Hardening Recommendations |
| 61 | + |
| 62 | +When deploying Conative Gating: |
18 | 63 |
|
19 | | -Tell them where to go, how often they can expect to get an update on a |
20 | | -reported vulnerability, what to expect if the vulnerability is accepted or |
21 | | -declined, etc. |
| 64 | +1. Run with minimal privileges |
| 65 | +2. Use read-only access to scanned directories where possible |
| 66 | +3. Validate all external inputs (proposal JSON schemas) |
| 67 | +4. Review audit logs regularly |
0 commit comments