Weblate 事件响应计划

作用域和对象

事件响应计划涵盖影响 Weblate 运作的部署的机密性、完整性、或可用性的事件。

备注

此计划特为由 Weblate s.r.o 运作的部署而设计。其他部署需调整针对特定提供方的步骤和组织步骤以适合自身的环境。

Handling an incident

One team member handles the incident and names an available teammate as a backup. They coordinate investigation, containment, recovery, reporting, and user communication, asking other teammates or outside specialists for help when needed. The backup takes over when the handler is unavailable.

Use 事件报告 for reporting decisions, deadlines, and a private incident note. No separate management approval is needed to begin responding.

沟通工作

• 内部沟通：

  • 主要渠道是 Signal，用于人际协作。

  • 仍然不会在 Signal 中发布技术警报以避免信息噪音。

• 外部沟通：

  • 电子邮件 用于联系客户。

  • 我们在数个地点维护客户联系列表确保在服务中断期间的访问。

• 公开披露：

  • If an incident includes a Weblate product vulnerability, follow the product vulnerability reporting process and 漏洞披露政策 in 漏洞和事件处理.

事件类别和严重程度

事件激活

• 当确认事件或强烈怀疑事件会给服务带来超出日常运营噪音的机密性、完整性或可用性影响时宣布事故。

• Whoever identifies the incident alerts teammates through Signal. An available teammate takes responsibility, records the initial severity, and names a backup.

• 如果事件作用域或影响在调查期间改变重新分类事件。

事件类别

• 类别 1 – 未经授权的访问

• 类别 2 - 数据完整性违背

• 类别 3 - 服务中断或降级

• 类别 4 - 配置错误或部署错误

严重程度和 SLA

These are operational response targets, not a statement of continuous staffing. Assess product-security reporting separately using 事件报告; these targets do not extend reporting deadlines.

严重程度	定义	目标确认	目标初始行动
严重	完全中断；管理权限沦陷；活跃的数据泄露；需立即限制。	< 30 分钟	< 4 小时
高	核心功能不工作；单一用户的个人数据泄露。	< 2 小时	12 小时
中	性能降级；不大的安全问题。	1 个营业日	3 个营业日
低	用户界面 bug；Staging 问题；非安全问题。	最大努力	最大努力

事件响应生命周期

准备

• 使用 Weblate 的内置备份轮换确保 PostgreSQL 数据库和数据目录的每天常规备份，见 备份和迁移 Weblate。

• 确保 Weblate 使用正确配置的有 HTTPS（TLS 1.2+）的反向代理。

• 所有管理员级别账户启用 2FA。

• 保持 Weblate 实例及其依赖项（Python、Django、Celery、数据库等）为最新版。

• 用 GELF 协议和 SIEM 系统集成，用于审计和程序日志转发。

• Complete the preparation checklist in 事件报告 and keep private contact and access details current.

识别

• 监控系统和程序日志（journalctl、反向代理日志、Weblate 程序和审计日志）。

• 分析登录事件、webhook 执行、推送/拉取失败。

• 为多次登录失败、意外重启或异常的 VCS 操作配置警报（通过 Prometheus、Zabbix 或 SIEM）。

• Record awareness times and assess authority and user notifications using 事件报告, without waiting for a complete investigation.

• Assess whether a security incident caused accidental or unlawful destruction, loss, or alteration of personal data, or unauthorized disclosure or access, and follow 个人数据泄露通知. This includes availability or integrity breaches without disclosure, such as accidental deletion or ransomware destruction. Seek privacy advice where needed while continuing investigation and reporting preparation.

个人数据泄露通知

The incident handler determines whether Weblate acts as controller or processor for the affected processing and records the assessment in the private incident note. Under GDPR Article 33:

• As controller, notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the personal-data breach, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. Record the reason for a decision not to notify.

• If notification takes longer than 72 hours, include the reasons for the delay. Where information cannot be supplied together, provide it in stages without undue further delay.

• As processor, notify the controller without undue delay after becoming aware of a personal-data breach; do not wait for the controller's 72-hour deadline.

The controller's supervisory-authority notification must include the following information under Article 33(3):

• The nature of the breach, including, where possible, the categories and approximate numbers of affected individuals and personal-data records.

• The name and contact details of the person who can provide further information, such as the incident handler or a data protection officer if one is appointed.

• The likely consequences of the breach.

• Measures taken or proposed to address the breach, including measures to reduce its adverse effects where appropriate.

Identify information that is not yet available and provide it in follow-up notifications without undue further delay. Do not wait for exact counts before notifying the authority.

As controller, separately assess communication to affected individuals under GDPR Article 34. If the breach is likely to create a high risk to their rights and freedoms, inform them without undue delay unless an Article 34(3) exception applies. This applies even without active exploitation or a severe product-security incident. Notification to the supervisory authority does not replace this communication.

Explain the breach in clear language, giving a contact for further information, likely consequences, measures taken or proposed, and actions individuals can take. Record the assessment and any exception relied on: effective protection of the affected data, such as encryption making it unreadable to unauthorized people, or subsequent measures ensuring the high risk is no longer likely. If individual communication would involve disproportionate effort, use public communication or a similar measure that informs individuals equally effectively. See the EDPB data-breach guidance.

Record breach-awareness timestamps, recipients, and deadlines separately from CRA reporting. A CRA submission does not replace a GDPR notification, and the two reporting clocks may start at different times.

抑制

• Maintain the private incident note from 事件报告, including timeline updates, reporting deadlines, and submission receipts.

• 在 Signal 中协调人员响应并在现有监控系统中保留技术警告信息。

• ** 对于 1 或 2 类事件，在安全情况下，进行破坏性操作前手动创建 Hetzner Cloud Snapshot。

  • 名称格式：IRP-[CaseID]-[YYYYMMDD]-Evidence .

  • 这些快照和标准轮换备份隔开，必须留存用于事件分析。

• 按需要隔离受影响的主机或服务（如通过防火墙规则或服务隔离）。

• 禁用外部集成（Git/webhooks），如果它们是攻击载体的一部分。

• 立即暂停受影响的用户账户。

• 如果适用，撤销或轮换受影响的管理、API、VCS 和 webhook 凭证。

• 保留相关证据，包括系统日志、反向代理日志、Weblate 程序和审计日志，受影响的配置状态、受影响的凭证或集成的列表。

消除

• 删除任何未经授权的代码或数据。

• 升级 Weblate 或服务器不见打上已知漏洞的补丁。

• 使用 SHA-256 校验和或 Git 日志验证二进制文件和仓库完整性。

恢复

• 从最新的已知良好的 Weblate 备份中恢复受影响服务或数据。

• 分阶段重新引入服务。

• 恢复正常流量前确认根本原因已解决或存在补偿性控制措施。

• 轮换受影响的凭证并验证已恢复系统、仓库和配置的完整性。

• The handler records the decision to return to normal operations, checking recovery with the backup or another teammate where practical.

• 恢复后至少 72 小时持续监控日志和系统行为。

事件后的调查

• 时间线： 在事件结束的 5 个营业日 内举行简短的团队回顾。

• 编译完整的事件时间线和采取的行动。

• 执行根源分析（RCA）并在 10 个营业日内 进行文档记录。

• 基于发现更新安全策略和事件响应计划（IRP)文档。

• 审核检测和抑制机制的有效性。

• 验证提升、警报和外部沟通是否如预期遵照 漏洞和事件处理 规范。

• Check for outstanding reports, promised updates, and delayed disclosures before closing the incident note.