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.

Whether a Data Protection Officer or an EU representative must be appointed has not yet been confirmed by legal counsel.

• 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 — supported text and Office files, read within KROMSE. PDF and image reading and external OCR are switched off; no document is sent to Mistral.
• Audit records — who did what and when inside your workspace.

Only after you enable analytics in cookie preferences on the public marketing pages, Google Analytics 4 measures visits to those pages: pages viewed, approximate location derived from your IP address, which Google Analytics 4 does not store, device and browser type, and referring site. It sets the cookies _ga and _ga_* for up to two years. The legal basis is your consent, which you can withdraw at any time through "Cookie settings" in the footer of those pages; withdrawing stops measurement and deletes those cookies. Google signals and ad personalisation are switched off. If you decline both optional purposes, nothing is loaded from Google and no measurement cookie is set.

Inside the product, page measurement is switched off: no page address, page title, workspace, product, repository, finding, vulnerability identifier, message or account detail is sent through Google Analytics usage events. If you allowed analytics, the product reports only a fixed list of named usage counts — for example that a scan was started, that an assistant message was sent or that a checkout was opened — with a constant placeholder in place of the page address. A statement on the strictly necessary session cookies set by the authentication provider is not published yet.

Only if you separately enable ad measurement, Google Ads (Google Ireland Limited) uses ad-click identifiers and conversion cookies, including _gcl_* (normally up to 90 days), to measure sales enquiries, successful sign-ins and sign-ups, scan starts, first completed free scans and first subscription payments. Events include their type, value, currency and a pseudonymous receipt identifier to avoid duplicates. Google also processes technical request information such as IP address and browser details. This may involve processing outside the EEA under Google’s applicable transfer safeguards.

We do not send names, email addresses, phone numbers, repository addresses, code, findings or payment-card details to Google Ads. Enhanced conversions, remarketing and personalized advertising are disabled. Product page addresses and titles are replaced with a constant placeholder. The legal basis is consent; you can withdraw it through Cookie settings, which stops future conversion reporting and removes our conversion cookies. Existing analytics permission does not grant permission for ad measurement.

With ad-measurement consent, the LinkedIn campaign fields utm_source, utm_medium and utm_campaign are stored in the first-party kromse_attr cookie for up to 30 days and saved with a backend signup receipt after confirmation by Clerk. This integration does not write unsafeMetadata.kromse_acquisition. Withdrawing consent deletes the cookie and stops further collection; contact info@kromse.com to request deletion of stored attribution.

With separate ad-measurement consent, the LinkedIn Insight Tag measures approved public pages and a confirmed new signup. It runs in an isolated frame with a fixed address and no access to app content or first-party cookies. LinkedIn receives technical network and browser information. No enhanced matching, email addresses, repository data, code, findings, billing details or later product events are sent to LinkedIn. You can withdraw consent in Cookie settings.

Workspace records — products, findings, cases, reports, audit entries — are stored in a PostgreSQL database that KROMSE runs on Hetzner servers in Germany. 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.

For data return, correction or closure, contact info@kromse.com. Kromse Labs S.L. verifies the requesting workspace owner and records the scope, delivery channel and target date. Existing downloads cover their stated scope. A wider export and deletion are handled manually, with checks for missing objects, shared accounts and retained records. Database rows, object files, provider records and backups are separate steps. Archiving is not erasure. A completion statement identifies what was removed and what remains; there is no self-service whole-workspace deletion or fixed completion deadline. Backup copies may retain previously stored data until their verified expiry or separate removal. A restricted deletion ledger records completed requests so they can be reapplied before a restored database is returned to service. Removing live data does not establish that every backup or provider copy has been erased.

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

A separate AI processing policy (Configured providers / EU-only / Deterministic-only) applies in addition to the AI data setting. Both settings must permit an AI request. EU-only and Deterministic-only currently block all customer AI, with no fallback provider: no EU AI endpoint is approved. A deterministic-only scan never sends repository source code or excerpts to AI; chat and verdicts can use its findings metadata, including attached scans and findings. Workspace Off blocks new requests. Stored verdicts remain visible with their recorded model and date.

The workspace AI data setting defaults to metadata-only. Off blocks workspace AI requests. Metadata-only permits recorded findings, repository names, paths and line numbers, SBOMs, public advisory information and the messages and history you send, but not automatic source excerpts, repository listing/reading tools or source-code triage. Code-excerpts permits bounded, redacted source context and repository tools where the feature supports them. Owners and administrators control this setting. A scan created as Deterministic scan only never sends repository source code or excerpts to AI. Chat and verdicts can still use its findings metadata. Free-plan verdicts never list or read repository files, including in code-excerpts mode. Text you type into chat may itself contain code or sensitive information; metadata-only does not remove that text.

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 the workspace permits code-excerpts and 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 — the only AI provider that receives your content today. It processes the chat assistant (Auto, High and Extra high, including web search and repository tools), finding verdicts, AI triage of static-analysis findings, the optional AI code review of a scan and the other AI actions in the product. The request sets store=false. The data-control settings on the KROMSE OpenAI project also apply.
• Anthropic (United States) — named in section 6, but no KROMSE feature sends your content to Anthropic today. Every AI feature listed above runs on OpenAI, and KROMSE's routing admits OpenAI only. Adding a provider means changing that routing together with this notice and its version (section 11).
• Mistral AI (EU endpoint api.eu.mistral.ai) — named in section 6, but no KROMSE feature sends your content to Mistral today, and no Mistral fallback exists for any other AI feature. External document OCR is switched off: PDF and image reading are unavailable and no uploaded document is sent to Mistral.

The chat assistant receives your messages and a bounded metadata summary for the selected workspace, product, scan, finding or case. 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. This describes the digest itself: evidence tools and verdicts can add paths and line numbers in metadata-only or code-excerpts mode when both workspace settings permit AI. Historical AI records retain the provider identity recorded when they were created.

Current chat requests are processed by OpenAI. The assistant can retrieve relevant workspace evidence and use OpenAI web search for external information. Queries and selected context needed for those operations are processed by OpenAI; retrieved information may be included in subsequent model requests.

With workspace code-excerpts enabled and an AI-eligible scan, when you ask about a selected finding from a GitHub App repository scan, KROMSE may also read that finding's file at the scanned commit and send an excerpt to OpenAI. This separate source context contains up to 40 numbered lines, limited to 4,000 characters, plus the file path, commit reference and line numbers. Secret redaction is applied before the excerpt is sent, but cannot guarantee removal of every sensitive value. This initial excerpt is separate from repository tools: during chat, the assistant can search repository paths and read additional bounded file excerpts at the scanned commit. Those tool responses include file paths, line numbers and redacted source text, and are sent to OpenAI. These separate source channels require the code-excerpts workspace setting; the initial metadata digest alone does not describe their payload. The AI receipt records whether an excerpt was available and its source details. An excerpt does not establish reachability or exploitability.

Finding verdicts. When a finding verdict is requested, OpenAI receives advisory text, component name and version, severity and exploitation signals, product answers, finding identifiers, file path and line number where available. Paid verdicts may use repository evidence tools only with workspace code-excerpts enabled and an AI-eligible scan; bounded reads at the scanned commit may return redacted source excerpts. Free-plan verdicts cannot list or read repository files. Metadata-only verdicts can still include paths and line numbers. Workspace Off blocks new verdict generation. Existing verdicts remain visible with their recorded model and date. Verdicts are cached for their current inputs; Free-plan generation is capped per workspace. There is no Mistral fallback. Redaction is pattern-based and cannot guarantee removal of every secret.

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.

• Hetzner — production hosting on servers in Germany: the web application, the API, the CRM, the scanner workers and the PostgreSQL database. This includes workspace records, the temporary repository copies and the firmware and container analysis workspaces on the scanner servers, and encrypted database backups. Using Hetzner does not establish EU-only processing by the other services listed here.
• 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.
• Stripe — subscription billing and payments. When you start a checkout, buy extra allowance or open the customer portal, you are sent to Stripe's hosted pages, where Stripe collects your payment details, billing name and address, tax ID and the contact details you enter. KROMSE gives Stripe the workspace identifier as a reference and receives subscription, invoice and payment status. KROMSE stores Stripe customer, subscription and invoice references and plan status, not card numbers.
• Google Workspace — application email, sent through Google's mail service (SMTP server smtp.gmail.com), including contact-form enquiries to info@kromse.com and configured operational notifications. Google receives the message content and sender and recipient addresses. Contact-form enquiries include the submitted name, work email, company and any optional fields you provide.
• 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 — the AI provider for every AI feature that sends your content: chat assistance when you send a message, including relevant retrieved workspace context and web search, finding verdicts, triage of static-analysis findings, and optional code review when you select it, as described in section 5.
• Anthropic (United States) — named as an AI service provider. No KROMSE feature sends it your content today; section 5 explains what that means.
• Mistral AI (EU endpoint api.eu.mistral.ai) — named as an AI service provider. No KROMSE feature sends it your content today; the endpoint configured for it is Mistral's EU endpoint. External document OCR stays disabled.
• Google Analytics 4 (Google Ireland Limited) — visit measurement on the public marketing pages and named usage counts from the product, only with your consent, as described in section 3. It receives no workspace, product, scan or account data. Google may process this data outside the EU.
• 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. Application email uses Google Workspace as described above.

Planned provider changes are reviewed by Kromse Labs S.L. and communicated manually to verified workspace contacts, identifying the provider, purpose, affected data and intended date. Questions or objections go to info@kromse.com and are recorded before a decision on the affected processing. Any contractual authorisation, notice period or objection window must be agreed in the applicable customer agreement; this draft does not establish them. There is no automated advance-notice service.

What KROMSE implements today, described without embellishment:

Temporary scanner disks on Hetzner have no verified encryption-at-rest assurance.

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

On the Hetzner database server, the volume that holds the PostgreSQL database is encrypted at rest. The API and the workers are configured to reach the database over Hetzner's private network with TLS and certificate verification, and database backups are encrypted before they are stored. These are descriptions of KROMSE's configuration, not an independent audit of keys, backups or every connection.

The contractual and international-transfer questions identified in this draft remain subject to review.

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.

Send requests to info@kromse.com. Kromse Labs S.L. verifies identity and scope, records the request and coordinates the response. We agree a target date for the specific request and identify any outstanding information or retained records. No fixed service response time is promised here. The controller details and relevant complaint authority remain subject to the legal review identified in this draft.

US-based service providers include OpenAI, Anthropic, Clerk, Stripe, Cloudflare, Google and GitHub. The service or contracting entity may differ. Storage, authentication, payment, email, analytics and AI services listed in section 6 can involve processing outside the EEA, so KROMSE is not an EU-only service. Use of a regional endpoint for a particular provider feature does not make the whole product EU-only. The transfer mechanism for each sub-processor (standard contractual clauses, an adequacy decision or another mechanism) has not yet been confirmed by legal counsel.

Report a suspected incident to info@kromse.com, identifying the affected workspace and what you observed without sending passwords or unnecessary personal data. Kromse Labs S.L. coordinates the response: record the report, preserve relevant evidence, assess affected data and services, contain the incident, and track recovery. Customer communications distinguish confirmed facts from unknowns and identify outstanding actions. The responsible people and their advisers assess any applicable notification requirements; this notice does not make that legal determination or promise a fixed response 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.

Next-use acceptance is separate from advance notice. Planned material changes are reviewed and communicated manually to verified workspace contacts; any agreed notice period is recorded in the customer agreement. No automated advance-notification service or fixed notice period is promised by this draft.