How we secure the platform itself
A platform that reads your whole estate should be able to describe its own controls without a sales call. This page is that description.
How is DevOpsArk secured?
How DevOpsArk secures its own platform: least-privilege revocable access, agentless by default, encryption in transit and at rest, and public disclosure.
The least access that does the job
- Agentless by default: nothing runs inside your clusters unless you opt in.
- Read-only credentials cover inventory, monitoring, cost and security posture in full.
- Write access is a separate grant, scoped per system, per namespace and per action type.
- Every credential is one you create in your own system and can delete without our involvement.
- No standing production access internally; elevation is time-bound with a recorded justification.
- Every privileged action, internal or agent-initiated, is written to an audit trail.
What we hold, and for how long
| Data | Purpose | Retention |
|---|---|---|
| Resource inventory and configuration | Inventory, posture evaluation, dependency mapping | Life of the connection, plus your configured history window |
| Metrics | Monitoring, baselining, capacity and cost attribution | Configurable per resolution; downsampled beyond the hot window |
| Logs you route to us | Search, pattern analysis, correlation | Configurable per tier and per class |
| Deployment and pipeline history | Provenance, correlation, delivery metrics | Configurable; audit classes retained separately |
| Customer credentials | Connecting to your systems | Until you revoke them; held in a dedicated secret store with read audit |
| Application data | Not collected | Not applicable |
Platform security controls
Infrastructure and data
- TLS 1.2 or higher for all traffic in transit
- Encryption at rest for all stored telemetry and configuration
- Customer credentials in a dedicated store with separate access control and read audit
- Tenant isolation enforced at the data layer, not only in the application
- Regional data residency selected at onboarding
- Backups with tested restore, in a separate account and region
Development and operations
- Dependency, image and infrastructure-as-code scanning on every build
- Signed images, deployed by digest, verified at admission
- Peer review required; segregation of duties on production releases
- Time-bound elevation with recorded justification for production access
- Continuous posture evaluation against our own baseline
- Independent penetration testing on an annual cycle
Reporting a vulnerability
Email security@devopsark.ai with enough detail to reproduce the issue. Please do not test against other customers environments, and please give us a reasonable window before publishing.
We acknowledge within one working day and provide an assessment within five. Where a fix is required, we will tell you the timeline and let you know when it ships. Reporters are credited in the advisory unless they prefer otherwise.
- Acknowledgement within one working day
- Assessment within five working days
- No legal action for good-faith research within these terms
- Credit in the advisory, unless you prefer anonymity
- Notification to affected customers where a fix requires action from them
Security questions
Read-only credentials are enough for inventory, monitoring, cost attribution and security posture. Write access is a separate grant, scoped per system and per action type, needed only for deployment, provisioning or remediation. Every credential is one you create and can delete.
Not by default. Connection is through the Kubernetes API. An optional in-cluster component exists only for higher-frequency metric sampling, and it is opt-in.
Operational telemetry: resource inventory and configuration, metrics, events, deployment history, the logs you route to us, and access and policy configuration. Application data in your databases, persistent volumes and object storage is not read.
Yes. TLS 1.2 or higher in transit, and encryption at rest for all stored telemetry and configuration. Customer credentials are held in a dedicated secret store with separate access controls and a full read audit.
In the region you select at onboarding. Managed clusters provisioned through DMK8S run in your own cloud account, so workloads and application data never leave your governance boundary.
No. Customer environment data is used to answer that customer questions and build that customer baselines. It is not used as training data and is not shared between customers.
SOC 2 Type II and ISO 27001. Reports are available under NDA through your account contact.
Email security@devopsark.ai with enough detail to reproduce. We acknowledge within one working day, provide an assessment within five, and will credit you in the advisory unless you prefer otherwise. Please do not test against other customers environments.
Through the same model we sell: no standing production access, time-bound elevation with a recorded justification and approver, and a unified audit trail of privileged action. Access reviews are driven by actual usage rather than a list of grants.
Telemetry and configuration are deleted on request, and otherwise within the retention period stated in your agreement. Your clusters, images and generated container definitions are yours and are unaffected.
Need the reports for a vendor review?
SOC 2 Type II and ISO 27001 reports, subprocessor lists and completed questionnaires are available under NDA.