Ми програмуємо зі ШІ щодня. Власну систему для виставлення рахунків та управління InvoAIM ми вдвох інакше не побудували б — і немає сенсу вдавати, що це можливо без нього. Саме тому ми й знаємо, де воно скрипить. І скрипить не там, де на це чекають.
Що ШІ в коді псує насправді
Очікується, що ШІ робитиме одруки й нісенітниці. Але він цього не робить. Код, який він пише, компілюється, тести проходять, а демо працює. Помилки, яких він припускається, — іншого штибу:
- Відсутня перевірка прав доступу. Функція повертає замовлення за ID. Що це має бути замовлення авторизованого користувача, ніхто не написав — а ШІ сам цього не додасть.
- Відкриті інтерфейси. Адміністративний endpoint виник під час налагодження й лишився доступним без авторизації.
- Ключі в репозиторії. API-токен під час випробувань записали безпосередньо у файл. Пізніше його винесли до змінної середовища, але в історії комітів він лишився.
- Старі залежності. Модель запропонує бібліотеку, яку знає з тренувальних даних — тобто таку, що була популярною два роки тому.
Усе це речі, яких під час читання «виглядає добре» не помітиш. Їх треба шукати цілеспрямовано.
Числа, а не враження
Ідеться не про відчуття, що «код від ШІ гірший». Вимірювання за 2025 рік кажуть таке:
- У 45 % завдань згенерований ШІ код містив вразливість безпеки. Тестували понад 100 моделей на 80 завданнях — Veracode.
- Репозиторії, писані з асистенцією ШІ, показують до десяти разів більше знахідок з безпеки, ніж інші — Apiiro.
Друга половина рівняння — обсяг. Google і Microsoft публічно наводять, що ШІ сьогодні генерує приблизно чверть до третини нового коду, у частини молодих компаній це більшість. Помножте собі це.
Цікаво, що частота помилок на завдання порівняно з попередніми моделями суттєво не покращилася. Моделі вміють більше, пишуть читабельніший код — але перевірки безпеки додають лише тоді, коли їх про це попросять. Покращення здібностей саме собою цієї проблеми не розв’яже.
Чому цього не ловлять тести
Тести перевіряють, що застосунок робить те, що має. Безпека — про протилежне: що станеться, коли хтось використає його інакше, ніж ви задумували:
| Що ми тестуємо | Чого ми не тестуємо |
|---|---|
| користувач переглядає своє замовлення | користувач переглядає чуже замовлення |
| авторизований адмін відкриває адміністрацію | адміністрацію відкриває неавторизований |
| завантажується зображення | завантажується скрипт, перейменований на зображення |
| форма зберігає ім’я | форма зберігає шматок SQL-запиту |
Зелені тести й відкрита адміністрація існують поруч абсолютно без проблем. Одне про друге не каже нічого.
Від 11 вересня 2026 року це зміниться й на папері
Досі перевірка коду була добровільною турботою. Cyber Resilience Act робить із неї обов’язок із терміном.
Регламент ЄС 2024/2847 діє для продуктів із цифровими елементами, що виводяться на ринок ЄС. Вирішальним є те, чи постачаєте ви програмне забезпечення далі, а не те, які ви великі:
- 11. 9. 2026 — починають діяти обов’язки щодо повідомлення. Про активно експлуатовану вразливість або серйозний інцидент ви маєте повідомити: перше попередження протягом 24 годин, повне сповіщення протягом 72 годин, підсумковий звіт протягом місяця.
- 11. 12. 2027 — діє решта: безпека протягом усього життєвого циклу, технічна документація, оцінка відповідності та маркування CE.
Щоб вразливість можна було повідомити протягом 24 годин, хтось має вміти її знайти й описати. Це не та річ, яку ви розв’яжете аж тоді, коли вона настане.
До цього додається NIS2, який у Чехії діє як zákon č. 264/2025 Sb. (чеський закон про кібербезпеку) і стосується приблизно шести тисяч компаній. Він тисне на ланцюг постачання — коли ви постачаєте програмне забезпечення регульованій компанії, перевірка прийде від неї, незалежно від того, чи стосується вас регламент напряму, чи ні.
Що з цим робити практично
Якщо ви не хочете нічого купувати, ось це ви впораєте самі й воно має найкраще співвідношення користі до часу:
- Перегляньте історію комітів на ключі та паролі. Не лише поточний стан — історію. Знайдений токен потрібно анулювати, а не видалити.
- Випишіть собі всі endpointy й до кожного дайте відповідь: хто до нього дістанеться без авторизації?
- У кожного читання даних із бази перевірте, що воно фільтрує за авторизованим користувачем, а не лише за ID із запиту.
- Оновіть залежності й перегляньте відомі вразливості.
- Вимкніть debug і повідомлення про помилки, які виводять нутрощі застосунку.
Коли будете готові, лишається друга половина: задокументувати це. Нотатка в голові не є підставою ані для замовника, ані для документації згідно з CRA.
Коли покликати когось ззовні
Власний код читається погано — ви знаєте, як він мав працювати, і читаєте те, що задумували, а не те, що там є. Зовнішній погляд має сенс насамперед тоді, коли застосунок працює з персональними даними або платежами, коли ви передаєте його замовникові, або коли хтось вимагає від вас доказу, що його перевірено.
Ми робимо перевірку застосунку перед запуском: машинне сканування, ручну верифікацію знахідок і письмовий протокол із вердиктом. Код обробляємо локально в Чехії, а не в хмарі третьої сторони — у випадку вихідного коду це зазвичай умова, а не примха.
Часті запитання
Чи означає це, що зі ШІ не варто програмувати?
Ні. Ми самі програмуємо з ним щодня і без нього не побудували б власну систему в такому темпі. Проблема не в інструменті, а у співвідношенні між тим, скільки коду виникає, і тим, скільки його хтось прочитає. Раніше це співвідношення тримала швидкість написання. Сьогодні його не тримає ніщо — його треба відновити свідомо.
Хіба це не ловлять тести?
Здебільшого ні. Тести перевіряють, що застосунок робить те, що має, коли ним користується порядний користувач. Помилки безпеки — про те, що станеться, коли хтось використає його інакше: викличе чужий endpoint, надішле інший ID, спробує завантажити файл іншого типу. Зелені тести й відкрита адміністрація чудово існують поруч.
Чи стосується Cyber Resilience Act і малих компаній?
Вирішує те, чи постачаєте ви на ринок ЄС продукт із програмним забезпеченням, а не те, які ви великі. Обов’язки щодо повідомлення про активно експлуатовані вразливості та серйозні інциденти діють від 11 вересня 2026 року, решта — від 11 грудня 2027 року. Строки повідомлення — 24 години на перше попередження і 72 години на повне сповіщення.