New to Kestra?
Use blueprints to kickstart your first workflows.
Scan every push for committed secrets with gitleaks, open a labeled GitHub issue on findings, alert Slack, and fail the run — orchestrated in Kestra.
Secrets committed to git rarely stay secret: keys end up in issue threads, forks, and clone histories even after the file is deleted. This blueprint makes scanning automatic. A webhook fires on push, the repository is checked out into a shared working directory, gitleaks runs inside its official container with --redact so detected values never reach the logs, and a small Python step turns the JSON report into a leak count and the distinct rules that fired. Findings escalate three ways at once — a labeled GitHub issue, a Slack alert, and a failed execution — while a clean scan quietly records itself as proof the check ran.
on_push trigger (io.kestra.plugin.core.trigger.Webhook) exposes a keyed URL for your GitHub push hook or CI to POST to.workspace (io.kestra.plugin.core.flow.WorkingDirectory) opens one shared filesystem for everything that follows, so the scanner sees the clone and the parser sees the report.clone_repository (io.kestra.plugin.git.Clone) checks out {{ inputs.repository }} at {{ inputs.branch }}, authenticating with GITHUB_TOKEN.run_secret_scan (io.kestra.plugin.scripts.shell.Commands on the io.kestra.plugin.scripts.runner.docker.Docker runner, image zricethezav/gitleaks:latest) executes gitleaks detect --redact --report-format json --report-path gitleaks-report.json --exit-code 0: findings land in a redacted JSON file and the task stays green so evaluation happens in the next step.parse_report (io.kestra.plugin.scripts.python.Script on the Process runner) reads the report, and emits leak_count, rules, and rules_summary through Kestra's outputs protocol.check_findings (io.kestra.plugin.core.flow.If) branches on leak_count. Over zero, create_issue (io.kestra.plugin.github.issues.Create) opens an issue labeled security and secrets with the rule list, alert_slack posts the count and rules, and fail_the_run (io.kestra.plugin.core.execution.Fail) turns the execution red. At zero, log_clean records the all-clear.errors block alerts Slack when the scan itself fails, because a broken scanner looks exactly like a clean repository.leak_count and rules as outputs.gitleaks is an excellent scanner, but a scanner nobody runs catches nothing. Kestra supplies the loop around it: an event trigger for the scan, a hermetic Docker runner so the tool version lives in the flow, a branch that separates escalation from the all-clear, retries and execution history for every run, and alert routing into GitHub and Slack from one declarative file. A git hook running gitleaks locally gives developers none of that — it only protects the machines of people who remember to install it.
parse_report to a Docker task runner.repo, or fine-grained Issues: write plus Contents: read).GITHUB_TOKEN: personal access token used both to clone the repository and to open the issue on findings.SECRET_SCAN_WEBHOOK_KEY: key segment guarding the webhook URL — anyone with it can trigger a scan, so treat it as a secret.SLACK_WEBHOOK_URL: Slack incoming webhook URL.repository to the owner/repo you want scanned and branch if it is not main./api/v1/{tenant}/executions/webhook/{namespace}/github-secret-scan-gitleaks-on-push/{SECRET_SCAN_WEBHOOK_KEY}, or trigger the webhook manually.AKIA string) and confirm the issue, the Slack alert, and the failed execution.repository input per call, or fan out with a Loop over a repository list.{{ fromJson(trigger.body).repository.full_name }} and {{ trigger.ref }} for multi-repo setups.create_issue with a pull-request comment or a security ticket in Jira/Linear.gitleaks dir --no-git variants for repositories shipped as artifacts, or schedule the scan nightly with a Schedule trigger as defense in depth.