Чому код, згенерований штучним інтелектом, порушує вашу модель управління уразливостями

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

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

Проблема залежностей тепер є проблемою штучного інтелекту

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

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

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

Сканиування після факту не є стратегією

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

Сканери виявляють проблеми після того, як вони вже в вашому коді. Віконце між введенням та виявленням – це місце, де живе ваша вразливість. Коли штучний інтелект генерує код у масштабі, це віконце розширюється, а обсяг результатів зростає швидше, ніж будь-яка команда може вручну виправити. Результатом є запас уразливостей, який розширюється нескінченно, пріоритезація стає випадковою, а розробники витрачають 4-8 годин на уразливість на роботу, яка не дає жодної бізнес-цінності.

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

Зміна, яка справді працює: контроль того, що ввійшло

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

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

Як це виглядає на практиці

Для лідерів безпеки, які працюють над цим, кілька речей мають значення більше, ніж будь-що інше:

1. Визначте свій затверджений набір компонентів, перш ніж розширювати прийняття штучного інтелекту. Якщо ваші інструменти кодування штучного інтелекту розрізняють залежності з публічних реєстрів, ваш процес затвердження існує тільки на папері. Створіть керований внутрішній реєстр, маршрутизуйте все через нього та вимагайте, щоб компоненти були створені з джерела з верифікованим походженням.
2. Відносіться до виправлення як до керованого процесу, а не до черги квитків. Організації, які залишаються попереду боргу з уразливостями, не рухаються швидше на ручному виправленні. Вони видалили ручне виправлення з рівняції. Коли доступна затверджена патч-корекція спільноти, вона автоматично перебудовується у каталог. Розробники отримують оновлення наступного разу, коли вони витягують. Ніхто не призначає квиток. Ніхто не чекає 60 днів.
3. Пропустіть свою ланцюжок інструментів штучного інтелекту через свої зобов’язання з дотримання законодавства, перш ніж вас примусово змусять це зробити. Я бачив команди, які будували інструменти штучного інтелекту протягом місяців, тільки щоб зіткнутися з стіною, коли клієнт вимагав відповідності FedRAMP або свідчення SOC 2. Ваш кураторський каталог також є вашим слідом аудиту з дотримання законодавства. SBOM та записи походження повинні супроводжувати кожний компонент, а не зібрані ретроспективно під тиском терміну.
4. Призначте чітку власність на рівні управління, а не рівня квитків. Команди, які рухаються найшвидше на виправленні, не ті, у яких найбільше розробників. Це ті, де команда безпеки володіє політикою, команда платформи володіє поставкою, і жодна з них не чекає на іншу, щоб діяти.

Безпека, яка дозволяє, а не блокує

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

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