Öffentliche REST-API

Für jede Aktion in der Admin-Oberfläche von fremforge gibt es eine Entsprechung in der öffentlichen REST-API. Die Admin-Oberfläche ist selbst ein Client dieser Schnittstelle, und KI-Agenten, die im Auftrag von Nutzern handeln, verwenden dieselben Endpunkte. Es gibt keine Endpunkte nur für Admins und keine überraschenden Lücken.

Die Spezifikation holen

Die maßgebliche, maschinenlesbare Spezifikation ist OpenAPI 3.1.

• YAML: /api/openapi.yaml, maßgeblich, eine einzige Datei, zum Herunterladen für Werkzeuge.
• JSON-Spiegel: wird zum Launch unter /api/openapi.json aus derselben Quelle veröffentlicht, für Clients, die JSON bevorzugen.

Beide Dateien sind zusammen mit der API versioniert und werden mit jedem fremforge-Release aktualisiert. Das Versionsfeld der OpenAPI-Datei folgt MAJOR.MINOR.PATCH; die API selbst ist für inkompatible Änderungen im Pfad versioniert (/api/v1/...).

Authentifizierung

Drei Wege zur Authentifizierung, in der Spezifikation als getrennte securitySchemes deklariert, damit Clients den richtigen wählen können.

Personal Access Tokens (PAT), für menschliche Aufrufer und CI-Integrationen

Personal Access Tokens gehören zu einem Nutzer, nicht zu einer Organisation, deshalb liegen sie in deinen Benutzereinstellungen in Forgejo: Öffne /<your-user>/settings/applications in der Forgejo-Oberfläche (z. B. frem.sh/<your-user>/settings/applications). Tokens haben einen Namen, eine Menge von Scopes und eine Gültigkeitsdauer von bis zu 365 Tagen, begrenzt durch die organisationsweite Maximale PAT-Lebensdauer, falls dein Admin sie über die Authentifizierungsrichtlinie gesetzt hat. Das rohe Token wird einmal angezeigt; auf dem Server wird nur sein Hash gespeichert.

Davon zu unterscheiden sind Organisations-API-Tokens (weiter unten unter Token-Verwaltung beschrieben), die in der fremforge-Verwaltung unter /<org>/_admin/api-tokens liegen und das Ausscheiden einzelner Mitglieder überdauern. Verwende ein PAT für persönliche Skripte und die lokale Entwicklung und ein Organisations-API-Token für CI und Automatisierung in Produktion.

curl -H "Authorization: Bearer ${FREMFORGE_PAT}" \
     https://frem.sh/_app/api/v1/users/me

OAuth 2.0 Client Credentials, für Maschine-zu-Maschine

Der Standard-Grant für Client Credentials nach RFC 6749. Registriere einen Client auf Organisationsebene und tausche client_id + client_secret am Token-Endpunkt ein:

curl -X POST https://frem.sh/_app/api/v1/oauth/token \
  -d "grant_type=client_credentials" \
  -d "client_id=${CLIENT_ID}" \
  -d "client_secret=${CLIENT_SECRET}" \
  -d "scope=org:read seats:write"

OIDC-Token-Austausch, für IdPs und Workflow-Runner

Wenn dein IdP OIDC-JWTs ausstellen kann (Authentik, Entra, Okta, Keycloak, …) oder wenn ein Forgejo-Actions-Workflow in fremforge die API aufrufen muss, nimm lieber POST /_app/api/v1/auth/token-exchange als langlebige PATs. Kein gemeinsames Secret verlässt deine Umgebung, und der IdP rotiert den zugrunde liegenden Schlüssel nach seinem eigenen Zeitplan.

Akzeptierte Aussteller:

• IdP des Kunden, registriert als auth_sources-Eintrag für den Ziel-Mandanten (dasselbe JWKS, das schon für die Anmeldung der Mitglieder verwendet wird). Binde deinen IdP zuerst auf der SSO-Einstellungsseite des Mandanten an.
• fremforge-Runner-OIDC: Schritte auf Forgejo-Actions-Runnern können sich ohne weitere IdP-Anbindung selbst ein fremforge-Token ausstellen. Verwende das Standard-OIDC-Token des Runners, das Forgejo einspielt (in der Job-Umgebung des Runners als FREMFORGE_OIDC_TOKEN verfügbar).

Eingereichte JWTs MÜSSEN ein mandantenbezogenes aud=https://frem.sh/<slug> und ein aktuelles exp tragen. Das zurückgegebene Zugriffstoken ist ein gewöhnliches ffp_-PAT; übergib es bei folgenden Aufrufen als Authorization: Bearer <token>. Die Gültigkeitsdauer ist hart auf 1 Stunde begrenzt. Die Scopes sind die Schnittmenge aus Anfrage und Allowlist des Austauschs; * und tokens:manage werden hier nie gewährt, dafür verwende POST /_app/api/v1/auth/tokens oder die Admin-Oberfläche.

# 1. Mint a JWT from your IdP (aud=https://frem.sh/<your-tenant-slug>).
ASSERTION="$(your-idp-cli get-token --audience https://frem.sh/acme)"

# 2. Exchange it for a short-lived fremforge access token.
ACCESS_TOKEN="$(curl -s -X POST \
  -H 'Content-Type: application/json' \
  -d "{\"subject_token\":\"$ASSERTION\",\"tenant_slug\":\"acme\",\"scopes\":[\"exports:write\",\"exports:read\"]}" \
  https://frem.sh/_app/api/v1/auth/token-exchange | jq -r .access_token)"

# 3. Drive the API with the resulting token (TTL = 1 hour).
curl -s -H "Authorization: Bearer $ACCESS_TOKEN" \
  https://frem.sh/_app/api/v1/users/me

Aus einem Schritt eines Forgejo-Actions-Workflows sieht derselbe Ablauf so aus:

- name: Exchange runner OIDC for fremforge token
  run: |
    ASSERTION="$FREMFORGE_OIDC_TOKEN"  # injected by fremforge runners
    echo "FREMFORGE_TOKEN=$(curl -sX POST \
      -H 'Content-Type: application/json' \
      -d "{\"subject_token\":\"$ASSERTION\",\"tenant_slug\":\"${{ github.repository_owner }}\",\"scopes\":[\"sboms:write\"]}" \
      https://frem.sh/_app/api/v1/auth/token-exchange | jq -r .access_token)" >> $GITHUB_ENV

Der Endpunkt ist bewusst nicht authentifiziert (das JWT ist die Authentifizierung), aber auf 30 Versuche pro Minute und Quell-IP begrenzt. Darüber hinausgehende Bursts bekommen 429 Retry-After. Jeder abgelehnte Austausch kostet trotzdem eine RSA-Prüfung, sodass ein durchgesickerter IdP-Zugang oder eine fehlerhafte CI-Schleife eingedämmt wird, statt sich zu verstärken.

Endpunkte in Phasen und Agenten, die im Auftrag von Nutzern handeln

Die OpenAPI-Spezifikation kennzeichnet die Verfügbarkeit von Endpunkten mit der Erweiterung x-fremforge-phase:

• x-fremforge-phase: 1: live und jetzt verfügbar.
• x-fremforge-phase: 2: spezifiziert, aber noch nicht implementiert; liefert 501 Not Implemented.

Endpunkte ohne die Erweiterung gehören zu Phase 1. Ein noch nicht ausgelieferter Endpunkt liefert 501 als RFC 7807 Problem Details, wie jeder andere Fehler dieser API – das Feld detail nennt die funktionierende Alternative, wo es eine gibt:

{
  "type": "https://docs.frem.sh/reference/api/errors/not-implemented-yet",
  "title": "Not Implemented",
  "status": 501,
  "detail": "…what to use instead…"
}

Ein 501 kann auch einfach bedeuten, dass der Pfad auf nichts gepasst hat – dieselbe Antwort kommt für eine unbekannte URL. Gleiche deinen Pfad also mit der Spezifikation ab, bevor du schließt, dass ein Endpunkt nicht implementiert ist.

Es gibt keine Agenten-Identitäten. Ein KI-Agent handelt im Auftrag einer Person: Er ruft diese API mit einem Token auf, das die Person ausgestellt hat, mit einem Token aus dem Token-Austausch nach RFC 8693, das das actor_token des Agenten trägt, oder über einen MCP-Connector, den die Person erlaubt hat. Das Audit-Log verzeichnet die Person als actor und den Agenten als Detail (fields.agent, wobei fields.via_token das Token nennt), und das Admin-Audit-Log kennzeichnet solche Ereignisse mit über Agent. GET /orgs/{org}/audit?actor= vergleicht exakt mit dem Akteur, on_behalf_of oder fields.agent und findet so alles, was für eine Person oder von einem Agenten getan wurde. Was live ist und was auf der Roadmap steht, zeigt die Seite zur KI-Haltung.

Nutzungsmuster für Agenten

Drei Referenzszenarien, für die die Spezifikation entworfen wurde. Braucht dein Agent etwas, das die Spezifikation nicht sauber abdeckt, ist das eine meldenswerte Lücke; schreib uns an support@frem.sh.

Szenario 1: Eine neue Organisation aus einem delegierten Mandat bereitstellen

Ein Agent, der im Rahmen eines Mandats eines Resellers oder Admins handelt, kann eine vollständige Organisation mit vier API-Aufrufen bereitstellen:

1. POST /orgs: die Organisation mit Slug, Anzeigename und Rechnungskontakt anlegen
2. PUT /orgs/{org}/sso: OIDC-SSO für die neue Organisation einrichten
3. POST /orgs/{org}/seats: die anfängliche Nutzerzahl bereitstellen
4. GET /orgs/{org}: prüfen, ob die Organisation aktiv und SSO eingerichtet ist

Szenario 2: Befunde lesen und Pull Requests zur Behebung anlegen

Ein Mandat mit Lese-Scope. Der Agent fragt die Endpunkte für Befunde ab, ermittelt Einträge mit hohem Schweregrad und öffnet über die normale Git-Schnittstelle von Forgejo Pull Requests zur Behebung (das liegt außerhalb dieser REST-API; für diesen Teil verwendet der Agent Git über HTTPS oder SSH). Einträge im Audit-Log nennen die Person, für die der Agent handelt, mit dem Agenten in fields.agent und einem Chip über Agent im Admin-Audit-Log.

Szenario 3: Laufzeitrichtlinien während eines Vorfalls anpassen

Ein eng begrenztes, zeitlich befristetes Mandat (policy:write:scope=findings-only, 1 h gültig). Der Agent setzt eine strengere Richtlinie durch (z. B. Merge-Sperre bei CRITICAL-CVEs in allen Repositorys), die Änderung wird im Audit-Log mit der Person als Akteur und dem Agenten als Detail des Ereignisses protokolliert, und Owner der Organisation sehen sie im Audit-Log, wenn sie nach einem der beiden filtern.

Versionierungsrichtlinie

• Major-Versionen stehen im Pfad (/v1/..., /v2/...). Inkompatible Änderungen kommen in einer neuen Major-Version, mit einer Überschneidung von mindestens 12 Monaten, in der beide Versionen unterstützt werden.
• Minor- und Patch-Versionen stehen in info.version. Zusätzliche Endpunkte, neue optionale Felder und Verbesserungen der Dokumentation kommen innerhalb der aktuellen Major-Version, ohne die Kompatibilität zu brechen.
• Die OpenAPI-Spezifikation ist die maßgebliche Quelle; weicht ein Verhalten von der Spezifikation ab, ist die Spezifikation richtig, und die Implementierung wird korrigiert. Melde Abweichungen an support@frem.sh.

Rate-Limits

API-Anfragen sind pro Token begrenzt:

Wer ein Limit überschreitet, bekommt HTTP 429 mit einem Retry-After-Header, der angibt, wann das Fenster zurückgesetzt wird. Die Limits gelten pro Token, nicht pro IP. Organisations-API-Tokens und PATs haben dieselben Limits pro Token.

Jede Antwort trägt außerdem die IETF-Header RateLimit und RateLimit-Policy nach draft-ietf-httpapi-ratelimit-headers. Es gelten sowohl Rate-Limits pro Token als auch pro Organisation; die Header der Antwort zeigen das strengere der beiden.

Die Spezifikation lokal prüfen

Lade die Spezifikation herunter und lass dann einen Linter über die lokale Datei laufen:

curl -fsSL https://docs.frem.sh/api/openapi.yaml -o openapi.yaml

# Redocly CLI
npx @redocly/cli@latest lint openapi.yaml

# Swagger CLI
npx @apidevtools/swagger-cli@latest validate openapi.yaml

Die Spezifikation besteht beide Linter ohne Befund; das ist eine Zusage, ohne die der Launch von Phase 1 nicht stattfindet.

Sicherheitsbefunde

Jeder Scanner, der einen Merge blockieren kann – statische Analyse, Abhängigkeiten, Container-Images, Lizenzen –, stellt seine Befunde zum Auflisten und Verwerfen bereit:

GET  /orgs/{org}/code-security/{scanner}/findings
POST /orgs/{org}/code-security/{scanner}/findings/{id}/dismiss
POST /orgs/{org}/code-security/{scanner}/findings/bulk-dismiss
PUT  /orgs/{org}/code-security/{scanner}/settings

{scanner} ist einer von sast, deps, images, licenses. Diese Namen entsprechen nicht den Namen der Commit-Status, die du an einem Pull Request siehst (fremforge/sast, fremforge/dep-scan, fremforge/image-scan, fremforge/license-scan) – den Pfad aus dem Statusnamen abzuleiten ist der häufigste Weg zu einem 501.

Zwei weitere Dinge solltest du wissen, bevor du gegen diese Endpunkte skriptest. Befunde verschwinden nicht beim Merge – sie verschwinden, wenn ein späterer Scan desselben Ziels sie nicht mehr meldet; ein stündlicher Job löst sie dann als dismissed_by: auto-resolve auf. Verwirf ausdrücklich, wenn du einen Befund akzeptierst oder wenn kein weiterer Scan dieses Ziels zu erwarten ist. Und licenses bietet nur einzelnes Verwerfen, ohne Endpunkt für mehrere auf einmal.

Die vollständigen Anfrage- und Antwortschemas stehen in der Spezifikation. Ausgearbeitete curl-Beispiele findest du unter Befund-API.

Registry-Zugangsdaten

Die eigenen, schreibgeschützten Zugangsdaten deiner Organisation für private Container-Registries (kind: oci) und private Hosts für Git-Module (kind: git). Die Scanner von fremforge prüfen damit cosign-Signaturen, scannen Images und holen Bicep-br:- und Terraform-Module. Deine CI sieht sie nie. Wenn die Seite zum Image-Scanning meldet, dass Registry-Zugangsdaten abgelaufen sind oder abgelehnt wurden, ersetzt ein Owner sie hier oder in der Konsole unter Sicherheit › Zugriff › Registry-Zugangsdaten, was dasselbe mit denselben Regeln und Audit-Ereignissen tut. Zugangsdaten für die eigenen Upstreams des Abhängigkeits-Proxys (Docker Hub, ghcr.io, quay.io, die Red-Hat-Registries) sind davon getrennt: Ein Owner verwaltet sie unter Abhängigkeits-Proxy › Upstream-Zugangsdaten.

GET    /orgs/{org}/registry-credentials             list (policy:read)
PUT    /orgs/{org}/registry-credentials/settings    turn the feature on or off (policy:write)
POST   /orgs/{org}/registry-credentials             add one (policy:write)
PATCH  /orgs/{org}/registry-credentials/{id}        new secret, expiry or both (policy:write)
DELETE /orgs/{org}/registry-credentials/{id}        delete, effective at once (policy:write)

• Nur für Owner der Organisation. Verwende ein Organisations-API-Token mit policy:read zum Auflisten und policy:write zum Ändern.
• Das Secret ist nur schreibbar. Es wird verschlüsselt gespeichert und nie zurückgegeben. Aufgelistete Zugangsdaten zeigen fingerprint, expires_at, last_used_at und last_result (ok, refused, expired, rate_limited).
• Ein Satz Zugangsdaten pro Host und Art. host ist nur der Hostname, ohne Schema, Pfad oder Port. expires_at ist Pflicht und liegt höchstens 366 Tage in der Zukunft. Danach werden die Zugangsdaten nicht mehr verwendet.
• auth_type ist basic (username und password, das auch ein Token sein kann), bearer (token) oder, nur für oci, dockerconfigjson (nur der Eintrag für host wird behalten).
• Nur für einen Scan deiner Organisation verwendet. Seit dem 23.10.2026 muss jeder Lesezugriff, den die Scanner von fremforge mit deinen Zugangsdaten machen, ein kurzlebiges Ticket tragen, das an einen Scan deiner Organisation gebunden ist; ein Lesezugriff ohne Ticket wird abgelehnt. Ein Scan einer anderen Organisation kann sie nie verwenden.
• Schalte die Funktion zuerst ein. Solange sie ausgeschaltet ist, verwenden Scans keine Zugangsdaten, und es lassen sich keine hinzufügen oder rotieren. Löschen kannst du sie trotzdem. Jede Änderung wird ins Audit-Log geschrieben, ohne das Secret.

Liste die Zugangsdaten auf und ersetze dann Secret und Ablaufdatum der abgelaufenen:

curl -s -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
  https://frem.sh/_app/api/v1/orgs/acme/registry-credentials

curl -s -X PATCH -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
  -H 'Content-Type: application/json' \
  -d '{"auth_type":"basic","username":"scanner-bot","password":"<new-token>","expires_at":"2027-10-01T00:00:00Z"}' \
  https://frem.sh/_app/api/v1/orgs/acme/registry-credentials/<credential-id>

Füge Zugangsdaten für eine Registry hinzu, die noch keine hat, oder lösche welche:

curl -s -X POST -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
  -H 'Content-Type: application/json' \
  -d '{"host":"registry.example.com","kind":"oci","auth_type":"bearer","token":"<token>","expires_at":"2027-10-01T00:00:00Z"}' \
  https://frem.sh/_app/api/v1/orgs/acme/registry-credentials

curl -s -X DELETE -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
  https://frem.sh/_app/api/v1/orgs/acme/registry-credentials/<credential-id>

Die vollständigen Anfrage- und Antwortschemas stehen in der Spezifikation unter dem Tag Registry credentials.

Was diese Spezifikation nicht abdeckt

Zwei Bereiche sind bewusst ausgenommen:

1. Die native Forgejo-API, Endpunkte unter /api/v1/repos, /api/v1/users, /api/v1/issues, /api/v1/pulls usw. Das ist die API von Forgejo/Gitea, die fremforge unverändert unter https://frem.sh/_app/api/v1/... bereitstellt. Jede laufende fremforge-Instanz liefert außerdem die Live-Swagger-UI unter https://frem.sh/api/swagger aus (direkt aus dem laufenden Forgejo erzeugt, daher immer passend zur deployten Version). Die Migrationsanleitungen verweisen direkt auf diese Endpunkte, weil sie die Standardschnittstelle von Forgejo sind.
2. Payloads der Webhook-Zustellung: Die Ereignisformate der Webhooks von Forgejo sind upstream festgelegt. In der Admin-Oberfläche von fremforge richtest du Webhooks ein; die Payloads verwenden das Ereignisvokabular von Forgejo (Header X-Forgejo-Event, HMAC-SHA256 in X-Forgejo-Signature).

Die OpenAPI-Spezifikation deckt die fremforge-spezifische Steuerungsebene ab: Organisationen, Nutzer, Richtlinien, Befunde, Runner, Exporte, Audit, Mandate. Alles, was es gibt, weil fremforge es auf Forgejo aufgesetzt hat, steht in dieser Spezifikation.

Token-Verwaltung

Es gibt zwei Arten von Tokens.

Token-Arten

Faustregel: Verwende ein Organisations-API-Token für alles, was in Produktion oder in der CI läuft. Verwende ein PAT für persönliche Werkzeuge und Entwicklungsabläufe.

Ein Organisations-API-Token erstellen

1. Öffne Organisationsverwaltung → API-Token → Neues Token erstellen (frem.sh/<org>/_admin/api-tokens).
2. Gib einen aussagekräftigen Namen ein (z. B. ci-deploy, renovate-bot).
3. Wähle die Scopes. Verfügbare Scopes:

4. Lege ein Ablaufdatum fest. Die Standard-Gültigkeitsdauer (wenn ttl_days fehlt) ist 90 Tage, das ist zugleich das Maximum – ttl_days akzeptiert 1-90. (Auf dieser Seite stand früher 365; die API lehnt alles über 90 ab.) Tokens lassen sich nicht so einstellen, dass sie nie ablaufen.
5. Klicke auf Token erstellen.

Der Wert des Tokens wird beim Erstellen genau einmal angezeigt. Kopiere ihn sofort und speichere ihn in deinem Secret-Manager. fremforge speichert den rohen Wert nicht; auf dem Server wird nur sein Hash aufbewahrt. Verlierst du den Wert, widerrufe das Token und erstelle ein neues.

Ein PAT erstellen

1. Öffne Benutzereinstellungen → Git-Zugriffstoken → Neues PAT erstellen (frem.sh/user/settings#ff-git-pats).
2. Gib einen Namen ein, wähle die Scopes und lege ein Ablaufdatum fest (Standard 90 Tage; Maximum 365 Tage).
3. Klicke auf PAT erstellen.

PATs verwenden dasselbe Scope-Modell wie Organisations-API-Tokens. Ein PAT erbt den Zugriff des Nutzers, der es erstellt hat, zusätzlich eingeschränkt durch die gewählten Scopes.

Token-Isolation

Organisations-API-Tokens sind streng auf ihre Organisation beschränkt. Ein unter der Organisation acme erstelltes Token kann auf keine Ressource der Organisation beta zugreifen, selbst wenn der Nutzer, der das Token erstellt hat, Mitglied beider Organisationen ist. Das ist eine von der Plattform durchgesetzte Grenze, keine Berechtigungsprüfung, die sich umgehen lässt.

Für Automatisierung über mehrere Organisationen brauchst du daher ein Organisations-API-Token pro Organisation. Eine organisationsübergreifende Token-Art gibt es nicht.

Ein Token rotieren

Rotiere Tokens, wenn sie bald ablaufen, wenn ein Teammitglied geht, das den Wert kannte, oder wenn ein Token offengelegt worden sein könnte.

Ablauf der Rotation:

1. Erstelle das neue Token unter Organisationsverwaltung → API-Token → Neues Token erstellen.
2. Aktualisiere jeden Verbraucher des alten Tokens: CI-Secrets, Deployment-Konfigurationen, .env-Dateien, Integrationen von Drittanbietern.
3. Prüfe, ob das neue Token durchgängig funktioniert, indem du einen Testlauf auslöst oder einen Test-API-Aufruf machst.
4. Widerrufe das alte Token unter Organisationsverwaltung → API-Token → Token suchen → Widerrufen.

Erst erstellen, dann die Verbraucher aktualisieren, dann widerrufen. Widerrufe nie, bevor der Ersatz eingerichtet ist.

Ein Token widerrufen

1. Öffne Organisationsverwaltung → API-Token (für Organisations-API-Tokens) oder Benutzereinstellungen → Git-Zugriffstoken (für PATs).
2. Suche das Token anhand seines Namens.
3. Klicke auf Widerrufen.

Der Widerruf wirkt sofort. Jede Anfrage mit dem widerrufenen Token bekommt die Antwort 401 Unauthorized. Eine Schonfrist gibt es nicht.

Aktive Tokens auflisten

Organisationsverwaltung → API-Token zeigt alle Organisations-API-Tokens mit:

• Name des Tokens
• Benutzername des Erstellers
• Erstellungsdatum
• Datum der letzten Verwendung
• Ablaufdatum
• Scopes

Die Werte der Tokens sind nach dem Erstellen nicht mehr sichtbar. Owner der Organisation sehen alle Metadaten der Tokens, egal welcher Owner das Token erstellt hat. Nur der Ersteller hat den Wert beim Erstellen gesehen.

PATs kann jeder Nutzer für sich selbst unter Benutzereinstellungen → Git-Zugriffstoken auflisten. Owner der Organisation können die PATs anderer Nutzer nicht aufzählen, aber die PATs eines entfernten Mitglieds verlieren den Zugriff auf Ressourcen der Organisation in dem Moment, in dem das Mitglied aus der Organisation entfernt wird.

Ablauf von Tokens

Tokens laufen automatisch nach ihrer eingestellten Gültigkeitsdauer ab. Ein abgelaufenes Token liefert 401 Unauthorized. Abgelaufene Tokens lassen sich nicht verlängern. Erstelle ein neues Token und aktualisiere die Verbraucher; danach kannst du das abgelaufene Token optional aus der Liste löschen.

Um Ausfälle durch unbemerkten Ablauf zu vermeiden, richte in deinem Monitoring einen Alarm auf Basis des Ablaufdatums aus der Token-Liste ein, oder verlass dich auf die Benachrichtigungs-E-Mail, die fremforge 7 Tage vor dem Ablauf eines Organisations-API-Tokens sendet (an die Owner der Organisation).

Sicherheitspraktiken

• Speichere Tokens als verschlüsselte CI-Secrets, nicht in Repository-Dateien, Workflow-YAML oder im Commit-Verlauf.
• Verwende die kleinste Menge an Scopes, die die Aufgabe braucht. Ein Token, das nur Repositorys liest, braucht kein orgs:write.
• Wähle die kürzeste Gültigkeitsdauer, die im Betrieb praktikabel ist. Standard sind 90 Tage, und das ist für ein Organisations-API-Token auch das Maximum.
• Rotiere Tokens, die offengelegt worden sein könnten, statt anzunehmen, dass sie nicht benutzt wurden.
• Prüfe regelmäßig, wann Tokens zuletzt verwendet wurden. Ein Token, das 30 Tage lang nicht benutzt wurde, kann ein veralteter Zugang einer stillgelegten Integration sein.

Hilfe bekommen

Fragen zum Verhalten der API, fehlende Endpunkte oder Vorschläge für neue Operationen: support@frem.sh mit einer Betreffzeile, die mit API - beginnt.