Beleid voor het melden van kwetsbaarheden

In een oogopslag

Deze pagina definieert het beleid van NextPDF voor gecoördineerde openbaarmaking van kwetsbaarheden. Ze beschrijft hoe u privé contact opneemt met de beheerders, welke responstermijn u kunt verwachten en hoe embargo’s werken.

Afbakening. Een openbaarmakingsbeleid is een procesverplichting, geen garantie op termijn of uitkomst. De onderstaande doelen zijn de toezeggingen te goeder trouw van de beheerders aan u als melder; zij beschrijven het proces dat het project volgt, geen contractuele belofte dat een specifieke melding wordt bevestigd, in triage wordt beoordeeld, verholpen of openbaar gemaakt op een specifieke datum. Over de timing van gecoördineerde openbaarmaking wordt onderhandeld; die wordt niet eenzijdig gegarandeerd.

Installeren

Niet van toepassing. U hoeft niets te installeren om een kwetsbaarheid te melden. Het machineleesbare contactoppervlak wordt gepubliceerd op /.well-known/security.txt (Request for Comments (RFC) 9116). De SECURITY.md in de repository is het gezaghebbende beleid voor mensen.

Conceptueel overzicht

Het beleid implementeert gecoördineerde openbaarmaking van kwetsbaarheden zoals gedefinieerd in ISO/IEC 29147 en het afhandelingsproces in ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): melding via een privékanaal, triage en beoordeling van de ernst, herstel onder embargo en gezamenlijke openbare publicatie. Als een kwetsbaarheid meerdere leveranciers treft, stemmen de getroffen partijen de timing van de advisory onderling af; die wordt niet eenzijdig vastgesteld (iso_iec_29147#x3.x110.p13).

Het proces sluit ook aan op de verplichtingen voor fabrikanten inzake het afhandelen van kwetsbaarheden uit de European Union (EU) Cyber Resilience Act (CRA) (eu_cra#x1.p191) en op de praktijk „respond to vulnerabilities” in het National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) (nist_sp_800_218#x15). Beide kaders beschrijven dit als herhaalbare procesverplichtingen, niet als een garantie op een specifieke uitkomst.

API-oppervlak

Niet van toepassing. Openbaarmaking is een proces, geen application programming interface (API). Het machineleesbare ontdekkingsoppervlak is het RFC 9116-bestand security.txt; tooling leest daaruit de velden Contact: en Expires:. Deze pagina herhaalt de inhoud van dat bestand alleen voor de onderstaande kanalen.

Codevoorbeeld — Snelstart

Niet van toepassing. Er is geen code die u uitvoert wanneer u een kwetsbaarheid meldt. Gebruik een privékanaal:

• GitHub Security Advisories (voorkeur — versleuteld in rust, auditlog): open een concept-advisory op het tabblad GitHub Security van het project.
• E-mail: [email protected] met [SECURITY] in het onderwerp. Als u end-to-endversleuteling nodig hebt en er nog geen gepubliceerde OpenPGP-sleutel in security.txt staat, gebruik dan in plaats daarvan het GitHub Security Advisory-kanaal.

Meld niet via openbare issues, openbare mailinglijsten, sociale media of chat. Openbaarmaking voordat er een oplossing is, brengt gebruikers van ongepatchte versies in gevaar.

Codevoorbeeld — Productie

Niet van toepassing.

Randgevallen en valkuilen

• Doelen zijn toezeggingen, geen service-level agreements (SLA’s). De onderstaande tijdlijn geeft aan wat het project beoogt te doen. Een complex probleem met meerdere componenten of een probleem dat afstemming met upstream vereist, kan langer duren; het project houdt de melder op de hoogte.
• De embargoduur is onderhandelbaar, met een bovengrens. Het standaardembargo loopt van triage tot de uitgave van de oplossing. Als u meer tijd nodig hebt, vraag dit dan expliciet aan wanneer u de advisory opent. Na het bereiken van het maximum publiceert het project de advisory, ongeacht of er een oplossing beschikbaar is, in overeenstemming met de gangbare normen voor gecoördineerde openbaarmaking in de sector. Dit voorkomt dat een advisory onbeperkt wordt achtergehouden.
• De ernst bepaalt het schema. Een kritiek, actief misbruikt probleem wordt op een verkorte tijdlijn afgehandeld; een verhardingsvoorstel met lage ernst niet. De ernst wordt tijdens de triage beoordeeld en kan worden herzien.
• De uitgifte van een Common Vulnerabilities and Exposures (CVE) maakt deel uit van de triage. De beheerder vraagt een CVE aan via de registratie van het project bij de GitHub Security Advisory CVE Numbering Authority (CNA) als onderdeel van de triagestap; de melder hoeft er niet afzonderlijk een aan te vragen.

Prestaties

Niet van toepassing.

Beveiligingsnotities

De doelen in de responstijdlijn zijn toezeggingen aan melders en vormen de basislijn van het project voor het afhandelen van kwetsbaarheden. Het zijn doelen, geen garanties:

Fase	Doel
Ontvangst bevestigen	binnen 1–2 werkdagen
Eerste triage + beoordeling van de ernst	binnen ~5 werkdagen / 7 kalenderdagen
Patchontwikkeling + private review	doorgaans 14 werkdagen; 30–90 dagen voor complexe bevestigde CVE’s, afhankelijk van de ernst
CVE-toewijzing (indien geaccepteerd)	gelijktijdig met de patch, via het GitHub CNA-kanaal
Gecoördineerde openbare openbaarmaking	bij de uitgave van de patch, op een datum die gezamenlijk met de melder wordt bepaald
Embargo (van triage tot uitgave)	standaard ~90 dagen, verkort bij actief misbruik, op expliciet verzoek verlengbaar tot een vast maximum

Reviewers kunnen deze procesregels toetsen:

1. Privé-eerst. Meldingen via openbare kanalen worden niet geaccepteerd. De enige geaccepteerde kanalen zijn de GitHub Security Advisory en de beveiligings-e-mail.
2. Gecoördineerd, niet eenzijdig. Over de timing van openbaarmaking wordt onderhandeld met de melder en eventuele mede-getroffen leveranciers (iso_iec_29147#x3.x110.p13).
3. Begrensd embargo. Het embargo heeft een standaardduur en een harde bovengrens; het project houdt een advisory niet onbeperkt achter.
4. Vermelding op verzoek. Onderzoekers worden vermeld nadat het embargo is opgeheven, tenzij zij om anonimiteit verzoeken.

Deze uitspraken beschrijven het proces dat het project zich ertoe verbindt te volgen. Zij garanderen niet dat een bepaalde melding leidt tot een oplossing, een CVE of een openbaarmaking op een specifieke datum.

Conformiteit

Geen conformiteitsprofiel. Het beleid sluit aan op ISO/IEC 29147, ISO/IEC 30111 en de hierboven genoemde procesverplichtingen uit de CRA en het SSDF; „aligned with” is een bewuste formulering. Het project claimt geen certificering tegen een van deze schema’s. Deze bronnen definiëren een degelijk proces; deze pagina documenteert de toezegging van het project om zo’n proces te hanteren.

Zie ook

• Trust center
• Dreigingsmodel van de engine
• Beveiligingsmodel voor handtekening en versleuteling
• SECURITY.md en /.well-known/security.txt in de repository (RFC 9116)