Google пропонує встановити нові правила для покращення безпеки з відкритим кодом

Безпека програмного забезпечення з відкритим кодом привернула увагу галузі, але рішення вимагають консенсусу щодо викликів та співпраці у реалізації.

Проблема складна, і є багато аспектів, які потрібно охопити, з ланцюга поставок, управління залежністю, ідентичності, серед іншого. Для цього нещодавно Google випустив структуру ("Знай, запобігай, виправляй"), яка пояснює, як галузь може думати про вразливі місця у відкритому коді та конкретні сфери, які потрібно вирішити в першу чергу.

Google пояснює свої причини:

«Завдяки останнім подіям світ програмного забезпечення глибше зрозумів реальний ризик атак ланцюга поставок. З точки зору безпеки програмне забезпечення з відкритим кодом має бути менш ризикованим, оскільки весь код та залежності відкриті та доступні для перевірки та перевірки. І хоча це загалом правда, передбачається, що люди фактично виконують цю інспекційну роботу. З такою великою кількістю залежностей неможливо відстежувати всі з них, і багато пакетів з відкритим кодом погано підтримуються.

«Загальноприйнята ситуація, коли програма прямо чи опосередковано залежить від тисяч пакетів та бібліотек. Наприклад, Kubernetes зараз залежить приблизно від 1000 пакетів. З відкритим кодом, ймовірно, використовуються залежності, а не власне програмне забезпечення, і походить від більш широкого кола постачальників; кількість незалежних організацій, яким можна довіряти, може бути дуже великою. Це надзвичайно ускладнює розуміння того, як у продуктах використовується відкритий код та які вразливі місця можуть бути актуальними. Також немає гарантії, що побудоване буде відповідати вихідному коду.

У рамках, запропонованих Google, пропонується розділити цю складність на три в основному незалежні проблемні області, кожна з яких має конкретні цілі:

Знайте вразливості вашого програмного забезпечення

Пізнання вразливостей вашого програмного забезпечення складніше, ніж можна було очікувати з багатьох причин. так, добре існують механізми повідомлення про вразливості, незрозуміло, чи вони дійсно впливають на конкретні версії програмного забезпечення, яке ви використовуєте:

• Завдання: Точні дані вразливості: По-перше, критично важливо отримати точні метадані вразливості з усіх доступних джерел даних. Наприклад, знання, яка версія представила уразливість, допомагає визначити, чи не постраждало програмне забезпечення, і знання, коли воно було виправлене, дає точні та своєчасні виправлення (і вузьке вікно для потенційного використання). В ідеалі цей класифікаційний робочий процес повинен бути автоматизованим.
• По-друге, більшість вразливостей лежать у ваших залежностях, а не в коді, який ви пишете або керуєте безпосередньо. Тож навіть коли ваш код не змінюється, ландшафт вразливостей, що впливають на ваше програмне забезпечення, може постійно змінюватися - деякі виправляються, а деякі додаються.
• Призначення: Стандартна схема для баз даних вразливостей Інфраструктура та галузеві стандарти необхідні для відстеження та підтримання вразливостей з відкритим кодом, розуміння їх наслідків та управління їх діями. Стандартна схема вразливості дозволить загальнодоступним інструментам працювати на декількох базах даних про вразливості та спростити завдання відстеження, особливо коли вразливості перетинають декілька мов або підсистем.

Уникайте додавання нових уразливостей

Ідеально було б уникнути створення вразливостей І хоча засоби тестування та аналізу можуть допомогти, профілактика завжди буде складною темою.

Ось, Google пропонує зосередити увагу на двох конкретних аспектах:

• Зрозумійте ризики, приймаючи рішення про нову залежність
• Удосконалити критичні процеси розробки програмного забезпечення

Виправте або видаліть вразливі місця

Google визнає, що загальна проблема ремонту виходить за рамки її компетенції, але видавець вважає, що актори можуть зробити набагато більше для вирішення проблеми специфічні для управління уразливостями у залежностях.

У ньому також згадується: 

«Сьогодні на цьому фронті мало що допомагає, але оскільки ми покращуємо точність, варто інвестувати в нові процеси та інструменти.

“Одним із варіантів, звичайно, є безпосереднє виправлення вразливості. Якщо ви можете зробити це у зворотно сумісній формі, рішення доступне кожному. Але проблема полягає в тому, що ви навряд чи матимете досвід у вирішенні проблеми або пряму здатність вносити зміни. Виправлення уразливості також передбачає, що відповідальні за обслуговування програмного забезпечення усвідомлюють проблему та мають знання та ресурси для розкриття вразливості.

Фуенте: https://security.googleblog.com