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

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

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

Сергій Дем'янчук займає посаду Старшого Технічного Лідера з Інженерії ПЗ у компанії Cisco, що входить до організації Security and Trust. Він є голосуючим членом технічних комітетів OASIS OpenEoX та OASIS CSAF, а також засновником платформи thin.ly, орієнтованої на захист приватності. Крім того, Сергій проводить дослідження у сфері безпеки постачання програмного забезпечення. Його професійний досвід в області безпеки застосунків, розробки розподілених систем і архітектури платформ з високим навантаженням перевищує 16 років. Він є автором трьох рецензованих наукових робіт 2025 року, що досліджують проблеми, пов'язані з програмним забезпеченням, яке досягло стадії завершення свого життєвого циклу.

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

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

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

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

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

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

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

Комерційні продукти мають чітко визначені роадмапи, політики підтримки та юридичні зобов'язання. У світі open-source така структура часто відсутня. Існуючі проєкти можуть виглядати активними, хоча насправді бути занедбаними. Через це ми створили набір метрик, який дозволяє аналізувати реальний стан проєкту, а не покладатися лише на його заяви. Коли наші дослідження виявили, що приблизно 42% широко використовуваного програмного забезпечення демонструє ознаки завершення життєвого циклу без офіційного підтвердження, це суттєво змінило дискусії в галузі. Тепер це не просто теоретична проблема, а виміряний ризик.

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

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

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

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

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

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

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

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

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

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

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

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

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

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