Інцидент із ізраїльською компанією Checkmarx, відомою рішеннями у сфері безпеки додатків та DevSecOps, показово демонструє, наскільки вразливою може бути ланцюг постачання програмного забезпечення навіть у самих вендорів безпеки. Після гучної supply chain-атаки зловмисники опублікували пов’язані з компанією дані на одному з ресурсів Dark Web, що привернуло увагу всієї кіберспільноти.
Витік даних Checkmarx: роль GitHub та Dark Web
За попередніми результатами внутрішнього розслідування, опубліковані на Dark Web матеріали, імовірно, походять з одного з GitHub-репозиторіїв Checkmarx. Компанія пов’язує несанкціонований доступ до нього з початковою supply chain-атакою, яку датують 23 березня 2026 року.
Checkmarx наголошує, що скомпрометований репозиторій фізично та логічно ізольований від продуктивних середовищ клієнтів, а отже, у ньому не зберігалися дані замовників. Наразі фахівці з цифрової криміналістики аналізують обсяг і характер витоку, щоб точно визначити перелік скомпрометованих артефактів: вихідний код, конфігурації, технічну документацію та службові дані.
У рамках реагування доступ до проблемного GitHub-репозиторію було оперативно заблоковано, а політики керування доступом, ключами та токенами переглядаються. Компанія офіційно заявила, що у разі виявлення будь-якої клієнтської інформації всі потенційно постраждалі сторони будуть негайно повідомлені, що відповідає кращим практикам реагування на інциденти.
LAPSUS$ проти TeamPCP: хто стоїть за атакою на Checkmarx
Додатковий резонанс інциденту надало повідомлення ресурсу Dark Web Informer у соцмережі X про запис на одному з сайтів витоків, пов’язаний з угрупованням LAPSUS$. У листингу стверджується, що Checkmarx стала однією з трьох нових «жертв» цієї групи.
Згідно з описом, у викраденому наборі даних нібито присутні вихідний код, база даних співробітників, API-ключі, а також облікові дані для MongoDB і MySQL. Незалежна верифікація цього масиву наразі ускладнена, а Checkmarx офіційно не підтвердила повний перелік викраденої інформації, що типовo для ранніх фаз розслідування кібератак.
Водночас за саму початкову supply chain-атаку раніше взяла на себе відповідальність інша група — TeamPCP. Саме їй приписують втручання у процеси розробки та публікації програмних компонентів Checkmarx. Подібна «конкуренція» заяв серед кіберзлочинців ускладнює атрибуцію нападу та підкреслює фрагментованість кримінального ландшафту.
Компрометація Trivy, GitHub Actions, Docker та VS Code
Коренем інциденту стала supply chain-атака, пов’язана з Trivy — популярним інструментом для сканування контейнерів та інфраструктури. Зловмисники модифікували два workflow-файли GitHub Actions і два плагіни, що розповсюджувалися через маркетплейс Open VSX для Visual Studio Code.
У змінені компоненти було непомітно вбудовано credential stealer — шкідливий модуль, спрямований на крадіжку секретів розробників: токенів доступу, паролів, API-ключів та конфіденційних змінних середовища. Такі модулі особливо небезпечні, оскільки дозволяють зловмисникам виконувати «стрибок» між системами, використовуючи цілком легітимні облікові дані CI/CD та хмарної інфраструктури.
За даними розслідування, той самий атакуючий пізніше скомпрометував Docker-образ Checkmarx KICS, ще два розширення Visual Studio Code та додатковий workflow GitHub Actions з аналогічним шпигунським функціоналом. Це призвело до каскадного ефекту у ланцюгу постачання — тимчасової компрометації npm-пакета Bitwarden CLI, який використовувався як залежність у процесі збірки.
Чому supply chain-атаки є стратегічною загрозою
На відміну від класичних атак на периметр, у випадку з атаками на ланцюг постачання ПЗ об’єктом компрометації виступають не кінцеві сервери або робочі станції, а інструменти та процеси розробки. Це дозволяє непомітно доставляти шкідливий код разом з легітимними оновленнями, бібліотеками чи контейнерними образами.
Міжнародна практика вже продемонструвала масштабність подібних інцидентів — достатньо згадати атаку на SolarWinds або компрометацію окремих пакетів у npm та PyPI. Один успішний злам постачальника може вплинути одразу на тисячі організацій, а автоматизація DevOps / DevSecOps-процесів лише підсилює потенційні наслідки, адже CI/CD-пайплайни мають широкий доступ до секретів і виробничої інфраструктури.
Ключові заходи захисту DevOps та DevSecOps-команд
1. Жорстке керування секретами. Використання спеціалізованих менеджерів секретів, регулярна ротація ключів і токенів, повна заборона зберігання паролів та API-ключів у Git-репозиторіях. Автоматичне сканування репозиторіїв на наявність секретів має стати стандартом.
2. Посилення безпеки CI/CD-процесів. Надання GitHub Actions та інших CI/CD-систем прав за принципом найменших привілеїв, обмеження використання сторонніх action’ів, валідація артефактів збірки, підпис контейнерних образів і перевірка цих підписів перед розгортанням.
3. Неперервний моніторинг ланцюга постачання. Впровадження SBOM (Software Bill of Materials) для прозорості залежностей, контроль цілісності пакетів, використання інструментів виявлення аномалій у процесах збірки та публікації, а також регулярні аудити конфігурацій DevOps-інфраструктури.
4. Прозорість та обмін технічними деталями. Швидка публікація технічної інформації про інциденти, індикаторів компрометації (IoC) та рекомендацій з реагування допомагає зменшити сумарні збитки для екосистеми та прискорює виявлення вторинних жертв у ланцюгу постачання.
Історія з кібератакою на Checkmarx та подальшою публікацією даних на Dark Web ще раз підкреслює: безпека ланцюга постачання ПЗ стала критичним елементом сучасної кібербезпеки. Організаціям варто переглянути свої DevSecOps-процеси, посилити контроль над CI/CD, керуванням секретами та зовнішніми залежностями, а також системно навчати команди принципам безпечної розробки. Ті, хто інвестує у захист supply chain сьогодні, суттєво знижують ризик того, що наступний гучний інцидент буде пов’язаний саме з їхньою інфраструктурою.
