Security & Vulnerability Disclosure

1. How to report a vulnerability

• Primary contact: Support@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.
• 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 developer account on the U.S. App Store.
• Android applications published by RoxyKovu on Google Play.
• Desktop applications distributed by RoxyKovu (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 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 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.
• Cross-Origin-Resource-Policy: same-origin prevents our resources (assets, images, scripts) from being embedded by cross-origin sites without explicit opt-in.
• CSP violation reporting wired via report-uri + report-to directives (plus the modern Reporting-Endpoints header), so attempted resource-injection blocks are surfaced to operations rather than silently swallowed.

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. For classified-level work, use the iOS app on an authorized enclave-issued device.
• CUI flagger (four tiers): (1) six-point informed-consent modal on the first CUI selection covering CAC workstation appropriateness, current DoD CUI training, marking responsibility, dissemination control, and shared-workstation hygiene; (2) a persistent CUI MODE indicator pill in the header for the duration of the session; (3) an always-visible data-handling ribbon disclosing the client-side-only data flow; (4) an export-step reminder above the .docx download button. Acknowledgment is recorded in browser localStorage so the modal does not re-prompt on every CUI letter. CUI handling aligns with DoDI 5200.48 (DoD CUI Program) and DON CIO Revised CUI Marking Guidance.
• CUI category coverage: the full NARA CUI Registry (117 categories) selectable via a typeahead picker. Banner formats from CUI through CUI//<CATEGORY> are rendered at the top and bottom of every page per DoDM 5200.01 V-2 conventions.
• CUI Designation Indicator (DI) block: appears on page 1 of every CUI letter, with five operator-completable fields (Controlled by / Office / Category / Distribution Statement / POC) per DON CIO Revised CUI Marking Guidance.
• Portion markings: (CUI) prefix activates per paragraph automatically when the document classification is CUI, with a per-paragraph override available in the body editor.
• PII-to-CUI bridge: an in-tool PII auditor flags SSN, DODID, passport, MRN, phone, and address patterns in the draft. When triggered, the operator can mark the letter CUI in one click with the appropriate NARA category prefilled (commonly PRVCY for general privacy, HLTH for health information, or MIL for military personnel records).
• FOUO legacy support: the UNCLASSIFIED//FOR OFFICIAL USE ONLY banner renders in green (#007A33) per ISOO Marking Classified National Security Information conventions because FOUO is a handling caveat on otherwise-UNCLASSIFIED material. FOUO itself is deprecated per DoDI 5200.48; the wizard surfaces the deprecation warning and recommends CUI for any current document.
• Caveat database (CAVEAT_DB): a single authoritative table inside the bundle lists CUI categories, dissemination controls, classified caveats, and SCI compartments. Codes (e.g. PRVCY, NOFORN, NNPI) are verbatim from the NARA registry and DoD marking authorities to keep banners and portion markings consistent with the source-of-truth.
• Bundle integrity: deterministic build with build-manifest.json tracking source-file hashes; deploy.sh verifies reproducible-build byte-equality before sync.
• Deployment provenance: an index.deployment-manifest.json sidecar is published next to the deployed bundle. It carries the SHA-256 of the served HTML, the SHA-256 of the source bundle, and the deployment timestamp. Anyone auditing the deployed tool can compute the served file's SHA-256 and compare against the manifest.
• 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 - weekly scans of npm and GitHub Actions dependencies.
• Static analysis (SAST) in CI: Semgrep against OWASP Top Ten, JavaScript, Node, and secrets rulesets; OSV-Scanner for multi-ecosystem CVE coverage; gitleaks for secret detection on every push; npm audit on every Lambda + ffm-site project.
• OWASP ZAP baseline scan runs weekly against the production site with a published rules file.
• Daily monitor against the CISA Known Exploited Vulnerabilities (KEV) catalog filtered to our technology stack.
• Deployment uses authenticated AWS CLI with SSO-backed credentials; deployment events logged in CloudTrail with log-file validation.

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. Mitigations: zero user-content reflection on the page, no external script loads, and CSP violations are reported to a private monitoring endpoint so any attempted injection is surfaced.
• 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. Compliance and standards

RoxyKovu is a commercial / open-source provider. We do not currently hold any third-party security certification. The list below is the public summary of the frameworks we align with and the operational controls we run. Specific scoring, gap data, asset detail, and incident-response runbooks are maintained internally and are not published.

7.1 Frameworks we align with

• NIST SP 800-53 Rev 5 - control families implemented for our architecture (Access Control, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Risk Assessment, System and Communications Protection, System and Information Integrity, Supply Chain Risk Management).
• NIST SP 800-171 Rev 3 - annual control-by-control self-assessment maintained; scored using the DoD Assessment Methodology rubric.
• NIST SP 800-218 (SSDF) - software development practices: reproducible builds, SBOM-equivalent build manifests, deployment provenance sidecar.
• DoDI 5200.48 - CUI marking and handling for tools that surface CUI.
• DoDM 5200.01 V-2 / ISOO Marking Classified National Security Information - classification banner conventions used by the Naval Letter Builder.
• RFC 9116 - machine-readable security.txt with current contact + policy URL + expiration.
• WCAG 2.0 AA - accessibility targets for the public site and the Naval Letter Builder UI.

7.2 Continuous controls in production

• AWS Security Hub continuously scores our cloud posture against NIST SP 800-53 Rev 5, the CIS Foundations Benchmark, and AWS Foundational Security Best Practices. Findings are reviewed on the quarterly cadence below.
• AWS Config records every resource configuration change.
• AWS Inspector v2 scans Lambda function code for known vulnerabilities.
• AWS GuardDuty is enabled in every compute region.
• IAM Access Analyzer monitors cross-account access posture.
• CloudTrail multi-region trail with log-file validation; data events enabled on user-content S3 buckets so per-object reads and writes are recorded.
• Account-level S3 Block Public Access is enforced.
• Daily monitor against the CISA Known Exploited Vulnerabilities (KEV) catalog filtered to our technology stack; alerts surface to the operator.

7.3 Documented controls

We maintain the following operational documentation under version control. These are internal-only; the summaries are described here so customers and researchers understand the posture without exposing specifics:

• System Security Plan (SSP) - control implementation matrix aligned to the families above.
• Threat model - STRIDE methodology applied per surface; refreshed quarterly.
• Asset inventory - domains, AWS resources, third-party dependencies.
• Risk register / POA&M - open items, accepted risks, closure log.
• Incident response runbook - scenario-specific procedures with response steps, regulatory decision tree, and external-communications guidance.
• NIST SP 800-171 self-assessment - control-by-control scoring against the DoD Assessment Methodology.

7.4 Review cadence

• Quarterly: threat model refresh, risk register review, asset inventory reconciliation, an automated cross-resource security baseline audit (scheduled), and a tabletop exercise rotating through documented incident scenarios.
• Annually: full SSP review, self-assessment refresh, disaster-recovery drill.
• Triggered: material architecture change, new asset, new third-party dependency, security incident.

7.5 What we deliberately do not claim

• No DoD Authority to Operate (ATO).
• No FedRAMP authorization.
• No CMMC certification.
• Not a HIPAA Covered Entity. Some products (e.g. EDEN EHR) operate as a Business Associate where a Business Associate Agreement is in place with the controlling Covered Entity.
• Users on regulated networks are responsible for ensuring their use of our tools complies with their organization's policy.

7.6 Publicly verifiable artifacts

Where possible, the controls above produce artifacts that anyone can fetch and verify:

• /.well-known/security.txt - RFC 9116 machine-readable contact + policy.
• /sitemap.xml - public sitemap.
• For the Naval Letter Builder bundle: index.deployment-manifest.json alongside the served HTML carries the SHA-256 of the served artifact and the source bundle. Compute the served HTML's SHA-256 and compare.

8. Acknowledgments

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

9. 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.

10. 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.

11. Contact

• All contact (security or otherwise): Support@roxykovu.com
• Web form: roxykovu.com/contact-us