API-Keys in Secrets

Der API-Key authentifiziert eure CI gegen das CodeGuard-Portal. Er ist genauso sensibel wie ein Production-DB-Passwort und sollte auch so behandelt werden.

Wo Keys hingehören

Wo Keys NICHT hingehören

• Nie ins Repo committen. Auch nicht "nur kurz zum Testen". Git-History ist permanent, ein einmal exponierter Key ist verbrannt.
• Nicht in Logs. Wenn ihr in einem Skript echo "Key: $CODEGUARD_API_KEY" macht, taucht er im Build-Log auf und damit potenziell auch in Artifacts und Sicherheits-Scans.
• Nicht in .env-Files die ihr versehentlich in Backups, Slack-Threads oder Wikis verschickt.

Maskieren in CI-Logs

Die meisten CI-Systeme maskieren Secret-Variables automatisch im Log wenn sie als Secret markiert sind. Trotzdem aufpassen mit:

# Schlecht, das Token landet als URL-Parameter im Log
curl "https://example.com/?token=$CODEGUARD_API_KEY"

# Besser, als Header, der nicht ge-loggt wird
curl -H "Authorization: Bearer $CODEGUARD_API_KEY" https://example.com/

Rotation

Empfehlung: alle 6 Monate rotieren, plus immer wenn jemand das Team verlässt der den Key gesehen haben könnte.

So geht's:

1. Im Portal unter API Keys einen neuen Key erzeugen.
2. Den neuen Key im CI-System hinterlegen (Update der Secret-Variable).
3. Einmal CI laufen lassen, prüfen dass alles grün ist.
4. Den alten Key im Portal revoken.

Es darf zwei aktive Keys gleichzeitig geben, das ist explizit so designt, damit ihr ohne Downtime rotieren könnt.

Pro Repo oder pro Team?

Faustregel:

• Ein Key pro CI-Job-Familie. Wenn ihr fünf Repos habt die alle CodeGuard laufen lassen, ein Key reicht. Wenn ihr aber ein offenes Repo und ein internes Repo habt: zwei Keys.
• Nicht ein Key pro Entwickler. Keys gehören zum CI, nicht zu Personen.
• Aussagekräftige Namen. Im Portal kannst du dem Key einen Namen geben. acme-web-ci ist gut, prod-key ist okay, key ist nicht hilfreich beim Audit.

Compromittiert, was tun

1. Key sofort im Portal revoken.
2. Neuen Key erzeugen.
3. CI-Secret-Variable aktualisieren.
4. Prüfen ob ungewöhnliche Pull-Aktivität in den Logs steht (Portal-Audit).
5. Falls der Key öffentlich (z.B. in einem PR) exponiert war: GitHub Secret Scanning meldet sich typisch automatisch. Wir bekommen dann auch eine Notification und können den Key auf unserer Seite force-revoken.

Lifecycle

Im Portal könnt ihr pro Key eine Lifetime setzen (z.B. 90 Tage). Nach Ablauf wird der Key automatisch deaktiviert. Sinnvoll für temporäre Keys, z.B. für eine externe Beratungsfirma die eure CI temporär anbindet.

Siehe API-Keys verwalten.