Ключові моменти
- Безпека CI/CD вимагає використання інструментів, спеціально призначених для конкретних етапів; жодна платформа не здатна охопити всі ризики, пов’язані з конвеєром.
- Розкриття секретних даних залишається основним вектором порушень, причому тривалі періоди усунення вразливостей активно використовуються зловмисниками.
- SAST, SCA, DAST та IAST звертаються до різних рівнів вразливостей та повинні використовуватися комбіновано.
- Цілісність артефактів завдяки підпису та відстеженню походження за допомогою SLSA запобігає підробці складання та розгортання.
- Моніторинг під час виконання (CNAPP) має вирішальне значення, оскільки ризики продовжують розвиватися після розгортання.
- Застосування блокуючих шлюзів безпеки та принципу мінімальних привілеїв безпосередньо знижує вразливість до експлоїтів.
Безпека конвеєра CI/CD не зводиться до вибору одного інструмента. Конвеєр охоплює вихідний код, системи збирання, реєстри контейнерів, конфігурації інфраструктури та робочі навантаження у виробничому середовищі. Кожен етап пов’язаний з різними ризиками та вимагає застосування різних заходів контролю. У цьому посібнику розглядається повний набір інструментів для безпеки конвеєра CI/CD, галузеві стандарти, що регулюють їх використання, а також передові практики безпеки CI/CD, що забезпечують їх ефективну роботу у виробничому середовищі.
Згідно зі звітом Datadog «Стан DevSecOps у 2026 році»187% організацій експлуатують у виробничому середовищі як мінімум одну відому вразливість, що піддається злому. Звіт Verizon «Розслідування витоків даних 2025»2показав, що токени CI/CD становлять 32% всіх секретних даних, розкритих у публічних репозиторіях, у своїй середній час усунення становить 94 дня. Це тримісячне вікно вразливості, тоді як зловмисники цілодобово запускають автоматичні сканери облікових даних проти публічних репозиторіїв.
- 87% організацій мають принаймні одну відому вразливість, яку можна використовувати, у розгорнутих сервісах
- 32% всіх секретних даних, що витікають з публічних репозиторіїв, – це токени CI/CD та розробки
- 71% робочих процесів GitHub Actions залишаються повністю незакріпленими
- Середній час усунення витоку секретного токена CI/CD у публічному репозиторії становить 94 дні
Інструменти безпеки конвеєра CI/CD за етапами
Кожен етап конвеєра CI/CD пов’язаний із певними ризиками. Початковий код може містити логічні помилки. Залежності можуть нести відомі вразливості (CVE). Системи збирання схильні до злому. Образи контейнерів містять вразливості лише на рівні ОС. Файли «інфраструктура як код» можуть містити помилки в налаштуваннях. Розгорнуті робочі навантаження продовжують накопичувати ризик після запуску. Жодна платформа не здатна охопити всі ці аспекти. Наведені нижче інструменти безпеки CI/CD призначені на вирішення завдань на кожному конкретному етапі.
1 SAST
Статичне тестування безпеки додатків (SAST) є статичний аналіз вихідного коду, що проводиться до початку його виконання. Воно дозволяє виявляти жорстко запрограмовані конфіденційні дані, небезпечні шаблони, вразливості до впровадження коду та недоліки безпеки на ранніх етапах розробки, коли витрати на їхнє усунення є мінімальними.
2 SCA
Аналіз складу програмного забезпечення (SCA) перевіряє сторонні бібліотеки та компоненти з відкритим вихідним кодом на відповідність базам даних CVE та каталогу CISA KEV3. Тільки 21% організацій мають повну видимість залежностей. SCA безпосередньо усуває цю прогалину.
3 DAST
Динамічне тестування безпеки додатків (DAST) перевіряє працюючі програми на наявність вразливостей, які не може виявити статичний аналіз: обхід автентифікації, вразливості, пов’язані з ін’єкцією, некоректна обробка сеансів. SAST працює з кодом. DAST працює з поведінкою. Обидва підходи необхідні.
4 IAST
Інтерактивне тестування безпеки програм (IAST) моделює роботу програми під час виконання функціональних тестів. Воно відстежує поведінку зсередини запущеного процесу, поєднуючи статичні та динамічні сигнали. Дає менше помилкових спрацьовувань, ніж SAST чи DAST окремо.
5 Виявлення секретних даних
Сканує репозиторії коду, файли YAML конвеєра, образи контейнерів та історію фіксацій на наявність відкритих ключів API, токенів та паролів. Повинно запускатись при кожній фіксації та злитті, а не лише при початковому надсиланні. Секретні дані також з’являються внаслідок автоматичних злиття та оновлення залежностей.
6 Управління секретами
Замінює статичні облікові дані у конфігураціях конвеєрів на короткострокові секрети, що витягуються під час виконання сховища. Усуває основну причину 94-денного періоду вразливості облікових даних: довгострокові токени, які нескінченно зберігаються у змінних середовищах та конфігураційних файлах.
7 Сканування контейнерів
Здійснює сканування образів контейнерів на наявність відомих вразливостей у пакетах ОС та бібліотеках додатків до того, як образ потрапляє до реєстру. Запобігає попаданню образів з активними CVE у виробничі робочі навантаження.
8 Підпис образу
Створює криптографічні підтвердження, які пов’язують образ контейнера з перевіреною історією складання. Контролери доступу можуть відхиляти непідписані образи на етапі розгортання, блокуючи підстановку артефактів перед виконанням.
9 Сканування IaC
Сканування безпеки «інфраструктура як код» виявляє помилки конфігурації в Terraform, маніфестах Kubernetes, CloudFormation та діаграмах Helm до розгортання. Виправити надмірно дозвільні ролі IAM та відкриті групи безпеки набагато дешевше, поки вони залишаються текстовими файлами.
10 CNAPP
Платформи захисту хмарних програм забезпечують безпеку як на етапі розробки, а й у виробничому середовищі. CSPM контролює конфігурацію хмарної інфраструктури. CWPP забезпечує захист запущених робочих навантажень. Безперервний моніторинг після розгортання дозволяє підтримувати високий рівень безпеки організації, що виходить за межі можливостей сканування на етапі складання.
SAST, DAST та IAST: Статичний аналіз коду виявляє помилки у вихідному коді. Динамічне тестування виявляє вразливість у працюючому додатку. Інтерактивне тестування спостерігає реальне виконання під час функціональних тестів. Кожен із цих підходів охоплює окрему область вразливостей. Використання лише одного типу означає наявність передбачуваних «сліпих зон» у безпеці додатка.
Стандарти безпеки конвеєрів CI/CD: NIST, SLSA та OWASP
Існує низка авторитетних методологій, що визначають підходи до забезпечення безпеки конвеєрів CI/CD як на управлінському, так і на технічному рівнях. Вони фігурують у звітах з аудиту відповідності, федеральних вимогах до закупівель програмного забезпечення та оцінки безпеки постачальників. Кожна їх охоплює свій рівень.
У документі NIST SP 800-218 визначено цілі, які має досягати процес розробки. У документі OWASP CI/CD Top 10 ці цілі перетворені на конкретні заходи контролю конвеєра. SLSA забезпечує рівень криптографічної перевірки для забезпечення цілісності складання та відстеження походження артефактів. У сукупності: управління, реалізація та перевірка.
Передові практики безпеки конвеєра CI/CD: Як захистити свій конвеєр
Наведені нижче практики спрямовані на усунення вразливостей, які, згідно з даними про загрози, найактивніше використовуються зловмисниками. Кожна їх безпосередньо співвідноситься з категоріями інструментів, зазначеними вище.
Закріпити дії робочого процесу та залежності за конкретним SHA-кодом комміту
Коли конвеєр посилається на тег actions/checkout@v4, він запускає код під цим тегом на момент виконання. Зловмисник, який одержав доступ до облікового запису супроводжуючого, може непомітно перемістити цей тег. В результаті при наступному запуску конвеєр виконуватиме код, контрольований зловмисником, при цьому жодних змін у файлах робочого процесу не буде видно.
Прив’язка до повного SHA, наприклад, у actions/checkout
@11bd71901bbe5b1630ceea73d27597364c9af683 гарантує, що виконання відповідає тому, що було перевірено та схвалено. Злам GitHub Action Xygeni у березні 2026 року був здійснений саме з використанням цього шаблону: за допомогою викрадених облікових даних змінений тег був переміщений у коміт з бекдором, що торкнулося всіх репозиторій, в яких він згадувався. Виправлення в обох випадках однакове: один рядок на дію, нульові витрати.
Перетворіть сканування безпеки на блокуючі етапи конвеєра
Коли сканування SAST виявляє критичну вразливість, а складання проходить успішно, розробники приходять до висновку, що ці попередження не мають значення. У конвеєрах, що швидко працюють, попередження, що не призводять до блокування, систематично ігноруються. Перевірки безпеки в CI/CD, які мають виключно рекомендаційний характер, не змінюють такої поведінки.
Виявлені в ході статичного тестування безпеки додатків, аналізу складу програмного забезпечення та сканування IaC вразливості високого ступеня небезпеки, які можуть бути використані зловмисниками, повинні призводити до зупинки збирання. Вразливість середнього ступеня небезпеки супроводжується попередженням. Усі інші випадки фіксуються у журналі. Блокуючий фільтр дозволяє приймати рішення на тому етапі, коли усунення проблеми обходиться найдешевше.
Замініть статичні облікові дані на токени з обмеженим терміном дії
Кількість API-ключів, що зберігаються як змінні середовища CI/CD, постійно зростає. Більшість із них ніколи не оновлюються. Згідно з звітом Verizon DBIR за 2025 рік, середній термін усунення вразливостей, пов’язаних із секретними даними, виявленими у публічних репозиторіях, становить 94 дні. Для ключів, які ніколи не виявлялися, термін усунення вразливостей взагалі відсутні.
Федерація ідентифікаційних даних OIDC повністю унеможливлює зберігання облікових даних. GitHub Actions і GitLab CI підтримують цю технологію на рівні платформи: платформа генерує короткочасний токен, що діє тільки в рамках конкретного завдання і втрачає чинність після його виконання. Вкрасти нічого, оскільки жодні дані не зберігаються. HashiCorp Vault, AWS Secrets Manager та Azure Key Vault забезпечують динамічну передачу секретних даних для сервісів, які не можуть безпосередньо використовувати OIDC.
Підписуйте результати збирання та перевіряйте їх перед розгортанням
Непідписаний образ контейнера в реєстрі не має криптографічної прив’язки до збирання, внаслідок якого він був створений. У період між відправкою до реєстру та витягом із кластера він може бути підмінений на шкідливу версію.
Підписка артефактів за допомогою Cosign і генерація сертифікатів походження SLSA дозволяють створити ланцюжок, що піддається перевірці, від вихідного комміту до запущеного контейнера. Контролери доступу, такі як Kyverno або OPA Gatekeeper, забезпечують, щоб у виробниче середовище потрапляли лише підписані та завірені образи. Підміна артефактів перестає бути непомітною та блокується на вході.
Створюйте специфікацію програмного забезпечення при кожній збірці
Згідно зі звітом Datadog DevSecOps Report 20261, середнє відставання виробничих бібліотек від останньої основної версії складає 278 днів. Бібліотеки 2023 містять у середньому 3,8 вразливості на кожен сервіс. Коли з’являється новий CVE для компонента, розташованого третьому рівні залежностей, організації, які мають специфікації програмного забезпечення, змушені вручну перевіряти кожну кодову базу, щоб визначити, які сервіси торкнулися.
Генерація списку компонентів (SBOM) у форматі CycloneDX або SPDX на етапі складання та його інтеграція в систему безперервного моніторингу вразливостей CVE перетворює процес перевірки «Чи торкнулися ми?» з займає кілька днів завдання запит, відповідь який надходить за лічені секунди.
Застосовуйте контроль доступу на основі ролей до всіх ідентифікаторів конвеєра
Права доступу облікових записів служб конвеєра розширюються завдяки додаванням, які ніколи не видаляються. Завданню, що виконує компіляцію вихідного коду, не потрібен доступ на запис до виробничих систем, але багато з них все одно мають такі права. Згідно зі звітом Cloud Security Alliance «Стан безпеки SaaS у 2025 році»446% організацій не можуть здійснювати моніторинг своїх нелюдських ідентифікаторів.
Будь-який дозвіл із надмірними повноваженнями — це потенційна загроза горизонтального проникнення після злому. Обмеження доступу для кожного завдання до мінімально необхідного рівня та регулярна перевірка налаштувань доступу дозволяють звести до мінімуму наслідки злому облікових даних.
Розширіть сферу безпеки від етапу збирання до етапу експлуатації
Сканування на етапі збирання дає результат, актуальний тільки на певний момент часу. Після розгортання з’являються нові вразливості (CVE), зміни змінюються, а поведінка системи під час роботи може змінюватися. Те, що було схвалено на етапі збирання шість місяців тому, може не відображати профіль ризиків поточного робочого середовища.
Платформи CNAPP з функціями CSPM і CWPP забезпечують безперервний моніторинг після передачі проєкту конвеєром. Fidelis Halo інтегрується з робочими процесами CI/CD через API та механізми автоматизації, що дозволяє узгодити перевірки безпеки та відповідності вимогам з процесами розгортання, а також розширити захист на етап виконання у середовищах AWS, Azure, локальних та гібридних.
Як взаємодіють інструменти забезпечення безпеки конвеєра CI/CD
Забезпечення безпеки конвеєра CI/CD – це багаторівневе завдання. SAST виявляє вразливість у вихідному коді. SCA виявляє вразливість у сторонніх бібліотеках. Виявлення та керування секретними даними усувають ризик витоку облікових даних, який, згідно з звітом Verizon DBIR, є основним каналом проникнення. Сканування контейнерів та підпис образів забезпечують відстеження ланцюжка від складання до виконання. Сканування IaC виявляє помилки в налаштуваннях до розгортання інфраструктури. CNAPP розширює охоплення межі розгортання, охоплюючи виробниче середовище.
Згідно з даними про кіберзагрози Cyble, опубліковані Industrial Cyber, у жовтні 2025 року кількість атак на конвеєри CI/CD через ланцюжок поставок досягла нового рекордного рівня, перевищивши попередній пік більш ніж на 30%. Ці атаки цілеспрямовано використовують вразливості у взаємодії між різними категоріями інструментів. У пакет npm впроваджується шкідливий код, призначений для збирання облікових даних
Ряд засобів керування на рівні платформи також підвищують загальний рівень безпеки конвеєра без необхідності використання додаткових інструментів:
- Захист гілок з обов’язковою перевіркою коду на всіх гілках, що запускають складання, усуває ризик, пов’язаний з недостатнім механізмом контролю потоку, описаний в OWASP CI/CD SEC-1.
- Секретні дані, обмежені конфігурацією середовища, запобігають доступу конвеєрів проміжного середовища до облікових даних виробничого середовища і навпаки.
- Підписка коммітів створює перевірений запис про ідентичність для кожної зміни коду, що надходить до репозиторію.
- Сканування IaC як блокуюча перевірка перед розгортанням виявляє помилки в конфігурації маніфестів Terraform і Kubernetes до їх застосування.
- Оповіщення конвеєра, підключені до систем SIEM та SOAR, забезпечують автоматичну локалізацію загроз; час між компрометацією облікових даних та заподіянням реальних збитків становить лічені хвилини.
