Release-Branches

Wenn du ältere Versionen auf Branches wie release/1.x pflegst, gehen auch diese Branches an deine Kunden. fremforge scannt jeden geschützten Release-Branch mit denselben Scannern wie deinen Standard-Branch. Seine Befunde werden pro Branch aufgeführt, und keiner davon fließt in die Zahlen deines Standard-Branches ein.

Welche Branches gescannt werden

Ein Branch wird als Release-Branch gescannt, wenn beides zutrifft:

Er passt auf eines der Muster für geschützte Branches deiner Organisation (Repositorys › Branch-Schutz, standardmäßig main,master,release/*) oder auf eine der eigenen Branch-Schutzregeln des Repositorys.
Er ist nicht der Standard-Branch des Repositorys.

Welcher Branch der Standard-Branch ist, entscheidet das, was Forgejo für das Repository hinterlegt hat, nie eine Einstellung des Scans. Benennst du den Standard-Branch um, gilt der neue Name ab dem nächsten Scan als Standard, und der alte Name wird ab dann als Release-Branch behandelt, sofern er noch geschützt ist.

Wann sie gescannt werden

Beim Push. Ein Push auf einen Release-Branch fordert einen Scan dieses Branches an. Mehrere Pushes kurz hintereinander ergeben einen Scan des neuesten Commits.
Wöchentlich. Jeder Release-Branch wird mindestens einmal pro Woche neu gescannt, sodass neue Advisorys auch Branches erreichen, auf die niemand pusht. Ein Branch wird sofort gescannt, wenn er zum ersten Mal gefunden wird.
Gelöschte oder nicht mehr geschützte Branches werden vergessen. Das Löschen eines Branches entfernt seine Befunde. Ein Branch, der auf kein Schutzmuster mehr passt, wird beim nächsten wöchentlichen Durchlauf entfernt.

Ein Scan eines Release-Branches kostet dieselbe Runner-Zeit wie ein Scan deines Standard-Branches, pro Push und einmal pro Woche. Release-Branches sind weder im täglichen Image-Rescan noch im wöchentlichen Durchlauf der Secret-Historie enthalten.

Getrennt von deinem Standard-Branch

Befunde auf Release-Branches werden getrennt gespeichert. Die Zahlen deines Standard-Branches bleiben unverändert: die Übersicht, die Befundlisten und ihre Zählungen, SLA-Verstöße und SLA-Kennzahlen sowie der Lebenszyklus der Befunde.

Frist zur Behebung, keine SLA-Kennzahlen. Jeder Befund auf einem Release-Branch zeigt eine Frist aus deiner Behebungsfrist (SLA) für seinen Schweregrad, gerechnet ab dem Zeitpunkt, an dem der Befund auf diesem Branch zum ersten Mal gesehen wurde, oder Keine SLA, wenn der Schweregrad keine hat. Diese Daten dienen der Planung. Sie fließen nicht in SLA-Verstöße, die SLA-Kachel oder eine SLA-Kennzahl ein.
Benachrichtigungen und der wöchentliche Digest führen Release-Branches in einem eigenen Abschnitt auf: neue und offene kritische und hohe Befunde pro Branch. Die Zahlen des Standard-Branches darin bleiben unverändert.

In der Konsole

Sicherheit › Befunde › Alle zeigt eine Branch-Zeile, sobald ein Release-Branch gescannt wurde: Standard-Branch, dann ein Chip pro Release-Branch mit dessen offenen Befunden. Wählst du einen Branch, werden nur die Befunde dieses Branches aufgeführt, mit einer Spalte Beheben bis. Die Filter für Typ und Schweregrad funktionieren wie gewohnt.

Das Menü jeder Zeile enthält:

Auf diesem Branch verwerfen: siehe Verwerfungen.
Fix-PR in diesen Branch vorschlagen, bei einem Abhängigkeitsbefund mit einer behobenen Version: siehe Sicherheitskorrekturen. Solange eine Korrektur in der Warteschlange steht oder ihr Pull Request offen ist, verlinkt die Zeile stattdessen darauf.

Verwerfungen

Eine Verwerfung auf einem Release-Branch gilt nur für diesen Branch. Sie ist ein Eintrag in derselben Liste der Ausnahmen wie jede andere Verwerfung, mit der ID branch.<finding id> und dem Geltungsbereich branch, und sie nennt den Branch. Widerrufst du sie dort, ist der Befund wieder offen. Die Ausnahme-Einstellungen deiner Organisation gelten, einschließlich der maximalen Gültigkeitsdauer.

Einschränkung: Wo Verwerfungen eine Freigabe erfordern, kann nur eine freigebende Person einen Befund auf einem Release-Branch verwerfen. Die Warteschlange für Anfrage und Freigabe deckt Release-Branches noch nicht ab. Eine Verwerfung durch jemand anderen wird abgelehnt (403 approval-required über die API, ein Hinweis in der Konsole), und der Befund bleibt offen.

Sicherheitskorrekturen

Ein Abhängigkeitsbefund mit einer behobenen Version kann einen Pull Request für eine Sicherheitskorrektur in seinen Release-Branch erhalten. Alles an der Korrektur funktioniert wie auf deinem Standard-Branch, mit diesen Unterschieden:

Der Pull Request zielt auf den Release-Branch, von seinem eigenen Branch security-fix/<branch>/<package>-<version>, zum Beispiel security-fix/release-1.x/lodash-4.17.21.
Er behebt jeden offenen Befund zu diesem Paket auf diesem Branch, mit der niedrigsten Version, die sie alle behebt.
Eine aktive Korrektur pro Paket und Branch. Dasselbe Paket auf deinem Standard-Branch und auf release/1.x erhält zwei getrennte Korrekturen. Die Limits deiner Organisation zählen alle Branches zusammen.
Ein Pull Request, den der Lauf gegen einen anderen Branch öffnet, wird mit dem Grund scope_base geschlossen.
Eine Korrektur gilt als erledigt, wenn der nächste Scan des Release-Branches ihre Befunde nicht mehr meldet.

Sie wird nie automatisch gemergt, genau wie auf dem Standard-Branch.

Pull Requests in einen Release-Branch

Die Prüfungen eines Pull Requests in einen Release-Branch vergleichen ihn mit dem letzten Scan dieses Branches, nicht mit dem des Standard-Branches. Ein Pull Request wird nur durch Befunde blockiert, die er selbst einführt. Ein Pull Request, der nur Konfiguration ändert, wird nicht durch Befunde blockiert, die bereits auf dem Release-Branch vorhanden sind.

API

Aufruf	Was er tut
`GET /orgs/{org}/security/release-branches`	Die gescannten Release-Branches, jeweils mit der Anzahl offener Befunde.
`GET /orgs/{org}/security/findings?branch=release/1.x`	Die Befunde dieses Branches, in derselben Form wie die des Standard-Branches, zusätzlich `branch` und `fix_by`. Ein unbekannter Branch ergibt `404 unknown-branch`.
`POST /orgs/{org}/security/release-findings/{id}/dismiss`	Auf diesem Branch verwerfen: `reason`, optional `expires_at`.
`POST /orgs/{org}/security/release-findings/{id}/autofix`	Eine Sicherheitskorrektur in diesen Branch einreihen. Die Antwort enthält `base_branch`.

curl -sS "https://frem.sh/_app/api/v1/orgs/acme/security/findings?branch=release%2F1.x" \
  -H "Authorization: Bearer $FREMFORGE_TOKEN"

Lesen erfordert findings:read, Verwerfungen und Korrekturen erfordern findings:write. Alle Felder findest du in der API-Referenz.

Wenn Forgejo nicht erreichbar ist

Um einen Scan abzulegen, muss fremforge wissen, ob der gescannte Branch der Standard-Branch ist. Kann Forgejo das nicht beantworten, wird der Scan weder verworfen noch wird geraten. Er wird zurückgehalten und abgelegt, sobald Forgejo antwortet, normalerweise innerhalb von Minuten. Bis dahin zeigen die Befunde dieses Branches den vorherigen Scan.

Behebungsfrist (SLA)Schwachstellen melden