Automatisches Audit von Secrets für ein Repository mit Cursor CLI in GitHub Actions
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
War diese Seite hilfreich?