У 2026 році ландшафт кібербезпеки критичної інфраструктури та державного сектору України зазнає значних трансформацій. Активна фаза переходу на постквантову криптографію (PQC) та практичне впровадження регуляторних вимог NIS2 акцентують увагу на стійкості ланцюгів поставок програмного забезпечення (software supply chain security). Одночасно швидке інтегрування великомасштабних мовних моделей (LLM), AI-assisted development та агентних AI-систем у процеси розробки й експлуатації державних платформ, а також посилення регуляторного тиску з боку Cyber Resilience Act (CRA) Європейського Союзу, формують принципово нові вектори ризиків та архітектурні виклики.
ТОВ «Софтлайн ІТ», розробник захищеної платформи UnityBaseDefense для державного сектору та критичної інфраструктури, постійно аналізує ці виклики. Наш підхід до архітектури UnityBaseDefense інтегрує принципи Zero Trust, посилений контроль доступу та суворе дотримання національних стандартів (НД ТЗІ 2.5-004/005/010, ДСТУ 4145) та міжнародних фреймворків (ISO 27001, IEC 62443). У контексті CRA, AI-security та LLM-integrations ми розглядаємо необхідність поглибленої оцінки ризиків на всіх етапах життєвого циклу програмного забезпечення — від походження коду та залежностей до безпечного оновлення моделей та контролю AI-generated artifacts.
Cyber resilience act: розширення периметру відповідальності
Cyber Resilience Act (CRA), практичне застосування якого активно розгортається у Європейському Союзі у 2026 році, суттєво змінює парадигму відповідальності виробників та постачальників програмного забезпечення. Регулятор вимагає не лише забезпечення кібербезпеки продукту «за задумом» (security by design) та «за замовчуванням» (security by default), але й підтримання цього рівня захисту протягом усього життєвого циклу системи. Для державного сектору України, який активно використовує іноземне програмне забезпечення, open-source компоненти та AI-assisted development, це означає необхідність:
- Постійного моніторингу вразливостей: Виробники повинні розгортати процеси безперервного сканування та виправлення вразливостей, що виявляються після випуску продукту. Це стосується не тільки власних компонентів, але й залежностей у ланцюгу поставок, включаючи сторонні бібліотеки, контейнери, AI-generated code та інструменти автоматизації.
- Прозорості та звітності: Обов’язкова звітність про інциденти та вразливості, яка має бути доступною для регуляторів та кінцевих користувачів. Це включає надання Software Bill of Materials (SBOM) для всіх компонентів, а також дедалі частіше — документування походження AI-generated artifacts та моделей, інтегрованих у систему.
- Оцінки відповідності: Продукти, що підпадають під дію CRA, повинні проходити оцінку відповідності, яка може включати самооцінку або оцінку третьою стороною, залежно від категорії ризику продукту. Для критичної інфраструктури це поступово формує нові вимоги до provenance verification, secure development lifecycle та контролю supply chain.
CRA, у поєднанні з NIS2, яка посилює вимоги до управління ризиками та звітності про інциденти для операторів критичної інфраструктури, створює комплексний регуляторний ландшафт. Архітекторам систем необхідно переглядати підходи до управління залежностями, AI-компонентами, CI/CD pipelines та зовнішніми сервісами, що інтегруються у державні інформаційні системи.
LLM-security: нові вектори атак та методи захисту
Інтеграція LLM у процеси розробки (генерація коду, тестування, аналіз вразливостей), а також у процеси експлуатації (аналіз логів SIEM, автоматизоване реагування на інциденти, AI-assisted SOC workflows) відкриває нові, раніше невідомі вектори загроз. Особливої уваги потребують agentic AI-системи, які отримують доступ до внутрішніх інструментів, API, CI/CD-процесів та корпоративних knowledge base.
Згідно з MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), атаки на LLM можуть включати:
- Prompt Injection: Маніпулювання вхідними запитами для отримання несанкціонованої інформації або виконання небажаних дій. У корпоративному середовищі це може призвести до компрометації внутрішніх knowledge base або некоректного виконання automated workflows.
- Data Poisoning: Впровадження шкідливих даних у навчальний набір LLM, що може призвести до генерації вразливого коду, небезпечних конфігурацій або неправдивих рекомендацій щодо архітектури систем.
- Model Evasion: Розробка запитів, які обходять захисні механізми LLM, дозволяючи отримати доступ до чутливих даних або функціоналу.
- Supply Chain Attacks на моделі: Компрометація LLM-моделей, model adapters, fine-tuning datasets або зовнішніх AI-плагінів на етапі розробки чи розповсюдження.
- Компрометація AI-generated code: Генерація небезпечних або вразливих залежностей, які потрапляють у production-середовище через автоматизовані CI/CD-процеси без належної верифікації.
Окрему небезпеку становлять сценарії, коли LLM інтегруються у внутрішні DevSecOps-процеси. Наприклад, AI-асистент може автоматично рекомендувати бібліотеку або пакет із компрометованого репозиторію, що фактично створює новий клас supply chain attack. У середовищах критичної інфраструктури подібний сценарій може впливати не лише на конфіденційність даних, але й на безперервність функціонування систем.
Для захисту від цих загроз необхідне застосування багаторівневих підходів. Це включає валідацію та санітизацію вхідних даних для LLM, використання захищених середовищ для їх розгортання, впровадження механізмів аудиту та моніторингу взаємодії з LLM, контроль AI-generated artifacts, а також використання спеціалізованих фреймворків оцінки безпеки моделей, аналогічних OWASP Top 10 for LLMs.
Постквантова криптографія та supply chain: активна фаза інтеграції
У 2026 році процес переходу на постквантові криптографічні алгоритми (PQC) перебуває у фазі масштабної інтеграції. Національний інститут стандартів і технологій (NIST) вже опублікував фінальні стандарти для декількох PQC-алгоритмів, і їхнє впровадження стає критично важливим для довгострокового захисту державних інформаційних систем. Водночас PQC-міграція сама по собі створює додаткові ризики для software supply chain.
Інтеграція LLM у процеси розробки та експлуатації систем державного сектору відкриває нові, раніше невідомі вектори загроз, що вимагає посилених заходів захисту. Сергій Балашук, Директор, ТОВ «Айкюжн ІТ»
Архітектори повинні враховувати:
- Верифікацію PQC-бібліотек: Забезпечення цілісності та автентичності PQC-бібліотек, що інтегруються у системи. Це вимагає використання цифрових підписів, перевірки хешів, provenance verification та сканування на наявність відомих вразливостей.
- Керування гібридними режимами: Перехідний період вимагає підтримки гібридних криптографічних режимів (класичні + PQC алгоритми), що ускладнює керування ключами, сертифікатами та криптографічною сумісністю між системами.
- Безпеку оновлень: Механізми безпечного оновлення програмного забезпечення, що включають PQC-компоненти, повинні бути стійкими до компрометації. Це особливо актуально для критичної інфраструктури та державних систем із тривалим життєвим циклом.
- Контроль криптографічних залежностей: Постквантова міграція збільшує кількість зовнішніх криптографічних компонентів та бібліотек, що використовуються у системі. Це підвищує вимоги до контролю software provenance та оцінки ризиків supply chain.
UnityBaseDefense, як платформа для захищених систем, вже інтегрує PQC-ready компоненти та підтримує гнучкі механізми адаптації до нових криптографічних стандартів, мінімізуючи ризики, пов’язані з цією міграцією.
Архітектурні рішення для управління ризиками supply chain
Для ефективного управління ризиками, що виникають у контексті CRA, LLM-security та PQC-міграції, архітекторам необхідно впроваджувати комплексні рішення. Це включає:
- Автоматизований аналіз SBOM: Використання інструментів для автоматичного генерування та аналізу Software Bill of Materials (SBOM) для всіх компонентів системи. Це дозволяє ідентифікувати вразливості у залежностях, контролювати походження компонентів та відстежувати їхній життєвий цикл.
- Zero Trust для supply chain: Розширення принципів Zero Trust на ланцюг поставок. Кожен компонент, що надходить від зовнішнього постачальника або AI-assisted development pipeline, повинен розглядатися як потенційно скомпрометований до завершення його верифікації.
- Threat modeling для LLM-інтеграцій: Проведення систематичного аналізу загроз для всіх компонентів, що взаємодіють з LLM, AI-agents або зовнішніми AI-services. Це дозволяє ідентифікувати потенційні вектори атак, пов’язані з prompt injection, data leakage або компрометацією AI workflows.
- Безперервний моніторинг та аудит: Впровадження систем безперервного моніторингу (SIEM/SOAR) та аудиту для відстеження активності у supply chain, виявлення аномалій та швидкого реагування на інциденти. Це також включає моніторинг поведінки LLM у production-середовищі.
- Контроль AI-generated artifacts: Верифікація коду, конфігурацій та залежностей, створених за допомогою AI-assisted development. Для державного сектору це поступово стає обов’язковим елементом secure SDLC.
- Розробку та впровадження політик: Створення чітких політик щодо використання зовнішнього програмного забезпечення, open-source компонентів, AI-platforms та процедур реагування на вразливості у ланцюгу поставок відповідно до вимог НД ТЗІ, NIS2 та CRA.
У контексті цих викликів архітекторам систем у державному секторі та критичній інфраструктурі України необхідно інтегрувати вдосконалені механізми управління ризиками supply chain. Це вимагає не лише технічних рішень, але й організаційних змін, що забезпечують прозорість, підзвітність та безперервну адаптацію до нових загроз. Інтеграція принципів security by design та security by default із посиленим контролем software provenance, AI-components та всіх етапів життєвого циклу програмного забезпечення стає ключовою умовою побудови кіберстійких систем у 2026 році та надалі.