Continuous security testing
Replace the half-documented cron jobs with runbooks that explain themselves.
A security team's recurring tests live, almost universally, in a bash script on someone's laptop, a half-documented cron job, or in a person's head. Skydra turns that sequence into a workflow — written once, scheduled, observable, resumable, and auditable long after its author.
- Scheduled or webhook-triggered
- Durable retries and resume
- Per-step observability
- Full execution history
The three failures of ad-hoc automation
Why cron jobs rot.
Every security team has them. Every security team's post-incident write-ups eventually name one of them as the thing that was supposed to catch the issue and silently stopped.
"I can't tell what it does"
A DAG of opaque Lambda functions or a 600-line bash script tells you nothing without reading every line. Skydra's runbook is a graph of typed steps whose data flow is visible — labelled edges show the shape and the count moving between each step.
"I can't tell why it broke"
A Lambda log group with 48 hours of retention is the usual answer, searched by hand after the fact. In Skydra, every step records its input, output, logs, error, retries and attribution — on the run page, forever, with a one-click re-run from the failed step.
"I can't reuse it"
Copy-pasted scripts and ad-hoc rewrites are the norm. Every runbook in Skydra is callable as a step inside another runbook, which is the only honest definition of reuse. A single "resolve and probe hosts" workflow is one runbook; it is used by the nightly ASM sweep and by the cloud posture scan.
What continuous looks like
Four execution guarantees.
Scheduling is the easy part. The harder part is making a scheduled workflow one you still trust next year.
Scheduling is a property of the runbook
No separate scheduling section. The runbook's own triggers tab holds the schedule, the webhook signing secret, and the callable-from-other-runbook flag. Changing when a runbook runs is editing the runbook, which is auditable and versioned.
The scheduler's silent-failure detector
Overdue schedules — the ones that imply a run that should have happened and did not — are surfaced on the dashboard as "schedule health". A scheduler that quietly stopped is the kind of failure a security product exists to catch; it produces no errors and no findings on its own.
Durable retries
Per-step retry policy with attempts, backoff, jitter, retry-on classification, and a circuit breaker. A transient 429 does not fail the sweep; a persistent 500 does, after the configured retries and with the full context visible on the run page.
Resume from where it failed
A sweep that failed at the probe step does not re-run the entire inventory discovery when the operator clicks retry. Just the failed step, with the data that went in, re-executes. The successful steps are preserved; the run continues forward.
A representative schedule
A nightly job you can actually leave running.
triggers:
- schedule: "0 2 * * *" # daily, 02:00 UTC
timezone: "Europe/Warsaw"
inputs:
rootDomains: list<Domain>
cloudAccounts: list<CloudAccount>
steps:
asm:
runbook: external-sweep
with: { rootDomains: inputs.rootDomains }
cloud:
runbook: cloud-posture-scan
with: { accounts: inputs.cloudAccounts }
joined:
refine: >
concat(
asm.output.findings,
cloud.output.findings
)
new_critical:
refine: filter(joined.output, item.firstSeen in current_run && item.severity in ["critical", "high"])
notify:
action: slack.post
condition: new_critical.output ne []
with:
channel: "#security-ops"
summary: templates.nightly_summary.render(new_critical.output)
runUrl: run.urlTheexternal-sweepandcloud-posture-scanrunbooks are the ones from the ASM and cloud posture use cases. One schedule, two callable runbooks, one Slack message, no bash.
State you can read
Collections — the gap between a scalar and a finding.
A continuously-running workflow accumulates data. A typed, durable, deduplicating set of elements — a Collection — is where that data lives, with declared identity rules and first-seen/last-seen/observation-count already modelled. "Hosts seen responding to HTTPS at least once" is a collection; your runbook adds to it and your other runbooks read from it.
Durable, typed, deduplicated
An element is one record of a declared type. The identity rule — whole-value, field-mode, or an expression — decides when two inputs are the same element. Adding duplicates bumps the observation count; it never creates a new row.
"What changed since last time" is a free property
collection.append returns the elements it added. That is literally the set of new values this run observed, which is the question most continuous security workflows exist to answer.
Replace one cron job this week.
Pick the recurring workflow you trust the least and port it. Clone a starter runbook, add your scope, schedule it, and watch it explain itself.