CodeVet Security Measures
Version 1 · Effective October 1, 2026
These Security Measures are incorporated into the CodeVet Labs Subscription Agreement. CodeVet may update them under Section 19.6 of the Standard Terms: on notice, never retroactively, and never in a way that materially decreases CodeVet’s overall obligations during a Subscription Term. Prior versions remain published.
1. Certification status
CodeVet is not SOC 2 certified and holds no third-party security certification or attestation. This document describes controls as implemented.
2. Hosting and tenancy
The Cloud Service is hosted on Amazon Web Services. All customer data is stored in the US East (N. Virginia) region. Customers cannot select a hosting region.
Each customer has a dedicated application tenant with its own identity store, data store, encryption key and application credentials. Where infrastructure is shared between customers, access is scoped per customer and enforced by access policy, so that no customer’s data or derived project context is reachable from another customer’s tenant.
Isolation is logical. CodeVet does not represent that customers are separated by dedicated physical infrastructure.
3. Source code
The Cloud Service does not require access to customer source code repositories, and CodeVet does not access any repository unless the customer expressly enables it.
4. Model inference
All model inference is performed through Amazon Bedrock within CodeVet’s AWS environment. Amazon Web Services, through Amazon Bedrock, is CodeVet’s sole Model Provider. The current list of Model Providers is published at codevet.dev/legal/subprocessors. Inference requests may be processed in the US East (N. Virginia), US East (Ohio) or US West (Oregon) regions. Data at rest remains in US East (N. Virginia).
CodeVet does not use Customer Data, or anything derived from Customer Data, to train, retrain or fine-tune any artificial-intelligence or machine-learning model, and requires each Model Provider processing Customer Data to be contractually prohibited from doing so. Amazon Bedrock does not store model inputs or outputs. Where a subprocessor processes limited service or account data for its own purposes under its own terms, that processing is described in the CodeVet Privacy Policy.
5. Encryption
In transit. TLS is enforced for connections to the Cloud Service and between the Cloud Service and its data stores. Internal transport carrying authentication traffic refuses unencrypted connections.
At rest. All customer data is encrypted at rest using AWS Key Management Service. Third-party credentials a customer provides are additionally encrypted at the application layer under a per-customer key with automatic rotation, and are readable only within that customer’s tenant.
6. Authentication
Each customer has a dedicated user directory. Accounts are provisioned by administrators; self-service signup is disabled by default.
Password requirements are enforced at account creation and at every password change. Account recovery is by verified email only.
Two-factor authentication is required for all production users. The second factor is a single-use one-time code delivered by email, valid for a short period and rate limited.
A customer may elect to have a user’s device remembered for thirty days. Remembered devices are revoked on password reset, on administrative reset, and on any change to the customer’s two-factor setting.
Passwords are stored only as irreversible verifiers, never in a form from which the original value can be recovered. Invitation credentials are single-use, expire after seven days, and require both an invitation link and a separately issued temporary password, which is itself stored only as an irreversible verifier. Password reset tokens are single-use and expire after one hour. Password reset requests do not reveal whether an account exists, and are rate limited.
7. Access control
Application interfaces require an authenticated session token, validated on every request against the customer’s identity store. Unauthenticated access is limited to the minimum set of endpoints needed to sign in, recover an account and report service availability.
Cross-origin access is restricted to each customer’s own domain. No wildcard origin is permitted.
Application components are not directly reachable from the internet. Administrative access to production is restricted to a small number of named individuals, authenticated through federated identity, and logged.
8. Logging and monitoring
Application logs for the customer-facing service are retained for one year. Every other log group has a defined retention period, available on request.
CodeVet maintains an inference audit trail recording metadata only — timestamp, customer, model, token counts, latency, status, and a truncated hash of the request. This trail contains no prompt or generated content.
Separately, CodeVet retains diagnostic records of model requests and responses, which include prompt and generated content, solely to detect, prevent, and remediate abuse, misuse, security incidents, malfunctions, or abnormal performance relating to the AI Features. These records are stored per customer within CodeVet’s AWS environment, are accessible only to personnel with a need to know for those purposes, and are deleted automatically after thirty days. Prompt and generated content are not written to any other log or telemetry store.
Transactional email delivery is recorded by provider reference. One-time codes, temporary credentials and API keys are never written to logs.
CodeVet operates automated alerting on security-relevant and operational conditions affecting the Cloud Service, routed per customer and delivered to monitored channels, so that CodeVet becomes aware of a Security Incident in time to meet the notification window in the Data Protection Addendum.
9. Vulnerability management
Static analysis runs on every change to the main and release branches, covering the application and infrastructure code with an extended security rule set. Dependency, infrastructure-configuration and secret scanning run on the same schedule. Dynamic application security testing runs weekly.
Deployments authenticate through short-lived federated credentials. No long-lived cloud access keys are held in the build system.
A web application firewall is deployed at the content delivery edge for the production service.
Managed threat detection runs continuously across CodeVet’s cloud accounts, with findings routed to the monitored channels described in Section 8.
Administrative actions in CodeVet’s cloud environment are recorded to an audit trail with log-file validation enabled and access to the log store restricted.
10. Backup and recovery
CodeVet-controlled backups and snapshots, including automated backups, manually created and pre-deployment backups, and final snapshots, are retained for no more than thirty-five days. The primary application database has continuous point-in-time recovery with a thirty-five day restore window. For a final snapshot created when a production cluster is deleted, the period runs from cluster deletion.
11. Retention and deletion
Retention periods by data category are:
| Data | Retention |
|---|---|
| Active customer data and project context | For the Subscription Term |
| Application logs, including the inference audit trail | One year |
| Diagnostic records of model requests and responses | 30 days, deleted automatically |
| API gateway and infrastructure provisioning logs | Defined retention period per log group, available on request |
| CodeVet-controlled backups and snapshots | No more than 35 days |
| Authentication tokens, one-time codes, invitations, remembered devices | Expire automatically; see Section 6 |
| Message queue contents | 15 minutes to 14 days depending on queue |
| Access logs | 365 days |
Customer Data deleted from active systems may remain in encrypted, access-restricted backups until those backups expire, and is not accessed for ordinary business purposes. If a backup is restored, applicable deletion is reapplied. CodeVet does not retain a backup or snapshot indefinitely except under a documented legal hold.
Copies of Customer Data held by a subprocessor expire under that subprocessor’s own published retention and backup terms, which may run longer than CodeVet’s own periods. Retention at CodeVet’s transactional email provider is described in the CodeVet Privacy Policy.
Archiving a project stops processing and retains its configuration. Removing a project permanently deletes its configuration.
On termination, CodeVet deletes customer data in accordance with Section 12.4 of the Standard Terms. Deletion covers the primary application database, stored source documents, diagnostic records of model requests and responses, the retrieval index and its underlying stored objects, derived vector representations, and customer-supplied integration credentials and related tenant secrets. Test cases already written into the customer’s own systems are unaffected and are not deleted. Residual copies in backups and at subprocessors expire under the periods described in this Section; if a backup is restored, applicable deletion is reapplied.
12. Incident response
CodeVet notifies affected customers of a security incident affecting their data without undue delay, and in any event within the period stated in the Data Protection Addendum.
13. Subprocessors
CodeVet’s current subprocessors and model providers are published at codevet.dev/legal/subprocessors. Changes are notified in accordance with the Data Protection Addendum.
14. Further information
CodeVet maintains a more detailed description of the controls summarized above, including architecture, tenancy enforcement, key management, network design and monitoring coverage. It is confidential and is provided to Customers and prospective Customers on request under a non-disclosure agreement. Request it from security@codevet.dev.
CodeVet also responds to customer security questionnaires on the same basis.