Vulnerability Disclosure

For: security researchers, and customers running their own pen-test, who want to report an issue and know what to expect back.

This is the full policy: how to report, what is in and out of scope, our service-level targets, how we talk to you, and the safe-harbour terms. To report, email maicon.burn@gmail.com with a subject line beginning [InnerWarden Security] (see How to report below). The policy is honoured from its publication date, and we review our performance against these targets each quarter.

Plain version: report it privately, give us a fair chance to fix it, stay inside the scope, and we will not come after you. We acknowledge within two days, triage within a month, and ship a fix for serious issues within 90 days.

---

How to report

Report privately by email:

Email maicon.burn@gmail.com with a subject line beginning [InnerWarden Security].

Only the maintainers see these reports. We will acknowledge receipt, open a private advisory to coordinate the fix, and can issue a CVE if the issue warrants one.

Please do not:

• Open a public issue describing the vulnerability.
• Post details on social media before coordinated disclosure.
• Exploit the vulnerability against deployments you do not own.

---

What to put in a report

The more of this you give us, the faster we triage:

• A description of the vulnerability.
• The affected version(s) (the output of innerwarden --version if you have it).
• The component: sensor, agent, dashboard, CLI, installer, release pipeline, AI integration, and so on.
• Reproduction steps: specific commands, configs, payloads.
• The impact in concrete terms (what an attacker actually gains).
• A suggested fix or mitigation, if you have one.
• Whether you plan to publish your own write-up, and when, so we can coordinate timing.

We accept reports in English and Portuguese.

---

Our service-level targets

Stage	Target	What it means
Acknowledgement	48 hours	A human reads your report and responds to confirm receipt, ask questions, or start triage.
Initial triage	30 days	We have a severity, an owner, and a tentative remediation date, and we share them with you.
Fix for Critical / High	90 days	A patched release ships. Sooner if the issue is actively exploited; for the most severe cases the response is hours, not days.
Fix for Medium	120 days	A patched release ships, or a documented mitigation.
Fix for Low	next release cycle	Bundled into the normal cadence.
Public disclosure	within 14 days of the fix	A joint advisory plus release notes, and a CVE where applicable.

Reality note. InnerWarden is solo-maintained today. These targets are the policy we hold ourselves to, not a promise that nothing will ever slip. If we are going to miss a milestone we will tell you why and propose a new date. Silence is not an acceptable response from us.

---

Severity tiers

We score with CVSS v3.1 and map to four response-speed tiers.

Tier	CVSS v3.1	Examples in an InnerWarden context
Critical	9.0 to 10.0	Remote code execution via a dashboard auth bypass, signing-key compromise, release-artefact tampering, a malicious upstream that lands on main.
High	7.0 to 8.9	Authenticated dashboard privilege escalation, an AI-provider data leak, an unprivileged process able to silence the sensor.
Medium	4.0 to 6.9	Information disclosure to authenticated users, denial of service of the agent loop, a missing rate-limit on a sensitive API.
Low	0.1 to 3.9	Hardening recommendations, defence-in-depth gaps with no known exploit path, documentation that misrepresents a security guarantee.

---

Scope

In scope

• The sensor.
• The agent and dashboard.
• The CLI: installer, hardening, scan, upgrade.
• The supporting crates (agent-guard, supervisor, and the firmware, hypervisor, killchain, and DNA modules).
• The release pipeline and signing path.
• install.sh (hosted at https://innerwarden.com/install).
• The local Warden model installer.
• Documentation pages that document a security guarantee or invariant (see Trust and Safety Invariants).

Out of scope

• Third-party AI providers we integrate with: report those directly to the provider.
• An operator's own misconfiguration (weak passwords, an internet-facing bind with no firewall, a leaked TOTP secret).
• Vulnerabilities in the operating system, the container runtime, or eBPF in the Linux kernel itself: report upstream.
• The marketing site content pages; we will handle a security issue there but do not make the same SLA commitment.
• Social engineering of contributors or operators.
• Physical attacks on operator hardware.

If you are unsure whether something is in scope, ask via the private channel and we will tell you.

---

Safe harbour

We will not pursue legal action against researchers who:

• Report in good faith via the channels above.
• Stay within the in-scope list.
• Access no more data than is necessary to demonstrate the issue.
• Do not test production deployments they do not own or have written permission to test.
• Give us a reasonable chance to remediate before public disclosure.

Research outside the scope (for example, testing against an InnerWarden customer's production environment without their permission) is not protected by this safe harbour and may be illegal in your jurisdiction. Please stay inside it.

---

Coordinated disclosure

By default we publish a joint advisory within 14 days of the fix shipping, and we will coordinate timing if you want to publish your own analysis.

• For Critical, the advisory and the release ship together where possible.
• For High, the advisory ships with the release; some details may be held up to 30 days post-release if exploitation is ongoing.
• For Medium and Low, the advisory ships with the next release notes.

We credit reporters by name or handle unless you ask us not to.

---

What we do NOT offer

• No paid bug-bounty. We thank reporters publicly with consent, and credit them in advisories and release notes, but we do not pay monetary rewards today.
• No out-of-hours SLA for non-critical issues. Critical issues fall back to the project's incident-response timelines, where the most severe cases are measured in hours.
• No retest service. You are welcome to verify a fix once it ships, but we do not provide a paid retest engagement.

---

What we ask of you

• Give us a chance to fix before going public.
• Tell us if you widen the scope mid-research (starting on the dashboard, then poking at the mesh interface is fine; just keep us informed).
• Tell us if you see evidence of active exploitation in the wild during your research. That changes our response speed.
• If you find a deployment that looks misconfigured (running with auth disabled and exposed to the internet), do not touch it. Report it to us; we may know the operator and can route the warning.

---

Track record

We commit to publishing a quarterly review of our own disclosure performance: how many reports we received, how many hit each SLA, the median and p95 time-to-fix per severity, and any policy changes we made as a result. Transparency about disclosure performance is itself part of the policy.

---

Related

• Security reporting (email maicon.burn@gmail.com, subject [InnerWarden Security]): the short policy, supported versions, and the supply-chain signing fingerprint.
• Trust and Safety Invariants: the guarantees we make, which tells you which class of report is in scope.
• Customer Security Pack: the procurement-facing pack that references this policy.
• THREAT_MODEL.md (source access is available to licensed customers): assets, actors, and what is out of scope by design.

---

Changes to this policy

We note material changes here with a date and a brief summary. The change history of this page is the authoritative record.