[Feature]: Add security CI scanners (zizmor, gitleaks, bandit, pip-audit)

[timzsu]

Component

Other

Motivation

FlowMesh currently has no automated security scanning in CI. The runtime is a multi-tenant service fabric that handles user workflows, persisted artifacts, secrets, and downstream worker traffic — exactly the surface where a missed CVE, leaked secret, or weak crypto choice has user-visible consequences.

Four orthogonal classes of security finding cover the codebase + pipeline:

1. CI workflow misconfigurations (overly broad token permissions, unpinned actions, command-injection vectors, credential persistence) — caught by zizmor (docs).
2. Committed secrets (private keys, API tokens, credentials accidentally added to a commit) — caught by gitleaks.
3. Insecure source-code patterns (weak hashes, tarfile.extractall without filters, jinja2 with autoescape disabled, eval/exec, etc.) — caught by bandit (docs).
4. Dependency CVEs (transitive packages with published advisories) — caught by pip-audit against the resolved lockfile.

Each tool is independent; nothing covers more than one of these layers. A complete security CI runs all four.

Proposed solution

Each aspect lands as its own PR, independently reviewable + revertible:

• zizmor (chore: add zizmor security audit; harden existing workflow permissions #5) — adds the zizmor job in .github/workflows/security.yml; hardens existing workflows to land clean (least-privilege permissions:, persist-credentials: false, SHA-pinned uses:). No rule overrides.
• gitleaks (chore: add gitleaks (CI job + pre-commit hook) #9) — adds the gitleaks CI job (full-history scan via fetch-depth: 0) and a SHA-pinned pre-commit hook so secrets are caught locally before they reach a remote.
• bandit — Python source security audit, run with no severity / confidence threshold so every finding gets classified once: source-level fix, project-skip in [tool.bandit] with rationale, or per-line # nosec BXXX with rationale at the call site.
  • Bandit CI job + source-level fixes for every High/Medium finding + documented [tool.bandit] skips (chore: add bandit Python source security audit #10).
  • Migrate the SFT / DPO / PPO distributed launchers to in-process torch.distributed.run.main and deepspeed.launcher.runner.main; swap B404 ↔ B603 in the bandit skip list so every subprocess call site has a per-line written rationale instead of a blanket skip (refactor: in-process torchrun + DeepSpeed launchers; fix multi-GPU SFT/DPO/PPO spawn #12).
• pip-audit (chore: add pip-audit dependency CVE scan #11) — adds the pip-audit job against each generated requirements file. Direct deps with a clean upgrade path are bumped; transformers 4.57 ↔ vllm/vllm-omni 0.18 are held together (5.x / 0.19+ lines not yet mutually compatible) and the resulting advisories — plus a handful of transitive caps (pillow via gradio, lxml via crawl4ai, gradio via vllm-omni, unmaintained diskcache) — are silenced via --ignore-vuln with a written upgrade-blocker for each in AGENTS.md.

Alternatives considered

• trufflehog (vs gitleaks) — its credential-verification feature suits incident response; for pre-merge prevention, gitleaks's pattern detection is faster with fewer false positives.
• CodeQL (vs bandit) — deeper semantic analysis, but GitHub-specific, much slower, and noisier. Bandit covers the "dangerous code" patterns we care about and runs anywhere.
• safety (vs pip-audit) — uses the PyUp database (paid for current data); pip-audit is PyPA-official and queries the canonical OSV database, fully open.

Additional context

No response

Before submitting

• I have searched existing issues and confirmed this is not a duplicate.

[kaiitunnz]

@timzsu Making separate PRs for each workflow and fixing the issues being raised in the corresponding PRs sounds good. There will be merge conflicts, but we can resolve them later. Let me know if you need any help in fixing the vulnerabilities found.