Policy för rapportering av sårbarheter

Om du har hittat ett säkerhetsproblem i fremforge berättar den här sidan hur du rapporterar det, vad som omfattas, vad som inte gör det och vad vi lovar tillbaka. Vi följer ISO/IEC 29147 (rapportering av sårbarheter) och RFC 9116 (security.txt).

Den maskinläsbara motsvarigheten till den här sidan finns på /.well-known/security.txt på varje domän som fremforge driver. Forskare och automatiserade verktyg bör använda den adressen; den här sidan finns för människor som kommer från ett sökresultat.

Så rapporterar du

• E-post: security@frem.sh (fingeravtrycket för PGP-nyckeln står i security.txt).
• Föredragen kanal: krypterad e-post. Okrypterad e-post tas emot; SMTP-TLS till mailbox.org är obligatoriskt vid leverans.
• Mål för bekräftelse: inom 24 timmar.
• Mål för triage: inom 5 arbetsdagar skickar vi dig vår bedömning av allvarlighetsgraden, det förväntade fönstret för en fix och en referens för uppföljning.

Öppna inte publika issues på frem.sh och lägg inte ut detaljer i sociala medier eller forum förrän vi har kommit överens om ett datum för offentliggörande.

Vad som omfattas

• frem.sh och varje underdomän vi driver (*.frem.sh).
• fremverk.com och *.fremverk.com.
• Container-images som fremforge publicerar (den hostade runner-imagen och plattformens images).
• Problem i fremforges kundvända API, administrationsgränssnitt eller CI-runners.

Vad som inte omfattas (och inte belönas)

• Fynd i innehåll som kunder äger: kod, hemligheter och filer i kunders repon. Rapportera dem direkt till kunden; det är en incident på kundsidan.
• Sårbarheter i våra uppströmsberoenden med öppen källkod (till exempel en CVE i själva forgejo). Rapportera dem till uppströmsprojektets program för rapportering. Vi följer och patchar dem när en CVE är publik.
• Problem som kräver fysisk åtkomst, social manipulation av fremverks personal eller tredjepartstjänster i samma nätverk som fremforges användare.
• Rapporter som bygger på inaktuell information (till exempel en skärmbild av en gammal administrationssida från före en publik migrering).
• Fynd om “god praxis” utan ett scenario som går att utnyttja (till exempel “ni borde lägga till headern X”): användbara, men ingen sårbarhet.
• Rapporter om DDoS, brute force eller kringgående av hastighetsbegränsningar. Det är justering av infrastruktur, inte säkerhetsbrister.

Åtgärdsfrist (SLA)

Klockan startar vid vår bekräftelse.

Tidsplanen för offentliggörande kan förlängas efter ömsesidig överenskommelse (till exempel när fixen kräver en åtgärd från kunden som tar tid).

Rättsligt skydd (safe harbour)

Vi kommer inte att vidta civilrättsliga eller straffrättsliga åtgärder mot dig, eller göra anmälningar, när din forskning bedrivs i god tro och du:

• Inte läser, ändrar eller raderar data som inte tillhör dig. Använd testkonton när det är möjligt.
• Inte försämrar tjänsten för andra användare: ingen DoS, ingen skanning i stor volym, ingen automatiserad brute force.
• Inte för ut mer data än vad som behövs för att visa effekten. Några byte räcker; vi behöver inte databasen.
• Rapporterar problemet privat via security@frem.sh och ger oss ett rimligt fönster att åtgärda det innan du går ut publikt.
• Följer tillämplig lag i den jurisdiktion du verkar från.

Forskning som bedrivs i god tro enligt de villkoren är auktoriserad enligt Computer Misuse Act 1990 §17(5)(c) (Storbritannien), undantaget för “research” i Computer Fraud and Abuse Act 18 U.S.C. §1030(f) (där det är tillämpligt), och motsvarigheterna i EU:s medlemsstater. Där lokal lag kräver uttrycklig auktorisering utgör den här sidan den auktoriseringen.

Bug bounty-program

Vi har för närvarande inget betalt bug bounty-program. Vi har en publik hall of fame för forskare som rapporterar verifierade problem och samtycker till att nämnas, och vi skickar ett tackpaket med fremverks profil (t-shirt, pin, klistermärken) för varje rapport som vi levererar en fix för.

Vi räknar med att formalisera ett betalt program när fremforge passerar den nivå av kunder där det är rimligt för båda sidor, för närvarande planerat till andra halvåret 2026.

Historik över offentliggöranden

När vi levererar en fix för ett rapporterat problem publicerar vi en kort efteranalys på statussidan med erkännande till den som rapporterade (om samtycke finns). Ett särskilt register över säkerhetsmeddelanden kommer att finnas på den här adressen efter lanseringen.

Se även

• security.txt: den maskinläsbara versionen av den här sidan.
• Granskningskedjans integritet: relevant bakgrund för rapporter om att “granskningsloggen kan inte spelas upp igen av någon”.
• Vidarebefordran till SIEM: relevant bakgrund för rapporter om att “kunden kan inte se händelsen”.