Security at Codnov
This page lists the security controls we have in place today. Each one is written so that it can be checked against our configuration rather than taken on trust. If you are running a vendor review and need evidence for a specific control, ask and we will show you.
Encryption in transit
codnov.ai and api.codnov.ai are served over HTTPS only. Plain HTTP is redirected, and both domains send HSTS with includeSubDomains and preload. Connections negotiate TLS 1.3 where the client supports it and TLS 1.2 otherwise; TLS 1.1 and 1.0 are refused.
Role-based access control
The Codnov API defines four roles — CEO, admin, staff and client — enforced through a shared authorisation dependency rather than ad-hoc per-endpoint checks. Client accounts are excluded from staff and administrative endpoints and see only the records assigned to them.
Audit logging
Create, update and delete operations on core business records — projects, tasks, deals, clients, payments, subscriptions, users and organisations — are written to an audit log. Each entry records a server-side timestamp, the acting user where an authenticated actor is known, the entity affected and a diff of what changed. Entries are readable only through an endpoint restricted to administrator roles.
Dependency and code scanning
Dependabot raises grouped dependency-update pull requests against the Codnov web and API repositories, and GitHub security advisories are enabled on both. The build pipeline also runs automated secret scanning and static analysis of the Python codebase.
Multi-tenant architecture
Codnov runs as a single multi-tenant application. Clients share the application and database rather than receiving dedicated infrastructure. Records carry an organisation identifier and queries are scoped automatically to the requesting client's organisation.
Incident response
We maintain a written incident response playbook covering severity classification with defined response targets, and a fixed sequence of acknowledgement, investigation, mitigation, communication, resolution and post-mortem. Disaster recovery is documented alongside it.
Practices outside the product
Controls that live in how we work rather than in the application.
Two-factor authentication is required for every member of the GitHub organisations that hold Codnov's source code.
Codnov accounts support TOTP two-factor authentication with encrypted secrets and single-use backup codes.
Application changes are developed and merged as pull requests, with full commit history retained.
Users can permanently delete their account and its personal data from within the product.
Operational runbooks for incident response and disaster recovery are maintained in the same repository as the code they describe.
Report a vulnerability
If you have found a security issue in Codnov, email us with enough detail for us to reproduce it. We will confirm we have received the report and tell you what we are doing about it. We do not currently run a bug bounty programme.