Програмне забезпечення є основою сучасного бізнесу та має вирішальне значення в усіх аспектах діяльності. Майже кожен бізнес використовуватиме програмне забезпечення з відкритим кодом, свідомо чи ненавмисно, оскільки навіть пропрієтарне програмне забезпечення залежить від бібліотек з відкритим кодом. OpenUK Звіт «State of Open» за 2022 рік показує, що 89% компаній покладаються на програмне забезпечення з відкритим кодом, але не всі з них чітко розуміють деталі програмного забезпечення, на яке вони покладаються.
Підприємства все частіше вимагають більше інформації про критичне для роботи програмне забезпечення. Відповідальні підприємства детально цікавляться своїм ланцюжком постачання програмного забезпечення та створюють специфікацію програмного забезпечення (SBOM) для кожної програми. Цей рівень інформації має вирішальне значення для того, щоб, коли в програмному забезпеченні виявлено недоліки безпеки, вони могли негайно визначити, яке програмне забезпечення та версії використовуються, а також які системи вплинули. У таких ситуаціях знання - сила!
Опора на волонтерів
Наприкінці 2021 року виникла вразливість системи безпеки Log4Shell був ідентифікований у широко використовуваній структурі журналювання Java, Log4j. Оскільки це широко використовувана бібліотека з відкритим вихідним кодом, уразливість була широко розголошена, і очікувалися виправлення. Однак, супроводжувачами проекту були волонтери. Вони мали денну роботу і не були на виклику для термінових виправлень безпеки, навіть якщо велика кількість систем постраждала. Лише ця вразливість, за оцінками, вплинула на 93% корпоративних хмарних середовищ.
У той час преса негативно відгукувалася про відкрите програмне забезпечення, але правда полягає в тому, що якби це був компонент із закритим вихідним кодом, про вразливість, можливо, ніколи не було відомо публічно, залишаючи організації відкритими для атак. Природа бібліотеки з відкритим вихідним кодом означала, що її можна було перевіряти, виявляти проблеми та давати поради іншим. Отже, так, супроводжувачі не були на виклику через проблеми безпеки у своєму волонтерському проекті. Отже, велике запитання: як ми потрапили в ситуацію, коли великі компанії залежали від програмного забезпечення, за яке відповідав хтось, хто робить щось інше, щоб оплачувати свої рахунки?
Нехтування залежностями програмного забезпечення є ризикованою справою, незалежно від ліцензії на програмне забезпечення, але коли воно має відкритий код і дуже широко використовується, це стає особливо небезпечним. Дотримуючись історії про одну вразливість; проблема існувала в кодовій базі роками, але не була помічена. Інструмент, який так широко використовувався, насправді не мав такої широкої підтримки — і те, що сталося далі, це історія.
Ця історія повторюється знову і знову в багатьох компаніях, які мають критичні залежності, але не вживають заходів для підтримки ані супроводжувачів, ані самих проектів. Наявність SBOM для програмного забезпечення, яке використовується бізнесом, означає, що вони мають інформацію під рукою. Для організацій, які постачають програмне забезпечення іншим, очікування постачання SBOM разом із кодом стає все більш нормою.
Знати залежності для оцінки ризику
Знання про залежності полегшує оцінку ризику, пов’язаного з кожною з них. Ці проекти з відкритим вихідним кодом найпростіше оцінити: чи вирішено проблеми та чи були нещодавні випуски? Можливість бачити супроводжувачів і проектну діяльність для кожного проекту дає хороше уявлення про стан проекту.
Підприємства можуть зіграти свою роль у зменшенні ризиків, підтримуючи проекти, від яких вони залежать. Деякі проекти приймають спонсорство безпосередньо через схему спонсорів GitHub, інші можуть натомість оцінити пропозиції хостингу або перевірку безпеки. Кожен проект із відкритим кодом цінує внески. Якби ваш бізнес сам створив цю бібліотеку, то інженерам усередині компанії довелося б самостійно виправляти всі помилки.
Відкритий код більше схожий на схему спільного володіння. Ми не повинні створювати одне й те саме повторно, ми можемо зробити свій внесок, що потребує менше зусиль і, як наслідок, покращує якість. Однією з найефективніших речей, які можуть зробити компанії, є використання трохи своїх інженерних ресурсів і сприяйте виправленню помилок або доповнюйте функції проектів які є ключовими для бізнесу.
Залучення власних інженерів до проекту має багато переваг. Вони знайомляться з ним і можуть стежити за новими функціями або за новими випусками. Найважливіше те, що бізнес має уявлення про здоров’я та статус залежного проекту та є частиною того, що підтримує його працездатність, зменшуючи ризик для бізнесу проблеми із залежністю. Деякі організації, включно з Aiven, мають OSPO (офіс програм з відкритим вихідним кодом), штат якого займається підтримкою та підтримкою проектів, які використовує організація. Ці відділи часто роблять внесок у загальну присутність компанії в екосистемі з відкритим кодом і дозволяють іншим співробітникам працювати з відкритим кодом.
Інший підхід полягає в підтримці організацій, які існують для підтримки відкритого коду. The OpenSSF (Фонд безпеки відкритого коду) працює над підвищенням безпеки проектів з відкритим кодом і фінансується організаціями, які залежать від цих проектів. Він також публікує чудові навчальні ресурси, щоб компанії могли ознайомитися з ризиками програмного забезпечення, яке вони використовують. Інша подібна організація є Відлив, яка співпрацює з супроводжувачами, щоб забезпечити виконання певних основних вимог, знову ж таки фінансується організаціями. Tidelift також надає інструменти та навчальні засоби, щоб допомогти компаніям керувати ланцюгом постачання програмного забезпечення та застосувати передовий досвід у цій галузі.
Забезпечення безпечнішого майбутнього програмного забезпечення
Компанії залежать від програмного забезпечення, і це включає програмне забезпечення з відкритим кодом, яке широко використовується та зазвичай безпечніше, ніж пропрієтарні альтернативи.
Це розумний крок, але ще розумнішим кроком є чітке знання ланцюга постачання програмного забезпечення та його залежностей. Коли проблема все-таки виникає, залежність від здорових проектів і наявності деталей вашого програмного забезпечення допомагає кожній організації. Якщо кожна організація зробить це, то ризик виникнення таких подій, як уразливість Log4Shell, зменшиться.
