Хоча уразливості у відкритому вихідному коді продовжують робити заголовки, наприклад Інші технології, такі як Heartbleed і Log4Shell, залишаються непоміченими через приховане джерело ризику відкритого коду – невідповідність ліцензіям відкритого коду.
На думку Palo Alto Networks, ліцензії на програмне забезпечення з відкритим вихідним кодом є основним джерелом ризику, оскільки навіть одна невідповідна ліцензія на програмне забезпечення може призвести до судового позову, тривалих заходів для виправлення ситуації та затримок у виведенні продукту на ринок. Незважаючи на очевидний ризик, дотримуватись правил ліцензування нелегко. Різноманітність ліцензій з відкритим кодом і складність визначення того, які ліцензії застосовуються до частини програмного забезпечення, ускладнюють відстеження, розуміння та керування ліцензіями.
Як і під час пошуку високорівневих або критичних уразливостей, пошук невідповідних ліцензій вимагає від організацій розгадати мережу відкритих і транзитивних залежностей, часто більш ніж на чотирьох або п’яти рівнях. Ці залежності часто призводять до появи кількох версій одного пакета з відкритим вихідним кодом, і нерідко можна знайти надто обмежувальні ліцензії з копілефтом, схованими в цій мережі. Щоб гарантувати відповідність ліцензій, організації повинні використовувати розширений контекстний аналіз складу програмного забезпечення. Це дає змогу ідентифікувати, виявляти та визначати пріоритети невідповідних ліцензій, які загрожують компанії.
Вступ до ліцензій з відкритим кодом
Коли користувачі чують термін «відкритий вихідний код», легко припустити, що вони можуть використовувати цей пакет як завгодно, напр. B. шляхом використання його для розробки комерційного продукту. Але навіть якщо вихідний код відкритий для всього світу, відкритий код не вільний від обмежень щодо використання.
Пакунки з відкритим кодом постачаються з ліцензіями, які регулюють використання, повторне використання, спільний доступ, модифікацію та розповсюдження коду. Сотні різних ліцензій з відкритим вихідним кодом диктують, як користувачі можуть використовувати код з відкритим кодом, і покарання за їх недотримання є реальним. Якщо компанія використовує пакет із відкритим вихідним кодом і не відповідає вимогам ліцензії, вона може бути змушена відкрити вихідний код свого власного коду або пройти через дорогий і трудомісткий процес видалення та заміни невідповідного пакета в коді. база.
Отже, як відповідальні особи знають, яким конкретним вимогам вони повинні відповідати, щоб залишатися сумісними? Тут справа стає складною, оскільки вимоги сильно відрізняються залежно від ліцензії. Деякі ліцензії – напр. B. Копілефт – дуже обмежувальні. Інші, у свою чергу, підлягають оплаті, а інші знову ж таки можуть вільно використовуватися, якщо вказано правильну авторство. Однак загалом ліцензії з відкритим кодом поділяються на дві основні категорії: ліцензії з копілефтом і дозвільні ліцензії.
Ліцензії Copyleft
Ліцензії на програмне забезпечення Copyleft є дуже обмежувальними ліцензіями, які вимагають від компаній відкривати будь-який код, який використовує відповідне програмне забезпечення з відкритим кодом. Ці ліцензії вимагають від них розповсюдження файлів вихідного коду програмного забезпечення, які зазвичай містять копію умов ліцензії та вказують авторів коду. Найвідомішою ліцензією з копілефтом є GNU General Public License (GPL).
Дозвільні ліцензії
Дозвільні ліцензії містять лише мінімальні обмеження щодо використання, модифікації та розповсюдження програмного забезпечення. Ці ліцензії зазвичай включають відмову від гарантій. Деякі приклади дозвільних ліцензій: ліцензія GNU All-permissive License, ліцензія MIT, ліцензії BSD, ліцензія Apple Public Source і ліцензія Apache. У 2016 році найпопулярнішою ліцензією на безкоштовне програмне забезпечення є дозвільна ліцензія MIT. Помітним і успішним пакетом програмного забезпечення з відкритим кодом, який використовує ліцензію Apache, є Kubernetes.
Приклад: Невідповідність ліцензіям Copyleft
У 2008 році Фонд вільного програмного забезпечення (FSF) подав до суду на Cisco за продаж програмного забезпечення під брендом LinkSys, яке не відповідало відкритому коду, який вона використовувала. Як це часто буває, невідповідне програмне забезпечення, яке спричинило порушення авторських прав GPL, було інтегровано в програмне забезпечення Cisco як частину придбання. З повсюдним розповсюдженням програмного забезпечення з відкритим кодом, зростанням кількості придбань і глибиною структур залежностей стає все важче ідентифікувати ліцензії з відкритим кодом, які глибоко вкорінені в комерційних пропозиціях програмного забезпечення. Однак невиконання вимог може перешкодити зусиллям зберегти комерційну інтелектуальну власність приватною. Наприклад, компанія, яка не дотримується ліцензії, може бути змушена відкрити програмне забезпечення або припинити його продаж. І навіть якщо ліцензія не є настільки обмежувальною, як ліцензія з копілефтом, командам, можливо, доведеться перебудувати своє програмне забезпечення, щоб подолати залежність ключів, що коштує дорого та сповільнює швидкість випуску.
Контроль відповідності ліцензії
Ніби ідентифікувати всі ліцензії було недостатньо складно, ліцензія з відкритим кодом може бути змінена в будь-який момент. Наприклад, у 2021 році широко використовуваний пакет із відкритим кодом Elasticsearch перейшов із дозволеної ліцензії на більш обмежувальну. Перевірка відповідності ліцензії не є одноразовою справою. Натомість управління відповідністю потребує постійного підходу, який вимагає такої ж належної обачності, як і інші процеси безпеки з відкритим кодом, напр. Б. Оновлення пакетів сторонніх розробників до новіших і безпечніших версій.
Стратегія управління відкритим кодом
На перший погляд дотримання ліцензій з відкритим кодом може здатися простим. Однак насправді це так само складно, як і природа самого відкритого коду. І сумна правда полягає в тому, що навіть якщо існуюча стратегія безпеки з відкритим кодом включає ретельний аналіз залежностей і процесів керування вразливістю, все одно може бути значна відкритість - Джерело ризики, які компанії не враховують. Досить лише одного невідповідного пакета, щоб уся програма стала невідповідною вимогам ліцензії. Тому організації повинні включити проактивну та комплексну стратегію безпеки з відкритим вихідним кодом у свою стратегію, щоб належним чином захистити свій ланцюжок постачання.Застосовуючи проактивний підхід, який визначає та усуває проблеми з ліцензуванням відкритого коду на ранніх стадіях циклу розробки, організації можуть підвищити продуктивність розробників. У той же час вони можуть зменшити стрес від необхідності виривати та замінювати невідповідні пакети зі свого програмного забезпечення пізніше в циклі розробки.
Застосування комплексної безпеки з відкритим кодом може здатися складним, але це можливо. Якщо все зроблено правильно, це може навіть бути зручним для розробників. Інтегруючи такі інструменти з відкритим вихідним кодом, як Checkov, із такими IDE, як VSCode та PyCharm від Jetbrains, розробники додатків і команди DevOps можуть отримати видимість вразливостей і потенційних проблем із відповідністю ліцензій якомога раніше в циклі розробки. Це дозволяє їм завчасно виправляти проблеми з невідповідними пакетами та підтримувати швидкість їх випусків.
Більше на PaloAltoNetworks.com
Про Palo Alto Networks Palo Alto Networks, світовий лідер у сфері рішень для кібербезпеки, формує хмарне майбутнє за допомогою технологій, які змінюють спосіб роботи людей і компаній. Наша місія — бути кращим партнером із кібербезпеки та захищати наш цифровий спосіб життя. Ми допомагаємо вам вирішувати найбільші світові виклики безпеки за допомогою безперервних інновацій, використовуючи останні досягнення в області штучного інтелекту, аналітики, автоматизації та оркестровки. Пропонуючи інтегровану платформу та надаючи можливості зростаючій екосистемі партнерів, ми є лідерами у захисті десятків тисяч компаній у хмарах, мережах і мобільних пристроях. Наше бачення — це світ, у якому кожен день безпечніший за попередній.