Describe the feature
Refactor the GitHub Actions workflow "Security Scanners" (.github/workflows/security-scanners.yml) so that it delegates as much as possible to mise tasks instead of manually installing tools and running commands in the workflow.
Today the workflow has per-job steps that:
- Install tools manually (e.g.
curl for gitleaks/grype, pip install for bandit/semgrep/checkov)
- Pin versions in the workflow (e.g.
GITLEAKS_VERSION, requirements.txt with specific versions)
- Duplicate run logic that already exists in
mise.toml (e.g. security:bandit, security:semgrep, security:gitleaks, security:checkov, security:grype)
The goal is to have the workflow: install mise, optionally install tools via mise, then run the appropriate mise run security:* tasks (or equivalent) so that scanner versions and invocation stay defined in one place (mise.toml).
Use Case
- Single source of truth: Scanner versions and CLI invocations are already in
mise.toml. When we bump a version or change flags (e.g. semgrep exclusions), we have to change both mise.toml and the workflow. That’s error-prone and causes drift.
- Consistency:
mise run security locally should mirror what CI runs. Today the workflow re-implements install + run steps, so behavior can diverge.
- Maintainability: Adding or changing a scanner (e.g. new tool, new SARIF output) should ideally mean updating
mise.toml and possibly one or two workflow steps, not large YAML blocks.
Proposed Solution
-
Use mise in CI
- Add an early step in the workflow (or a reusable setup job) that installs mise (e.g. via
curl | sh or actions/setup-mise if available).
- Run
mise install (or equivalent) so tools declared in mise.toml are available.
-
Delegate to mise tasks
- For each scanner that already has a task in
mise.toml (bandit, semgrep, gitleaks, checkov, grype), replace the manual install + run steps with a single step that runs the corresponding task, e.g. mise run security:bandit, and then handles artifacts (SARIF upload, exit code) as today.
- Extend
mise.toml tasks if needed so CI can get SARIF output (e.g. security:bandit:ci or flags that write SARIF to a known path). The workflow would then only need to run the task and upload the artifact.
-
Scanners without a mise task
- For jobs that don’t yet have a task (e.g. ClamAV, SonarQube), leave the current implementation as-is or add a minimal task later that wraps the same commands, so the pattern is consistent.
-
Version pinning
- Keep versions in
mise.toml only. Remove duplicate version env vars and requirements.txt from the workflow where the task is used.
Other Information
- Existing mise tasks:
security:bandit, security:semgrep, security:gitleaks, security:checkov, security:grype (see mise.toml). Some may need to be extended to support SARIF output and paths expected by the CodeQL upload step.
- Jobs like
gitleaks use a baseline and config (.gitleaks.toml, .gitleaks-baseline.json); the task in mise should use the same so local and CI stay aligned.
- Semgrep has many
--exclude-rule flags; keeping them only in mise.toml avoids duplication and keeps the workflow shorter.
Acknowledgements
Describe the feature
Refactor the GitHub Actions workflow "Security Scanners" (
.github/workflows/security-scanners.yml) so that it delegates as much as possible to mise tasks instead of manually installing tools and running commands in the workflow.Today the workflow has per-job steps that:
curlfor gitleaks/grype,pip installfor bandit/semgrep/checkov)GITLEAKS_VERSION,requirements.txtwith specific versions)mise.toml(e.g.security:bandit,security:semgrep,security:gitleaks,security:checkov,security:grype)The goal is to have the workflow: install mise, optionally install tools via mise, then run the appropriate
mise run security:*tasks (or equivalent) so that scanner versions and invocation stay defined in one place (mise.toml).Use Case
mise.toml. When we bump a version or change flags (e.g. semgrep exclusions), we have to change bothmise.tomland the workflow. That’s error-prone and causes drift.mise run securitylocally should mirror what CI runs. Today the workflow re-implements install + run steps, so behavior can diverge.mise.tomland possibly one or two workflow steps, not large YAML blocks.Proposed Solution
Use mise in CI
curl | shoractions/setup-miseif available).mise install(or equivalent) so tools declared inmise.tomlare available.Delegate to mise tasks
mise.toml(bandit, semgrep, gitleaks, checkov, grype), replace the manual install + run steps with a single step that runs the corresponding task, e.g.mise run security:bandit, and then handles artifacts (SARIF upload, exit code) as today.mise.tomltasks if needed so CI can get SARIF output (e.g.security:bandit:cior flags that write SARIF to a known path). The workflow would then only need to run the task and upload the artifact.Scanners without a mise task
Version pinning
mise.tomlonly. Remove duplicate version env vars andrequirements.txtfrom the workflow where the task is used.Other Information
security:bandit,security:semgrep,security:gitleaks,security:checkov,security:grype(seemise.toml). Some may need to be extended to support SARIF output and paths expected by the CodeQL upload step.gitleaksuse a baseline and config (.gitleaks.toml,.gitleaks-baseline.json); the task in mise should use the same so local and CI stay aligned.--exclude-ruleflags; keeping them only inmise.tomlavoids duplication and keeps the workflow shorter.Acknowledgements