ການຈັດການຊ່ອງໂຫວ່ ແລະ ອຸບັດຕິເຫດ

ລາຍງານຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນ

See also

ກະລຸນາອ່ານ ການໃຊ້ AI ເພື່ອສ້າງ Issues ໃນກໍລະນີທີ່ທ່ານໃຊ້ AI ເພື່ອຄົ້ນພົບບັນຫາຄວາມປອດໄພໃນ Weblate.

ທີມພັດທະນາຂອງ Weblate ມີຄວາມມຸ່ງໝັ້ນຢ່າງແຮງກ້າຕໍ່ການລາຍງານ ແລະ ການເປີດເຜີຍບັນຫາທີ່ກ່ຽວຂ້ອງກັບຄວາມປອດໄພຢ່າງມີຄວາມຮັບຜິດຊອບ. ພວກເຂົາໄດ້ຮັບເອົາ ແລະ ປະຕິບັດຕາມນະໂຍບາຍທີ່ເນັ້ນໃສ່ການສົ່ງມອບການອັບເດດຄວາມປອດໄພໃຫ້ Weblate ຢ່າງທັນການ.

ລາຍງານຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນກວມເອົາບັນຫາຄວາມປອດໄພໃນ Source code ຂອງ Weblate, ສິ່ງປະດິດທີ່ປ່ອຍອອກມາ (release artifacts), ແລະ ຄຸນສົມບັດດ້ານຄວາມປອດໄພຂອງ Weblate ທີ່ໄດ້ບັນທຶກໄວ້. ມັນບໍ່ໄດ້ທົດແທນການຕອບໂຕ້ອຸບັດຕິເຫດທາງການດຳເນີນງານສຳລັບການຕິດຕັ້ງສະເພາະໃດໜຶ່ງ.

ລາຍງານກ່ຽວກັບ Weblate Client (wlc) ທີ່ແຈກຢາຍແຍກຕ່າງຫາກ ຈະຖືກປະເມີນຕາມ wlc threat model, ເຊິ່ງລະບຸຂອບເຂດຄວາມໄວ້ວາງໃຈທີ່ຕັ້ງໄວ້, ຄຸນສົມບັດດ້ານຄວາມປອດໄພທີ່ຮອງຮັບ ແລະ ເປົ້າໝາຍທີ່ບໍ່ກ່ຽວຂ້ອງ.

ບັນຫາປົກກະຕິສ່ວນໃຫຍ່ໃນ Weblate ຈະຖືກລາຍງານໃສ່ GitHub issues tracker ສາທາລະນະຂອງພວກເຂົາ, ແຕ່ເນື່ອງຈາກລັກສະນະທີ່ລະອຽດອ່ອນຂອງບັນຫາຄວາມປອດໄພ, ພວກເຮົາຈຶ່ງຂໍໃຫ້ບໍ່ລາຍງານຕໍ່ສາທາລະນະໃນຮູບແບບນີ້.

ແທນທີ່ຈະເປັນແບບນັ້ນ, ຖ້າທ່ານເຊື່ອວ່າທ່ານພົບສິ່ງໃດໜຶ່ງໃນ Weblate ທີ່ມີຜົນສະທ້ອນດ້ານຄວາມປອດໄພ, ກະລຸນາສົ່ງຄຳອະທິບາຍບັນຫາໄປທີ່ security@weblate.org, GitHub, ຫຼື ໂດຍໃຊ້ HackerOne.

ຜູ້ປະຕິບັດງານແບບ Self-hosted ຄວນໃຊ້ຂະບວນການນີ້ເມື່ອພວກເຂົາເຊື່ອວ່າອຸບັດຕິເຫດໃນການຕິດຕັ້ງຂອງຕົນເອງເກີດຈາກຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນ Weblate. ການຄວບຄຸມໃນລະດັບທ້ອງຖິ່ນ, ການກູ້ຄືນ, ການແຈ້ງເຕືອນລູກຄ້າ, ການຍົກລະດັບຫາຜູ້ໃຫ້ບໍລິການ, ແລະ ການຕອບໂຕ້ອຸບັດຕິເຫດສະເພາະອື່ນໆໃນການຕິດຕັ້ງ ຍັງຄົງເປັນຄວາມຮັບຜິດຊອບຂອງຜູ້ປະຕິບັດງານ.

A member of the security team will respond to you within 48 hours, and depending on what action is taken, you may get more follow-up emails. Suspected active exploitation and severe security incidents receive immediate internal attention under Incident reporting. Acknowledging a report or completing an investigation does not postpone reporting deadlines.

Note

ການສົ່ງລາຍງານແບບເຂົ້າລະຫັດ

ຖ້າທ່ານຕ້ອງການສົ່ງອີເມລແບບເຂົ້າລະຫັດ (ທາງເລືອກ), ກະລຸນາໃຊ້ Public key ສຳລັບ security@weblate.org ທີ່ມີ ID 8EA7 6E43 0976 3323 C2E3 D5A0 C472 9F23 8A80 EA93.

Public key ນີ້ມີໃຫ້ບໍລິການໃນ Key servers ທີ່ໃຊ້ກັນທົ່ວໄປທີ່ສຸດ, ໂດຍໃຊ້ WKD ຫຼື ໂດຍກົງຈາກ weblate.org.

Hint

Weblate depends on third-party components for many things. In case you find a vulnerability affecting one of those components in general, please report it directly to the respective project. If it also affects a shipped Weblate artifact or a Weblate deployment, report that impact to Weblate through the private channels above.

ບາງຢ່າງໃນນັ້ນໄດ້ແກ່:

• Django

• Django REST framework

• Python Social Auth

See also

• ການລາຍງານບັນຫາໃນ Weblate

ອຸບັດຕິເຫດການບໍລິການທີ່ດຳເນີນງານໂດຍ Weblate

ອຸບັດຕິເຫດທາງການດຳເນີນງານທີ່ມີຜົນກະທົບຕໍ່ Hosted Weblate, Dedicated Weblate, ຫຼື ການຕິດຕັ້ງອື່ນໆທີ່ດຳເນີນງານໂດຍ Weblate s.r.o. ຈະຖືກຈັດການໂດຍໃຊ້ ແຜນການຕອບໂຕ້ອຸບັດຕິເຫດສຳລັບ Weblate.

ເມື່ອອຸບັດຕິເຫດດັ່ງກ່າວຍັງກ່ຽວຂ້ອງກັບຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນ Weblate, ລາຍງານຊ່ອງໂຫວ່ ແລະ ຄຳແນະນຳສາທາລະນະຈະປະຕິບັດຕາມຂະບວນການລາຍງານຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນ ແລະ ນະໂຍບາຍການເປີດເຜີຍຊ່ອງໂຫວ່ ໃນໜ້ານີ້.

ອຸບັດຕິເຫດໃນການຕິດຕັ້ງແບບ Self-hosted

ຜູ້ປະຕິບັດງານຂອງການຕິດຕັ້ງ Weblate ແບບ Self-hosted ມີຄວາມຮັບຜິດຊອບຕໍ່ຂະບວນການຕອບໂຕ້ອຸບັດຕິເຫດໃນລະດັບທ້ອງຖິ່ນຂອງຕົນເອງ, ລວມທັງການຄວບຄຸມ, ການກູ້ຄືນ, ການແຈ້ງເຕືອນ, ແລະ ການຍົກລະດັບຫາຜູ້ໃຫ້ບໍລິການສະເພາະ. ແຜນການຕອບໂຕ້ອຸບັດຕິເຫດສຳລັບ Weblate ທີ່ດຳເນີນງານໂດຍ Weblate ສາມາດໃຊ້ເປັນອ້າງອີງໄດ້, ແຕ່ມັນບໍ່ແມ່ນແຜນການຕອບໂຕ້ອຸບັດຕິເຫດທີ່ໄດ້ຮັບການຮັກສາໄວ້ສຳລັບການຕິດຕັ້ງຂອງບຸກຄົນທີສາມ.

ຖ້າອຸບັດຕິເຫດໃນການຕິດຕັ້ງແບບ Self-hosted ເບິ່ງຄືວ່າເກີດຈາກຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນ Weblate, ໃຫ້ລາຍງານໂດຍໃຊ້ຂະບວນການລາຍງານຊ່ອງໂຫວ່ຂອງຜະລິດຕະພັນຂ້າງເທິງ.

ນະໂຍບາຍການເປີດເຜີຍຊ່ອງໂຫວ່

Weblate publishes a security advisory alongside a release containing a vulnerability fix at https://github.com/WeblateOrg/weblate/security/advisories. Advisories identify affected versions, impact, severity, and steps users can take to remediate the vulnerability.

Technical details may be delayed when publishing them would create greater security risks than benefits while users apply the fix. The incident handler records the reason and a review date in the private incident note. This does not delay authority reports or protective advice users need.

Authority reporting

Weblate adopts the following reporting timelines as a voluntary policy baseline for actively exploited Weblate product vulnerabilities and severe product-security incidents. This includes affected shipped dependencies and incidents learned about through self-hosted deployments. Severe security incidents affecting Weblate-operated services also follow this baseline.

ລາຍງານ	Deadline
Early warning	Without undue delay, within 24 hours of awareness.
Main notification	Without undue delay, within 72 hours of awareness.
Final report for an actively exploited vulnerability	Within 14 days after a corrective or mitigating measure becomes available.
Final report for a severe incident	Within one calendar month after the main incident notification.

Hours include weekends and holidays. Acknowledgment, incident declaration, handover, or completion of an investigation does not restart these clocks. When an event involves both active exploitation and a severe incident, track both reporting obligations and final-report deadlines.

These timelines follow the European Commission reporting guidance. The incident handler records whether mandatory or voluntary reporting applies and uses the corresponding route. For CRA reporting, the Single Reporting Platform routes notifications to the coordinating CSIRT and ENISA. This policy does not determine Weblate's regulatory role or claim compliance; see ຂໍ້ມູນຜະລິດຕະພັນ ແລະ ຂໍ້ມູນຕິດຕໍ່.

For classification, submission steps, and private incident records, see Incident reporting.

User notifications

Weblate informs impacted users of active exploitation or severe security incidents without undue delay, including available mitigations and corrective actions. Where appropriate, warnings address all users. Known affected contacts, including Hosted and Dedicated Weblate customers, receive e-mail notifications. Public GitHub security advisories provide warnings and updates for self-hosted users whose contact details are not known.

Initial warnings can provide protective advice before a fix or detailed vulnerability disclosure is ready. Authority reporting, user warnings, and publication of technical details proceed separately as needed.

Personal-data breaches also require a separate assessment of notifications to affected individuals, even when there is no active exploitation or severe product-security incident.