Security & AI-Governance Audit Trail

This page documents how to report vulnerabilities, what's in scope, our response commitment, and the security posture of the products we ship. The operational companion to the trust & compliance posture page — that page covers framework status (SOC 2 / ISO 42001 / EU AI Act Article 12 / NIST AI RMF) and the procurement artifact set; this page covers vulnerability disclosure, supply-chain integrity, and the secure-defaults of the products we ship.

Reporting a vulnerability

Email [email protected] with details. Please include:

• A clear description of the issue and how to reproduce it
• The affected URL, command, or code path
• Your assessment of impact (data exposure, availability, etc.)
• Optional: a proof-of-concept

Acknowledgement within one business day (Athens, Greece time), with a substantive triage response within two business days. For high-severity issues we engage immediately on receipt. (These SLAs match the procurement-facing commitment on the trust page security-contact row.)

Safe-harbour commitment

We will not pursue legal action against good-faith security research that:

• Avoids accessing, modifying, or destroying customer data
• Doesn't degrade service availability for other users
• Stops at proof-of-concept (no exfiltration, no ransom, no public disclosure before fix)
• Gives us a reasonable window to remediate (default 90 days; extendable on request)

In scope

• roam-code.com and all sub-paths/sub-domains we control
• The roam-code Python package on PyPI and any binary releases
• The Cranot/roam-code GitHub repository (source + workflows)
• The MCP server (roam mcp) and its tool surface
• Anything reachable from /docs/

Out of scope

• Findings on third-party services (Cloudflare, GitHub, PyPI) — please report to those vendors directly
• Self-hosted installations of customer code that include Roam — those are the customer's responsibility
• Non-security bugs (e.g. UI glitches, broken links) — open a regular GitHub issue instead

Hall of thanks

We acknowledge security researchers who report responsibly. Once we have a name to credit, it goes here. Send us how you'd like to be credited (full name, handle, or anonymous).

No reports yet — be the first.

Roam does not run a monetary bug-bounty program yet. Until a paid program is announced, responsible reports receive public acknowledgement in this hall plus, on request, a written reference confirming the report and remediation outcome. Same stance is cited from the trust page vulnerability-disclosure row.

Security posture

The CLI runs locally

The roam-code CLI is local source analysis with no API key and no automatic repository-content upload. It writes a SQLite file in your repo's .roam/ directory. No automatic telemetry, update check, model-training upload, or listener. A cold parser cache may retrieve one checksum-verified platform bundle from the dependency's GitHub release; the bundle is retained for offline reuse. Explicit commands and flags can contact PyPI, GitHub, user-selected URLs, Roam Cloud, or Sigstore, opt-in MCP model summarization can send selected report snippets to the configured model provider. The explicit bench-compile benchmark launches claude -p with task prompts and generated context; optional MCP/webhook modes can open a listener. The complete trigger, destination, payload, and default inventory is in docs/network-boundary.md. This same default-local, no-automatic-upload stance is contractually committed in DPA §6 (Security measures). The engine is Apache 2.0; audit the source on GitHub and rebuild every release from the tagged commit.

Explicit network boundary

For air-gapped use, install from an approved wheelhouse, prewarm the parser cache on each target platform, use fixture/file inputs and offline-key signing, and enforce egress at the host boundary for any project test/build commands launched by verification hooks.

Supply-chain integrity

• PyPI releases use OIDC Trusted Publishing (no long-lived API tokens) — see .github/workflows/publish.yml
• Releases are built by the published workflow from tagged source
• The publish workflow produces Sigstore-backed PyPI attestations linking artifact digests to the publishing identity
• The workflow emits a CycloneDX SBOM describing dependencies in its release inspection environment
• The repo enables Dependabot security updates + secret scanning + push-protection

Local analysis does not require granting a hosted review service access to your repository. It still depends on the package, its dependencies, the build and publishing chain, and your machine. Attestations establish provenance within that trust model; an SBOM inventories dependencies. Neither establishes that the code is safe or that an independent rebuild is bit-for-bit identical. We do not claim independently verified reproducible builds. Inspect the workflow and tagged source when evaluating a release.

Verify a release yourself

Select the exact distribution file you intend to install, then follow PyPI's attestation verification instructions with the expected repository https://github.com/Cranot/roam-code. The documented pypi-attestations verifier fetches the file and its provenance separately and checks the publishing identity and artifact digest. A normal pip download does not supply an attestation sidecar. Missing or failed verification is not a successful provenance check.

SBOM (CycloneDX) and the workflow's GitHub Attestations view are linked from each GitHub release.

Audit-trail evidence

Roam's evidence workflows, when configured, can emit in-toto v1 attestation statements and an HMAC-chained run ledger. They are not automatic records of every analysis. Inspect which checks ran and which were missing; a signed record does not authenticate who acted or prove complete coverage. Run roam runs verify to confirm the ledger chain and roam cga verify STATEMENT.json to confirm the in-toto predicate before consuming the artefact in CI. Per-run CGA, index, VSA, and PR-bundle statements support optional Cosign signing today. Local-key signing is the offline path; --keyless explicitly contacts OIDC, Fulcio, and Rekor services and publishes signing evidence.

Hosted services posture

• roam-code.com — static site on Cloudflare Pages. Its source configures CSP, HSTS, COOP+CORP, Permissions-Policy, and X-Frame-Options DENY; verify deployed response headers for the live policy. The code atlas uses first-party JavaScript and a bundled source snapshot, with a static fallback. It does not connect to your repository. No third-party analytics are configured.
• Roam Cloud (when launched) — metrics-only ingestion. Source code is never uploaded.
• Roam Review (when launched) — PR diffs are processed ephemerally in our cloud. Private-deployment pilots are scoped by SOW when hosted processing is blocked by policy. Diffs discarded after analysis. Audit-trail metadata retained per the Privacy Policy.

Disclosure timing

We aim to remediate high-severity issues within 30 days, medium within 90 days, low at our next scheduled release. We'll coordinate any public disclosure with the reporter. Default public-disclosure window is 90 days from initial report; we may extend on request when more time is genuinely needed.

PGP / encrypted reports

Both [email protected] and [email protected] have OpenPGP keys auto-published by Proton. Look them up via:

• Proton public key server: https://api.protonmail.ch/pks/lookup?op=get&[email protected]
• Or send any email and Proton attaches the public key in headers (Autocrypt standard).

Once you have the key, encrypt your report with PGP and send to [email protected]. We'll decrypt and respond from the same address with the same key.

For the most current contact info, see our security.txt — it lists the encryption-key URL too.

Compliance posture

Evidence support, not certification. Roam maps to and supports evidence for the controls below; it does not certify, attest, or make a customer compliant. No current independent attestation against any of these frameworks. See the trust & compliance posture page for framework-by-framework status and roadmap candor.

• SOC 2 CC8.1 (change management) — Roam's tamper-evident audit-trail and proof bundles map to the change-management control; they supply evidence inputs an auditor would draw from, not the attestation itself.
• ISO/IEC 42001 (AI management system) — the AI management system standard published April 2024. Roam's structural-review records and in-toto attestations support clauses on documentation, monitoring, and operational controls for AI-generated artefacts.
• Internal AI-governance policies — configured Roam workflows can supply development-check records for a team's review process. Whether those records meet a policy's needs depends on the required checks and the evidence actually collected.
• EU AI Act — Article 12 addresses record-keeping for high-risk AI systems within the Regulation's applicable regime. High-risk classification is not limited to Annex III: Article 6(1) also covers qualifying product-related systems under Annex I. Applicability depends on the system, role, classification, scope exceptions and applicable dates. Roam's development records are not themselves Article 12 system logs and do not establish compliance. Consult your DPO or counsel and the Regulation, including Articles 2, 6, 12 and 113.
• GDPR — see Privacy Policy for data-processing details + sub-processors, and templates/legal/dpa.md for the Article 28 processor agreement.
• SOC 2 / ISO/IEC 42001 / ISO 27001 — control mappings exist as evidence-support templates; standalone certification and packaged Self-Hosted controls are roadmapped, with no current independent attestation. See trust page framework status for current roadmap candor.

Procurement-trio companions: the trust & compliance posture page covers framework status and the procurement artifact set; the privacy policy covers data processing, retention, and sub-processors; this page is the operational security companion. The DPA, NDA template, security procurement packet, and master SOW are all public at templates/legal/.

Questions about this policy? [email protected].