New to Kestra?
Use blueprints to kickstart your first workflows.
Use Aikido reachability analysis in Kestra to auto-snooze vulnerabilities with no call chain, escalate exploitable reachable code, and keep an audit trail of every suppression.
Most vulnerability backlogs are noise. A scanner flags every CVE in every transitive dependency, and an engineer spends the week proving that ninety percent of them are never actually executed. Aikido already answers that question with reachability analysis, tracing whether application code can reach the vulnerable function at all. This blueprint turns that answer into an automated decision: findings with no call chain and no known exploit are snoozed with a written justification, findings that are reachable or actively exploited page the on-call engineer, and anything ambiguous is queued for a human. The suppression is recorded in Aikido itself, so the audit trail survives long after the execution log rolls off.
on_new_high_severity_issue trigger (io.kestra.plugin.aikido.issues.Trigger) polls Aikido every ten minutes and fires one execution per newly detected issue group scoring 80 or above. On first activation it records a baseline instead of flooding you with the existing backlog.authenticate task (io.kestra.plugin.core.http.Request) performs the OAuth2 client-credentials exchange against /api/oauth/token using basic auth, returning a short-lived bearer token.issue_detail task reads /api/public/v1/issues/{id}, which carries the three fields the gate depends on: reachability_status, exploitability, and severity_score alongside original_cvss_severity_score.reachability task calls /api/public/v1/issues/{id}/reachability for the traced call chains. It runs with options.allowFailed: true so a workspace without the reachability engine degrades to the unknown path instead of failing the flow.classify task (io.kestra.plugin.core.debug.Return) collapses those signals into one JSON verdict object, including how many call chains were returned and the delta between Aikido's re-scored severity and the raw CVSS score.route task (io.kestra.plugin.core.flow.Switch) branches three ways. suppress calls io.kestra.plugin.aikido.issues.Snooze with a written reason and a dated expiry. escalate posts a structured Slack block with the call chain count. review logs the finding for a human.errors block guarantees a failed triage is announced rather than silently dropping a finding on the floor.verdict, reachability_status) that a parent flow or a reporting job can consume.Reachability data is only useful if something acts on it. Aikido exposes the analysis over its API, but deciding what to do with it is a workflow problem: authenticate, correlate several endpoints, branch on the result, write a suppression back with an expiry, and notify the right channel. Kestra gives that logic a declarative home with retries on the token exchange, a graceful degradation path when reachability is unavailable, branch-level task isolation through Switch, and an execution record that shows exactly why a given CVE was suppressed six months ago. Doing the same in a scheduled script means reimplementing OAuth refresh, partial-failure handling, and an audit trail that auditors will actually accept.
issues:read and issues:write scopes.review branch.AIKIDO_CLIENT_ID, AIKIDO_CLIENT_SECRET: OAuth2 client credentials for the Aikido public API.SLACK_WEBHOOK: incoming webhook URL used for escalations and failure notices.vars.api_base and vars.token_url to your Aikido region if you are not on the EU instance. The US, AU, and ME regions use app.us.aikido.dev, app.au.aikido.dev, and app.me.aikido.dev.issue_group_id to confirm authentication and routing before enabling the trigger.escalation_score and the trigger's severityThreshold to your own paging appetite.review branch with io.kestra.plugin.core.flow.Pause so a human resumes the execution with an explicit snooze or escalate decision.escalate branch with io.kestra.plugin.jira.issues.Create and store the ticket key back on the Aikido issue group as a note.suppress branch to also require sla_remediate_by to be more than thirty days out, so nothing close to an SLA breach is ever auto-snoozed.io.kestra.plugin.pagerduty.alerts.Create when the finding is both reachable and actively exploited.