Führe automatisch ein Audit deines Repositories auf Sicherheitslücken und Secret-Exposition mit Cursor CLI durch. Dieser Workflow scannt nach potenziellen Secrets, erkennt riskante Workflow-Muster und schlägt Sicherheitsfixes vor.
name: Auto Secrets Audit

on:
  schedule:
    - cron: "0 4 * * *"
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write
  actions: read

jobs:
  secrets-audit:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install Cursor CLI
        run: |
          curl https://cursor.com/install -fsS | bash
          echo "$HOME/.cursor/bin" >> $GITHUB_PATH

      - name: Configure git identity
        run: |
          git config user.name "Cursor Agent"
          git config user.email "cursoragent@cursor.com"

      - name: Scan and propose hardening
        env:
          CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
          MODEL: gpt-5
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          BRANCH_PREFIX: audit
        run: |
          cursor-agent -p "Du arbeitest in einem GitHub Actions Runner.

          Die GitHub CLI ist als \`gh\` verfügbar und über \`GH_TOKEN\` authentifiziert. Git ist verfügbar. Du hast Schreibzugriff auf Repository-Inhalte und kannst Pull Requests kommentieren, aber du darfst keine PRs direkt erstellen oder bearbeiten.

          # Kontext:
          - Repo: ${{ github.repository }}
           - Hardening Branch Prefix: ${{ env.BRANCH_PREFIX }}

          # Ziel:
          - Führe ein geplantes Repository-Audit für Secret-Exposition und Workflow-Härtung durch und schlage minimale sichere Fixes vor.

          # Anforderungen:
          1) Scanne nach potenziellen Secrets in verfolgten Dateien und der aktuellen Historie; unterstütze Allowlist-Muster falls vorhanden (z.B. .gitleaks.toml).
          2) Erkenne riskante Workflow-Muster: nicht gepinnte Actions, zu weitreichende Berechtigungen, unsichere pull_request_target-Nutzung, Secrets in Fork-PR-Kontexten, veraltete unsichere Befehle, fehlende Permissions-Blöcke.
          3) Verwalte einen persistenten Branch für diesen Lauf mit dem Hardening Branch Prefix aus dem Kontext. Erstelle ihn falls nicht vorhanden, aktualisiere ihn andernfalls und pushe Änderungen zu origin.
          4) Schlage minimale Bearbeitungen vor: redaktiere Literale wo sicher, füge Ignore-Regeln hinzu, pinne Actions zu SHA, reduziere Berechtigungen, füge Schutzmaßnahmen zu Workflows hinzu und füge eine SECURITY_LOG.md hinzu, die Änderungen und Behebungsanleitungen zusammenfasst.
          5) Pushe zu origin.
          6) Falls mindestens ein offener PR im Repo existiert, poste oder aktualisiere einen einzelnen natürlichsprachigen Kommentar (1–2 Sätze) auf dem zuletzt aktualisierten offenen PR, der die Härtungsänderungen kurz erklärt und einen Inline-Vergleichslink zum schnellen Erstellen eines PRs enthält.
          7) Vermeide doppelte Kommentare; aktualisiere einen vorhandenen Bot-Kommentar falls vorhanden. Falls keine Änderungen oder keine offenen PRs vorhanden sind, poste nichts.

          # Eingaben und Konventionen:
          - Verwende \`gh\` um PRs aufzulisten und Kommentare zu posten. Vermeide doppelte Kommentare.

          # Ergebnisse bei Aktualisierungen:
           - Gepushte Commits zum persistenten Härtungs-Branch für diesen Lauf.
          - Ein einzelner natürlichsprachiger PR-Kommentar mit dem Vergleichslink oben (nur falls ein offener PR existiert).
          " --force --model "$MODEL" --output-format=text