# Security Disclosure

*"Good disclosure is a professional courtesy. Great disclosure is a cultural practice."*

## Overview

Naridon, Inc. welcomes security research on Aura and on the Aura Mothership. This page is the canonical contact for reporting vulnerabilities, the policy under which reports are handled, and the commitments Naridon makes to researchers who act in good faith. Aura is open source under Apache 2.0; its security posture benefits directly from external review, and we prefer to hear about findings from researchers before we hear about them from users in distress.

The goals of this policy are straightforward: get reports to the right inbox, triage them quickly, ship fixes on a predictable timeline, and publicly credit the people who helped. We do not use disclosure as a PR instrument and we do not litigate researchers who follow this policy.

## Threat Scope

Disclosure policy covers:

- The Aura CLI and daemon (this repository and its official binary releases).
- The Aura Mothership daemon.
- The Aura MCP server implementation.
- Official Naridon-published documentation where it would mislead a user into an insecure configuration.

Disclosure policy does not cover:

- Third-party forks or re-distributions of Aura. Contact the fork maintainer.
- Deployments operated by customers of Naridon (we do not run a managed service at this time; your Mothership is yours to secure).
- Dependencies of Aura (report to upstream; we will coordinate if the issue materially affects Aura users).
- Denial-of-service findings that require privileged on-network positioning; these are in scope only if they are exploitable over the public Mothership API surface.
- Social-engineering tests against Naridon personnel. Out of scope, and not welcomed.

Out-of-scope findings may still be interesting and we are happy to receive them — but the commitments below regarding triage SLA, fix targets, and credit are limited to in-scope reports.

## Mechanism

### Contact

Primary channel: **security@naridon.com**.

All reports should be encrypted with the Naridon security PGP key, whose fingerprint is published in three locations:

- `SECURITY.md` at the root of the Aura source repository.
- `https://naridon.com/.well-known/security.txt` (per RFC 9116).
- The release notes of every signed Aura release.

The three publications carry the same fingerprint; if they diverge, that is itself a security-relevant event and should be reported (ideally through a side channel).

The fingerprint is a standard 40-hex-character OpenPGP v4 key fingerprint. We rotate it on a routine cadence (typically every 2–3 years) and sign the new fingerprint with the old key for at least six months of overlap, so researchers with cached keys can verify continuity.

If you cannot use PGP, email security@naridon.com from any account and ask for an alternative secure channel. We will offer Signal or a one-time Keybase contact.

Do not open public GitHub issues for suspected vulnerabilities. Do not post to public Slack, Discord, or forums. A public disclosure before coordination materially hurts other Aura users, including organizations that may be affected far more seriously than the reporter.

### Report contents

An ideal report includes:

- A concise description of the vulnerability and its impact.
- Affected versions (Aura, Mothership, and/or MCP server). We often need to reproduce on the tip of a release branch; `aura --version` output is useful.
- Steps to reproduce, ideally including a minimal proof-of-concept.
- Proposed severity, based on CVSS 3.1 or a similar rubric.
- Any remediation ideas, if you have them.
- How you would like to be credited in the advisory (or that you prefer not to be).

If the report describes a cryptographic weakness, attach the specific construction being attacked and, where possible, the analysis (reference papers, attack traces). Cryptographic claims require the most rigor to triage.

### SLA

Our response commitments for in-scope reports:

| Phase | Target |
|---|---|
| Acknowledge receipt | within 72 hours of the report reaching security@naridon.com |
| Initial triage (scope confirmed, severity assigned) | within 5 business days |
| Status update cadence during investigation | at least every 10 business days |
| Public advisory + patched release — high/critical severity | within 90 days of acknowledgement |
| Public advisory + patched release — medium severity | within 120 days |
| Public advisory + patched release — low severity | coordinated; typically within 180 days |

If we cannot meet a target, we tell you explicitly and explain why. If you disagree with our severity classification, we are happy to discuss; in genuine disagreements we document the researcher's assessment alongside ours in the advisory.

Embargo periods may be extended by mutual agreement — for example, if a coordinated fix across multiple projects requires more time, or if the complexity of the issue demands careful architectural remediation rather than a patch. We do not unilaterally extend embargoes without consent.

### What we ask of researchers

We ask that you:

- Make a good-faith effort to avoid privacy violations, data destruction, and service disruption during testing.
- Do not access, modify, or delete data that does not belong to you.
- Do not pivot from a found vulnerability into lateral movement across Naridon infrastructure.
- Give us reasonable time to respond before any public disclosure, consistent with the SLA above.
- Avoid fishing through private user data. If you encounter any, stop and report immediately.

In exchange, Naridon commits to:

- Not pursue legal action against researchers acting in good faith under this policy.
- Treat you as a partner in the process — including honest discussion of severity, scope, and timeline.
- Credit your work in the public advisory, unless you prefer otherwise.
- Not require NDAs as a condition of reporting.

This is a standard safe-harbor framing. We do not consider good-faith security research to violate our terms of service, DMCA, or any computer-fraud statute interpretation.

### Coordinated advisory

When a fix is ready, the sequence is:

1. We prepare a patched release, signed with the usual minisign key (see [supply-chain integrity](/supply-chain-integrity)).
2. We prepare a draft advisory, which we share with the reporter for review before publication.
3. On the agreed disclosure date, we publish:
   - The patched release.
   - The advisory on Naridon's security page and as a GitHub Security Advisory.
   - A CVE, where warranted. We request CVEs from MITRE; we also accept CVEs the researcher has already reserved.
   - A writeup in the release notes explaining the fix for operators who need to assess their exposure.
4. We update relevant documentation, including this page if the fix introduces new configuration or operator actions.

Advisories follow a consistent template: summary, affected versions, mitigations, remediation, credit, timeline. They are structured so that a regulated operator can map them to internal change-management evidence without having to re-parse the narrative.

### Bounty program

A formal bug bounty program is in development. The current status:

- No monetary rewards are advertised at this time; any future amounts and tiers will be published on the Naridon security page.
- We reserve the right to offer discretionary rewards for unusually high-impact reports, with amounts determined case-by-case.
- If a bounty program launches, in-scope issues reported before launch will be reviewed retroactively for eligibility.

We would rather start narrow and broaden the program responsibly than announce amounts we cannot sustain. Concrete details will be posted to security.naridon.com when available.

### Hall of fame

Researchers who report valid vulnerabilities are credited — by name, by handle, or anonymously, per their preference — in:

- The specific advisory for their report.
- A hall-of-fame page at security.naridon.com.
- The `ACKNOWLEDGEMENTS.md` in the Aura source repository.

Credit is offered for medium-and-above severity in-scope findings; low-severity findings are credited at the researcher's request. We do not require you to sign anything to be listed; an email confirming your preferred attribution is sufficient.

### What to do while you wait

Between acknowledgement and public advisory, please refrain from:

- Posting details to social media, blog posts, or conference submissions.
- Testing against unrelated users' deployments to characterize prevalence.
- Sharing the report with third parties other than CERTs or vulnerability coordinators (where sharing is appropriate).

We encourage — and will help with — responsible conference submissions that align the talk date with the advisory date. Let us know early; we want your research to be well-received.

## Configuration

There is no configuration knob for disclosure policy. But two operator actions are policy-adjacent:

**Subscribe to security advisories.** RSS and email subscriptions are available at security.naridon.com. Advisories are also published as GitHub Security Advisories on the Aura repository.

**Pin the release-signing public key at install time.** See [supply-chain integrity](/supply-chain-integrity). A patched release distributed under our normal channel is signed by the same key you pinned at install; verifying the signature of an advisory-linked release is the mechanism by which you confirm the fix you applied is the fix we announced.

Example `security.txt` contents that your organization might mirror to document its own process:

```text
Contact: mailto:security@naridon.com
Expires: 2027-01-01T00:00:00Z
Encryption: https://naridon.com/.well-known/security.asc
Preferred-Languages: en, de
Policy: https://naridon.com/security/policy
Acknowledgments: https://naridon.com/security/hall-of-fame
```

## Limitations

- **We are a small team.** Response times at the edges of the SLA may reflect workload; we will tell you if a specific report is sliding against the target so you are not left guessing.
- **We are not the right contact for issues in your deployment.** If your Mothership was compromised, that is an incident for your internal IR process. Consult [incident response](/incident-response); contact us only if the root cause is an Aura vulnerability.
- **We cannot guarantee a CVE in every case.** CVE assignment depends on MITRE and the nature of the finding; some operator-configuration issues do not warrant CVEs. We will document the finding publicly either way.
- **We do not run a managed service.** Researchers who find issues in customer-operated Mothership deployments should report to the customer first. We will coordinate if there is an Aura-side fix, but we have no operational authority over deployments we do not run.
- **Policy evolves.** The exact SLA targets, scope, and bounty arrangements may change. Updates are announced via the security advisory channel; material changes are dated and summarized on the security page.

## See Also

- [Threat model](/threat-model) — what Aura claims to defend against
- [Supply-chain integrity](/supply-chain-integrity) — how you verify the patched release
- [Cryptographic design](/cryptographic-design) — context for crypto-adjacent reports
- [Incident response](/incident-response) — your side of the table when a fix lands
- [Audit trail](/audit-trail) — evidence format useful in reports