Retningslinjer for sårbarhetsrapportering

Har du funnet et sikkerhetsproblem i fremforge, forteller denne siden deg hvordan du rapporterer det, hva som er innenfor omfanget, hva som ikke er det, og hva vi lover deg tilbake. Vi følger ISO/IEC 29147 (sårbarhetsrapportering) og RFC 9116 (security.txt).

Den maskinlesbare utgaven av denne siden ligger på /.well-known/security.txt på hvert domene fremforge drifter. Forskere og automatiserte verktøy bør bruke det endepunktet; denne siden finnes for mennesker som kommer fra et søkeresultat.

Slik rapporterer du

• E-post: security@frem.sh (fingeravtrykket til PGP-nøkkelen står i security.txt).
• Foretrukket kanal: kryptert e-post. Vanlig e-post godtas; SMTP TLS til mailbox.org er påkrevd ved levering.
• Mål for bekreftelse: innen 24 timer.
• Mål for triagering: innen 5 virkedager sender vi deg vår vurdering av alvorlighetsgraden, forventet tidsvindu for rettelsen og en sporingsreferanse.

Ikke opprett offentlige issues på frem.sh eller legg ut detaljer i sosiale medier eller fora før vi har avtalt en dato for offentliggjøring.

Hva som er innenfor omfanget

• frem.sh og hvert underdomene vi drifter (*.frem.sh).
• fremverk.com og *.fremverk.com.
• Containerimager som fremforge publiserer (imaget for hostede runnere og plattformimagene).
• Problemer i fremforges kunderettede API, administrasjonsgrensesnitt eller CI-runnere.

Hva som er utenfor omfanget (og ikke belønnes)

• Funn i innhold kundene eier – kode, secrets, filer i kundenes repositoryer. Rapporter dem direkte til kunden; det er en hendelse på kundens side.
• Sårbarheter i våre upstream-avhengigheter med åpen kildekode (for eksempel en CVE i selve forgejo). Rapporter dem til upstream-prosjektets program for sårbarhetsrapportering. Vi følger med på dem og patcher dem når en CVE er offentlig.
• Problemer som krever fysisk tilgang, social engineering mot fremverks ansatte eller tredjepartstjenester på samme nettverk som fremforge-brukere.
• Rapporter basert på utdatert informasjon (for eksempel et skjermbilde av en gammel administrasjonsside fra før en offentlig migrering).
• «Beste praksis»-funn uten et utnyttbart scenario (for eksempel «dere burde legge til header X») – nyttig, men ikke en sårbarhet.
• Rapporter om DDoS, brute force eller omgåelse av frekvensgrenser. Det er finjustering av infrastrukturen, ikke sikkerhetsfeil.

SLA for utbedring

Klokken starter når vi bekrefter rapporten.

Tidsplanen for offentliggjøring kan forlenges etter gjensidig avtale (for eksempel når rettelsen krever tiltak hos kunden som tar tid).

Safe harbour

Vi går ikke til sivilt eller strafferettslig søksmål mot deg og leverer ikke klager når forskningen din gjøres i god tro og du:

• Ikke leser, endrer eller sletter data som ikke tilhører deg. Bruk testkontoer der det er mulig.
• Ikke svekker tjenesten for andre brukere – ingen DoS, ingen skanning med stort volum, ingen automatisert brute force.
• Ikke henter ut mer data enn nødvendig for å vise konsekvensen. Noen få byte er nok; vi trenger ikke databasen.
• Rapporterer problemet privat via security@frem.sh og gir oss et rimelig tidsvindu til å rette det før du går ut offentlig.
• Følger gjeldende lov i jurisdiksjonen du opererer fra.

Forskning som gjøres i god tro på disse vilkårene, er autorisert etter Computer Misuse Act 1990 §17(5)(c) (UK), unntaket for «research» i Computer Fraud and Abuse Act 18 U.S.C. §1030(f) (der det gjelder) og tilsvarende regler i EUs medlemsstater. Der lokal lov krever uttrykkelig autorisasjon, utgjør denne siden den autorisasjonen.

Dusørprogram

Vi har foreløpig ikke et betalt dusørprogram (bug bounty). Vi har derimot en offentlig hall of fame for forskere som rapporterer bekreftede problemer og samtykker til å bli navngitt, og vi sender en takkepakke med fremverk-profil (t-skjorte, pin, klistremerker) for hver rapport vi ruller ut en rettelse for.

Vi regner med å formalisere et betalt program når fremforge når et antall kunder der det gir mening for begge parter – foreløpig planlagt for andre halvår 2026.

Historikk for offentliggjøringer

Når vi ruller ut en rettelse for et rapportert problem, publiserer vi en kort etteranalyse på statussiden og krediterer den som rapporterte (der det er samtykke). En egen indeks over sårbarhetsvarsler kommer på denne URL-en etter lansering.

Se også

• security.txt – den maskinlesbare utgaven av denne siden.
• Integritet i revisjonskjeden – relevant bakgrunn for rapporter om at «revisjonsloggen ikke kan spilles av på nytt av noen».
• Videresending til SIEM – relevant bakgrunn for rapporter om at «kunden ikke kan se hendelsen».