Gå til hovedinnhold

Sikkerhetsvarsler for repositoryene dine

Når noen finner en svakhet i programvare du vedlikeholder, retter du den først og forteller om den etterpå. Et sikkerhetsvarsel er måten du forteller det på: en kort, strukturert beskrivelse av hva som er berørt, hvor alvorlig det er, og hvilken versjon som retter det. Skannere leser sikkerhetsvarsler for å advare alle som er avhengige av pakken din.

fremforge oppbevarer en organisasjons sikkerhetsvarsler under Sikkerhet › Rapporter › Sårbarhetsvarsler, og gjennom API-et på /_app/api/v1/orgs/{org}/security-advisories.

Utkast i det skjulte

Nytt sårbarhetsvarsel åpner et utkast. Et utkast angir:

  • repositoryet det gjelder;
  • en tittel på én linje og en beskrivelse: hva svakheten er, hvem som er berørt, konsekvensen, og hvordan den rettes eller omgås;
  • de berørte pakkene, hver med økosystem, pakkenavn, sårbare versjoner og den første rettede versjonen;
  • alvorlighetsgraden, som en CVSS-vektor eller et nivå (critical, high, medium, low);
  • svakhetene (CWE-id-er), en valgfri CVE-id og referanser.

Et utkast er bare synlig for:

Tittel, beskrivelse, referanser og kommentarer lagres kryptert. Verken fremforges egne driftsverktøy eller AI-agenter ser teksten eller hvem som skrev den.

De som kan se et utkast, kan diskutere det i konfidensielle kommentarer. De forblir private, også etter at varselet er publisert.

Sårbare versjoner

Skriv de sårbare versjonene som én eller to betingelser, på samme form som GitHub bruker:

Du skriverBetyr
< 1.2.3alle versjoner før 1.2.3
>= 1.0.0, < 1.2.3fra 1.0.0 opp til, men ikke med, 1.2.3
<= 2.0.1alle versjoner til og med 2.0.1
= 3.1.0bare 3.1.0

> avvises: OSV-formatet har ingen eksklusiv nedre grense, så bruk >=. Med < X er den første rettede versjonen X. La Rettet versjon stå tom, eller bruk <= for den siste berørte versjonen.

Økosystemer: npm, PyPI, Maven (groupId:artifactId), Go (modulstien), crates.io, RubyGems, NuGet, Packagist, Pub, Hex, GitHub Actions (owner/repository), SwiftURL og CRAN.

Alvorlighetsgrad

En CVSS 3.1-basisvektor bestemmer alvorlighetsgraden ut fra basispoengene, som fremforge beregner. En CVSS 4.0-basisvektor sjekkes og beholdes slik den er oppgitt. Velg da alvorlighetsgraden selv: CVSS 4.0-poengene beregnes ikke.

Publisere

Publiser varselet krever en alvorlighetsgrad og minst én berørt pakke.

  • For et offentlig repository (ikke privat, i en organisasjon med offentlig synlighet) blir varselet offentlig med en gang: en side på https://frem.sh/_app/advisories/<id> og en OSV-post (se under). Om repositoryet er offentlig, sjekkes på nytt ved hver offentlig lesing. Gjør du repositoryet privat senere, slutter varslene å bli levert ved neste lesing.
  • For et privat repository forblir varselet bare synlig i organisasjonen din. Det blir ikke offentlig om du åpner repositoryet senere; publiser i så fall et nytt.

Slipp rettelsen før du publiserer: varselet forteller alle hvor svakheten er.

Rettelsen utvikles foreløpig utenfor fremforge. Et varsel inneholder tekst; fremforge har ingen midlertidig privat fork for det. Et privat repository i organisasjonen din ville vært lesbart for alle team med tilgang til alle repositoryer, som som standard omfatter Members og Viewers, så det tilbys ikke. Utvikle rettelsen slik prosjektet ditt håndterer upubliserte sikkerhetsrettelser, og publiser varselet når den rettede versjonen er sluppet.

Hvert varsel har en id på formen FFSA-xxxx-xxxx-xxxx, som fastsettes når utkastet opprettes.

Administratorer av repositoryet

Administratorene av et repository håndterer sikkerhetsvarslene og de private rapportene for det repositoryet uten å være eiere av organisasjonen, slik GitHub lar administratorer av repositoryer gjøre det. De finner rapportene som er sendt til repositoryene de administrerer, under Reports to repositories you administer på /_app/security-reports, kan godta eller avvise dem, og kan lese og kommentere utkastene for disse repositoryene. Om noen administrerer et repository, spørres frem.sh om ved hver forespørsel, så en endring i tilganger gjelder med en gang. En eier av organisasjonen regnes som administrator av alle repositoryer i organisasjonen.

Samarbeidspartnere

Inviter personer til et utkast eller et publisert varsel med frem.sh-brukernavnet deres, for eksempel en ekstern forsker eller en vedlikeholder fra et annet prosjekt. De trenger ikke være medlemmer av organisasjonen din. En invitert person leser varselet og de konfidensielle kommentarene, og legger til kommentarer, fra sin egen side på /_app/security-reports. Vedkommende kan ikke endre eller publisere det. Fjerner du personen, opphører tilgangen med en gang. Opptil 20 personer kan inviteres til ett varsel.

Privat sårbarhetsrapportering

Med privat sårbarhetsrapportering slått på kan alle som er logget inn på frem.sh og kan lese et repository, rapportere en svakhet i det til deg privat, også personer utenfor organisasjonen din. Uten den må den som finner svakheten, gjette en e-postadresse eller åpne en offentlig issue.

Den er av til du slår den på. Eiere angir en standard for hele organisasjonen under Sikkerhet › Rapporter › Sårbarhetsvarsler › Innstillinger, og kan slå den av eller på for enkeltrepositoryer der; en innstilling på et repository overstyrer standarden.

Hva en rapportør sender

Rapportskjemaet ligger på https://frem.sh/_app/security-reports/new?repo=<org>/<repository>. Lenk til det fra SECURITY.md i repositoryet ditt. En rapport har en tittel, en beskrivelse, de berørte versjonene, hvordan svakheten ble funnet og et valgfritt konseptbevis (proof of concept). Den lagres kryptert, og bare organisasjonens eiere, repositoryets administratorer og rapportøren ser den. Teksten havner aldri i en e-post eller i revisjonsloggen; revisjonsloggen navngir rapporter med id.

For at kanalen skal forbli brukbar, begrenser fremforge rapportene:

  • 3 per person til ett repository, og 10 per person totalt, innen 24 timer;
  • ingen fra en konto som er mindre enn 24 timer gammel;
  • 5 i minuttet fra én IP-adresse.

En forespørsel som ville bryte en grense, avvises, og ingenting lagres.

Avgjøre en rapport

Organisasjonens eiere får en e-post når en rapport kommer inn, og finner den under Sikkerhet › Rapporter › Sårbarhetsvarsler › Private rapporter. Repositoryets administratorer finner den på sin egen side på /_app/security-reports.

  • Godta lager et utkast til varsel fra rapporten, inviterer rapportøren til det som samarbeidspartner, og ber vedkommende godta en reporter-kreditering.
  • Ikke godta lukker rapporten med en begrunnelse: ikke en sårbarhet, duplikat, utenfor omfang, spam eller annet.

Uansett får rapportøren beskjed på e-post. En rapportør kan trekke tilbake en rapport til den er avgjort. En avvist rapport slettes 2 år etter at den ble avvist. Godtatte rapporter og varslene deres blir værende hos organisasjonen din.

Skanning av avhengigheter

Et publisert varsel matches mot organisasjonens oversikt over avhengigheter hver dag og rett etter at du publiserer det: et repository som er avhengig av en berørt versjon, får et funn under Sikkerhet › Funn › Avhengigheter, med varselets FFSA-id, som enhver annen sårbarhet. Trekker du tilbake varselet, fjernes funnene det skapte.

For andre organisasjoner matches et varsel bare når det er med i fremforges plattformfeed. Det krever, sjekket på nytt hver dag:

  • at repositoryet er offentlig; og
  • at organisasjonen din beviselig eier alle berørte pakker: en pakke fra organisasjonen din i frem.sh-pakkeregisteret, eller en Go-modul under frem.sh/<your organisation>/; ellers at fremforge har gjennomgått varselet og godkjent det.

Eierskap hentes fra frem.sh’ egne registre, aldri fra pakkenavnet: et npm-scope eller en modulsti som bare ligner på navnet til organisasjonen din, teller ikke. Mister du pakken eller gjør repositoryet privat, forlater varselet plattformfeeden ved neste daglige kjøring. Plattformfeeden leveres på /_app/api/v1/advisories?scope=platform, og fremforge legger den inn i OSV-databasene skannerne leser.

Trekke tilbake, lukke, slette

  • Et publisert varsel trekkes tilbake, det slettes aldri. Det blir værende i feeden med withdrawn satt, slik at skannere får vite at det ikke lenger gjelder.
  • Et utkast du ikke publiserer, kan lukkes (og åpnes igjen) eller slettes sammen med kommentarene.

Krediteringer

Krediter personene som fant, rapporterte eller rettet svakheten, med frem.sh-brukernavnet deres og en OSV-krediteringstype. En kreditering vises offentlig og eksporteres først når den krediterte personen har godtatt den, på sin egen side på /_app/security-reports. Å kreditere deg selv krever ingen godkjenning.

Eksport: OSV og CSAF

Alle varsler, også utkast, kan lastes ned som:

  • OSV 1.6: formatet skannere for avhengigheter leser (osv-scanner, Trivy og fremforges egen skanning av avhengigheter);
  • CSAF 2.0: et csaf_security_advisory-dokument, det maskinlesbare formatet for sikkerhetsvarsler som veiledningen under EUs Cyber Resilience Act og BSI forventer fra produsenter. Et utkast er TLP AMBER med status draft, et publisert varsel TLP WHITE med status final.

Hver nedlasting registreres i revisjonsloggen (security.advisory.exported), fordi eksporten av et utkast beskriver en svakhet som ikke er rettet ennå.

Den offentlige OSV-feeden

Publiserte varsler for offentlige repositoryer leveres uten autentisering, eldste endring først, høyst 100 per side:

# The first page
curl -s 'https://frem.sh/_app/api/v1/advisories?limit=100'

# The next page: pass the `next` value of the previous answer as `since`
curl -s 'https://frem.sh/_app/api/v1/advisories?since=2026-10-25T00:00:00Z'

# One advisory
curl -s https://frem.sh/_app/api/v1/advisories/FFSA-xxxx-xxxx-xxxx

Hver post følger OSV-skjemaet, med CVE-id-en (hvis den finnes) som alias og database_specific.source satt til fremforge. Om repositoryet er offentlig, sjekkes ved hver forespørsel, så et varsel for et repository som er gjort privat, leveres ikke ved neste lesing. De offentlige lesingene er begrenset til 60 forespørsler i minuttet per klientadresse (429 over det).

Be om en CVE-id

fremforge er ikke en CVE Numbering Authority og ber ikke om CVE-id-er på dine vegne. Under Be om en CVE-ID gir et varsel deg innholdet som tekst til MITREs skjema for CVE-forespørsler, eller til den CNA-en som dekker prosjektet ditt, hvis det finnes en. Send det selv, og legg deretter inn CVE-id-en du får, i varselet. API-et har den samme teksten på /orgs/{org}/security-advisories/{id}/cve-request.

EUs Cyber Resilience Act

CRA forventer at en produsent håndterer sårbarheter i produktene sine: retter dem og publiserer informasjon om de som er rettet. Sikkerhetsvarsler med CSAF-eksport støtter dette. De gjør deg ikke regelverksetterlevende alene, og fremforge rapporterer ingenting til ENISA eller et nasjonalt CSIRT på dine vegne. Rapportering etter CRA artikkel 14 er fortsatt ditt ansvar.

Ikke tilgjengelig ennå

  • En midlertidig privat fork å utvikle rettelsen i: tilbys ikke, se Publisere.

API

Metode og stiScopeGjør
GET /orgs/{org}/security-advisoriesfindings:read / advisories:readlister (?state=, ?repo=)
POST /orgs/{org}/security-advisoriespolicy:writeoppretter et utkast
GET, PUT, DELETE /orgs/{org}/security-advisories/{id}findings:read eller advisories:read / policy:writeleser, erstatter, sletter et utkast eller et lukket varsel
POST .../{id}/publish, /close, /reopen, /withdrawpolicy:writeendrer tilstanden
GET .../{id}/osv, /csaf, /cve-requestfindings:read eller advisories:readeksport
POST .../{id}/credits, DELETE .../{id}/credits/{credit}policy:writekrediteringer
GET, POST .../{id}/commentsadvisories:read / policy:writekonfidensielle kommentarer

findings:read leser bare publiserte varsler for offentlige repositoryer, med bare godtatte krediteringer. Utkast, lukkede varsler, varsler for private repositoryer og kommentarene til alle varsler krever advisories:read, som findings:read ikke omfatter, og som tokener utstedt for CI-jobber ikke har som standard. En kreditering navngir en frem.sh-bruker: et ukjent brukernavn avvises.

De fullstendige skjemaene finner du i API-referansen.