Privacy Policy

KROMSE analyzes repository code, uploaded SBOMs and firmware, and container images. When you connect a repository and start a scan, KROMSE downloads a complete copy of that repository at one exact commit and reads the files in it. This is not incidental metadata — it is your code, and you should read the rest of this page with that in mind.

The working copy is short-lived. It is unpacked into a private per-scan workspace on the scanner worker, used by the scanners, and removed by normal scan cleanup on success or handled failure. If the worker is forcibly stopped, temporary files can remain until cleanup or service replacement. KROMSE does not archive these working copies as durable product inputs.

What KROMSE does keep is scan evidence: the output of the scanners, which can quote fragments of your code — a vulnerable line, a matched pattern, a dependency manifest. Section 4 covers where that lives and for how long.

Uploaded firmware is retained as a product input; it is not deleted when a scan finishes. Section 4 explains its lifecycle. Source code is not sent to an AI provider by default. Advisory lookups, optional AI review, chat and document reading have different data flows, described in section 5.

For the personal data of your own end users that may appear inside your repositories or evidence, you are the controller and KROMSE is your processor. The Data Processing Terms govern that relationship.

For the account data of the people who log in to KROMSE, KROMSE is the controller.

Any appointment of a Data Protection Officer or EU representative remains [ TO BE CONFIRMED BY LEGAL COUNSEL — KROMSE cannot determine this ].

• Account and workspace data — your name, email address, and organization membership and role. Authentication is handled by Clerk; KROMSE does not receive or store your password.
• Repository source code — the full contents of a connected repository at the resolved commit you scan, obtained through an authorized GitHub App installation or an attached Git source, including a public Git repository.
• Other scan inputs — uploaded SBOM files, firmware bytes and their identifying metadata, and container images retrieved from the registry reference you attach. Where supplied, Git and registry credentials are stored encrypted.
• Scan evidence — scanner output, dependency inventories and SBOMs, findings, and the code fragments those findings cite.
• Compliance workspace content — products, cases, deadlines, report drafts, and anything you or your colleagues type into KROMSE.
• Documents you upload during onboarding, including PDFs and images you choose to have read by optical character recognition.
• Audit records — who did what and when inside your workspace.

KROMSE does not use tracking cookies, advertising identifiers, or third-party analytics on the product surface. [ TO BE COMPLETED BY KROMSE — not established today ] — a cookie statement covering the strictly necessary session cookies set by the authentication provider still needs to be written and confirmed.

Workspace records — products, findings, cases, reports, audit entries — are stored in a managed PostgreSQL database. Every record carries the identifier of the organization it belongs to, and reads are filtered by that identifier, so one workspace cannot read another's data.

Raw scan evidence is stored separately as content-addressed objects in private object storage with server-side encryption enabled and verified at the moment of writing. Evidence references are internal identifiers; KROMSE does not create public or pre-signed links to them. Storing evidence on local disk is rejected outright in the production configuration.

Each scan evidence object is given an expiry when it is written, derived from your plan's retention period. A periodic lifecycle job attempts to delete expired objects in bounded batches and retries failed deletions. After a successful deletion it replaces the object location with a deletion marker and records the time. The database record retains its digest and other metadata. Findings, reports, audit records and database backups are not erased by this object-expiry job. Retention periods currently range from 7 days on the free tier and 90 days for beta workspaces up to multi-year periods on higher plans.

Uploaded firmware bytes remain in private object storage while the product input is active. Archiving that input starts its plan-based retention period; it does not immediately delete the bytes. Container references and observed digests are stored with the product, and images are retrieved from the selected registry for analysis. The registry has its own storage and retention arrangements.

Deletion on request and account closure: [ TO BE COMPLETED BY KROMSE — not established today ]. There is no complete self-service workspace export or "delete my workspace" action. Existing SBOM, audit and report downloads each cover their stated scope. Archiving a product preserves its records; it is not workspace erasure. The request owner, verified manual process and treatment of retained backups still need confirmation. No deletion turnaround time is committed in this draft.

Temporary repository working copies use the cleanup lifecycle described in section 1, separately from the evidence-retention schedule above.

Source code is not sent to an AI provider by default. Deterministic scanning still makes external requests to retrieve inputs, scanner databases and vulnerability information.

OSV lookups can include component names, ecosystems, exact versions, package URLs (purls), Git commits and repository URLs on supported public hosting domains. Lookup and enrichment can send vulnerability identifiers to NIST NVD, FIRST EPSS and ENISA EUVD, and product, vendor or keyword searches to NVD or EUVD. KROMSE downloads CISA's Known Exploited Vulnerabilities catalogue and matches identifiers locally; it does not ask CISA to analyze your source code. These requests do not require optional AI review to be enabled.

If you explicitly select an AI model for a scan, KROMSE sends a bounded, redacted selection of your code to that provider. Concretely, and enforced in code rather than by policy:

• The secret scanner must have completed first. An AI review cannot run before it.
• At most 24 files are selected, capped at roughly 80,000 characters in total, and no single file over 256 KB.
• Only recognized source file types are eligible. Build output, dependency directories, and version-control internals are skipped.
• Any file in which the secret scanner found a secret is excluded from the selection entirely.
• The remaining text is passed through secret redaction before it is sent: private keys, GitHub tokens, cloud access keys, API keys, and password- or token-shaped assignments are replaced with redaction markers.
• The model's output is checked against the exact files and line ranges that were sent, and a response citing anything outside them is rejected.

Redaction is pattern-based and does not guarantee that every sensitive string is removed. To avoid the optional AI transfer of selected source code, leave code review disabled. External advisory lookups still apply to deterministic scans.

Provider-specific handling, as configured today:

• OpenAI — provides Auto, High and Extra high assistance and optional code review. The request sets store=false. The data-control settings on the KROMSE OpenAI project also apply.
• Mistral — provides the explicitly selected 🇪🇺 KROMSE assistance option through its configured EU regional endpoint. It also provides optional optical character recognition of documents uploaded during onboarding, with separate confirmation before a document is sent. A regional endpoint alone does not establish every aspect of provider retention or data residency.

The chat assistant receives your messages and a bounded metadata summary for the selected workspace, product, scan, finding or case. KROMSE does not automatically attach repository files to chat. Text you put in a message is part of the request, including any code or sensitive information you choose to paste. The finding digest uses an explicit field allowlist and a size limit; it excludes file paths, line numbers, source code, evidence blobs and raw scanner output. Historical AI records retain the provider identity recorded when they were created.

The following list describes the current technical services and external data flows. Their contractual roles, applicable terms and transfer arrangements remain part of the review of this draft.

• Render — API hosting, the scanner worker, managed PostgreSQL 18 and Valkey for the scan queue and rate limiting. These four services are configured in Frankfurt.
• Vercel — web application hosting.
• Cloudflare R2 — encrypted scan evidence and uploaded firmware. KROMSE uses the EU jurisdiction endpoint with automatic region selection; this identifies the configured endpoint, not an individual storage country or a guarantee covering every processing operation.
• Clerk — authentication, session management, workspace membership and invitation emails.
• GitHub, other attached Git hosts and container registries — provide the repositories or images you select. GitHub App access uses your authorized installation; other attached sources use their configured URL and, where supplied, credentials.
• OSV, NIST NVD, FIRST EPSS, ENISA EUVD and CISA — vulnerability and prioritization data services, with the requests and local catalogue matching described in section 5.
• OpenAI — default chat assistance when you send a message, and optional code review when you select it.
• Mistral — the explicitly selected alternative chat provider and optional document OCR.
• Sentry — supported but not currently configured for error monitoring. If enabled, initialization disables default personal-data collection.
• Email delivery — Clerk sends workspace invitations from invitations@kromse.com. Inviting a member provides Clerk with the recipient's email address and workspace details; the email includes the workspace name and inviter's display name. Delivery of other notification types has not yet been verified.

Sub-processor change notice: [ TO BE COMPLETED BY KROMSE — not established today ]. There is no mechanism today for notifying customers before a sub-processor is added or replaced, and no objection window. Both the notice period and the objection process need to be decided and built before this section can promise either.

What KROMSE implements today, described without embellishment:

• Every workspace record is scoped to its organization, and data access is filtered by that scope.
• Scan evidence is written to private object storage with server-side encryption, and the encryption and content digest are verified after each write.
• Detected secrets are redacted from any code selected for AI review, and files containing found secrets are excluded from that selection.
• GitHub installation tokens are used only for API calls, are never forwarded to the archive download host, and are never written to storage, logs, or error messages.
• Downloaded archives are size-bounded and unpacked with protection against path traversal, symlinks, and archive bombs.
• Audit entries are chained with SHA-256 over the previous entry, so tampering with the history is detectable.
• The scanner runs as a non-root user in an isolated container image with checksum-pinned scanner binaries.

KROMSE has no SOC 2 report, no ISO 27001 certification, and has not had a third-party penetration test. None of those should be claimed here, in sales material, or in a security questionnaire until they exist.

Render documents AES-256 encryption at rest for its managed PostgreSQL primary and replica storage and backups. Checks on 7 September 2026 observed TLS 1.3 on fresh private database connections from the API and worker. These are provider documentation and specific connection checks, not an independent audit of storage keys or every historical connection. See Render's encryption documentation.

The request-handling, incident and contractual questions elsewhere in this draft remain unresolved.

If you are in the EU or the UK you have rights of access, rectification, erasure, restriction, portability, and objection in respect of personal data KROMSE holds about you as a controller. For personal data inside your own repositories and workspace, those requests should go to your organization, which is the controller for that data; KROMSE will assist as described in the Data Processing Terms.

Request channel and response time: [ TO BE COMPLETED BY KROMSE — not established today ] — a monitored contact owner and a response policy still need confirmation. No fixed service response time is promised here. The identity of the supervisory authority a complaint may be lodged with depends on the establishment of the controller entity, so it is [ TO BE CONFIRMED BY LEGAL COUNSEL — KROMSE cannot determine this ].

[ TO BE CONFIRMED BY LEGAL COUNSEL — KROMSE cannot determine this ]. Hosting, storage, and several of the AI providers listed in section 6 can involve processing outside the EEA. The 🇪🇺 KROMSE option uses Mistral's EU regional endpoint; that choice does not establish EU-only processing for the whole product. The transfer mechanism relied on for each sub-processor — standard contractual clauses, an adequacy decision, or otherwise — must be established by counsel and set out here before this document is relied on. Do not describe KROMSE as EU-only while section 6 lists non-EU processing.

[ TO BE COMPLETED BY KROMSE — not established today ]. The incident-response procedure, notification contacts and any response window remain to be confirmed for this notice. The responsible people and their advisers assess an incident and any applicable notification requirements; this draft does not make that legal determination or promise a notification deadline.

This policy is versioned. The current version is shown at the foot of this page. When the text changes in a way that affects you, the version is raised and you are asked to accept the new version the next time you use KROMSE — your earlier acceptance is kept on record rather than being treated as agreement to the new text.

Advance notice before a material change takes effect: [ TO BE COMPLETED BY KROMSE — not established today ]. Re-acceptance happens at next sign-in; there is no advance notification mechanism, so no notice period should be promised here until one is built.