Sicherheitsrichtlinien

Sicherheit › Richtlinien enthält die Regeln, die deine Organisation durchsetzt. Die Befundseiten zeigen, was gefunden wurde. Die Richtlinien-Tabs entscheiden, was ein Befund blockiert und was ein Push, ein Merge, ein Download oder ein Pull darf. Nur ein Owner der Organisation kann eine Richtlinie ändern, und jede Änderung wird in das Audit-Log geschrieben.

Die Tabs

Die Befund-Tabs zeigen Befunde; was ein Scanner tut, wird hier eingestellt. Im Tab Ausnahmen unter Befunde wird ein Befund für eine Zeit akzeptiert, mit oder ohne Genehmigung einer zweiten Person.

Scanner

Sicherheit › Richtlinien › Scanner enthält die Einstellungen jedes Scanners. Bis zum 2026-10-15 standen sie oben in dessen Befund-Tab, der jetzt zuerst seine Befunde zeigt sowie eine Zeile mit dem Zustand des Scanners und einem Link hierher.

• SAST: an oder aus und der Schweregrad (info, warning, error), ab dem die Prüfung fremforge/sast fehlschlägt.
• Abhängigkeiten: an oder aus und der Schweregrad (low bis critical), ab dem die Prüfung fremforge/dep-scan fehlschlägt.
• Lizenzen: ob Pull Requests auf Lizenzen gescannt werden. Was ein Lizenzbefund bedeutet, legt die Lizenzrichtlinie fest.
• Secret-Scanning: ob Pull Requests, die ein Secret hinzufügen, blockiert werden.
• Container-Images: Image-Scan und Pull-Sperre liegen unter Image-Richtlinien.

Wird ein Speichern abgewiesen, etwa weil ein Schweregrad keine der Auswahlmöglichkeiten ist, kehrt die Seite zum Abschnitt des Scanners zurück und nennt den Grund. API und Terraform-Ressourcen sind unverändert: PUT /orgs/{org}/code-security/{scanner}/settings und die Ressourcen fremforge_*_settings.

Release-Alter

Sicherheit › Richtlinien › Release-Alter ist eine Zahl von Tagen, 0 bis 14, die angibt, wie lange eine neue Version veröffentlicht sein muss, bevor deine Organisation sie übernimmt. Bis zum 2026-10-16 waren das vier Einstellungen an vier Stellen. Jetzt setzt sie alle vier:

Nichts hat sich von selbst geändert. Jede Stelle hat ihren eigenen Wert behalten. Wo sie sich unterscheiden, zeigt die Seite jeden heutigen Wert und was ein Speichern setzen würde, und sie schlägt den Wert der Sicherheitskorrekturen vor. Nichts wird geschrieben, bis ein Owner speichert, und Speichern wird nur für die Zahl angeboten, deren Änderungen die Seite gezeigt hat.

Eine Korrektur für eine bekanntermaßen ausgenutzte Schwachstelle wartet weiterhin weder in der Pull-Request-Prüfung noch bei Sicherheitskorrekturen noch bei einem Download über den Abhängigkeits-Proxy. Pakete in deiner eigenen Registry warten weiterhin.

Der Sicherheitskorrektur-Weg in der Pull-Request-Prüfung

In der Prüfung fremforge/release-age wartet eine Version, die eine Schwachstelle deines Basis-Branches behebt, gleich welchen Schweregrads, 24 Stunden statt deines Release-Alters. Eine Version qualifiziert sich nur, wenn all das zutrifft:

• Dein Basis-Branch löst eine frühere Version des Pakets auf, und der Pull Request entfernt sie.
• Eine Advisory betrifft diese frühere Version und nennt eine korrigierte Version, die gleich der neuen ist oder darunter liegt. Ein Release, das nur behauptet, etwas zu beheben, qualifiziert sich nicht.
• Die Advisory ist geprüft, unabhängig von ihrem Schweregrad: eine GitHub-Advisory, die GitHub geprüft hat, oder ein Eintrag aus der eigenen Datenbank des Ökosystems (RustSec, die Go-Schwachstellendatenbank, PyPA). Sie wurde mindestens 24 Stunden vor der Prüfung veröffentlicht und geprüft. Ein Paket und eine Advisory, die am selben Tag zusammen veröffentlicht wurden, qualifizieren sich also nie.
• Kein Eintrag zu schädlichen Paketen passt auf die neue Version. Der Malware-Abgleich wird für diesen Weg nie gelockert.

Eine neue transitive Abhängigkeit, die nur die Korrektur mitgebracht hat, erhält in einem von zwei Fällen dieselben 24 Stunden:

• Eine Advisory nennt auch sie als Korrektur, nach denselben Regeln wie oben.
• Die Leute der Korrektur veröffentlichen sie selbst. Der npm-Benutzer, der diese Version veröffentlicht hat, muss bekannt sein und muss Maintainer der Korrektur sein. Zusätzlich muss eines davon zutreffen:
  • Jeder Maintainer der Abhängigkeit pflegt auch die Korrektur.
  • Abhängigkeit und Korrektur geben dasselbe Quell-Repository an, wie es die Pakete eines Monorepos tun.

Ein angegebenes Repository genügt allein nie. Das Feld repository in einer package.json enthält, was auch immer der Veröffentlichende dort einträgt, also kann jeder das Repository eines anderen beanspruchen. Eine Abhängigkeit, deren Veröffentlichender unbekannt ist, wartet immer.

Andernfalls wartet sie dein volles Release-Alter, und der Pull Request wartet mit. Jede andere neue Version im Pull Request behält dein Release-Alter. Der Weg macht die Prüfung nie strenger. Bei einem Release-Alter von 1 Tag oder 0 ändert sich nichts.

Der Status der Prüfung nennt jede Version, die über den Weg durchgelassen wurde, und die Advisory, die sie behebt, zum Beispiel 1 version(s) via the security-fix lane (24h): body-parser@2.4.0 fixes GHSA-…. Jede solche Version schreibt code-security.release_age.waived_security_fix_lane in das Audit-Log, mit Paket, Version, Advisorys, der Korrektur, die sie mitgebracht hat, und dem Pull Request. Downloads über den Abhängigkeits-Proxy und gehostetes Renovate behalten ihre eigenen Regeln. Pakettypen mit eigenem Mindestalter in der Paketrichtlinie behalten es, und die Seite listet sie auf. Ist die Paketrichtlinie nicht im Modus Durchsetzen, wird ein zu neuer Download nur festgehalten.

Eines ist nicht abgedeckt: Für npm, pnpm und Yarn 1 löst gehostetes Renovate die Lockfile über die Release-Alter-Sicht von fremforge auf die npm-Registry auf, die für jede Organisation 3 Tage verwendet. Mit einem längeren Release-Alter hält die Prüfung fremforge/release-age den Pull Request trotzdem zurück, bis jede Version in der Lockfile alt genug ist.

Über die API: GET/PUT /orgs/{org}/release-age (policy:read, policy:write) mit {"days": 7, "package_policy_version": 12} und POST /orgs/{org}/release-age/preview mit {"days": 7} für das, was ein PUT an jeder Stelle ändern würde. Das PUT wird gegen die Version der Paketrichtlinie geprüft, wie beim Speichern einer Paketrichtlinie, und antwortet mit 409 policy-version-conflict, wenn sie sich geändert hat. Jede Änderung schreibt security.release_age.updated in das Audit-Log, neben die Ereignisse der Einstellungen, die sie geändert hat.

Image-Richtlinien

Sicherheit › Richtlinien › Image-Richtlinien hat zwei Teile. Beide standen früher unten unter Befunde › Container-Images.

• Scan und Pull-Sperre. Schaltet den Image-Scan ein oder aus und legt die Sperraktion fest: none, warn oder block_pull. Mit block_pull wird der Pull eines Images mit einem nicht verworfenen Befund auf oder über deiner Sperrschwelle abgewiesen, und die Prüfung fremforge/image-scan schlägt fehl. Siehe Richtlinienschalter.
• Image-Signaturen beim Pull. Wessen cosign-Signaturen du vertraust (eine Liste vertrauenswürdiger Signierender, Schlüssel oder das öffentliche Sigstore), für welche Images das gilt und ob ein unsignierter Pull nur festgehalten (Schatten) oder abgewiesen (Durchsetzen) wird. Siehe Image-Signaturen.

Repository-Regeln

Sicherheit › Richtlinien › Repository-Regeln ist eine Seite für die Regeln, an die jedes Repository der Organisation gebunden ist.

• Branch-Schutz (#org-baseline). Die Regel, die jedes neue Repository für seine geschützten Branches erhält: erforderliche Genehmigungen, CODEOWNERS-Review, Statusprüfungen, lineare Historie und der Rest. Beim Speichern werden die Standards sofort auf bestehende Repositorys angewendet. Siehe Branch-Schutz.
• Commit-Signierung (#commit-signing). Eine Einstellung: Ist sie an, verlangt der Standard-Branch jedes Repositorys signierte Commits, und neue Repositorys erhalten dieselbe Anforderung über die Standards oben. Hat eine ältere Einstellung die beiden auseinanderlaufen lassen, sagt die Seite das; das Speichern der Commit-Signierung bringt sie wieder in Einklang. Siehe Signierte Commits verlangen.
• Organisationsweite Sperre (#actions-gate): Actions nur auf geschützten Branches. Ist sie an, läuft ein Workflow nur auf einem geschützten Branch, sodass ein Push auf einen anderen Branch keinen Code mit den Secrets der Organisation ausführen kann. Siehe Actions nur auf geschützten Branches.

Die alten Adressen funktionieren weiterhin: _admin/repo-defaults sowie die Einstellungen für Commit-Signierung und Actions unter Organisation › Repositorys und Build und Deployment › Umgebungen verlinken oder leiten jetzt hierher weiter.

API und Terraform

Die vollständige Liste mit Scopes und Feldern steht in der API-Referenz und auf der Seite Terraform-Provider.