Інженери Google опублікувати пост про безпеку проєктів з відкритим кодом — щоб привернути увагу до захисту такого ПЗ та викликати дискусію у спільноті.
Автори пропонують ввести нові правила для відкритих проєктів, які спільнота визнає критичними. Тоді процес розробки мав би стати більш узгодженим, автоматизованим і чітким. У пості розробники нагадали, як важливо дбати про безпеку open source, адже вразливості в коді однієї програми впливають подекуди на мільйони систем.
Інженери Google вважають, що учасникам відкритих проєктів варто ретельніше дбати про контроль, звітність, ідентифікацію тощо. Це стосується насамперед важливих розробок, що впливають на всю екосистему. Якщо спільнота визнає певні проєкти критичними, у них пропонують:
- Заборонити односторонні зміни в коді, оновлювати щось лише після згоди двох незалежних учасників.
- Підтверджувати особу: власники та мейнтейнери не можуть бути анонімними, а мають проходити надійну автентифікацію (наприклад, 2FA).
- Отримувати сповіщення, якщо у ПЗ змінився рівень ризику.
- Забезпечити прозорість програмних артефактів.
- Зробити так, щоб процес збірки був надійним, а усі компоненти перевірялись.
Окрім критичних проєктів, автори рекомендують подбати й про розробки з відкритим кодом взагалі. Наприклад, створити стандартну схему для баз даних про вразливості, полегшити автоматизацію виявлення помилок, розробити систему сповіщень про фактичне виявлення вразливостей тощо.
Пропозиції Google, з одного боку, нагадують про важливість проблем у проєктах з відкритим кодом (і нещодавні атаки SolarWinds чи баг у sudo це підтверджують). З іншого боку — такий рівень контролю дещо далекий від культури open source. Видання The Register зауважує, що стандарти Google можуть зробити відкриті розробки повільнішими, бюрократичнішими й відбити бажання в людей цим займатися.
Спробуйте сказати лідерам проєктів на кшталт libpng, libjpeg-turbo, openssl, ffmpeg, що їм не можна робити «односторонні» зміни у власних проєктах просто тому, що вони є критично важливим програмним забезпеченням у світі FOSS.
Інженери Google визнають, що ці правила дійсно можуть бути обтяжливими для розробників. Тому спочатку планується визначити найбільш критичне ПЗ і змінити підхід лише для нього.
Як з'ясувалось з цього посту, Google не довіряє звичайним менеджерам пакетів та репозиторіям з відкритим кодом. Компанія має внутрішнє сховище пакетів, через яке розробники Google відстежують усі зміни у відкритих проєктах. Але навіть в такий спосіб це не завжди вдається і Google шукає, як автоматизувати цей процес.
Ще немає коментарів