# ci-security.yml — the security gate as a CI step (Module 15).
#
# This is a PROVIDER-NEUTRAL snippet, not a drop-in file. The YAML below uses the widely-shared
# "workflow / job / steps" shape that most hosted and self-hosted CI systems understand (the exact
# top-level keys and runner labels follow whatever host you set up in Module 14). Copy the *steps*
# into the pipeline you already have rather than adding a second, competing workflow.
#
# The contract is the same on every platform:
#   1. check out the code
#   2. install the scanners
#   3. run the gate (security-scan.sh), which exits non-zero on any finding -> the job goes red
#
# Because the real logic lives in security-scan.sh, this file stays tiny and your local run and your
# CI run can never drift apart.

name: security

on: [push, pull_request]   # run on the same events as your Module 14 build/test job

jobs:
  security-scan:
    runs-on: ubuntu-latest   # or your self-hosted runner label (Module 19)
    steps:
      - name: Check out the code
        uses: actions/checkout@v7
        # Secret scanning cares about history. If your tool scans commits (not just the working
        # tree), fetch full history here — e.g. set `with: { fetch-depth: 0 }`.

      - name: Set up Python
        uses: actions/setup-python@v6
        with:
          python-version: "3.x"

      - name: Install scanners
        run: pip install pip-audit detect-secrets

      - name: Run the security gate
        run: |
          chmod +x security-scan.sh
          ./security-scan.sh
        # Non-zero exit fails the job. Require this job to pass before merge (branch protection on
        # your remote, Module 8/10) and the gate actually has teeth.