Security & Vulnerability Disclosure

1. How to report a vulnerability

• Primary contact: security@roxykovu.com (preferred for any security finding).
• General contact: roxykovu.com/contact-us if you prefer the web form.
• Machine-readable policy: /.well-known/security.txt per RFC 9116.
• Encryption: we do not currently publish a PGP key. If your report contains sensitive details and you need an encrypted channel, ask in your first email and we will arrange one (Signal, Keybase, or an ad-hoc PGP exchange).

Please include in your report: (a) a clear description of the issue, (b) reproduction steps or proof-of-concept, (c) the affected URL or application, (d) any prerequisites (e.g. an authenticated session), and (e) your assessment of severity. Screenshots or short video are welcome.

2. Scope

The following are in scope for responsible disclosure:

• Website: roxykovu.com, www.roxykovu.com, and all subdomains hosted by RoxyKovu LLC.
• Naval Letter Builder web tool: /government-solutions/online-tools/naval-letter-builder/.
• RoxyKovu API endpoints: any HTTPS endpoint we expose under our domain (chat assistant, contact form, feedback ingest).
• iOS applications published under the RoxyKovu LLC developer account on the U.S. App Store.
• Android applications published by RoxyKovu LLC on Google Play.
• Desktop applications distributed by RoxyKovu LLC (e.g. PatchShepherd).

2.1 Out of scope

• Vulnerabilities in third-party services we link to but do not operate (Apple App Store, Google Play, AWS, Cloudflare, Google Tag Manager, etc.).
• Denial-of-service (DoS / DDoS) testing, traffic flooding, or any high-volume automated scanning that degrades service for other users.
• Social engineering of RoxyKovu employees, contractors, customers, or vendors.
• Physical attacks against RoxyKovu property, personnel, or data centers.
• Spam or content-injection in user-generated fields that have no security impact.
• Missing security headers, cookie flags, or HTTP best practices on pages that do not process user input (purely cosmetic or informational hardening reports).
• Issues that require an already-compromised user account, rooted/jailbroken device, or local administrative access on the user's machine.
• Reports based purely on outdated software versions in dependency listings without a working exploit against our deployment.
• Vulnerabilities that require the user to install a malicious browser extension or modify browser security settings.
• Findings against tools running in unsupported browsers (Internet Explorer is not supported).

3. Our commitments to researchers

• Acknowledgment within 2 business days of receiving your report.
• Triage and severity assessment within 5 business days, including a determination of whether the finding is in scope.
• Status updates at least every 14 days until the issue is resolved or we communicate a final disposition.
• Coordinated disclosure: we will work with you on a public-disclosure timeline. Our default is 90 days from your initial report, but we will negotiate longer windows for complex fixes (e.g. supply-chain remediation) or shorter windows for actively exploited issues.
• Credit: if you wish to be acknowledged publicly, we will credit you (name or handle of your choice) in the security section of our news feed and, where applicable, in CVE disclosures.
• No legal action against researchers who comply with this policy in good faith. See the safe-harbor terms in Section 5.

4. Severity and prioritization

We use a CVSS-informed severity scale and prioritize accordingly:

• Critical (CVSS 9.0-10.0): remote code execution, authentication bypass on a system with PII or controlled data, full S3 bucket exposure. We aim to remediate within 7 days.
• High (CVSS 7.0-8.9): stored XSS in an authenticated context, sensitive data leak, server-side request forgery. We aim to remediate within 30 days.
• Medium (CVSS 4.0-6.9): reflected XSS, weak crypto configuration with limited exposure, CSRF on non-critical actions. Remediate within 60 days.
• Low (CVSS 0.1-3.9): information disclosure with minimal impact, missing hardening best practices on pages without user input. Remediate within 90 days or accept the risk.

5. Safe harbor

RoxyKovu LLC considers good-faith security research conducted under this policy to be authorized activity. If you make a good-faith effort to comply with this policy during your security research, we will:

• Consider your research to be authorized under the Computer Fraud and Abuse Act (CFAA) and similar U.S. state computer-misuse statutes.
• Consider your research to comply with our Terms of Service (where they would otherwise prohibit such activity).
• Waive any DMCA claim against you for circumventing technical access controls solely for the purpose of your security research.
• Not pursue or support any legal action against you for accidental, good-faith violations of this policy.

To qualify for safe harbor you must: (a) report the issue to us before any public disclosure, (b) make a good-faith effort to avoid accessing, modifying, or destroying user data that is not your own, (c) avoid degrading service availability, (d) cease testing and notify us immediately upon discovering a vulnerability that exposes user data, (e) comply with all applicable laws, and (f) not engage in extortion or threats.

This policy applies only to vulnerabilities in RoxyKovu LLC systems. If your research touches a third party (a customer's deployment, a vendor's service, etc.), you are responsible for ensuring you have authorization from that third party.

6. Security posture

A snapshot of the controls currently in place across our hosted services. This is provided as transparency to researchers and customers; specifics may change as the security posture evolves.

6.1 Hosting and transport

• Static site hosted on AWS S3 with server-side encryption (AES-256) at rest, fronted by Amazon CloudFront with Origin Access Control. Direct S3 access is blocked.
• HTTPS-only via CloudFront with TLS 1.2 minimum (TLS 1.3 preferred).
• HSTS preload: max-age=31536000; includeSubDomains; preload.
• HTTP-to-HTTPS upgrade enforced via upgrade-insecure-requests directive.

6.2 Browser security headers (site-wide)

• Content-Security-Policy with explicit allowlist for required origins.
• X-Frame-Options: DENY and CSP frame-ancestors 'none' (no embedding / clickjacking).
• X-Content-Type-Options: nosniff.
• Referrer-Policy: strict-origin-when-cross-origin.
• Permissions-Policy disabling camera, microphone, geolocation, clipboard read/write, accelerometer, gyroscope, magnetometer, MIDI, payment, USB.

6.3 Naval Letter Builder web tool (additional)

• Page-level CSP with connect-src 'none' (zero network requests after page load), form-action 'none', object-src 'none'.
• Web build classification gate: Confidential / Secret / Top Secret options are stripped from the UI and blocked at the state layer. UNCLASSIFIED, CUI, and legacy FOUO only.
• CUI flagger: informed-consent modal on first CUI selection, persistent header indicator, always-visible data-handling ribbon, export-step reminder.
• Bundle integrity: deterministic build with build-manifest.json tracking source-file hashes; deploy.sh verifies reproducible-build byte-equality before sync.
• No analytics, no telemetry, no third-party scripts on the tool page. Verified by static analysis of the served HTML.

6.4 Data flow

• The Naval Letter Builder web tool processes nothing server-side: drafts live in the user's browser localStorage; the .docx export is generated client-side and downloaded directly.
• The chat assistant ("Kovu") forwards messages to Google Gemini for processing (see Terms of Service §12 and Privacy Policy); chat messages are not permanently stored.
• Contact form submissions route to RoxyKovu's inbox via an authenticated AWS API Gateway / Lambda path. Submissions are retained per our Privacy Policy.
• Cookie consent defaults to "denied" for ad/analytics storage; analytics fire only after explicit user opt-in.

6.5 Software supply chain

• Application source under version control with traceable change history.
• Reproducible builds via build.py for the Naval Letter Builder bundle; manifest with per-file SHA-256 tracking.
• Dependency monitoring via Dependabot / equivalent for the JavaScript and Python toolchain.
• Static analysis (SAST) configured in CI for the application bundle and supporting Lambda functions.
• Deployment uses authenticated AWS CLI with SSO-backed credentials; deployment events logged in CloudTrail.

6.6 Architecture limits and known trade-offs

• The Naval Letter Builder web build uses 'unsafe-inline' in script-src because the toolkit currently relies on inline event handlers and inline <script> blocks. This is a known weakness; mitigations include zero user-content reflection on the page and no external script loads.
• The website does not currently carry a DoD Authority to Operate (ATO), FedRAMP authorization, or CMMC certification. The hosted tools are commercial / open-source offerings; users on regulated networks are responsible for ensuring their use complies with their organization's policy.
• For classified-level work (Confidential / Secret / Top Secret), use the iOS app on an authorized enclave-issued device. The web build deliberately refuses those levels.

7. Acknowledgments

Researchers who have responsibly disclosed vulnerabilities to RoxyKovu LLC will be acknowledged here (with their permission). No reports to acknowledge yet. Be the first.

8. Policy updates

We may revise this policy at any time. The effective date at the top of this page reflects the most recent revision. Material changes will be announced via the News page. The machine-readable policy at /.well-known/security.txt is updated in lockstep.

9. Related policies

• Terms of Service (especially §15 Disclaimers and §16 Limitation of Liability).
• Privacy Policy.
• Naval Letter Builder web tool — open the tool and click "About this tool & data handling" in the ribbon for tool-specific posture.

10. Contact

• Security reports: security@roxykovu.com
• General inquiries: Support@roxykovu.com
• Web form: roxykovu.com/contact-us