Trust
What a security review can read, and how to get the rest
This page is a map rather than more content. It exists because the worst outcome of a security review is a reviewer who cannot find something and assumes the worst about it.
Two documents are published: the privacy policy and the legal notice. Everything else on this page is either a page you can read now or an artefact provided during commercial and security due diligence, which means writing to info@ximplicity.es and asking. There is no form and no gate; a person answers.
The reason for that split is worth stating rather than hiding. Contractual and security documents are written for a named counterparty and are read in the context of a deal; publishing them as downloads invites them to be quoted out of that context, and the version somebody found on the internet is never the version they signed.
What exists, and where it is
Available means you can read it now. Preview here means it exists and is provided on request. Planned means it is not written yet, and saying so is the point of the vocabulary.
- AvailableSecurity — what is read, what is never read, and in which mode. At /security/. The three analysis modes and the default.
- AvailableArchitecture — what runs, where, and what it can reach. At /architecture/. Containers, identity, tenancy and what the code reading does.
- AvailableChangelog, including security fixes. At /changelog/, and it keeps its history rather than tidying it.
- AvailablePrivacy policy and legal notice. The two documents this site publishes.
- AvailableVulnerability reporting. Below, and at /.well-known/security.txt.
- AvailableResponsibility matrix — who operates which control. Below, per deployment.
- PreviewTerms, and the data processing agreement. Provided during commercial due diligence.
- PreviewSubprocessor information for hosted deployments. Current subprocessor information for hosted deployments is available on request as part of security and commercial due diligence.
- PreviewHosted data flow — what enters, what is kept, and for how long. Provided during security due diligence, with the retention table below as its public summary.
- PlannedThreat model. Being written. It will be dated, versioned, and separate about the hosted and self-hosted scopes; until it exists this says so rather than implying a document nobody has.
- PlannedThird-party certification — ISO 27001, SOC 2 or equivalent. None held. There is no audit, no report and no certificate, and no page on this site suggests otherwise.
Available is in the product today. Preview is built and reachable, and still changing shape. Planned is specified and not built — published in advance so it can be judged before it exists.
Who operates which control
The question underneath most of a security review is not "is it secure" but "who does this, me or you". On a self-hosted installation most of the answers are yours, and a page that listed them among what the platform provides would be promising something it does not do.
| Control | Self-hosted | Hosted |
|---|---|---|
| The application, and the analysis it performs | EVIDENT | EVIDENT |
| Authentication and the role model | EVIDENT, on your identity provider | EVIDENT |
| Tenant and project scoping | EVIDENT | EVIDENT |
| Removal of fetched source working copies | Not applicable — nothing is fetched | EVIDENT, and proved by test |
| Where the deployment sits on the network | You | Ximplicity |
| Host hardening and patching | You | Ximplicity |
| Backups and restore | You | Ximplicity |
| Disaster recovery | You | Ximplicity |
| Monitoring and alerting | You | Ximplicity |
| Certificate lifecycle | You | Ximplicity |
| Log and telemetry retention | You, at your collector | Ximplicity, at the collector |
| Incident response for the infrastructure | You | Ximplicity |
| Deciding who may reach the deployment | You | You, through the roles you define |
On a self-hosted installation we support the platform and getting it running. The rows marked you stay with you, and support does not silently become an operational commitment because a page was vague about it.
Reporting a vulnerability
Write to info@ximplicity.es with enough detail to reproduce it. If you would rather not send details over email first, say so and we will arrange something.
What you can expect: an acknowledgement within 2 business days, an initial triage within 5, and while an issue is open and confirmed an update at least every 10.
We do not publish a fix deadline. Committing to a remediation window for a defect nobody has seen is a promise made in advance of the facts, and it is the promise most often broken. What we will do is tell you what we found, what we are doing and when that changes.
Please give us a reasonable opportunity to fix an issue before describing it publicly. We will not take legal action against somebody who reports in good faith, does not access or modify other people’s data, and does not degrade the service.
When a fix gets an advisory
Security corrections are recorded in the changelog, in full, including the uncomfortable ones. Above a threshold they also get a structured advisory, so a reader can tell whether they were affected and what to do.
That threshold, written down so it is a rule rather than a judgement made under pressure: a vulnerability in a released version involving an authentication or authorisation bypass, cross-tenant access, unauthorised exposure of customer data, remote code execution, a credential or secret compromise, High or Critical severity, known exploitation, or any issue requiring an action from you.
An issue that never reached a released version needs no advisory. It was never anybody’s exposure.
The index is at /advisories/.