The following versions of BTagent receive security updates:

We recommend running the latest patch release within a supported minor version. Older minor versions receive security patches for 6 months after the next minor version is released.

Do NOT open a public GitHub issue for security vulnerabilities.

If you discover a security vulnerability in BTagent, please report it privately:

1. Email: Send a detailed report to security@btagent.dev
2. Subject line: [SECURITY] Brief description of the vulnerability
3. Include:
   • Description of the vulnerability
   • Steps to reproduce (proof of concept if possible)
   • Affected version(s)
   • Potential impact assessment
   • Any suggested fix (optional)

PGP encryption is available upon request. Contact security@btagent.dev for our public key.

We take all security reports seriously and follow this timeline:

For critical vulnerabilities (CVSS 9.0+), we aim to release a patch within 7 days of triage confirmation. If we need more time, we will communicate the revised timeline within the triage window.

1. Patch development: Security fixes are developed in a private branch to prevent exploitation before the fix is available.
2. Testing: All security patches go through the full test suite (unit, UAT, security-specific tests) before release.
3. Release: Security patches are released as new patch versions (e.g., 0.3.1 -> 0.3.2) with a security advisory.
4. Advisory: We publish a GitHub Security Advisory with CVE assignment (when applicable), affected versions, and upgrade instructions.
5. Notification: Users watching the repository receive automatic notifications for security advisories.

# Check your current version
make --version  # or check your docker-compose image tags

# Pull the latest patch
git pull origin main
make build
make up

We value the work of security researchers who help keep BTagent and its users safe. Contributors who responsibly disclose vulnerabilities will be:

• Credited in the security advisory (unless they prefer anonymity)
• Listed in our Security Hall of Fame (coming soon)
• Eligible for our recognition program (details TBD)

We ask that you:

• Give us reasonable time to address the issue before public disclosure
• Make a good-faith effort to avoid impacting other users during your research
• Do not access or modify data belonging to other users
• Do not perform denial-of-service attacks

The following are in scope for security reports:

• BTagent backend API (backend/)
• Agent engine (agents/)
• Frontend application (frontend/)
• Shared library (shared/)
• Infrastructure configurations (infra/)
• Authentication and authorization (JWT, RBAC)
• Data handling (TLP enforcement, audit trail integrity)
• Prompt injection vectors
• MCP connector security

The following are out of scope:

• Third-party dependencies (report these to the upstream project)
• Issues in development-only configurations (e.g., default Docker Compose passwords)
• Social engineering attacks
• Physical attacks

We conduct regular security audits of the BTagent codebase. Published audit reports are available in the docs/ directory:

• Security Audit Report (Phase 1) -- Full codebase review covering backend, agents, shared, and infrastructure
• Security Audit Report (Phase 2) -- Phase 2 features including IOC enrichment, knowledge base, playbooks, and MITRE integration

BTagent implements multiple layers of security controls:

• Authentication: JWT token pairs (access + refresh) with bcrypt password hashing
• Authorization: Role-based access control (RBAC) with four hierarchical roles
• TLP enforcement: Classification-aware LLM routing prevents data leakage to unauthorized providers
• Prompt injection defense: All external data wrapped in <external-data> XML tags
• Scope enforcement: Agent actions restricted to authorized investigation perimeter
• Audit trail: SHA-256 hash-chained audit log with 7-year retention
• Evidence integrity: SHA-256 hashing of all tool outputs for forensic chain of custody

For detailed architecture information, see docs/ARCHITECTURE.md.