Готовність до CRA починається з кодової бази: 7 запитань для виявлення прогалин

Акт про кіберстійкість (CRA) часто розглядають як політичний або звітний виклик, але для виробників цифрових елементів його вплив виявляється значно раніше: у pull request, build-пайплайнах, затвердженні релізів і наборах тестів. Компанія не зможе подати достовірний звіт про використану вразливість, якщо заздалегідь не відповість на прості інженерні запитання: які версії уражені, який компонент створив ризик і чи спрацювало виправлення в реальному продукті.

Терміни, які вже набули чинності

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

Від політики до спостережуваного контролю

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

Сім запитань, які виявляють прогалини

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

Пріоритизація за ризиком і вплив AI

Результат оцінювання має бути планом, упорядкованим за ризиком: відсутній безпечний параметр за замовчуванням у відкритому для інтернету продукті нагальніший, ніж прогалина в автоматизації низькоризикового внутрішнього компонента. Враховуються відкритість продукту, критичність функції, можливість експлуатації та кількість уражених версій. До цього додається зростання агентної розробки: у дослідженні Sonar 96% розробників заявляють, що не повністю довіряють коду, написаному AI, однак лише 48% завжди перевіряють його до коміту. Ця розбіжність робить автоматичний контроль незамінним, незалежно від того, належить код людині чи агенту.

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