Security posture that is checked continuously, not quarterly
Cloud, cluster, image and pipeline configuration measured against policy every hour, with findings ranked by whether they are actually reachable and routed to whoever can fix them.
What is Security?
DevOpsArk security is the module that continuously evaluates cloud, Kubernetes, container and pipeline configuration against security policy, prioritises findings by real-world exposure, and routes each one to the team that owns the affected resource.
What Security is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- The security review is a point-in-time exercise, and the environment changes daily.
- The findings list has 4,000 items and no ordering that reflects real risk.
- A finding lands in a security team queue with no owner and no path to a fix.
- Policy exists in a document, so compliance depends on people remembering it.
- Nobody can distinguish a critical vulnerability in a reachable service from the same vulnerability in a container that has no network path.
Security evaluates the live inventory (cloud accounts, clusters, workloads, images, pipelines and identities) against a policy set that starts from recognised baselines such as the CIS benchmarks and Kubernetes pod security standards, and that you extend with your own rules. Findings are not returned as an undifferentiated list: each one is scored by exposure, meaning whether the affected resource is internet-reachable, whether the vulnerable code path is actually loaded, whether the workload holds credentials, and what data it can reach. That ordering makes the top of the list genuinely the top. Every finding is attributed to the owning team through the application catalogue and carries the specific change that resolves it, so it becomes a work item rather than a notification. Policy can also be enforced earlier (at build, at admission, or at deploy), so the same rule that reports a violation can prevent the next one.
What Security does
The 7 capabilities that make up Security.
Continuous posture evaluation
Cloud, cluster, workload, image and pipeline configuration checked against policy continuously rather than during an audit.
Exposure-based prioritisation
Findings ranked by network reachability, code-path loading, credential access and data sensitivity, not by CVSS alone.
Ownership routing
Each finding is attributed to the team that owns the resource, with the specific remediation attached.
Policy enforcement points
The same rule can report at runtime, fail a build, or block an admission request, so reporting turns into prevention.
Baseline frameworks
CIS benchmarks, Kubernetes pod security standards and common regulatory control mappings, extensible with your own policy.
Drift from baseline
A resource that was compliant and stopped being compliant is reported as a change, with what changed and when.
Evidence for audit
Control status over time, exportable, so an audit is a report rather than a project.
How Security fits together
Outcomes
- Security posture reflects today rather than the last review.
- The top of the findings list is worth working from.
- Findings reach the person who can fix them with the fix already stated.
- A rule that catches a problem can be promoted to prevent the next one.
- Audit evidence is produced from continuous data instead of assembled by hand.
Using Security, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Connect the estate
Cloud accounts, clusters, registries and Git providers are attached.
- 2Select baselines
Start from CIS and pod security standards, then add your own policy.
- 3Evaluate continuously
Configuration is checked against policy on a continuous cycle.
- 4Score by exposure
Findings are ordered by reachability, loading, credentials and data access.
- 5Route and remediate
Owners receive findings with the specific change required.
- 6Promote to prevention
Clean rules are moved to build or admission enforcement.
Where teams apply Security
Prioritise a large findings backlog
Rank by real exposure so the work at the top of the list is the work that reduces risk.
Enforce a cluster baseline
Move a reported rule to an admission control rule once the estate is clean.
Evidence controls continuously
Export control status over time rather than reconstructing it for each audit.
Receive actionable findings
Get the specific configuration change for your service instead of a generic advisory.
What Security works with
Named integrations link to their own page. The rest are supported runtimes and formats.
Security: frequently asked questions
The 8 questions teams ask most often before adopting Security.
DevSecOps is the practice of building security verification into the delivery process rather than applying it as a separate review stage. In practical terms it means policy is checked at build, at admission and at runtime, and findings reach the engineers who own the affected code and configuration.
By exposure rather than severity score alone. A finding is ranked higher when the resource is internet-reachable, the vulnerable code path is actually loaded, the workload holds credentials, or it can reach sensitive data. This usually reorders a list dramatically compared with sorting by CVSS.
CIS benchmarks for cloud providers and Kubernetes, Kubernetes pod security standards, and mappings to common regulatory control sets. Your own policies can be added alongside them.
Yes. The same policy can report at runtime, fail a build, or reject an admission request. Teams generally start in report mode, clean the estate and then promote the rule to enforcement.
Through the ownership recorded against each service in the application catalogue, which is derived from live infrastructure. The finding arrives with the resource, the owning team and the specific change that resolves it.
Yes. AWS, Azure and Google Cloud account configuration (identity, network, storage, encryption and logging) is evaluated alongside cluster and workload configuration in the same policy engine.
Drift is a resource that satisfied policy and stopped satisfying it, usually because of a manual change. DevOpsArk reports it as a change event with what changed and when, rather than as a new finding with no history.
Control status is recorded continuously, so evidence for a period is exported rather than reconstructed. The same data shows when a control was not satisfied and for how long, which is usually the question that follows.
See Security against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.