Governed Vulnerability Exception Workflow with Aikido and Kestra

id: aikido-security-exception-approval
namespace: company.security

inputs:
  - id: issue_group_id
    type: STRING
    defaults: "5004"
    description: Aikido issue group the requester wants suppressed.

  - id: requester
    type: STRING
    defaults: dev@acme.io
    description: Who is asking for the exception. Recorded in the Aikido snooze
      reason so the suppression is attributable.

  - id: justification
    type: STRING
    defaults: Not exploitable in our deployment, compensating WAF rule in place.
    description: Why the requester believes this finding can wait.

  - id: requested_days
    type: INT
    defaults: 90
    description: How long the exception is requested for. Policy caps this per severity.

variables:
  api_base: https://app.aikido.dev
  token_url: https://app.aikido.dev/api/oauth/token
  max_days_high: 30
  max_days_medium: 90

tasks:
  - id: authenticate
    type: io.kestra.plugin.core.http.Request
    description: Obtain a bearer token for the Aikido public API.
    uri: "{{ vars.token_url }}"
    method: POST
    contentType: application/json
    body: '{"grant_type": "client_credentials"}'
    options:
      auth:
        type: BASIC
        username: "{{ secret('AIKIDO_CLIENT_ID') }}"
        password: "{{ secret('AIKIDO_CLIENT_SECRET') }}"
      timeout:
        connectTimeout: PT10S
        readIdleTimeout: PT30S
    retry:
      type: constant
      interval: PT5S
      maxAttempts: 3

  - id: issue_detail
    type: io.kestra.plugin.core.http.Request
    description: Read the finding so policy is evaluated against Aikido's own data
      rather than the requester's description of it.
    uri: "{{ vars.api_base }}/api/public/v1/issues/{{ inputs.issue_group_id }}"
    method: GET
    headers:
      Authorization: "Bearer {{ fromJson(outputs.authenticate.body).access_token }}"
    options:
      timeout:
        connectTimeout: PT10S
        readIdleTimeout: PT30S

  - id: policy_check
    type: io.kestra.plugin.core.debug.Return
    description: Decide whether this finding is even eligible for an exception, and
      cap the duration by severity.
    format: |
      {{
        {
          "severity": fromJson(outputs.issue_detail.body).severity ?? 'low',
          "score": fromJson(outputs.issue_detail.body).severity_score ?? 0,
          "reachability": fromJson(outputs.issue_detail.body).reachability_status ?? 'unknown',
          "exploitability": fromJson(outputs.issue_detail.body).exploitability ?? 'no_known_exploit',
          "repo": fromJson(outputs.issue_detail.body).code_repo_name ?? 'unknown',
          "title": fromJson(outputs.issue_detail.body).title ?? 'unknown finding',
          "eligible": (
            (fromJson(outputs.issue_detail.body).exploitability ?? 'no_known_exploit') != 'actively_exploited'
            and (fromJson(outputs.issue_detail.body).severity ?? 'low') != 'critical'
          ),
          "granted_days": (
            (fromJson(outputs.issue_detail.body).severity ?? 'low') == 'high'
          ) ? min(inputs.requested_days, vars.max_days_high) : min(inputs.requested_days, vars.max_days_medium)
        } | toJson
      }}

  - id: eligibility
    type: io.kestra.plugin.core.flow.If
    description: An actively exploited or critical finding is refused before it ever
      reaches a human, so nobody can approve it by accident.
    condition: "{{ fromJson(outputs.policy_check.value).eligible }}"
    else:
      - id: auto_denied
        type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
        url: "{{ secret('SLACK_WEBHOOK') }}"
        payload: |
          {
            "text": "Exception request auto-denied by policy",
            "blocks": [
              {"type": "header", "text": {"type": "plain_text", "text": "Exception denied by policy"}},
              {"type": "section", "text": {"type": "mrkdwn", "text": "*Requester* {{ inputs.requester }}\n*Finding* {{ fromJson(outputs.policy_check.value).title }}\n*Repository* {{ fromJson(outputs.policy_check.value).repo }}"}},
              {"type": "section", "text": {"type": "mrkdwn", "text": "Policy refuses exceptions for critical or actively exploited findings. Severity is {{ fromJson(outputs.policy_check.value).severity }} and exploitability is {{ fromJson(outputs.policy_check.value).exploitability }}. Remediate instead, or escalate to the security lead out of band."}}
            ]
          }

    then:
      - id: security_review
        type: io.kestra.plugin.ee.flow.HumanTask
        description: Route the request to the security group. Only a member of that
          group can grant the exception.
        assignment:
          groups:
            - security-approvers
        pauseDuration: P3D
        behavior: FAIL
        onResume:
          - id: decision
            type: SELECT
            values:
              - approve
              - deny
            defaults: deny
            description: Grant or refuse the exception.
          - id: reviewer_note
            type: STRING
            defaults: ""
            description: Reviewer rationale, stored alongside the suppression in Aikido.

      - id: apply_decision
        type: io.kestra.plugin.core.flow.If
        condition: "{{ (outputs.security_review.onResume is defined) and
          outputs.security_review.onResume.decision == 'approve' }}"
        else:
          - id: notify_denied
            type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
            url: "{{ secret('SLACK_WEBHOOK') }}"
            payload: |
              {
                "text": "Exception request for {{ fromJson(outputs.policy_check.value).title }} was denied by security review. Reviewer note: {{ outputs.security_review.onResume.reviewer_note ?? 'none given' }}. The finding stays open and on the clock."
              }

        then:
          - id: snooze_with_audit
            type: io.kestra.plugin.aikido.issues.Snooze
            description: Record the exception in Aikido itself, so the justification travels
              with the finding rather than living in a chat thread.
            clientId: "{{ secret('AIKIDO_CLIENT_ID') }}"
            clientSecret: "{{ secret('AIKIDO_CLIENT_SECRET') }}"
            issueGroupId: "{{ inputs.issue_group_id }}"
            until: "{{ now() | dateAdd(fromJson(outputs.policy_check.value).granted_days,
              'DAYS') }}"
            reason: "Exception granted via Kestra execution {{ execution.id }}. Requested by
              {{ inputs.requester }}: {{ inputs.justification }} Reviewer note:
              {{ outputs.security_review.onResume.reviewer_note ?? 'none given'
              }} Granted for {{
              fromJson(outputs.policy_check.value).granted_days }} days
              (requested {{ inputs.requested_days }})."

          - id: schedule_recheck
            type: io.kestra.plugin.core.flow.Subflow
            description: Hand the expiry to a follow-up flow so the exception is revisited
              on purpose instead of silently lapsing.
            namespace: company.security
            flowId: aikido-reachability-gated-triage
            wait: false
            inputs:
              issue_group_id: "{{ inputs.issue_group_id }}"
            labels:
              exception_expiry: "{{ now() |
                dateAdd(fromJson(outputs.policy_check.value).granted_days,
                'DAYS') | date('yyyy-MM-dd') }}"
              granted_to: "{{ inputs.requester }}"

          - id: notify_granted
            type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
            url: "{{ secret('SLACK_WEBHOOK') }}"
            payload: |
              {
                "text": "Security exception granted",
                "blocks": [
                  {"type": "header", "text": {"type": "plain_text", "text": "Exception granted"}},
                  {"type": "section", "fields": [
                    {"type": "mrkdwn", "text": "*Finding*\n{{ fromJson(outputs.policy_check.value).title }}"},
                    {"type": "mrkdwn", "text": "*Repository*\n{{ fromJson(outputs.policy_check.value).repo }}"},
                    {"type": "mrkdwn", "text": "*Requested by*\n{{ inputs.requester }}"},
                    {"type": "mrkdwn", "text": "*Granted for*\n{{ fromJson(outputs.policy_check.value).granted_days }} days of {{ inputs.requested_days }} requested"}
                  ]},
                  {"type": "section", "text": {"type": "mrkdwn", "text": "{{ outputs.snooze_with_audit.snoozedSingleIssuesAmount }} individual issues suppressed. Expiry recorded as an execution label so the recheck is auditable."}}
                ]
              }

triggers:
  - id: exception_requested
    type: io.kestra.plugin.core.trigger.Webhook
    description: A developer portal, a Slack shortcut, or a Backstage action posts
      the exception request here.
    key: "{{ secret('EXCEPTION_WEBHOOK_KEY') }}"

errors:
  - id: request_failed
    type: io.kestra.plugin.slack.notifications.SlackIncomingWebhook
    url: "{{ secret('SLACK_WEBHOOK') }}"
    payload: |
      {
        "text": ":warning: Exception request from {{ inputs.requester }} for issue group {{ inputs.issue_group_id }} could not be processed. The finding was NOT suppressed and remains open. Execution {{ execution.id }}."
      }

outputs:
  - id: granted_days
    type: INT
    value: "{{ fromJson(outputs.policy_check.value).granted_days }}"

  - id: eligible
    type: BOOL
    value: "{{ fromJson(outputs.policy_check.value).eligible }}"

Every security team has an exception process, and in most places it is a chat message that ends with someone clicking ignore. The justification is lost, the expiry is never set, and nobody can say later who approved what. This blueprint replaces that with a governed path. A developer submits a request through a webhook, policy is evaluated against Aikido's own data rather than the requester's summary, anything critical or actively exploited is refused before a human ever sees it, and the remaining requests go to a named security group for approval. When granted, the exception is written back into Aikido as a snooze whose reason carries the requester, the justification, the reviewer note, and the Kestra execution id, with a duration capped by severity rather than by whatever was asked for.

How it works

The exception_requested trigger (io.kestra.plugin.core.trigger.Webhook) accepts the request from a developer portal, a Backstage action, or a Slack shortcut, guarded by a shared key.
The authenticate and issue_detail tasks fetch the finding from the Aikido public API, so severity, reachability, and exploitability come from the scanner and not from the request form.
The policy_check task (io.kestra.plugin.core.debug.Return) computes eligibility and the granted duration in one place. High severity findings are capped at thirty days and medium at ninety, and the requested duration is never exceeded.
The eligibility task (io.kestra.plugin.core.flow.If) refuses critical and actively exploited findings automatically. This matters: a reviewer under time pressure cannot approve something the policy forbids, because the request never reaches them.
The security_review task (io.kestra.plugin.ee.flow.HumanTask) assigns the decision to the security-approvers group with a three day expiry. Unlike a generic pause, only a member of that group can resume it, so the approval is genuinely attributable.
On approval, snooze_with_audit (io.kestra.plugin.aikido.issues.Snooze) writes the suppression into Aikido with the full justification chain in the reason field, and reports how many individual issues the group-level snooze covered.
The schedule_recheck task launches the reachability triage flow with the expiry date attached as an execution label, so the exception is revisited deliberately rather than lapsing unnoticed.

What you get

An exception process where the justification lives on the finding in Aikido, not in a chat thread.
Hard policy limits that cannot be approved around, enforced before human review.
Duration capped by severity, so a ninety day request on a high severity finding becomes thirty.
Approval restricted to a named group through Enterprise human tasks, with the approver recorded.
An automatic follow-up so a granted exception has an owner and an end date.

Who it's for

Security teams formalising an exception process that currently runs on goodwill.
Platform teams offering self-service to developers without handing out the ignore button.
Regulated organisations that must evidence who approved each accepted risk and for how long.

Why orchestrate this with Kestra

An exception workflow is mostly governance, and governance is exactly what a script cannot provide. Kestra contributes the webhook entry point, a policy branch that runs before any human is involved, an Enterprise human task scoped to a named approver group rather than anyone with the link, execution labels that make the expiry queryable, and a permanent record tying the request, the decision, and the resulting API write together. The Aikido snooze reason then carries that same chain, so the audit trail survives even for someone reading Aikido alone.

Prerequisites

Kestra Enterprise Edition, for io.kestra.plugin.ee.flow.HumanTask and its group assignment.
A security-approvers group defined in your Kestra instance, containing the people allowed to grant exceptions.
An Aikido workspace with API credentials carrying the issues:read and issues:write scopes.
The companion flow aikido-reachability-gated-triage deployed in the same namespace, or change schedule_recheck to point at your own follow-up flow.

Secrets

AIKIDO_CLIENT_ID, AIKIDO_CLIENT_SECRET: OAuth2 credentials for the Aikido public API.
SLACK_WEBHOOK: incoming webhook for decisions and failures.
EXCEPTION_WEBHOOK_KEY: shared secret guarding the webhook trigger.

Quick start

Add the secrets above to your Kestra namespace and create the security-approvers group.
Adjust max_days_high and max_days_medium to your own risk appetite.
Execute the flow manually with the default inputs to see the approval land in the assigned group's task list.
Try it with a critical or actively exploited issue id to confirm the automatic denial path fires before review.
Point your developer portal at the webhook URL with the configured key.

How to extend

Replace the webhook with a Kestra App so developers get a real form with validation instead of posting JSON.
Add a second approver for high severity findings by chaining a second HumanTask assigned to a different group.
Write the decision to your GRC system with io.kestra.plugin.servicenow.Post so the risk register stays in step.
Query executions by the exception_expiry label to build a dashboard of every exception about to lapse.
Require a linked Jira ticket in the request and reject any exception without a remediation plan attached.
Swap the schedule_recheck subflow for a scheduled unsnooze that calls io.kestra.plugin.aikido.issues.Unsnooze on the expiry date, forcing the finding back into the queue.

Govern Security Exception Requests End to End, from Developer Request to an Auditable Aikido Snooze

How it works

What you get

Who it's for

Why orchestrate this with Kestra

Prerequisites

Secrets

Quick start

How to extend

Links

Tasks

Orchestrate with Kestra

Share this Blueprint

Create a Blueprint

New to Kestra?

Govern Security Exception Requests End to End, from Developer Request to an Auditable Aikido Snooze

How it works

What you get

Who it's for

Why orchestrate this with Kestra

Prerequisites

Secrets

Quick start

How to extend

Links

Tasks

Orchestrate with Kestra

Share this Blueprint

Create a Blueprint

More Business Blueprints

Sync Postgres records to Algolia index

Generate and Deliver an AI-Powered Daily News Digest from RSS Feeds via Slack and Email

Sync new users from Postgres to HubSpot

AI Slack Chatbot with Per-User Conversation Memory Using OpenAI and KV Store

Convert Natural Language Prompts to Structured Todoist Tasks with Deepseek AI

Turn Aikido Compliance Reports into a Dated Evidence Pack That Shows Control Drift, Not Just a Score

More Infrastructure Blueprints

Gate Releases on New Licence Risk with an Aikido SBOM Diff Instead of a Full Backlog Scan

Security & Compliance, Detect and Alert on Infrastructure Configuration Drift with Ansible

Ansible Scalability, Deploy Configuration Files to Multiple Servers at Scale

Patch an Actively Exploited CVE Across the Fleet with Ansible, Gated by Human Approval and Verified by Aikido

Automatically Review GitHub Pull Requests with OpenAI GPT-4o and Post Comments

Triage Aikido Vulnerabilities by Reachability, Auto-Snooze Unreachable Findings and Page Only on Real Risk

New to Kestra?