Security & trust at OpsCodex

OpsCodex is deployed single-tenant, on-premise, inside your own environment. Your documents and process models are stored only in your environment. They go to an AI model only where you decide — and only into your own network, if you wish. There is no shared, multi-tenant data plane.

Docker Compose on one server

The whole application runs with Docker Compose on one server. A small server is enough for a pilot; the requirements, the backup routine and the update flow are on the evaluation page.

Kubernetes with a Helm chart

The chart installs OpsCodex into one namespace and needs no cluster-wide rights. Every container runs as a non-root user with a fixed UID, on a read-only root filesystem, with all Linux capabilities dropped; the chart is tested with Pod Security restricted enforced on its namespace. PostgreSQL and S3-compatible storage come from your platform, or run as containers in the same namespace — our own database image, which runs without root, and an S3 server under the Apache 2.0 licence. Traffic reaches it through your Ingress or Gateway API.

Role-based access control

Granular roles map to the governance workflow — author, reviewer, approver, administrator, auditor and documentation editor. People see and do exactly what their role allows, and nothing more.

Single sign-on

Sign-in through your identity provider (OIDC, SAML) is in the works. Until then: local accounts with password rules following NIST, lockout after failed attempts and sign-out after inactivity.

Passwords

Password rules follow NIST SP 800-63B-4: at least 15 characters by default — what the standard requires of a password that is the only sign-in factor — with no forced character classes and no forced periodic change. Common and leaked passwords are refused, checked against a list that ships with the product, so the check makes no outbound call. Ten failed sign-ins in a row lock the account for 15 minutes against the address they came from (both adjustable), so a stranger cannot lock out the owner. Passwords are stored one-way hashed (bcrypt); changing one requires the current password and ends existing sessions.

Sessions

Sessions use short-lived, HttpOnly, Secure cookies and end after a period without activity — two hours by default, adjustable by an administrator — which the server checks on every request. Sign-out, deactivation and role changes take effect immediately.

Employee portal

The read-only portal where employees look up approved processes is either open to everyone who reaches it within your network or, with one administrator setting, open to signed-in users only. It shows released versions only — drafts and work in progress are never in it.

Access for AI agents

A read-only endpoint over the Model Context Protocol (MCP) lets AI agents read approved processes, each answer with its revision, approver and release date. It is off until it is switched on in the installation's configuration. Each client needs its own token, which an administrator issues and can revoke; the endpoint has no write operation at all, and every access is logged.

In transit

All traffic is encrypted with modern TLS; weak ciphers are not offered.

At rest

Application secrets — such as AI provider keys — are encrypted with AES-256-GCM, and account passwords are one-way hashed. In an on-premise deployment you hold all key material yourself.

Uploaded files

User-uploaded content is served as a download with MIME-sniffing disabled, so untrusted files cannot execute in the browser.

Governance actions are written to an append-only audit trail. This is enforced in the database, not in application code: a trigger on the audit table rejects every UPDATE and DELETE, and the database role the application runs under has those rights revoked. The application cannot rewrite its own audit history even if it is compromised — only the separate migration role used for schema changes and test teardown can, and that role is never used to serve a request.

To be precise about the boundary: the trigger covers row-level modification and deletion. It does not cover TRUNCATE, and it does not defend against someone with superuser access to your own database server — no application-level control can. Treat the trail as tamper-evident within the application's reach, and pair it with the backup and database-access controls you already run for other systems of record.

When an auditor asks who approved a model and when, the answer is on record: author, reviewer, approver, timestamp, and the export hash of what was released.

Every response carries modern browser security headers — Content-Security-Policy, HTTP Strict Transport Security, clickjacking and MIME-sniffing protections, and a locked-down Permissions-Policy. Request rate-limiting protects authentication and other sensitive endpoints, and dependency and security checks run in continuous integration.

Release gate

A release is published only when its gate has passed: the production setup starts cold on empty volumes and is smoke-tested, every container image is scanned with Trivy — a HIGH or CRITICAL finding for which a fix exists stops the release — and the running application is attacked from outside with OWASP ZAP, where a high-severity finding stops the release as well. The images that ship are the images that were tested; they are not rebuilt afterwards.

Software bill of materials

Every release carries a CycloneDX SBOM for each image, plus one for the full dependency graph, so you can check what you were given against your own vulnerability feeds.

Release rhythm and support

Releases are named after the month they are published, such as 2026.11, and come about once a quarter. Each one receives fixes for high and critical vulnerabilities for nine months after it is published. Patches ship on a monthly patch day; a fix for a critical vulnerability does not wait for it. Nothing updates itself: you decide when an installation moves to a new release.

You own your data

Your content is yours. It is available for export at any time; on termination it can be exported immediately and deleted on request. On-premise, you control destruction directly.

GDPR

The operator is EU-based (Mews Group SAS, France). On-premise, your process data stays in your own infrastructure and your own jurisdiction — it is not transmitted to us, so there is no cross-border transfer on our side to justify.

No third-party tracking

No third-party sharing of personal data, no third-party cookies, and no access to contacts, calendar or other device data.

AI is an optional assist layer: it proposes, a human approves. By default the content of your prompts is not stored; if an administrator switches on the chat history, it stays in your own database. See AI governance for how provider keys, data retention and private or self-hosted inference work.

We assess OpsCodex ourselves against the OWASP Application Security Verification Standard (ASVS) 5.0.0 at level 2. Level 2 includes level 1, so all 253 requirements of both levels are assessed, one by one, against the source code, the tests, the container images and the deployment artefacts of the release. Every requirement that is met names the place in the code, test or configuration that enforces it; every one that is not names the open item that closes it.

What it is not. This is the vendor's own white-box assessment, made with AI-assisted code review and checked by hand. It is not an independent penetration test and not a certification. It is refreshed for every feature release, so it describes the release you install.

Assessed on 29 October 2026, for release 2026.11.

Result per level

Level	Require­ments	Met	Partly	Not met	N/A
Level 1, the baseline	70	42	23	0	5
Level 2, including level 1	253	92	88	11	62

Met holds for every relevant part of OpsCodex; Partly for some of them; N/A means the subject of the requirement does not exist in OpsCodex (for example WebRTC, or an OAuth authorization server). Some requirements depend on the installation (for example TLS at your edge, or multi-factor sign-in at your identity provider); those are judged by what OpsCodex ships and documents, never counted as N/A.

Partly usually means one of two things: the code meets the requirement, but ASVS also asks for a document that does not exist yet; or the requirement is met in most places and not yet in one.

20 items are still open, none of them with high priority. Each one is tracked as a task on our side.

The full assessment — one row per requirement, with the evidence and the detail of each gap — is available to your security team under NDA: [email protected].

A security page that lists only what exists tells you half of what you need. These are the gaps you would otherwise have to find by asking — named here so you can weigh them early rather than late.

Certifications

No ISO 27001, no SOC 2, no TISAX. OpsCodex runs on-premise inside your own certified environment, which is why this has not been a hurdle so far. If a certificate is a must in your procurement, raise it early.

Independent penetration test

None commissioned to date. OpsCodex runs on-premise inside your own perimeter, not as a service on the open internet. That lets your security team, or the testers you already work with, test exactly the installation you run, and we support that directly. On our side: a daily scan of every dependency and of the base images the releases are built on, a weekly static analysis of the code, the container scan and an automated attack from outside on the running application in every release gate, and a regression test that fails the build if the security headers above are dropped. The ASVS self-assessment above is our own and does not replace an independent test.

Data classification and DLP labels

No sensitivity-label or DLP feature. Access is controlled structurally instead: roles, team-scoped permissions, and a hard boundary between internal drafts and the published portal.

Managed key service

Every secret lives in your own environment and we hold none of them — but there is no managed KMS or HSM integration to plug into if that is how your organisation prefers to hold keys.

If you find a gap that neither this list nor the open items of the ASVS self-assessment name, tell us and it goes on the list. A page like this is only worth reading if it is the whole set.

Found a security issue? Please write to [email protected].