Currently supported versions for security updates:

In Scope:

• GraphQL API injection attacks
• ArangoDB query injection (AQL)
• Authentication/authorization bypasses (Phase 2+)
• XSS in web interface
• CSRF in state-changing operations
• Sensitive data exposure (interview subjects, confidential evidence)
• Dependency vulnerabilities

Out of Scope (Current Phase):

• DDoS attacks (no production deployment yet)
• Physical security of infrastructure
• Social engineering of users
• Client-side attacks on user browsers (beyond standard web security)

10+ Dimensions of Security (RSR Framework):

1. Type Safety: Elixir compile-time checks, Ecto schemas, GraphQL type system
2. Memory Safety: BEAM VM memory isolation, no manual memory management
3. Input Validation: Ecto changesets, GraphQL schema validation, AQL parameterization
4. Authentication: (Phase 2) JWT tokens, BCrypt password hashing
5. Authorization: (Phase 2) Role-based access control (admin, journalist, reviewer, reader)
6. Data Protection: EU GDPR compliance, anonymized interview subjects
7. Transport Security: HTTPS/TLS in production (Phase 2)
8. Audit Logging: All mutations logged with user attribution
9. Dependency Scanning: Automated via CI/CD (see justfile security-scan)
10. IPFS Provenance: (Phase 2) Tamper-evident evidence storage with hash verification

This project handles sensitive investigative journalism data:

• Anonymization: Interview subjects can be anonymized in database
• Right to Erasure: Evidence marked as deleted (soft delete) with audit trail
• Data Minimization: Only essential metadata collected
• Encryption: Database-level encryption in production (ArangoDB Enterprise)
• Data Sovereignty: EU hosting (Hetzner Cloud)

DO NOT open public GitHub issues for security vulnerabilities.

Preferred Methods (in order):

1. Email: security@evidencegraph.org (PGP key below)
2. GitHub Security Advisory: https://github.com/Hyperpolymath/bofig/security/advisories/new
3. GitLab Confidential Issue: (if hosted on GitLab)

Please provide:

1. Description: Detailed explanation of the vulnerability
2. Impact: What an attacker could do (CVSS score if calculated)
3. Reproduction: Step-by-step instructions to reproduce
4. Environment: Version, OS, configuration
5. Proposed Fix: If you have suggestions (optional)
6. Disclosure Timeline: When you plan to publish (if at all)

We commit to:

• 24 hours: Initial acknowledgment of report
• 7 days: Preliminary assessment (severity, affected versions)
• 30 days: Fix deployed or detailed remediation plan
• 90 days: Public disclosure (coordinated with reporter)

Current Status: No formal bug bounty (Phase 1 PoC)

Phase 2+: Considering partnership with:

• HackerOne / Bugcrowd
• EU-specific platforms (YesWeHack)

Acknowledgments: Security researchers will be credited in:

• CHANGELOG.md
• .well-known/humans.txt
• Security Hall of Fame (if program established)

1. No Authentication: Phase 1 PoC has no user authentication

   • GraphQL API is publicly accessible
   • Mitigation: Only run locally, use network firewall
   • Fix: Phase 2 Month 7 (JWT auth)

2. No Rate Limiting: API can be abused

   • Mitigation: Reverse proxy with rate limits (Nginx)
   • Fix: Phase 2 Month 8 (Phoenix rate limiting)

3. No Input Sanitization: Beyond Ecto validation

   • Mitigation: Use parameterized queries (already done)
   • Fix: Add content security policy, stricter validation

4. Dependency Vulnerabilities: Not auto-scanned yet

   • Mitigation: Manual mix deps.audit checks
   • Fix: CI/CD integration (see justfile)

5. No Security Headers: Missing CSP, HSTS, X-Frame-Options

   • Mitigation: Add in production deployment
   • Fix: Phoenix security headers plug (Phase 2)

We follow:

• OWASP Top 10 prevention guidelines
• Elixir Security Working Group recommendations
• Phoenix Security Guide
• ArangoDB Security Best Practices

We avoid:

• String.to_existing_atom/1 on user input (atom exhaustion)
• Code.eval_string/1 on untrusted input
• Storing plaintext secrets (use environment variables)
• SQL injection (we use ArangoDB with parameterized queries)

# Dependency vulnerability scan
mix deps.audit

# Static analysis
mix credo --strict

# Code quality
mix dialyzer

# Security-focused linting
just security-scan  # (see justfile)

GraphQL API Fuzzing:

# Test injection attacks
echo '{ claims(investigationId: "inv\"; DROP TABLE claims;--") { id } }' | \
  http POST :4000/api/graphql query=@-

AQL Injection Testing:

# Should be safe due to parameterized queries
EvidenceGraph.Claims.search_claims("'; DROP COLLECTION claims;--")

Phase 2+ Plan:

• External penetration test before public launch
• Red team exercise on production infrastructure
• OWASP ZAP automated scanning in CI/CD

Subscribe to security announcements:

1. GitHub Watch: Enable "Custom" notifications → "Security alerts"
2. RSS Feed: https://github.com/Hyperpolymath/bofig/security/advisories.atom
3. Mailing List: security-announce@evidencegraph.org (low-traffic)

All security fixes documented in CHANGELOG.md with:

• CVE ID (if assigned)
• Severity level
• Affected versions
• Credit to reporter

Critical Dependencies:

• Phoenix 1.7.x (web framework)
• Absinthe 1.7.x (GraphQL)
• Arangox 0.5.x (database driver)
• Ecto 3.11.x (schemas/validation)

Audit Process:

1. Weekly mix deps.audit check
2. Automated GitHub Dependabot alerts
3. Manual review of security advisories
4. Test suite run before all updates

• Critical vulnerabilities: Patch within 24 hours
• High severity: Update within 7 days
• Medium/Low: Include in next minor release

Hetzner Cloud (EU):

• Firewall: Ports 80/443 only, no SSH from public internet
• SSH: Key-based auth only, fail2ban active
• Nginx: Reverse proxy with rate limiting, ModSecurity WAF
• SSL: Let's Encrypt with HSTS, TLS 1.3 only

ArangoDB Oasis:

• Managed service, automatic security patches
• Network isolation (VPC peering)
• Encryption at rest + in transit
• Daily backups with 30-day retention

Never commit:

• SECRET_KEY_BASE
• ARANGO_PASSWORD
• API keys, tokens, credentials

Use:

• Environment variables (.env ignored by Git)
• Phoenix releases config (config/runtime.exs)
• Hetzner Cloud metadata service (production)
• 1Password/Vault for team secrets (Phase 2)

1. Detection: Automated alerts, user reports, security scans
2. Containment: Isolate affected systems, revoke credentials
3. Eradication: Apply patches, remove malicious code
4. Recovery: Restore from backups, verify integrity
5. Lessons Learned: Post-mortem, update security measures

• Internal: Maintainers via encrypted channel (Signal/Matrix)
• Users: Security advisory published within 24 hours of fix
• Public: CVE assignment for critical issues, blog post with details

If sensitive investigative data is compromised:

1. Notify affected journalists within 24 hours
2. Report to data protection authority (GDPR Article 33)
3. Publish incident report with timeline
4. Offer mitigation (password reset, evidence re-upload)
5. Forensic analysis to prevent recurrence

• EU GDPR: Article 25 (Privacy by Design), Article 32 (Security)
• ISO 27001: Information security management (future certification)
• OWASP ASVS: Application Security Verification Standard Level 2
• CWE Top 25: Common Weakness Enumeration prevention

All security-relevant events logged:

• Authentication attempts (Phase 2)
• Authorization failures
• Data access (GDPR Article 30)
• Configuration changes
• Security updates applied

Logs retained for 90 days (GDPR minimum), 1 year for security incidents.

• Lead: @Hyperpolymath (GitHub)
• Email: security@evidencegraph.org
• PGP Key: [To be published]
• Response Hours: Mon-Fri 9am-5pm UTC (best-effort, volunteer project)

For urgent issues (active exploitation):

• Phone: [To be published for Phase 2]
• Matrix: [To be set up]

We thank the following security researchers:

(None yet - Hall of Fame will be added as reports are received)

• OWASP Top 10: https://owasp.org/www-project-top-ten/
• Elixir Security: https://elixir-lang.org/blog/2021/10/13/security-working-group/
• Phoenix Security Guide: https://hexdocs.pm/phoenix/security.html
• ArangoDB Security: https://www.arangodb.com/docs/stable/security.html

Last Updated: 2025-11-22 Policy Version: 1.0 (Phase 1) Next Review: 2025-12-22 (monthly during Phase 1)

This security policy is maintained in accordance with RSR (Rhodium Standard Repository) framework requirements and RFC 9116 (security.txt).