"Безпека давно вийшла за межі окремих команд" — експерт з кібербезпеки Сергій Дем'янчук про те, чому open-source потребує системного підходу

Одним із фахівців, які безпосередньо працюють з цими викликами, є Сергій Дем’янчук — інженер, дослідник і технічний лідер, залучений до розробки міжнародних стандартів у сфері кібербезпеки.

Сергій Дем’янчук — Senior Software Engineering Technical Leader у Cisco (Security and Trust Organization), Voting Member технічних комітетів OASIS OpenEoX та OASIS CSAF, засновник privacy-first платформи thin.ly, а також дослідник у сфері безпеки ланцюгів постачання ПЗ. Має понад 16 років досвіду в application security, розробці розподілених систем і архітектурі високонавантажених платформ. Автор трьох рецензованих наукових публікацій 2025 року, присвячених проблемі end-of-life програмного забезпечення.

Ми поговорили з Сергієм Дем’янчуком про те, як виглядає робота над міжнародними стандартами кібербезпеки зсередини, чому open-source став одночасно основою та слабким місцем цифрової економіки, і як інженерний досвід трансформується у системні рішення для всієї галузі.

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

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

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

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

— Ви стали одним із авторів досліджень, які показали, що значна частина open-source ПЗ фактично перебуває у "сірих зонах" життєвого циклу. Як ви до цього дійшли?

— Це почалося з практичного запиту. У корпоративному середовищі завжди є вимога: розуміти, який компонент підтримується, який — ні, і які ризики це несе. Але коли я почав глибше аналізувати open-source залежності, виявилося, що більшість існуючих фреймворків просто не працюють для цієї реальності.

У комерційних продуктів є роадмапи, політики підтримки, юридична відповідальність. У open-source цього часто немає. Проєкти можуть фактично бути покинутими, але формально залишатися "живими". Саме тому ми розробили набір метрик, який дозволяє оцінювати реальний стан проєкту, а не покладатися на декларації. Коли результати показали, що близько 42% активно використовуваного ПЗ має ознаки end-of-life без офіційного статусу, це змінило розмову в індустрії. Це вже не гіпотеза, а вимірюваний ризик.

— Ви залучені до роботи в технічних комітетах OASIS разом із представниками великих корпорацій і державних структур. Як виглядає ця робота на практиці?

— Це складний, але дуже прагматичний процес. У комітетах зібрані люди з різним досвідом і мотиваціями: хтось представляє великого вендора, хтось — open-source спільноту, хтось — державні агенції. Завдання полягає не в тому, щоб створити ідеальний документ, а в тому, щоб знайти рішення, яке реально зможуть впровадити. У цьому сенсі мій досвід інженера дуже допомагає. Я завжди дивлюся на стандарт через призму питання: чи можна це автоматизувати, чи не створить це зайвого навантаження, чи є користь для команд, які працюють з обмеженими ресурсами. OpenEoX, наприклад, задумувався як інструмент зниження хаосу, а не ще один бюрократичний шар. Саме тому ми багато уваги приділяємо практичним сценаріям використання.

— Ви паралельно працюєте зі стандартами, дослідженнями й власним продуктом — thin.ly. У чому принципова відмінність цього проєкту від інших сервісів скорочення посилань і чому ви вважали за потрібне зробити його саме так?

— thin.ly з’явився з дуже практичного спостереження. Працюючи над маркетинговою кампанією, я звернув увагу, що всі популярні сервіси скорочення посилань використовують однакову модель: кожен клік користувача обробляється через сторонні геолокаційні API. Це означає, що IP-адреси та інші технічні дані передаються третім сторонам, додається затримка в роботі сервісу і з’являється додатковий вектор ризику. У галузі це вважається нормальною практикою, але з точки зору безпеки й архітектури — це слабке місце.

У thin.ly я свідомо відмовився від цієї моделі. Аналітика збирається безпосередньо на рівні CDN, ще до того, як запит доходить до серверів застосунку. Це дозволило повністю прибрати зовнішні API-запити. У результаті середній час редиректу зменшився до менш ніж 50 мс, тоді як для ринку типовими є 200–300 мс. Паралельно з цим зникає потреба передавати дані користувачів за межі інфраструктури AWS, що спрощує питання відповідності GDPR і знижує ризики витоків.

Для мене thin.ly — не спроба "перевинайти" знайомий інструмент, а демонстрація того, як архітектурне рішення може дати одразу кілька ефектів: зростання продуктивності, кращу масштабованість і вищий рівень приватності. Це той самий підхід, який я застосовував у великих корпоративних системах, де за рахунок усунення системних обмежень вдавалося досягати приросту продуктивності на 50–90 відсотків. У цьому сенсі thin.ly — практичний приклад того, як принципи безпеки й ефективності можуть працювати не лише в стандартах чи великих платформах, а й у споживчому сервісі.

— Ви поєднуєте глибоку технічну роботу з лідерськими та дослідницькими ролями. Як вам вдається не втратити інженерну експертизу?

— Я принципово не відмовляюся від роботи з кодом. Для мене технічне лідерство — це не управління людьми, а створення систем, які дозволяють командам працювати ефективніше. Це означає бути в курсі реальних обмежень, а не лише керувати процесами.

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

— І наостанок, якщо подивитися на індустрію на кілька років уперед, які зміни ви вважаєте неминучими? І виходячи з того, що варто враховувати тим, хто тільки починає кар’єру в безпеці та розробці?

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

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

Тим, хто тільки входить у галузь, я б радив не гнатися за "модними" ролями чи гучними назвами позицій. Набагато корисніше потрапити в середовище, де є реальні обмеження — регуляторні, технічні, операційні — і навчитися з ними працювати. Досвід участі у проєктах, де помилки мають ціну, формує зовсім інший рівень відповідальності, ніж робота з ізольованими демо-рішеннями.

У довшій перспективі виграють ті спеціалісти, які вміють поєднувати інженерне мислення з розумінням процесів і контексту. Саме такі фахівці здатні не лише реалізовувати вимоги, а й впливати на те, як ці вимоги формуються — у компаніях, індустрії та, зрештою, у стандартах.