Керівництво спільноти щодо реагування на інциденти

Вразливості безпеки повинні оброблятися швидко та іноді приватно. Основна мета цього процесу — зменшити загальний час, протягом якого користувачі вразливі до відомих експлойтів.

Технічний комітет OpenTelemetry (OTel TC) та відповідні підтримувачі репозиторіїв, за підтримки інструментів, наданих SIG Security, відповідають за реагування на інцидент, організацію всього процесу реагування, включаючи внутрішню комунікацію та зовнішнє розкриття інформації.

Підтримувані версії

Проєкт OTel надає підтримку спільноти лише для останньої загальної мінорної версії: виправлення помилок випускаються або як частина наступної мінорної версії, або як патч-версія на вимогу. Незалежно від того, яка версія буде наступною, всі патч-версії є кумулятивними, тобто вони представляють стан нашої гілки main на момент випуску. Наприклад, якщо остання версія — 0.10.0, виправлення помилок випускаються або як частина 0.11.0, або 0.10.1.

Виправлення безпеки мають пріоритет і можуть бути достатніми для випуску нової версії. Кожен репозиторій має право встановлювати свої власні додаткові процеси. SIG Security разом з TC можуть надати консультації у разі необхідності розʼяснень.

Розкриття інформації

Процеси приватного розкриття

Щоб звіти про уразливості досягали підтримувачів якомога швидше, переважний спосіб — використовувати кнопку Report a vulnerability на вкладці Security у відповідному репозиторії GitHub. Це створює приватний канал звʼязку між репортером та підтримувачами.

Якщо ви абсолютно не можете або маєте вагомі причини не використовувати робочий процес звітування GitHub, будь ласка, звʼяжіться з Технічним комітетом за допомогою cncf-opentelemetry-tc@lists.cncf.io і ми надамо інструкції щодо того, як повідомити про уразливість за допомогою зашифрованого повідомлення, якщо це бажано.

Процеси публічного розкриття

Якщо ви знаєте про публічно розкриту уразливість безпеки, будь ласка, НЕГАЙНО надішліть електронного листа на адресу cncf-opentelemetry-tc@lists.cncf.io, щоб повідомити Комітет з реагування на безпеку (SRC) про уразливість, щоб вони могли розпочати процес виправлення, випуску та комунікації. Будь ласка, включіть будь-яку відповідну інформацію про поточні публічні використання цієї уразливості, якщо відомо, щоб допомогти з оцінкою та пріоритизацією.

TC повинен отримати повідомлення і перенаправити його відповідним підтримувачам репозиторіїв для взяття на себе відповідальності. Якщо можливо, підтримувачі репозиторіїв звернуться до особи, яка робить публічний звіт, з проханням, чи можна вирішити питання через процес приватного розкриття. Якщо репортер відмовляє у запиті, підтримувачі репозиторіїв швидко приступають до процесу виправлення та випуску. У крайніх випадках ви можете попросити GitHub видалити тікет, але це зазвичай не є необхідним і навряд чи зробить публічне розкриття менш шкідливим.

Виправлення, випуск та публічна комунікація

Організація команди з виправлення

Команда з виправлення складається з людей з наступними ролями:

• Командир інциденту, особа, яка керує комунікацією навколо інциденту.
• Дослідник(и) інциденту, зазвичай один або кілька підтримувачів постраждалих репозиторіїв.
• Експерти з предметної області, зазвичай включають репортера та інших учасників, таких як власники коду для постраждалих компонентів або затверджувачі репозиторіїв, які надають швидкі огляди коду для запропонованих виправлень.
• Інші зацікавлені сторони, такі як інші SIG, які можуть потребувати використання виправлення.

Роль TC

• Член TC повинен переглянути запропонований CVSS бал та серйозність від команди з виправлення
• Підтвердити, коли запропоноване виправлення завершено

Процес розробки виправлення

Всі наведені нижче терміни є рекомендаціями, які передбачають приватне розкриття та прийняття звіту як дійсного.

Початкове реагування на інцидент

• TC повідомляється про інцидент, і відповідні підтримувачі репозиторіїв автоматично додаються за допомогою робочого процесу Zapier як команда з виправлення до проблеми.
• Команда з виправлення підтверджує інцидент репортеру, запитує додаткові деталі, якщо необхідно, і починає планування виправлення.
• Команда з виправлення підтверджує з репортером, чи є інцидент дійсним і потребує виправлення.
• Команда з виправлення створює тимчасову приватну гілку для початку роботи над виправленням.
• Команда з виправлення створить CVSS базовий бал за допомогою CVSS калькулятора і повідомить команду GitHub TC, @open-telemetry/technical-committee для підтвердження.
• Команда з виправлення запросить CVE від GitHub і звʼяжеться з репортером.
• Команда з виправлення публікує CVE в базі даних GitHub Security Advisory для повідомлення користувачів.

Помʼякшення наслідків інциденту

Терміни помʼякшення наслідків інциденту залежать від серйозності інциденту та частоти випуску релізів репозиторію.

• Команда з виправлення повідомить @open-telemetry/technical-committee, щоб повідомити їх, що робота над гілкою виправлення завершена, коли є LGTMs на всіх комітах у тимчасовій приватній гілці, створеній для GitHub Security Advisory.
• Оновлена версія випускається з виправленням.
• Інцидент публікується в базі даних GitHub Security Advisory, і постраждалі користувачі автоматично повідомляються за допомогою сповіщень безпеки GitHub.

Процес розкриття виправлення

OTel покладається на інструменти GitHub для повідомлення постраждалих репозиторіїв та публікації консультації з безпеки. GitHub опублікує CVE в списку CVE, розповсюдить консультацію з безпеки через базу даних GitHub Advisory і надішле сповіщення про безпеку всім репозиторіям, які використовують пакет і мають увімкнені сповіщення. CVE також буде додано до стрічки CVE на вебсайті OTel.

День випуску виправлення

Команда з виправлення як власники репозиторію випустять оновлену версію і за бажанням повідомлять свої спільноти через Slack.

Серйозність

Команда з виправлення оцінює серйозність уразливості в кожному конкретному випадку, керуючись CVSS 3.1 і підлягає перегляду TC.