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

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

Довідка про експерта:

Сергій Дем’янчук — Senior Software Engineering Technical Leader у Cisco (Security and Trust Organization), провідний архітектор у сфері AppSec та управління життєвим циклом ПЗ. Як Voting Member комітетів OASIS (OpenEoX, CSAF), він є співавтором міжнародних стандартів, що розробляються спільно з експертами Microsoft, Oracle, Red Hat, Dell, NSA та CISA. 

Сергій став автором резонансного дослідження, яке викрило "приховану кризу" open-source: 42% активно використовуваних бібліотек не мають підтримки, що створює критичні ризики для світової інфраструктури. Його впровадження в Cisco прискорили доставку сповіщень про загрози на 98%, забезпечивши миттєву реакцію на інциденти для тисяч організацій по всьому світу. 

За свою кар’єру Дем’янчук працював у великих технологічних компаніях, зокрема Cisco, Narvar, RxVantage, SoftServe, очолював інженерні команди до 12 фахівців і реалізовував проєкти з високими навантаженнями. 

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

Діагностика кризи: як 42% "невидимого" коду стали загрозою світовій інфраструктурі

Одним із ключових напрямів роботи Дем’янчука стала безпека ланцюга постачання ПЗ. У межах академічного дослідження, опублікованого у форматі peer-reviewed, він запропонував модель з 24 метрик для оцінки життєвого циклу open-source проєктів. Аналіз показав, що близько 42% активно використовуваного відкритого програмного забезпечення перебуває у невизначеному стані підтримки — без формального оголошення end-of-life, але й без гарантій безпеки.

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

Від реакції до профілактики: роль міжнародних стандартів OASIS

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

Цей підхід напряму пов’язаний із практичним досвідом: у корпоративних проєктах Дем’янчук неодноразово стикався з тим, що формально "працюючі" рішення приховували системні вразливості, які ставали помітними лише під час інцидентів.

Продуктовий маніфест: рекордна швидкість без компромісів із приватністю

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

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

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