Security
We handle your code.
That means security
is not optional.
Cordenex processes source code — the most sensitive asset an engineering team has. We built our security practices around that reality from day one, not as an afterthought.
This page describes how we protect your code, your data, and our infrastructure. If you have specific security questions, contact our team directly.
Security principles
Defense in depth
No single security control is considered sufficient. We layer multiple defenses — network isolation, encryption, access controls, monitoring, and code review — so that a failure in one layer does not compromise the system.
Least privilege
Every system, service, and employee has access only to what is strictly necessary for their function. Access is granted on a need-to-know basis and reviewed regularly. No engineer has standing access to production customer data.
Zero trust architecture
We do not trust any network, device, or user by default — even internal ones. Every request is authenticated and authorized independently. Internal services communicate over encrypted channels with mutual TLS.
Secure by default
Security configurations are enabled by default, not opt-in. Encryption is always on. Logging is always active. Insecure options do not exist in our configuration. You do not need to remember to turn security on.
Transparency
We document our security practices publicly. We disclose incidents honestly and promptly. We publish a transparency report annually. If something goes wrong, you will hear it from us first.
Infrastructure
Cloud infrastructure
Production systems run on AWS with VPC isolation. Each service operates in its own subnet with security groups that restrict traffic to the minimum required. No service is directly accessible from the public internet unless explicitly required.
Container isolation
All services are containerized using Docker and orchestrated with Kubernetes. Containers run with read-only file systems, non-root users, and restricted capabilities. Images are scanned for vulnerabilities before deployment.
Network segmentation
Internal networks are segmented by function — compute, storage, management, and monitoring each operate in isolated network zones. Cross-zone traffic is encrypted and logged.
DDoS protection
Traffic passes through rate limiting and DDoS mitigation at the edge. Anomalous traffic patterns trigger automatic blocking. We maintain capacity to absorb large-scale attacks without service degradation.
High availability
Critical services are deployed across multiple availability zones. Databases are replicated with automatic failover. We maintain a recovery time objective of under 4 hours and a recovery point objective of under 1 hour.
Infrastructure as code
All infrastructure is defined in Terraform and version-controlled. No manual changes are made to production. Every infrastructure change goes through code review and automated validation before deployment.
How we secure your code
When Cordenex processes a request, your source code passes through our system briefly. Here is how we protect it at every stage.
Encrypted in transit
All communication between the Cordenex CLI and our servers uses TLS 1.3 with strong cipher suites. Certificate pinning is enforced in the CLI to prevent man-in-the-middle attacks. Connections using older TLS versions are rejected.
Minimal data transmission
The CLI sends only the context needed for the specific request — not your entire codebase. File scanning happens locally on your machine. Only relevant snippets are transmitted. You can inspect exactly what is sent using the --dry-run flag.
Isolated processing
Each request is processed in an isolated container that is created for that request and destroyed afterward. No request shares compute resources with another request. Your code context never co-exists with another customer's data.
No persistent storage
After the response is generated and delivered, the input context and output are deleted from memory. Nothing is written to disk. No logs contain the content of your code. Only operational metadata — timestamp, request type, latency — is retained.
No training use
Your code is never used to train, fine-tune, or evaluate our models. The processing pipeline and the training pipeline are completely separate systems with no data flow between them.
Inspect what gets sent
Encryption
In transit
- TLS 1.3 enforced on all connections
- TLS 1.0 and 1.1 are not supported
- Certificate pinning in the Cordenex CLI
- HSTS enabled on all web endpoints
- Forward secrecy with ECDHE key exchange
- Mutual TLS between internal services
At rest
- AES-256 encryption for all stored data
- Encryption keys managed through AWS KMS
- Automatic key rotation every 90 days
- Database encryption enabled at the storage layer
- Backup encryption with separate key hierarchy
- No unencrypted data at rest anywhere in the system
Access control
Internal access
- No standing access to production systems
- Just-in-time access with automatic expiration
- Every access request requires a documented reason
- All access is logged and audited weekly
- Multi-factor authentication required for all employees
- Hardware security keys required for production access
- Background checks for all team members
Customer access (Enterprise)
- SSO via SAML 2.0 and OIDC
- Role-based access control per team and project
- Configurable session timeouts
- IP allowlisting for API access
- Admin dashboard for user management
- Audit logs exportable to your SIEM
- Automatic deprovisioning via SCIM
Application security
Secure development lifecycle
Every code change goes through peer review with security considerations as a mandatory checklist item. Security-sensitive changes require review from a designated security reviewer.
Dependency management
Dependencies are automatically scanned for known vulnerabilities on every commit. Critical vulnerabilities are patched within 24 hours. We maintain a software bill of materials for all production components.
Static analysis
Automated static analysis runs on every pull request. This includes SAST tools for common vulnerability patterns, linting for security anti-patterns, and secret scanning to prevent accidental credential exposure.
Input validation
All inputs — from CLI commands to API requests — are validated and sanitized before processing. We protect against injection attacks, path traversal, and other input-based vulnerabilities at every entry point.
Rate limiting
API endpoints enforce rate limits per user and per IP address. Aggressive or anomalous request patterns trigger automatic throttling and alerting. Limits are configurable for enterprise customers.
Error handling
Error messages returned to users never contain internal system details, stack traces, or sensitive information. Detailed error information is logged internally for debugging but never exposed externally.
Monitoring and incident response
What we monitor
- Unauthorized access attempts across all services
- Unusual API usage patterns and traffic anomalies
- Failed authentication attempts and brute force indicators
- Configuration changes to production systems
- Network traffic between internal services
- Resource utilization anomalies
- Certificate expiration and TLS configuration drift
Incident response process
Detection
Automated alerts trigger on anomalous activity. On-call engineer acknowledges within 15 minutes.
Assessment
Severity is classified. Customer data impact is evaluated immediately. Containment actions are taken.
Notification
Affected customers are notified within 72 hours with a clear description of what happened and what data was involved.
Remediation
Root cause is identified and fixed. Additional controls are implemented to prevent recurrence.
Post-mortem
A blameless post-mortem is conducted and documented. Findings are shared with the team and, where appropriate, with affected customers.
Testing and audits
Penetration testing
We engage independent security firms to conduct penetration testing at least annually. Tests cover our cloud infrastructure, APIs, CLI tool, and web applications. Critical and high-severity findings are remediated before the next release.
Automated vulnerability scanning
Every deployment triggers automated vulnerability scans across our container images, dependencies, and infrastructure configurations. Known vulnerabilities are flagged and blocked from reaching production.
Code review
All code changes require at least one peer review. Changes to authentication, authorization, encryption, or data handling require review from a designated security-focused engineer.
Access audits
We review all internal access permissions weekly. Unused access is revoked automatically. Quarterly audits verify that access levels align with current roles and responsibilities.
Third-party audits
We undergo external audits as part of our SOC 2 certification process. Audit reports are available to enterprise customers under NDA upon request.
Compliance
| Framework | Status | Details |
|---|---|---|
| SOC 2 Type II | In progress | Audit expected Q3 2026 |
| GDPR | Compliant | DPA available on request |
| CCPA | Compliant | Privacy policy updated |
| HIPAA | Available | Enterprise self-hosted only. BAA available |
| FERPA | Compliant | Education products |
| ISO 27001 | Planned | Targeted 2027 |
Self-hosted enterprise security
For organizations that require maximum control, Cordenex Enterprise can be deployed entirely within your infrastructure. In this configuration, our security responsibilities and yours are clearly defined.
We are responsible for
- Secure, signed container images with no known vulnerabilities
- Regular security patches and updates
- Secure default configurations in all deployment manifests
- Documentation of security hardening options
- Incident response for vulnerabilities in our code
- Security advisories for critical issues
You are responsible for
- Network security and firewall configuration
- Operating system and host security
- Access control to the deployment environment
- Backup and disaster recovery
- Monitoring and log management
- Applying updates and patches we provide
Responsible disclosure
If you discover a security vulnerability in any Cortiqa product, we want to hear about it. We maintain a responsible disclosure program and will work with you to understand and address the issue.
How to report
- Email security@cortiqa.com with a description of the vulnerability
- Include steps to reproduce if possible
- We will acknowledge receipt within 24 hours
- We will provide an initial assessment within 72 hours
- We will keep you informed of our progress toward a fix
- We will credit you publicly (unless you prefer otherwise) once resolved
We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to address it. We will not pursue legal action against researchers who report vulnerabilities in good faith.
Common questions
Can I see exactly what data the CLI sends?
Yes. Use the --dry-run flag on any Cordenex command to see the exact payload that would be sent without actually sending it. You can inspect and verify the data before every request.
Has Cortiqa ever had a security breach?
No. As of the last update of this page, we have not experienced a security breach or unauthorized access to customer data. We publish a transparency report annually.
Can I get a copy of your penetration test report?
Yes. Enterprise customers can request our latest penetration test summary report under NDA. Contact security@cortiqa.com.
Do you have a bug bounty program?
We have a responsible disclosure program. We do not currently offer monetary bounties, but we publicly credit researchers who report valid vulnerabilities (with their permission) and provide Cortiqa product credits.
How quickly do you patch critical vulnerabilities?
Critical vulnerabilities in our code are patched within 24 hours. Critical vulnerabilities in dependencies are patched within 48 hours. We notify affected customers immediately when a patch requires action on their part.
Can enterprise customers run their own security assessments?
Yes. Enterprise customers can conduct their own security assessments, penetration tests, and code audits of the Cordenex deployment within their infrastructure. We ask for advance notice and coordination to avoid triggering automated defenses.
Security is not a feature.
It is how we build everything.
If your security team needs more detail, a call with our engineering team, or access to compliance documentation — reach out. We are happy to answer every question directly.