Releasebranches

Als je oudere versies onderhoudt op branches zoals release/1.x, dan gaan ook die branches naar je klanten. fremforge scant elke beschermde releasebranch met dezelfde scanners als je standaardbranch. De bevindingen worden per branch vermeld, en geen ervan telt mee in de cijfers van je standaardbranch.

Welke branches worden gescand

Een branch wordt als releasebranch gescand als aan allebei deze voorwaarden is voldaan:

hij matcht een van de patronen voor beschermde branches van je organisatie (Repos › Branchbescherming, standaard main,master,release/*), of een van de eigen branchbeschermingsregels van de repository;
hij is niet de standaardbranch van de repository.

Welke branch de standaardbranch is, is wat Forgejo voor de repository vastlegt, nooit een instelling in de scan. Hernoem je de standaardbranch, dan telt de nieuwe naam vanaf de volgende scan als standaard, en wordt de oude naam vanaf dat moment als releasebranch behandeld, als hij nog beschermd is.

Wanneer ze worden gescand

Bij een push. Een push naar een releasebranch vraagt een scan van die branch aan. Meerdere pushes kort na elkaar geven één scan van de laatste commit.
Wekelijks. Elke releasebranch wordt minstens één keer per week opnieuw gescand, zodat nieuwe advisories ook branches bereiken waar niemand naar pusht. Een branch wordt direct gescand de eerste keer dat hij wordt gevonden.
Verwijderde of niet meer beschermde branches worden vergeten. Een branch verwijderen haalt zijn bevindingen weg. Een branch die niet meer met een beschermingspatroon matcht, wordt bij de volgende wekelijkse ronde verwijderd.

Het scannen van een releasebranch kost evenveel runnertijd als het scannen van je standaardbranch, per push en één keer per week. Releasebranches doen niet mee aan de dagelijkse herscan van images of de wekelijkse doorzoeking van de secretgeschiedenis.

Gescheiden van je standaardbranch

Bevindingen op releasebranches worden apart opgeslagen. De cijfers van je standaardbranch blijven ongewijzigd: het overzicht, de lijsten met bevindingen en hun aantallen, SLA-overschrijdingen en SLA-statistieken, en de levenscyclus van bevindingen.

Oplosdatum, geen SLA-statistieken. Elke bevinding op een releasebranch toont een datum waarvoor ze opgelost moet zijn, volgens je hersteltermijn (SLA) voor haar ernst, gerekend vanaf het moment dat de bevinding voor het eerst op die branch werd gezien, of Geen SLA als de ernst er geen heeft. Deze datums zijn bedoeld voor de planning. Ze tellen niet mee in SLA-overschrijdingen, de SLA-tegel of welke SLA-statistiek ook.
Meldingen en de wekelijkse samenvatting vermelden releasebranches in een eigen sectie: nieuwe en openstaande kritieke en hoge bevindingen per branch. De aantallen voor de standaardbranch erin blijven ongewijzigd.

In de console

Beveiliging › Bevindingen › Alle toont een rij met branches zodra een releasebranch is gescand: Standaardbranch, en daarna één chip per releasebranch met zijn openstaande bevindingen. Kies je een branch, dan zie je alleen de bevindingen van die branch, met een kolom Oplossen vóór. De filters op type en ernst werken zoals gewoonlijk.

Het menu van elke rij bevat:

Negeren op deze branch: zie Negeren.
Fix-PR voorstellen voor deze branch, bij een afhankelijkheidsbevinding met een gefixte versie: zie Beveiligingsfixes. Zolang er een fix in de wachtrij staat of de pull request ervan openstaat, linkt de rij daarnaartoe.

Negeren

Een negering op een releasebranch geldt alleen voor die branch. Het is een regel in dezelfde lijst Uitzonderingen als elke andere negering, met het id branch.<finding id> en het bereik branch, en ze noemt de branch. Trek haar daar in, en de bevinding staat weer open. De uitzonderingsinstellingen van je organisatie gelden, ook de maximale looptijd.

Beperking: waar negeren goedkeuring vereist, kan alleen een goedkeurder een bevinding op een releasebranch negeren. De wachtrij voor aanvragen en goedkeuren dekt releasebranches nog niet. Een negering door iemand anders wordt geweigerd (403 approval-required via de API, een melding in de console) en de bevinding blijft openstaan.

Beveiligingsfixes

Een afhankelijkheidsbevinding met een gefixte versie kan een pull request van Beveiligingsfixes naar haar releasebranch krijgen. Alles aan de fix werkt zoals op je standaardbranch, met deze verschillen:

De pull request heeft de releasebranch als doel, vanuit een eigen branch security-fix/<branch>/<package>-<version>, bijvoorbeeld security-fix/release-1.x/lodash-4.17.21.
Hij lost elke openstaande bevinding voor dat pakket op die branch op, met de laagste versie die ze allemaal oplost.
Eén actieve fix per pakket per branch. Hetzelfde pakket op je standaardbranch en op release/1.x krijgt twee afzonderlijke fixes. De limieten van je organisatie tellen alle branches samen.
Een pull request die de run tegen een andere branch opent, wordt gesloten, met de reden scope_base.
Een fix telt als opgelost wanneer de volgende scan van de releasebranch zijn bevindingen niet meer meldt.

Hij wordt nooit automatisch samengevoegd, net als op de standaardbranch.

Pull requests naar een releasebranch

De checks op een pull request naar een releasebranch vergelijken hem met de laatste scan van die branch, niet met die van de standaardbranch. Een pull request wordt alleen tegengehouden door bevindingen die hij zelf introduceert. Een pull request die alleen configuratie wijzigt, wordt niet tegengehouden door bevindingen die al op de releasebranch staan.

API

Aanroep	Wat hij doet
`GET /orgs/{org}/security/release-branches`	De gescande releasebranches, elk met het aantal openstaande bevindingen.
`GET /orgs/{org}/security/findings?branch=release/1.x`	De bevindingen van die branch, in dezelfde vorm als die van de standaardbranch, plus `branch` en `fix_by`. Een onbekende branch geeft `404 unknown-branch`.
`POST /orgs/{org}/security/release-findings/{id}/dismiss`	Negeren op die branch: `reason`, optioneel `expires_at`.
`POST /orgs/{org}/security/release-findings/{id}/autofix`	Een beveiligingsfix voor die branch in de wachtrij zetten. Het antwoord bevat `base_branch`.

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

Lezen vereist findings:read, negeren en fixes vereisen findings:write. Zie de API-referentie voor elk veld.

Als Forgejo niet bereikbaar is

Om een scan te registreren, moet fremforge weten of de gescande branch de standaardbranch is. Kan Forgejo dat niet zeggen, dan wordt de scan niet weggegooid, en er wordt ook niet gegokt. Hij wordt vastgehouden en geregistreerd zodra Forgejo antwoordt, normaal gesproken binnen enkele minuten. Tot die tijd tonen de bevindingen van die branch de vorige scan.

Hersteltermijn (SLA)Kwetsbaarheden melden