Security automation
Security work, written once.
Run forever. Explains itself.
Skydra turns a security engineer's ad-hoc sequence — pull the inventory, keep the domains, probe the services, flag broken TLS, run it nightly — into a workflow you can read, run, and audit. Attack surface management, cloud posture, and continuous testing on one engine.
- Nine cloud providers
- 250+ security detectors
- Observable, reproducible runs
- Scope-safe by default
What Skydra does
Three jobs, one workflow engine.
Every capability composes from the same action catalog. Add a step, wire its input, run it. Nothing is hard-coded for a single use case.
Attack surface management
Discover and track external-facing hosts, services, certificates, DNS records, cloud buckets, and exposed admin interfaces. Deduplicated, scoped, and explainable.
Learn moreMulti-cloud security posture
Assess AWS, Azure, GCP, and six more clouds from the outside and the inside. From misconfigured storage to IAM paths that lead to privilege escalation.
Learn moreContinuous security testing
Schedule the sweeps you repeat. Replace cron and shell scripts with a workflow engine that retries, deduplicates, and keeps the full history.
Learn moreHow it works
A security runbook is a graph of typed steps. A run is one trip through it.
Skydra's execution model is deliberately small: four step kinds, 24 primitives, typed inputs and outputs, and one source of truth per concept. Everything else is a composition.
Actions
One unit of security work: resolve DNS, probe HTTP, audit an AWS account, test a Firebase RTDB for anonymous writes. More than 250 of them ship with the platform.
- Typed inputs and outputs
- Deterministic by default
- Independently scalable
- Scope-checked before dispatch
Runbooks
A graph of actions, nested runbooks, waits, and approvals. Data flows between steps on labelled edges, so you can read what moves without opening the code.
- Versioned, with a canonical published state
- Scheduled or event-triggered
- Callable from other runbooks
- Changes keep every historical run readable
Runs
Every execution carries status, inputs, outputs, per-step logs, retry history, and failure attribution. If it broke, Skydra tells you which step and what data went in.
- Per-step observability
- Resume from the failed step
- Durable retries with backoff and jitter
- Fan-out at hundreds of thousands of items
The question Skydra answers is not can this be automated. It is can this automation be read, re-run, and trusted next quarter when nobody who wrote it is still here.
What makes it different
Four properties the industry treats as optional.
Scope-safe by default
Probing actions refuse to run until the workspace declares what Skydra is allowed to touch. Legal authorization, workspace scope, egress safety, and intrusive approval are separate controls, and all four must pass. "The URL exists on the internet" is never permission.
Evidence over count
A finding needs a target-specific signal that establishes the unsafe condition. Public identifiers, soft-404s, product banners, and public-by-design keys stay as leads unless a stronger check proves impact. Severity reflects demonstrated reach, not a product's theoretical worst case.
Observable at every level
Every step records its inputs, outputs, logs, timings, and retries. A failed sweep says which step, what the error was, and what data went in. The dashboard surfaces the one failure that produces no error — a schedule that quietly stopped firing.
Credentials never leave the vault
Third-party credential plaintext never enters a runbook graph or a routine API response. Sealed persistence, one-time grants, short-lived presigned capabilities. The console carries no database credential and no AWS key.
Breadth
Coverage you can audit, not just claim.
Every detector is a file in the public action catalog. Nine cloud providers, 250+ detectors, from external-facing probes to deep inside-account posture audits.
AWS, Azure, GCP, plus Alibaba, Huawei, IBM, OCI, Tencent, DigitalOcean, Linode, Hetzner, Scaleway, Vultr, OVH, Yandex
From cloud account audits to DNS hygiene, container registries, CI/CD pipelines, web application vulnerabilities, and supply chain checks
Every input and output carries meaning — Domain, URL, CIDR, port, cloud account, severity, CVE — so wiring steps rejects nonsense at compose time
Data shaping, filtering, deduplication, and extraction live inside steps as composable primitives — not as more queued jobs
Start with a runbook that already works.
Clone a starter runbook, point it at your scope, and watch each step execute. The empty state of a security product should not be a blank screen with a plus button.