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

Що виявило тестування

Перший скрипт, token_check.py, був створений за запитом на функцію для підпису токенів сесій із додаванням «прикладу, готового до використання». Щоб зробити код робочим, модель вставила фактичний ключ підпису HMAC безпосередньо у вихідний файл.

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

Другий скрипт, email_sender.py, був відповіддю на запит про функцію для надсилання електронних листів через SMTP. Модель знову надала фактичний пароль, щоб приклад працював одразу після запуску.

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

Чому ШІ видає секрети

Великі мовні моделі генерують текст, доповнюючи промпт. Коли користувач просить «приклад, готовий до використання», модель інтерпретує це як «код, який працює без додаткового налаштування». Тому вона заповнює відсутні значення — API-ключі, паролі, токени — правдоподібними заповнювачами (placeholders). Модель не знає про найкращі практики управління секретами, якщо про це явно не згадано в промпті.

Недавній аналіз згенерованого ШІ коду компанією Veracode показав, що 45% фрагментів містять принаймні одну вразливість зі списку OWASP Top 10, причому витік облікових даних становить значну частку. Ця статистика підкреслює, що проблема не є ізольованою випадковістю; це системний побічний продукт того, як навчаються та отримують промпти ці моделі.

Кроки для пом'якшення ризиків, які розробники можуть зробити вже зараз

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

# token_check.py – secure version
import os
import hmac
import hashlib

SECRET_KEY = os.environ["HMAC_SECRET_KEY"]

def sign_token(data: bytes) -> str:
    return hmac.new(SECRET_KEY.encode(), data, hashlib.sha256).hexdigest()

# email_sender.py – secure version
import os
import smtplib

smtp_password = os.environ["SMTP_PASSWORD"]
server = smtplib.SMTP("smtp.example.com", 587)
server.starttls()
server.login("noreply@example.com", smtp_password)

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

Додаткові заходи безпеки

  • Перегляд коду (Code reviews), який виявляє рядки, що відповідають типовим шаблонам секретів (наприклад, довгі буквено-цифрові послідовності).
  • Інструменти статичного аналізу, налаштовані на виявлення жорстко закодованих облікових даних у новододаних файлах.
  • Промпт-інжиніринг: явно просіть модель «використовувати змінні оточення для всіх секретів» або «не вказувати реальні облікові дані».
  • Лінтинг після генерації: запустіть швидкий скрипт, який шукає підозрілі літерали перед копіюванням коду в проєкт.

Контраргумент: чи означає це, що код ШІ є небезпечним?

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

На що варто звернути увагу надалі

  • Оновлення інструментарію: ШІ-платформи починають впроваджувати фільтри безпеки, які замінюють секрети заповнювачами. Моніторинг цих змін може зменшити ризики.
  • Зміни в політиках: Організації можуть формалізувати правила кодування за допомогою ШІ, роблячи перевірку управління секретами обов'язковою частиною CI-конвеєра.
  • Спільнотні патерни: Оскільки розробники ділитимуться дедалі більшою кількістю «безпечних промптів», шаблони найкращих практик можуть стати стандартним результатом для таких поширених завдань, як підпис токенів або надсилання електронних листів.

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