Умови продажу цифрових продуктів у Європейському Союзі змінилися. Із прийняттям Закону про кіберстійкість, раніше відомого як Регламент (ЄС) 2024/2847, кібербезпека більше не є технічною перевагою чи рекомендацією щодо найкращих практик. Вона стає юридичною вимогою для підключених цифрових продуктів, що виходять на ринок ЄС.

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

У Lionwood Software ми розглядаємо цей зсув як природне продовження того, як вже має створюватися потужне програмне забезпечення. Безпеку неможливо додати наприкінці розробки без витрат, труднощів та ризиків. Її потрібно планувати під час дослідження, формувати під час архітектури, перевіряти під час інженерії та підтримувати після випуску.

У цій статті пояснюється, що таке Регламент (ЄС) 2024/2847, чого він досягне, до кого він застосовується та як Lionwood Software дотримується інженерних практик, узгоджених з CRA, під час створення програмного забезпечення на замовлення для клієнтів, орієнтованих на європейський ринок.

Що таке Закон про кіберстійкість?

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

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

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

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

Для чого потрібен Регламент (ЄС) 2024/2847?

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

Регламент (ЄС) 2024/2847 має на меті змінити це, вимагаючи від виробників та учасників ланцюга поставок створювати, документувати, контролювати та обслуговувати продукти з урахуванням кібербезпеки.

Щодо програмного забезпечення на замовлення, регулювання впливає на кілька сфер:

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

Управління вразливостями: команди повинні мати змогу виявляти, оцінювати, виправляти та повідомляти про вразливості протягом життєвого циклу продукту.

Безпечні оновлення: Патчі безпеки мають доставлятися безпечно та без непотрібних порушень основної функціональності продукту.

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

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

Звітування про інциденти: Активно використовувані вразливості та серйозні інциденти безпеки повинні бути повідомлені у чітко встановлені терміни.

Готовність до маркування CE: Вироби, на які поширюється дія CRA, повинні бути підготовлені до оцінки відповідності та маркування CE, де це можливо.

Через це CRA особливо важлива для технічних директорів, власників продуктів, віце-президентів з інженерії та генеральних директорів, які планують запускати спеціалізоване програмне забезпечення в Європі. Продукт, який є технічно корисним, але погано документованим, слабо захищеним або залежить від некерованих програмних компонентів, може створювати серйозний комерційний ризик.

На кого поширюється дія Закону про кіберстійкість?

Закон про цифрові технології (CRA) визначає кількох учасників ланцюжка створення вартості цифрового продукту. Найважливішою роллю для багатьох клієнтів Lionwood є Виробник.

У проекті розробки програмного забезпечення на замовлення клієнт часто виступає в ролі Виробника, коли замовляє цифровий продукт та розміщує його на ринку під своїм власним ім'ям або торговою маркою. Lionwood Software виступає в ролі інженерного партнера, який проектує, створює, документує та підтримує технічну основу, необхідну для готовності до CRA.

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

Основна відповідальність залишається чіткою: Lionwood не замінює юридичні зобов'язання клієнта як виробника, імпортера чи дистриб'ютора. Натомість ми дотримуємося робочих процесів розробки, узгоджених з CRA, тому артефакти програмного забезпечення на замовлення, які ми надаємо, допомагають клієнтам підготуватися до маркування CE, оцінки відповідності, технічної документації, обробки вразливостей та безпечного обслуговування.

Чому CRA важлива для основних галузей промисловості Lionwood

Закон про кіберстійкість особливо актуальний для галузей, де програмне забезпечення пов'язане, операційно важливе та глибоко інтегроване з бізнес-інфраструктурою. Це включає багато секторів, де Lionwood Software створює індивідуальні рішення.

Логістика та транспорт

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

Згідно з Законом про кібербезпеку (CRA), до такого підключеного програмного забезпечення слід ставитися серйозно з точки зору кібербезпеки. Слабкий API, застарілі залежності, відкрита панель адміністратора або погано захищена інтеграція можуть створювати операційні ризики для всього ланцюжка поставок.

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

Платформи для охорони здоров'я та медичних даних

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

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

Роль Lionwood полягає в тому, щоб переконатися, що технічна архітектура не розглядає безпеку як пізніше вдосконалення. В охороні здоров'я безпека має бути частиною основи продукту.

H3: Виробниче та промислове програмне забезпечення

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

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

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

Цифрові активи та блокчейн

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

Саме тут стає актуальним досвід Lionwood з проектом Lingon Certificates. Проект передбачав створення мобільного застосунку, який створює унікальні сертифікати та реєструє право власності на активи електронної комерції на блокчейні Ethereum. Користувачі можуть сканувати QR-код, щоб перевірити оригінальність та уникнути підробок, а застосунок підтримує авторизацію за допомогою телефону та біометричну автентифікацію.

Lingon не є продуктом, що відповідає вимогам CRA, і його не слід представляти як такий. Його цінність у цьому контексті полягає в архітектурній складовій. Він демонструє досвід Lionwood у створенні систем, де автентичність, безпечний доступ, записи, захищені від несанкціонованого доступу, та відстеження життєвого циклу є центральними для продукту.

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

Як Lionwood Software дотримується робочих процесів, узгоджених з CRA, з нашого боку

У Lionwood Software ми не чекаємо фінального етапу контролю якості, щоб думати про кібербезпеку. Наш підхід базується на принципах безпеки за проектуванням та безпеки за замовчуванням.

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

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

1. Безпека за проектуванням починається на етапі виявлення

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

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

Під час дослідження наша команда перевіряє:

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

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

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

Категорія ризику: Чи належить продукт до загальної, важливої ​​або критичної категорії кібербезпеки згідно з логікою CRA.

Архітектура безпеки: Які елементи керування слід вбудувати в архітектуру перед початком розробки.

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

Ця рання робота допомагає клієнтам уникнути найдорожчої помилки в розробці програмного забезпечення: виявлення прогалин у безпеці та відповідності вимогам після того, як продукт вже зібраний.

2. Ми вбудовуємо прозорість залежностей та готовність до SBOM у процес розробки

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

Саме тут розробка специфікації матеріалів програмного забезпечення (SBOM) стає надзвичайно важливою.

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

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

Інвентаризація залежностей: Ми відстежуємо сторонні бібліотеки, фреймворки, пакети та сервіси, що використовуються в користувацькій кодовій базі.

Контроль версій: Ми відстежуємо версії, щоб можна було виявити та замінити застарілі або вразливі компоненти.

Відкритість коду: Ми допомагаємо клієнтам зрозуміти, які компоненти з відкритим кодом включені та як вони використовуються.

Інтеграція CI/CD: Де це доречно, ми інтегруємо автоматизоване сканування залежностей та робочі процеси генерації SBOM у конвеєр доставки.

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

Це забезпечує клієнтам чіткішу технічну видимість і допомагає їм підготуватися до зобов'язань CRA для виробників програмного забезпечення.

3. Ми застосовуємо принципи безпечного ведення журналу та відстеження

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

Ми розробляємо ведення журналу та відстеження на основі фактичного профілю ризику продукту. Логістична ERP, платформа даних охорони здоров'я та додаток сертифіката блокчейн не вимагатимуть однакової моделі журналу. Але всім серйозним підключеним продуктам потрібен спосіб реконструювати, що сталося, коли щось пішло не так.

Наш підхід до ведення журналу може включати:

Події автентифікації: відстеження спроб входу, змін доступу та активності, пов’язаної з ролями.

Активність API: моніторинг конфіденційних запитів, аномального трафіку та поведінки інтеграції.

Події безпеки: запис підозрілої активності, невдалих спроб доступу, змін конфігурації та системних сповіщень.

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

Дані розслідування інцидентів: Збереження технічних доказів, необхідних для розуміння та повідомлення про серйозні проблеми.

Це безпосередньо підтримує акцент CRA на управлінні вразливостями та готовності до звітування про інциденти.

4. Проєкт сертифікатів Lingon демонструє нашу дисципліну в архітектурі безпеки

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

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

З точки зору CRA, важливий урок полягає не в тому, що Lingon є рішенням для прямого забезпечення відповідності. Важливий урок полягає в тому, що Lionwood має практичний досвід розробки програмного забезпечення, в архітектуру якого вбудовані процеси відстеження, довіри, безпечного доступу та захисту від несанкціонованого доступу.

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

5. Ми розділяємо функціональні оновлення від патчів безпеки

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

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

Наш підхід включає:

Модульна архітектура: розділення критично важливих компонентів для застосування оновлень з меншими перебоями.

Безпечні конвеєри CI/CD: підтримка контрольованих процесів збірки, тестування та розгортання.

Патч-тестування: Перевірка оновлень безпеки перед їх випуском.

Планування відкату: підготовка шляхів відновлення, коли оновлення створює неочікувану поведінку.

Документація випуску: Ведення технічних записів про те, що змінилося, чому це змінилося та як це впливає на продукт.

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

6. Ми вбудовуємо готовність до звітності про інциденти в продукт

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

Lionwood допомагає клієнтам підготуватися до цієї реальності, розробляючи продукти з діагностичною прозорістю.

Системи моніторингу: Ми впроваджуємо логіку моніторингу, яка допомагає виявляти підозрілу або аномальну поведінку.

Реєстрація подій: Ми структуруємо журнали, щоб можна було переглянути та зрозуміти відповідні технічні події.

Логіка сповіщень: Ми допомагаємо визначити, коли система повинна повідомляти відповідальні команди про незвичайну активність.

Докази інциденту: Ми зберігаємо технічні деталі, необхідні для розслідування та пояснення того, що сталося.

Оперативна передача: Ми підтримуємо клієнтів з передачею документації та технічних знань, щоб їхні команди могли підтримувати прозорість після запуску.

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

7. Ми зменшуємо поверхню атаки завдяки чистій кастомній архітектурі

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

AtЦе важливо згідно з Законом про кредитування, оскільки кожен непотрібний компонент може стати додатковою загрозою безпеці.

У Lionwood ми прагнемо зменшити площу атаки шляхом:

Мінімізація даних: збір та обробка лише тих даних, які дійсно потрібні продукту.

Lean Feature Scope: Уникнення непотрібної функціональності, яка створює додатковий ризик без бізнес-цінності.

Контрольовані інтеграції: підключення лише до сервісів, які є обґрунтованими, задокументованими та захищеними.

Дозволи на основі ролей: надання користувачам лише доступу, необхідного для виконання їхніх обов’язків.

Простота архітектури: проектування систем, які легше обслуговувати, контролювати та оновлювати.

Безпека полягає не лише у додаванні додаткових інструментів. Вона також полягає у видаленні непотрібних елементів.