Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon
Schedule icon

Snyk Container Vulnerability Fixable Threshold Sentinel

Audits Snyk container security scans, isolates fixable high and critical CVEs breaching policy thresholds, and alerts DevSecOps via Slack.

Categories
CoreInfrastructure

Modern cloud applications rely on container images built from open-source base layers like Alpine, Debian, and Ubuntu. Even when an image is scanned and certified clean at build time, new Common Vulnerabilities and Exposures (CVEs) are published continuously. If container images in production registries are not audited continuously, security debt accumulates unnoticed until emergency zero-day patch cycles disrupt operations. Moreover, alerting developers on unfixable upstream vendor bugs leads to alert fatigue. This sentinel audits Snyk container security scans on a daily schedule, isolates fixable critical and high vulnerabilities where patch versions are already available, and alerts DevSecOps teams on Slack with direct project links and remediation steps before release gates block CI/CD pipelines.

How it works

  1. Scheduled triggering: Executes daily at 08:00 UTC via automated cron trigger (0 8 * * *) or runs on-demand via manual execution.
  2. Aggregated issues query: Invokes the Snyk REST API endpoint /v1/org/{org_id}/project/{project_id}/aggregated-issues with severities filtered for critical and high.
  3. Actionability filtering: Inspects the isFixable boolean property on every returned issue, ignoring non-fixable or ignored CVEs to eliminate noise.
  4. Threshold comparison: Evaluates whether total fixable critical vulnerabilities exceed max_critical_fixable_threshold or fixable high vulnerabilities exceed max_high_fixable_threshold.
  5. Conditional alerting: An io.kestra.plugin.core.flow.If flowable checks if the policy was breached and dispatches an incident notification to #devsecops-alerts.
  6. Compliance manifest export: Emits a structured JSON audit payload containing identified CVE identifiers and severity summaries for security compliance registries.

Architecture diagram

flowchart TD
  A[daily_snyk_security_audit Schedule Trigger] --> B[evaluate_snyk_vulnerabilities Python Script]
  B --> C[check_vulnerability_threshold Flowable If]
  C -- Policy Breached --> D[notify_slack_cve_breach Webhook]
  C -- Policy Compliant --> E[log_compliance_status Log]
  D --> E
  E --> F[export_snyk_manifest Return]

What you get

  • Continuous supply chain security auditing focused exclusively on actionable, fixable container CVEs.
  • Elimination of developer alert fatigue by filtering out unfixable upstream distro vulnerabilities.
  • Actionable Slack notifications containing direct permalinks to Snyk project dependency graphs.
  • Structured compliance manifests for tracking container image security posture over time.

Who it's for

  • DevSecOps Engineers enforcing software supply chain standards across container registries.
  • Platform Engineers maintaining Kubernetes deployment admission controllers and release gates.
  • Security Compliance Officers preparing automated audit evidence for SOC2 and ISO 27001 certifications.

Why orchestrate this with Kestra

Snyk scans images during CI/CD builds, but post-deployment vulnerability disclosures require an independent, recurring orchestration engine. Kestra provides automated scheduling, containerized Python execution, encrypted credential management for Snyk API tokens, and native Slack notification plugins. Orchestrating this audit in Kestra bridges the gap between static image analysis and active production supply chain governance.

Use cases

  • Production Base Image Freshness: Detect when base images (e.g. python:3.11-slim or node:18-alpine) have upstream security updates that resolve open vulnerabilities.
  • Pre-Release Deployment Gating: Audit staging container images before promotion to production to prevent CI/CD gate failures.
  • Compliance and Audit Reporting: Generate daily snapshots of container vulnerability compliance across all microservice repositories.

Inputs

Name Type Default Description
snyk_org_id STRING 12345678-abcd-1234-abcd-1234567890ab Snyk organizational UUID containing scanned container projects.
snyk_project_id STRING abcdef12-3456-7890-abcd-ef1234567890 Snyk container target project ID to evaluate for actionable vulnerabilities.
max_critical_fixable_threshold INT 0 Maximum allowable fixable critical vulnerabilities before gating container deployments.
max_high_fixable_threshold INT 5 Maximum allowable fixable high-severity vulnerabilities before alerting security teams.
alert_on_breach BOOL true Whether to dispatch automated Slack security notifications when vulnerability thresholds are breached.

Expected outputs

  • {{ outputs.evaluate_snyk_vulnerabilities.vars.critical_fixable_count }}: Total number of fixable critical-severity vulnerabilities identified.
  • {{ outputs.evaluate_snyk_vulnerabilities.vars.high_fixable_count }}: Total number of fixable high-severity vulnerabilities identified.
  • {{ outputs.evaluate_snyk_vulnerabilities.vars.is_breached }}: Boolean flag indicating whether container vulnerability thresholds were breached.
  • {{ outputs.export_snyk_manifest.value }}: Structured dictionary containing the consolidated security compliance summary.

Prerequisites

  • Outbound HTTPS network access from Kestra execution workers to api.snyk.io.
  • A Snyk API token or service account with read permissions for the target organization and project.
  • A Slack Incoming Webhook URL configured in Kestra secrets.

Secrets

  • SNYK_API_TOKEN: Snyk API token with permissions to query organizational projects and aggregated issues.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to dispatch security alerts.

Quick start

  1. Add SNYK_API_TOKEN and SLACK_WEBHOOK_URL to your Kestra secret storage.
  2. Import this blueprint into your Kestra instance under the company.security namespace.
  3. Update snyk_org_id and snyk_project_id to match your target container repository in Snyk.
  4. Run a manual execution to verify Snyk API connectivity and validate the compliance output format.

Common pitfalls and troubleshooting

  • Service Account Permissions: Ensure the token belongs to an account with at least Viewer permissions on the specified Snyk Organization.
  • Container Project Type: Verify that snyk_project_id corresponds to a Container or Dockerfile project; open-source package projects have different issue schemas.
  • Rate Limiting: Snyk API v1 enforces rate limits per minute; running audits on a scheduled cadence avoids concurrent burst limits.

How to extend

  • Automated Pull Request Creation: Automatically trigger a downstream flow to generate a GitHub pull request upgrading the Dockerfile base image tag.
  • Jira Security Ticket Creation: Create a high-priority security remediation ticket in Jira when a critical fixable CVE remains unpatched for more than 48 hours.
  • Multi-Project Matrix Audit: Loop over an array of container project IDs using io.kestra.plugin.core.flow.ForEach to audit an entire service catalog.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.