Програмний продукт може працювати без збоїв роками, а потім виявиться, що одну з його важливих бібліотек давно ніхто не підтримує. Антон Асєєв, CEO IT-компанії SharksCode, пояснює, чому технологічні залежності стають прихованою статтею витрат, як оцінювати їхні ризики та чому популярність інструменту ще не гарантує його надійності.
Проблема з бібліотекою починається не тоді, коли вона перестає працювати. Часто все навпаки: її встановили кілька років тому, вона виконує свою функцію, ніхто до неї не повертається. Саме тому застарілі компоненти так легко випадають із поля зору. Команда розвиває продукт, додає нові можливості, а частина його технологічної основи поступово залишається без підтримки.
Масштаб проблеми показує дослідження Black Duck Open Source Security and Risk Analysis 2026. У 93% перевірених кодових баз виявили компоненти, у яких не було активності розробки понад два роки. Це не означає, що всі такі бібліотеки вразливі. Але якщо згодом знайдуть серйозну помилку, може виявитися, що виправляти її вже нікому.
Коли справний код перетворюється на проблему
Уявімо платформу, яка використовує сторонню бібліотеку для обміну даними. Вона давно інтегрована, тести проходять, клієнти не скаржаться. Згодом з’являється нова вразливість, а розробник бібліотеки припинив випускати оновлення. Команді доведеться або підтримувати чужий код самотужки, або шукати заміну, або перебудовувати частину інтеграції.
На папері це виглядає як технічна задача. Для бізнесу це незаплановані витрати, зміна пріоритетів і час інженерів, який мав піти на розвиток продукту. Особливо відчутно це для B2B-платформ: замінити компонент потрібно так, щоб не порушити роботу клієнтів та їхніх процесів.
Тому, оцінюючи технологію, я дивлюся не лише на її функції сьогодні. Мені важливо, хто її підтримуватиме завтра, чи є прогнозований цикл оновлень, які залежності вона додає та наскільки складно буде від неї відмовитися. Останнє питання зазвичай ставлять рідше, ніж потрібно.
Скільки насправді коштує "безкоштовний" інструмент
Open source не означає відсутності витрат. Компанія може не платити за ліцензію, але все одно витрачатиме ресурси на перевірку безпеки, сумісність із новими версіями, тестування та підтримку. Якщо інструмент складно замінити, виникає залежність, ціна якої проявиться лише через кілька років.
До технічних ризиків додаються регуляторні вимоги. З 11 вересня 2026 року в ЄС почали діяти положення Cyber Resilience Act щодо повідомлення виробниками про активно експлуатовані вразливості та серйозні інциденти, які впливають на безпеку продуктів із цифровими елементами. Основні вимоги регламенту почнуть застосовуватися 11 грудня 2027 року. Йдеться не про будь-яку внутрішню програму без винятку, а про продукти, на які поширюється дія закону.
Для технологічного бізнесу це ще один аргумент розуміти склад власного продукту та відстежувати стан його компонентів. Коли вразливість уже знайдено, складати список залежностей із нуля запізно.
Що перевірити до того, як залежність стане критичною
Перше - активність проєкту. Важлива не кількість зірочок на GitHub, а те, чи виходять виправлення, чи відповідають розробники на повідомлення про проблеми та чи є зрозуміла політика підтримки. Друге - можливість заміни. Критична залежність не повинна перетворювати весь продукт на заручника одного інструменту.
Третє - люди. Якщо технологію розуміють лише двоє інженерів, її підтримка стає ризиком для компанії незалежно від якості коду. Четверте - повна вартість володіння: до початкової економії слід додати майбутні оновлення, міграції, перевірки безпеки та час команди.
Для мене це питання управління, а не консерватизму. Нові інструменти потрібні, але новизна не звільняє їх від перевірки. Особливо якщо рішення потрапляє в частину продукту, яку згодом буде дорого переписувати.
AI прискорює розробку, але не знімає відповідальності
Ще одна причина уважніше ставитися до складу коду - поширення AI-асистентів. У тому самому звіті Black Duck зазначено, що 16% виявлених open source-компонентів потрапили до кодових баз поза стандартними механізмами керування пакетами. Серед можливих джерел такого коду дослідники називають скопійовані фрагменти, сторонні залежності та результати роботи AI-асистентів. Це не означає, що саме AI спричинив усі ці випадки.
Коли інструмент пропонує готовий код, його зручно використати одразу. Але швидкість не скасовує питань: звідки взявся фрагмент, які компоненти він використовує, чи можна їх оновлювати та хто перевірить результат. Тому AI-генерація має проходити звичайні етапи рев’ю й перевірок безпеки, а не потрапляти в продукт автоматично.
Я не прихильник відмови від нових технологій заради стабільності. Навпаки, їх варто пробувати в ізольованих частинах системи, де наслідки помилки можна обмежити. Та між "інструмент показав хороший результат у тесті" і "на ньому можна будувати критичну частину бізнесу" є велика дистанція.
У довгостроковому B2B-продукті найдорожчим нерідко стає не те рішення, яке багато коштувало на старті, а те, від якого виявилося майже неможливо відмовитися. Саме тому надійний стек починається з простого запитання: що ми робитимемо з цією технологією через п’ять років?