Зміст
- З відкритим кодом скрізь
- Уразливості з відкритим кодом: результати є
- Що з них найвразливіше?
- Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя
- Дикий Захід вразливих версій з відкритим кодом
- Спільнота з відкритим кодом надіслана безпекою - тепер користувачів потрібно наздоганяти
- Як заздалегідь отримати безпеку з відкритим кодом
Винос:
Компоненти з відкритим кодом - прекрасний спосіб створення програмного забезпечення, але вразливості в них можуть загрожувати всій вашій організації. Знайте про ризики та будьте в курсі рішень із безпеки з відкритим кодом, щоб захистити себе та свій бізнес.
Оскільки команди розробників готуються йти в ногу з конкурентними темпами виробництва програмного забезпечення, компоненти з відкритим кодом стали невід’ємною частиною інструментарію кожного розробника, допомагаючи їм створювати та відправляти інноваційні продукти зі швидкістю DevOps.
Послідовне зростання використання відкритого коду, поряд із порушеннями заголовків даних, такими як порушення рівня Equifax, що використовувало вразливості в компонентах з відкритим кодом, може, нарешті, створити організації, готові керувати безпекою з відкритим кодом та вирішувати питання про незахищеність у відкритому коді на відкритому коді. Питання, однак, чи вони знають, з чого почати. (Щоб дізнатися більше, перегляньте розділ Якісні та кількісні: Час змінити, як ми оцінюємо ступінь уразливості сторонніх розробників?)
З відкритим кодом скрізь
Нещодавно WhiteSource опублікував звіт про стан відкритого джерела управління вразливістю, щоб надати інформацію, яка допоможе організаціям краще зрозуміти, як підходити до безпеки відкритого коду. Згідно з доповіддю, в якій були включені результати опитування щодо використання з відкритим кодом, проведеного серед 650 розробників з США та Західної Європи, колосальні 87,4 відсотка розробників покладаються на компоненти з відкритим кодом "дуже часто" або "весь час". Ще 9,4% відповіли, що вони "іноді" використовують компоненти з відкритим кодом. Виділялось лише те, що лише 3,2 відсотка учасників відповіли, що вони ніколи не використовують відкритий код, що, мабуть, було наслідком політики компанії.
Ці цифри безперечно свідчать про те, що розробник, який працює над програмним проектом, швидше за все використовує компоненти з відкритим кодом.
Уразливості з відкритим кодом: результати є
Звіт також заглибився в базу даних з відкритим кодом WhiteSource, яка агрегується з Національної бази даних про вразливість (NVD), рекомендацій щодо безпеки, рецензованих баз даних про вразливості та популярних трекерів з відкритим кодом, щоб дізнатися про вразливості з відкритим кодом, які потрібні командам розробки мати справу з.
Результати показали, що кількість відомих вразливих версій з відкритим кодом у 2017 році досягла найвищого рівня, маючи майже 3500 уразливостей. Це збільшилось на понад 60 відсотків кількість розкритих вразливих версій з відкритим кодом порівняно з 2016 роком, і ця тенденція не свідчить про те, що у 2018 році спостерігається уповільнення.
Що з них найвразливіше?
Дослідження також заглибилось у базу даних, щоб знайти найбільш вразливі проекти з відкритим кодом та придумало дивовижні результати. Хоча 7,5 відсотка всіх проектів з відкритим кодом є вразливими, 32 відсотки з топ-100 найпопулярніших проектів з відкритим кодом мають принаймні одну вразливість.
Хоча однієї вразливості достатньо, щоб поставити під загрозу кілька бібліотек, вразливий проект з відкритим кодом містить в середньому вісім вразливих місць. Це означає, що найпопулярнішими проектами з відкритим кодом часто є також проекти з високою вразливістю.
Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя
Ви не можете покращити свої навички програмування, коли ніхто не піклується про якість програмного забезпечення.
Це розуміння стає ще зрозумілішим, коли ми дивимось список 10 найкращих проектів з відкритим кодом з найбільшою кількістю вразливих версій з відкритим кодом. Список перших 10 включає надзвичайно популярні проекти з відкритим кодом, якими користується багато хто з нас.
Ці проекти мають більше одного спільного: Більшість із них - це інтернетні, фасадні компоненти з широкими нападаючими поверхнями, які дуже піддаються впливу, що робить їх відносно легкими в експлуатації. Ось чому вони привертають багато уваги громадськості з питань відкритого джерела безпеки безпеки.
Інший аспект, який поділяють багато з цих проектів, полягає в тому, що більшість підтримуються комерційними компаніями. Враховуючи ставки та ресурси, що стоять за ними, можна запитати: як проекти, які підтримують такі великі гравці, можуть бути настільки вразливими?
Дикий Захід вразливих версій з відкритим кодом
Раніше виявлення вразливих версій з відкритим кодом викликало б бурхливу дискусію щодо того, чи підтримуються компоненти з відкритим кодом достатньо, щоб бути безпечними для використання. На щастя, ці дні закінчилися, і сьогодні ми знаємо, що зростання повідомлень про відкриті джерела відкритого коду демонструє, як швидко реагують спільнота з відкритим кодом та спільнота безпеки, щоб не відставати від ландшафту загроз.
Експонентне зростання спільноти з відкритим кодом разом із пізнім відкриттям горезвісних уразливих версій у відкритих джерелах диких популярних компонентів, таких як ті, що дозволили процвітати Heartbleed, призвели до підвищеної обізнаності про безпеку з відкритим кодом та армії дослідників, що аналізують відкритий код проекти для вразливих ситуацій, а також швидкий поворот для виправлень.
Насправді у звіті WhiteSource було встановлено, що 97 відсотків усіх повідомлених уразливостей мають хоча б одне запропоноване виправлення у спільноті з відкритим кодом, а оновлення безпеки зазвичай публікуються протягом днів після публікації вразливості. (Докладніше про відкритий код: ознайомтеся з відкритим кодом. Чи занадто добре бути правдою?)
Спільнота з відкритим кодом надіслана безпекою - тепер користувачів потрібно наздоганяти
Хоча співпраця спільноти з відкритим кодом та зусилля щодо вдосконалення безпеки з відкритим кодом безумовно показують результати в плані виявлення вразливості, розкриття інформації та швидких виправлень, користувачам важко не відставати через децентралізований характер спільноти з відкритим кодом.
Коли розробники використовують комерційні компоненти програмного забезпечення, оновлення версій є частиною послуги, за яку вони платять, і постачальники можуть бути дуже наполегливими щодо того, щоб переконатися, що ви їх бачите.
Це не так, як працює відкритий код. Дані WhiteSource, які показали, що лише 86 відсотків повідомлених вразливих версій з відкритим кодом з'являються в базі даних CVE. Це пояснюється тим, що спільний і децентралізований характер спільноти з відкритим кодом означає, що інформація та оновлення про вразливі місця з відкритим кодом публікуються на сотнях ресурсів. Таку інформацію неможливо відстежити вручну, особливо якщо ми враховуємо обсяг використання відкритого коду.
Як заздалегідь отримати безпеку з відкритим кодом
Послідовне зростання вразливих версій з відкритим кодом є проблемою, з якою організації повинні вирішуватись з урахуванням того, як стало поширеним використання відкритого коду. Хоча велика кількість вразливих версій з відкритим кодом, у тому числі найпопулярніших проектів, може здатися непосидючою, вивчення способу управління громадою безпекою з відкритим кодом є кроком у правильному напрямку.
Наступним кроком є прийняття того, що управління безпекою з відкритим кодом має інший набір правил, інструментів та практик, ніж забезпечення комерційних або фірмових компонентів. Дотримуватися одних і тих же програм та інструментів управління вразливістю не допоможе управління безпекою з відкритим кодом.
Прийняття політики безпеки з відкритим кодом, яка вирішує ці відмінності, та включення правильних технологій для автоматизації управління ними допоможе командам безпеки та розвитку зіткнутися з унікальними викликами вразливих версій з відкритим кодом, що дозволить повернутися до бізнесу зі створення чудового програмного забезпечення.