Kwetsbaarheid en incidentafhandeling

Rapporten van kwestbaarheden product

Zie ook

Lees AI gebruiken om issues te maken in het geval u AI hebt gebruikt om een beveiligingsprobleem Weblate vast te stellen.

Het ontwikkelteam van Weblate is sterk verbonden met het verantwoordelijk rapporteren en onthullen van aan beveiliging gerelateerde problemen. We hebben beleid ontwikkeld, en volgen dat, dat is gericht op het tijdig leveren van beveiligingsupdates voor Weblate.

Rapporten over kwetsbaarheden in het product betreffen beveiligingsproblemen in de broncode van Weblate, artefacten van uitgaven en gedocumenteerde eigenschappen van de beveiliging van Weblate. Ze vervangen niet de beantwoording van operationele incidenten voor een bepaalde uitrol.

Rapporten die over de zelfstandig verspreidde Weblate Client (wlc) gaan worden beoordeld tegen het wlc threat model die documenteert de bedoelde vertrouwensgrenzen, ondersteunde beveiligingseigenschappen en expliciete niet-doelen.

De meeste normale problemen in Weblate worden gerapporteerd in ons publieke GitHub volgsysteem voor problemen, maar door de gevoelige status van problemen met beveiliging, vragen we om die niet op deze manier openbaar te rapporteren.

In plaats daarvan, als u gelooft dat u iets in Weblate hebt gevonden dat implicaties voor de beveiliging heeft, dien dan een beschrijving van het probleem in bij security@weblate.org, GitHub, of gebruik HackerOne.

Zelfgehoste operators zouden dit proces moeten gebruiken als ze geloven dat een incident in hun eigen uitrol wordt veroorzaakt door een kwetsbaarheid in het product Weblate. Lokale isolatie, herstellen, notificeren van gebruikers, escalatie naar provider en andere beantwoording van uitrolspecifieke incidenten blijven de verantwoordelijkheid van de operator.

Een lid van het beveiligingsteam zal u binnen 48 uur antwoord geven, en afhankelijk van welke actie is ondernomen, zou u meer opvolg-e-mails kunnen krijgen. Verdachte actieve exploitatie en ernstige beveiligingsincidenten krijgen onmiddellijke interne aandacht onder Incidenten rapporteren. Bevestigen van een rapport of voltooien van een onderzoek stelt niet de deadlines voor rapporteren uit.

Notitie

Versleutelde rapporten verzenden

Als u een versleutelde e-mail wilt verzenden (optioneel), gebruik dan de publieke sleutel voor security@weblate.org met ID 8EA7 6E43 0976 3323 C2E3 D5A0 C472 9F23 8A80 EA93.

Deze publieke sleutel is beschikbaar op de meeste gebruikte sleutelservers, met WKD of direct vanuit weblate.org.

Hint

Weblate is voor veel dingen afhankelijk van onderdelen van derde partijen. In het geval dat u een kwetsbaarheid vindt die in het algemeen een van deze onderdelen beïnvloedt, rapporteer het direct naar het respectievelijke project. Als het ook een meegedistribueerd artefact van Weblate beïnvloedt of een uitrol van Weblate, rapporteer die impact dan bij Weblate via bovenstaande privékanalen.

Enkele hiervan zijn:

• Django

• Django REST framewerk

• Python Social Auth

Zie ook

• Problemen rapporteren in Weblate

Security research and testing

When researching security issues in Weblate:

• Use the Sandbox translation project for testing on Hosted Weblate.

• Only interact with accounts you own or have explicit permission from the account holder to use.

• Avoid privacy violations, data destruction, and service interruption or degradation.

• Do not perform denial-of-service attacks, spam, social engineering (including phishing), or physical attacks.

• Obtain explicit permission from the operator before testing other deployments.

You may report availability vulnerabilities demonstrated safely in an environment you control. The prohibition on disruptive testing does not exclude these reports.

Incidenten met door Weblate uitgevoerde services

Operationele incidenten die Hosted Weblate, Dedicated Weblate of andere door Weblate s.r.o. uitgevoerde uitrollen beïnvloeden, worden afgehandeld met Incident herstelplan (Incident response plan (IRP)) voor Weblate.

Wanneer een dergelijk incident ook de kwetsbaarheid van een product Weblate betreft, volgen het rapport van de kwetsbaarheid en publieke adviezen het proces voor het rapporteren van een kwetsbaarheid in het product en Beleid voor openbaar maken kwetsbaarheden op deze pagina.

Incidenten met zelfgehoste uitrollen

Operators van zelfgehoste uitrollen van Weblate zijn verantwoordelijk voor hun lokale proces voor beantwoording van incidenten, inclusief isolatie, herstellen, notificatie en provider-specifieke escalatie. Het door Weblate gebruikte Incident herstelplan (Incident response plan (IRP)) voor Weblate mag worden gebruikt als verwijzing, maar is niet een onderhouden plan voor beantwoording van incidenten voor uitrollen van derde partijen.

Als een zelfgehost incident lijkt te zijn veroorzaakt door een kwetsbaarheid in het product Weblate, rapporteer dat dan met het proces voor het rapporteren van een kwetsbaarheid in het product hierboven.

Beleid voor openbaar maken kwetsbaarheden

Weblate publiceert een beveiligingsadvies naast een uitgave die de reparatie van een kwetsbaarheid repareert op https://github.com/WeblateOrg/weblate/security/advisories. Het advies identificeert de geraakte versies, impact, ernst en stappen die gebruikers kunnen nemen om de kwetsbaarheid op te lossen.

Technische details zouden kunnen worden vertraagd als het publiceren ervan meer beveiligingsrisico’s dan voordelen zou opleveren, terwijl gebruikers de reparatie toepassen. De incidentafhandelaar legt de reden en een beoordelingsdatum vast in de privé incidentnotitie. Dit vertraagt niet de rapporten aan autoriteiten of beschermende adviezen die gebruikers nodig hebben.

Rapportage aan autoriteiten

Weblate adopteert de volgende tijdlijnen als een vrijwillige beleidsregel voor actief geëxploiteerde kwetsbaarheden in Weblate-producten en ernstige productbeveiligingsincidenten. Dit omvat ook getroffen meegeleverde afhankelijkheden en incidenten die bekend werden via zelf gehoste uitrollen. Ernstige beveiligingsincidenten die een effect hebben op door Weblate uitgevoerde services volgen deze beleidsregel ook.

Verslag	Deadline
Vroege waarschuwing	Zonder onnodige vertraging, binnen 24 uur na bewustwording.
Hoofdmeldingen	Zonder onnodige vertraging, binnen 72 uur na bewustwording.
Eindrapport voor een actief misbruikte kwetsbaarheid	Binnen 14 dagen nadat een correctieve of beperkende maatregel beschikbaar komt.
Eindrapport voor een ernstig incident	Binnen één kalendermaand na de primaire incidentmelding.

Uren bevatten ook weekends en feestdagen. Erkenning, incidentdeclaratie, overdragen of voltooien van een onderzoek herstart deze klokken niet. Als een gebeurtenis zowel actieve exploitatie als een ernstig incident betreft, worden voor beide verplichtingen voor rapporteren en deadlines voor uiteindelijke rapporten bijgehouden.

Deze tijdlijnen volgt de European Commission reporting guidance. De incidentafhandelaar legt vast of verplicht of vrijwillig rapporteren van toepassing is en gebruikt de corresponderende route. Voor CRA-rapportage vermeld de Single Reporting Platform routes voor notificaties aan de coördinerende CSIRT en ENISA. Dit beleid bepaalt niet de regelende rol van Weblate of claim voor compliance; bekijk Product- en contactinformatie.

Voor classificatie, stappen om in te dienen en privé incident vastleggen, bekijk Incidenten rapporteren.

Gebruikersmeldingen

Weblate informeert getroffen gebruikers van actieve exploitatie of ernstige beveiligingsincidenten zonder onnodige vertraging, inclusief beschikbare beperkende en correctieve acties. Waar van toepassing richten waarschuwingen zich op alle gebruikers. Bekende getroffen contacten, inclusief klanten van Hosted en Dedicated Weblate, ontvangen e-mailnotificaties. Publieke GitHub-beveiligingsadviezen verschaffen waarschuwingen en updates voor zelf gehoste gebruikers waarvan geen contactdetails bekend zijn.

Initiële waarschuwingen kunnen beschermend advies bevatten voordat een reparatie of een gedetailleerde onthulling van de kwetsbaarheid klaar is. Rapporteren aan autoriteiten, waarschuwingen voor gebruikers en publiceren van technische details gaan, waar nodig, afzonderlijk door.

Inbreuken op persoonlijke gegevens vereisen ook een afzonderlijke beoordeling van notificaties aan getroffen individuen, zelfs als er geen actieve exploitatie of ernstig productbeveiligingsincident is.