If you discover a security vulnerability in Project Aura, please report it responsibly. Do not open a public GitHub issue for security vulnerabilities.

Email: security@aenealabs.com

Please include:

• Description of the vulnerability
• Steps to reproduce
• Potential impact assessment
• Any suggested fixes (optional)

The following are in scope for security reports:

• Core platform services (src/)
• Agent orchestration and execution
• Sandbox isolation mechanisms
• Authentication and authorization
• GraphRAG data access controls
• Infrastructure-as-code templates (deploy/)
• Container images and configurations

• Vulnerabilities in third-party dependencies (report to upstream maintainers)
• Social engineering attacks
• Denial of service attacks
• Issues in archived code (archive/ directory)

This is the outbound side of disclosure: when Project Aura, our recurring dependency audit, or upstream maintainers identify a vulnerability that affects a shipped Aura release, we publish a security advisory so self-hosted operators can take action on their own cadence.

• Primary channel: GitHub Security Advisories on this repository. GHSA is the canonical source — it gets a CVE assigned (when applicable), feeds into the GitHub Dependency Graph and Dependabot, and surfaces in npm audit / pip-audit automatically for any consumer that has Aura in their dependency closure.
• Mirrored to: CHANGELOG.md (auto-generated by Release Please from security: commits — see How releases reflect advisories below).

Self-hosted operators have three options, none of which require us to operate a notification pipeline:

1. GitHub repository watch with custom filter: watch aenealabs/aura and set "Custom" notifications to include only "Security alerts". Quietest signal, GitHub-native.
2. GHSA Atom feed: https://github.com/aenealabs/aura/security/advisories.atom. Works with any feed reader or alerting pipeline (Slack RSS bot, etc.).
3. Your existing SCA tooling (Snyk, Aqua, Prisma, Dependabot, etc.): point it at the SBOM artifact shipped with each Aura release (see Self-scanning via SBOM below). Your SCA tool already knows how to cross-reference CVEs against the components in the SBOM, so you don't need our advisory to feed the loop.

Every advisory we publish includes:

release-please-config.json is configured so that commits with the security: prefix surface in a dedicated Security section in CHANGELOG.md. Operators reading release notes can see at a glance whether a release contains security fixes:

security: replace tj-actions/changed-files (CVE-2025-30066)

When we publish a GHSA, we link it from the corresponding security: commit message and from the matching CHANGELOG entry.

Per ADR-076 (SBOM Attestation & Supply Chain), every Aura release ships a CycloneDX or SPDX Software Bill of Materials, signed via Sigstore. Operators in regulated environments often prefer to scan their deployment with their own tooling rather than depend on vendor advisories — the SBOM is the bridge that makes that possible. You don't need to wait for our advisory to detect a CVE; if your SCA scanner sees a known-vulnerable component in the SBOM, it can flag it on its own schedule.

To keep the producer-side surface focused, the following are explicitly not part of our disclosure pipeline:

• Push notifications (email blasts, Slack webhooks, customer-admin paging). Each operator's notification stack is theirs to run; we publish, you subscribe.
• A vendor-supplied scanner CLI. The SBOM + your SCA tooling is the right pattern for self-scanning; running our scanner against your deployment would just duplicate what your tools already do.
• Coordinated disclosure timelines for vulnerabilities we discover in our own platform (separate from third-party dep CVEs). Those follow the inbound process documented above and the Response Timeline table.

• SaaS customers: advisories are informational. Our deployment fix is your fix; the next deploy of aura.aenealabs.com (typically hours after the patch lands) protects you implicitly. The advisory still publishes so your security team has an auditable record.
• Self-hosted (ADR-049) customers: advisories are actionable. The patched release is on the registry; you decide when to pull and redeploy. The advisory tells you what's affected, how severe it is, and what's mitigated.

Multi-region disaster recovery (active failover, cross-region replication, RTO / RPO commitments documented in docs/support/architecture/disaster-recovery.md) applies to the Aenea Labs SaaS deployment only. Self-hosted Aura customers (ADR-049) are responsible for their own continuity planning per their deployment model -- their RTO / RPO depends on their own backup, replication, and failover setup, which is outside the Aura platform's purview.

The DR initiative (umbrella issue #143) is complete -- all 13 sub-issues closed (May 2026). SaaS DR posture is now audit-defensible: every regional failover runs through a Step Functions Standard pipeline (multi-region-pipeline.yaml, Layer 6.22) with HITL approval gates at every destructive step, and an evidence-package generator Lambda (DR-8 / #151) writes a manifest, state-machine history, and approval chain into s3://aura-compliance-evidence-{account}-prod/<quarter>/<execution>/manifest.json with Object Lock GOVERNANCE 7-year retention. Auditors asking "show me the last successful end-to-end failover with measured RTO and approval chain" can be answered directly from that bucket. Per-service runbooks: NEPTUNE_FAILOVER_RUNBOOK.md, OPENSEARCH_FAILOVER_RUNBOOK.md, COGNITO_FAILOVER_RUNBOOK.md. Operator runbook composing them: MULTI_REGION_DR_OPERATIONS.md. Compliance controls guide: DR_COMPLIANCE_CONTROLS_GUIDE.md.

Self-hosted operators reading the DR doc should treat it as guidance for one possible deployment topology (the one Aenea Labs runs), not as a contract about what their own deployment delivers.

Project Aura follows these security principles:

• Defense in depth: Multiple layers of security controls
• Least privilege: Minimal permissions for all components
• Secure defaults: Security-first configuration out of the box
• Audit trail: All actions logged for compliance
• Isolation: Sandboxed execution for untrusted code

See Security Architecture for detailed technical controls.