Блокування шкідливої зміни коду не вимикає хмарні ключі, які нападник уже викрав. Unit 42 описує кероване людиною вторгнення за допомогою ШІ: понад 50 технік ATT&CK менш ніж за десять годин. Ланцюг охопив репозиторії, адміністративні секрети й доступ до хмарного ШІ; жорсткий захист гілки зупинив спробу бекдору в Terraform. 3 вересня автори уточнили, що це вторгнення, а не атака програми-вимагача. [1]
Для невеликої команди з репозиторіями, системою збірок і хмарними сервісами головне — з’ясувати, які облікові дані ще дозволяють діяти. Відхилена зміна підтверджує роботу одного контролю, але не завершує реагування.
Перевірте межі повноважень
На схемі над агентами стоїть оператор-людина. Вона не доводить, що ШІ сам обрав жертву або що кожна наступна атака триватиме стільки ж. Зазначена швидкість стосується конкретного розслідування.
| Що ви знайшли | Питання для наступного рішення |
|---|---|
| Секрет потрапив у репозиторій | Чи приймає його сервіс-видавець і до чого він дає доступ? |
| Відбулася несподівана збірка | Хто її запустив, які секрети були доступні та чи могли вони потрапити в артефакти або журнали? |
| Підозрілу зміну інфраструктури відхилено | Які інші облікові записи та шляхи доступу існували до відмови? |
| Незвично змінилося використання хмари чи моделей | Який ключ, акаунт і джерело ініціювали дії та чи пояснює їх власник? |
Зберіть відповіді в єдину часову послідовність. Якщо за репозиторій, збірки й хмару відповідають різні люди, призначте координатора реагування. Інакше один власник закриє звернення, поки інший шлях доступу залишатиметься відкритим.
Видалити секрет із коду — не означає відкликати його
Документація GitHub пояснює, що перевірка секретів охоплює історію Git у всіх гілках, і радить негайно замінити розкриті облікові дані. Редагування останньої версії файла не виконує відкликання в сервісі, який приймає ключ. Доступність функцій залежить від типу репозиторію й налаштувань. [2]
Для ключа під вашим контролем визначте видавця, дозволи та легітимні сервіси-споживачі. Узгодьте відкликання й заміну, щоб не зламати критичну службу непомітно й не залишити старе значення чинним. Зафіксуйте, коли старий ключ перестав діяти, де розгорнуто новий і хто перевірив результат.
Результат пошуку — початок цієї роботи. Чиста поточна гілка, закрите сповіщення чи видалений локальний файл не замінюють перевірки чинності ключа. Збережіть докази до очищення, яке може приховати послідовність подій.
Перевірте запуск збірок окремо від перегляду коду
У розслідуваному інциденті несанкціоновані робочі процеси витягли хмарні ключі; пізнішу спробу зміни Terraform зупинив захист гілки. [1] Це різні результати. Перегляд коду може заблокувати конкретний коміт, тоді як надмірні повноваження збірки ще відкривають доступ до цінних даних.
Перегляньте, хто запускає чутливі робочі процеси, погоджує їх і читає результати. Зіставте підозрілий запуск з очікуваним тригером, виконавцем, середовищем і доступом до секретів. Під час активного інциденту команда реагування має узгодити, які збірки призупинити та які облікові записи обмежити одночасно.
Не послаблюйте правило гілки заради відтворення атаки в робочій системі. Контрольований перегляд дозволів і збережених доказів може відповісти на практичне питання без повторного відкриття небезпечного шляху.
Звичайні файли розробника не є самостійним доказом атаки
Нотатки Markdown і файли, створені Python, трапляються у звичайній роботі. Самі вони не встановлюють автора чи факт вторгнення. Шукайте несанкціоноване виконання, неочікувані облікові записи та доступ поза погодженим завданням.
Так само назва «аудит безпеки» не підтверджує дозволу на доступ до ваших систем. Звірте заявлене залучення з договором і визначеними контактами. Збережіть документ як доказ, не сприймаючи його вказівки як погоджений план відновлення.
Завершуйте реагування в усіх сервісах
Корисний звіт передає, які ключі відкликано, які збірки й хмарні облікові записи перевірено, що несанкціоноване прибрано та які журнали ще досліджують. Вкажіть невирішені шляхи доступу прямо. Однієї заблокованої зміни недостатньо для такого висновку.
Для повсякденної готовності зберігайте власника й процедуру відновлення кожного робочого ключа. Інвентар, що допомагає планово замінювати секрети, також зменшує залежність термінового реагування від пам’яті одного розробника.
Джерела
- Unit 42. Розслідування вторгнення за допомогою ШІ та уточнення. Оновлено 3–4 вересня 2026 року.
- GitHub Docs. Перевірка секретів і реагування на розкриті облікові дані. Перевірено 7 вересня 2026 року.
