Trivy filesystem mode: де ламається перевірка залежностей
Перевірка залежностей під час збирання ламається частіше не на самій уразливості, а на способі її пошуку.
Сканування складу залежностей чіпляють після збирання образу, окремим завданням і без блокування — конвеєр збирання формально зелений, а в реліз потрапляє пакет із відомою проблемою.
Зворотний варіант теж поганий: повне сканування образу на кожен коміт додає хвилини до кожного збирання, і крок вимикають, щоб не чекати.
Trivy filesystem mode знімає обидві крайнощі: він читає маніфести й lock-файли просто з робочої копії — package-lock.json, go.mod разом із go.sum, pom.xml, requirements.txt або poetry.lock — без зібраного образу, доступу до реєстру й прав на демон контейнеризації.
Достатньо одного виконуваного файлу та локального кешу бази уразливостей, який оновлюється окремим кроком і перевикористовується між запусками, зокрема в закритому контурі.
Ламається це на багатомодульних репозиторіях. У монорепо десятки модулів із власними lock-файлами, частина пакетів приходить транзитивно через батьківський маніфест, частина — інструментальна й тестова.
Без явного списку цілей і правил виключення сканування або шумить на непідтримуваних залежностях, або мовчки пропускає модуль, до якого не дійшло за деревом. Підсумок передбачуваний: команда звикає ігнорувати червоний статус.
Розбираємо, як це закривається — як задати цілі сканування, пороги за критичністю та поведінку на виході, щоб крок залишався швидким і справді зупиняв збирання.
Що змінюється після вбудовування перевірки в збирання
Вбудовування перевірки залежностей у збирання дає вимірювані зрушення, а не відчуття спокою. Нижче — чек-ліст, за яким ми звіряємо результат на прийманні: кожен пункт рахується за логами конвеєра та звітами сканера, а не на словах.
- Час збирання — Trivy у режимі filesystem розбирає маніфести й дерево залежностей без запуску контейнерів, тому приріст до загального часу йде на десятки секунд, а не на хвилини.
- Частка виявлених уразливостей — перевірка виконується на кожному коміті, знахідка фіксується до викочування; у звіті видно зріз за рівнями критичності та динаміку від релізу до релізу.
- Зниклий клас відмов — з викочувань зникають падіння через несумісні або відкликані версії бібліотек: їх відсікає збирання, а не черговий уночі.
- Вартість простою — вимірюється годинами недоступності та кількістю ручних відкатів; коли проблему ловлять до викочування, відновлення не потрібне взагалі.
- Читабельність звіту — вивід обмежуємо новими знахідками щодо базової лінії, тому у звіт потрапляє лише те, що з’явилося в поточній зміні.
- Відтворюваність — ту саму перевірку інженер запускає локально перед комітом, і результат збігається з тим, що бачить конвеєр.
Окремо налаштовуємо пороги: блокувати збирання на критичних рівнях і попереджати на решті. Без цього шум у звіті швидко призводить до того, що перевірку починають обходити, і вона перестає ловити будь-що.
Режими сканування: файлова система, образ, реєстр
Точка перевірки визначає, що сканер взагалі здатен побачити. Trivy у режимі filesystem читає маніфести й lock-файли просто в робочому каталозі: це найшвидший варіант, секунди на прогін, годиться для pre-commit і ранніх кроків збирання.
Перевірка готового образу дає повну картину — шари, системні бібліотеки, пакети, доустановлені поверх базової основи. Віддалений реєстр образів перевіряє те, що вже опубліковано й працює в середовищі.
| Точка перевірки | Коли підходить | Обмеження |
|---|---|---|
| Файлова система | Розробка, pre-commit, перевірка маніфестів до збирання | Не бачить пакети з базового шару та системні бібліотеки |
| Готовий образ | Ворота перед публікацією, перевірка того, що реально запуститься | Потрібні зібраний артефакт і локальний демон, прогін довший |
| Віддалений реєстр | Аудит опублікованих тегів, регулярний перегляд без перезбирання | Немає доступу до локальних шарів, є залежність від доступності реєстру |
Режими сканування не замінюють, а доповнюють один одного: файлова система ловить проблему на вході, готовий образ — до публікації, реєстр — після. Розбіжність між результатами нормальна, бо частина залежностей приходить із базового шару й у файлах проєкту не видна.
Загальне обмеження — актуальність бази уразливостей. Без регулярного оновлення індексу будь-який режим дає недостовірну картину, а кеш бази варто фіксувати за версією, інакше прогони між збираннями непорівнювані.
Вибір точки — це вибір місця воріт: де відмова коштує дешевше, там і ставимо перевірку.
Етапи впровадження перевірки складу залежностей
Порядок робіт будуємо так, щоб перевірка складу залежностей вбудовувалася поверх наявного конвеєра, а не замість нього.
Спершу фіксуємо поточний стан, потім вмикаємо сканування в режимі звіту й лише після обкатки робимо перевірку блокуючою — так збирання не зупиниться вже першого дня, а команда встигне розібрати накопичені зауваження.
- Аудит конвеєра. Дивимося, як збираються артефакти, де лежать маніфести й файли залежностей, які стадії вже є і на яку з них можна поставити перевірку без перебудови збирання.
- Схема перевірок. Визначаємо охоплення — дерева репозиторіїв і зібрані образи — та точку запуску Trivy filesystem mode: до збирання, щоб не витрачати час на явно проблемний коміт.
- Налаштування порогів блокування. Розділяємо знахідки за рівнями: що зупиняє збирання, що йде у звіт, що внесено до списку прийнятих ризиків із причиною та відповідальним.
- Обкатка в режимі звіту. Перші прогони не блокують, а збирають статистику: скільки спрацювань, які повторюються, де хибні. За нею калібруємо пороги.
- Переведення в блокуючий режим. Вмикаємо зупинку за критичними рівнями й формулюємо повідомлення розробнику так, щоб було зрозуміло, що саме оновити чи замінити.
- Передавання налаштувань команді. Віддаємо правила, схему запуску, порядок оновлення списку виключень і точку звернення при спрацюванні — далі конвеєр працює без нас.
Що залишається в репозиторії після впровадження
Після впровадження в репозиторії залишається не набір разових команд, а комплект артефактів. Trivy у режимі сканування файлової системи запускається з файлу конфігурації, тому результат відтворюється однаково і на локальній машині, і в конвеєрі.
- Конфігурація перевірки — єдиний файл у корені: цілі сканування, рівні серйозності, формати звітів, поведінка збирання при знахідці.
- Правила відсікання спрацювань — список виключень, де навпроти кожного зазначено обґрунтування: чому уразливість не застосовна до профілю використання сервісу.
- Політики доступу — хто має право правити виключення й затверджувати нові, як ведеться історія правок і хто робить рев’ю.
- Регламент оновлення бази — періодичність синхронізації, поведінка збирання при недоступному джерелі, відповідальний за оновлення.
- Документація з перевірок — розділ у README: як запустити перевірку локально, що означає збій збирання, де дивитися звіт.
- Матриця серйозності — які рівні блокують збирання, які йдуть у звіт і потрапляють до плану робіт.
- Шаблон для нових сервісів — базовий набір файлів, щоб новий репозиторій стартував із перевірками, а не наздоганяв решту.
Такий комплект переживає зміну інженерів і переїзд проєкту: перевірки піднімаються за документацією, а не за пам’яттю колеги. Окремо стежимо, щоб список виключень не розростався — переглядаємо його за розкладом і прибираємо правила, що втратили підставу.
Кейс: частка збирань з уразливими залежностями знизилася
Проєкт — платформа з кількох десятків сервісів зі спільним конвеєром збирання. Перевірку залежностей тут робили після збирання образу: результат приходив через 10–12 хвилин, уже після публікації артефакту, і сприймався як довідкова інформація. Частка збирань в основній гілці з уразливими залежностями високого рівня трималася близько 27%.
Що зробили
Ми перенесли перевірку на початок конвеєра й перевели її на Trivy у режимі сканування файлової системи. Прогін іде деревом вихідних кодів — маніфестами й файлами блокування залежностей — до збирання образу, тому не чекає готового артефакту й не потребує доступу до реєстру.
База уразливостей кешується між запусками, пороги та виключення задані файлом конфігурації, а звіт віддається в розмітці, яку система контролю версій показує як зауваження прямо в запиті на злиття. Блокує лише критична уразливість із доступним виправленням — решта йде в чергу завдань.
Результат
Після переходу перевірка одного сервісу займає близько 40 секунд замість 12 хвилин, і розробник бачить підсумок у першу хвилину.
Частка збирань з уразливими залежностями знизилася з 27% до 4%, а вісім із десяти виправлень потрапляють у той самий запит на злиття, де знайшлася уразливість.
Підтверджували ефект за журналами збирань і звіркою звітів до й після: рахували частку уразливих збирань за тижнями, а не за окремими релізами, щоб виключити разовий результат.
Чим Trivy відрізняється від перевірки на боці реєстру?
Перевірка на боці реєстру працює з уже зібраним образом — шарами, базою пакетів, вмістом файлової системи.
Точка входу одна й вона остання: годиться як фінальний бар’єр перед викочуванням, але сигнал приходить після збирання й публікації тегу, коли контекст завдання в розробника вже втрачено.
Trivy у режимі filesystem сканує робочий каталог до збирання: lock-файли й маніфести залежностей, Dockerfile, маніфести Kubernetes, конфігурації та випадково закомічені секрети.
Охоплення перевірки зміщується з артефакту на джерело — видно те, що ще тільки потрапить в образ, і проблема закривається на злитті гілки, а не після публікації.
Ціна помилки теж різна. Для реєстру знайдений дефект — це наявний образ, який потрібно перезібрати, перевипустити й заново викотити в середовище.
Для filesystem-режиму — правка одного рядка й збійна перевірка в тому самому завданні, де йдуть тести й лінтери; відкат не потрібен, бо поганий артефакт не створювався.
Перевірка на боці реєстру при цьому не скасовується: вона бачить реальне збирання, включно з базовими шарами, і покриває образи, зібрані не нашим конвеєром.
Плюс вона переперевіряє артефакти, що вже лежать у реєстрі, коли в базі з’являється нова уразливість, — вихідних кодів у старого тегу може вже не бути.
Підсумок: точки перевірки не замінюють одна одну, а ділять ролі. Режим filesystem дає ранню відмову й зворотний зв’язок за хвилини в тому самому прогоні, що й тести, реєстр залишається останнім бар’єром перед видачею.
Часті технічні сумніви щодо перевірки залежностей
Сумніви інженерів щодо перевірки залежностей зводяться до чотирьох тем: скільки хибних спрацювань доведеться розбирати вручну, чи працює розбір у закритому контурі, наскільки він сповільнює збирання і як оновлюється база уразливостей без зовнішніх запозичень.
Нижче — короткі відповіді на рівні конфігурації. Мова про режим trivy filesystem mode: він читає маніфести й файли блокування просто з робочої копії, не вимагаючи зібраного образу.
Чи потонемо ми в хибних спрацюваннях?
Поки не налаштовані фільтри — так. Ми відсікаємо невикористовувані вітки залежностей, обмежуємо правило рівнем критичності й ведемо файл виключень, де в кожного рядка є автор і строк перегляду. Після цього на реліз залишаються одиниці знахідок, і кожна потребує реального рішення.
Чи працює це в закритому контурі?
Так. База уразливостей розгортається у внутрішньому реєстрі артефактів, оновлення йде за розкладом, а сам розбір не звертається до зовнішньої мережі.
Там, де зовнішній доступ дозволено, база підтягується напряму; у закритому контурі дзеркало перевіряється на цілісність до прогону, інакше застарілий зліпок тихо пропускає знахідки.
Наскільки розбір сповільнює збирання?
Помітно лише без кешу. Крок ставимо після встановлення залежностей, проганяємо за зміненими файлами блокування, базу тримаємо локально поруч зі складальним агентом.
На типовому релізі приріст вимірюється секундами; звіт іде окремим артефактом і не блокує збирання, поки не виставлені пороги.
Обговоримо завдання: що надіслати для оцінки конвеєра
Щоб повернутися з оцінкою та планом робіт, нам потрібні вхідні дані щодо вашого конвеєра — без них розрахунок строків перетворюється на здогади. Нижче список того, що ми зазвичай уточнюємо на першій розмові; частина пунктів часто вже є під рукою.
- Посилання на репозиторій і файл опису збирання (GitLab CI, GitHub Actions, Jenkinsfile) — за ним видно, на якому етапі зараз запускаються перевірки і де стане крок сканування.
- Мови та менеджери залежностей: go.mod, package-lock.json, requirements.txt, pom.xml, composer.lock — від них залежить, які аналізатори увімкне Trivy filesystem mode і скільки часу займе прохід.
- Вимоги до звітів: потрібен SARIF для вбудованої панелі, JSON для розбору скриптами або таблиця в артефактах збирання.
- Політика щодо уразливостей: які рівні критичності зупиняють збирання, а які лише логуються; чи є виключення та файл .trivyignore.
- Обмеження середовища: закритий контур без зовнішніх звернень, власний реєстр образів, проксі, локальний кеш баз уразливостей.
- Регламент розбору знахідок: хто відповідає за виправлення, за який час закриваються критичні, як оформлюється відкат при хибному спрацюванні.
- Цільові цифри: скільки зараз триває збирання і який запас часу на крок сканування ми не повинні перевищувати.
Надішліть ці вхідні дані — обговоримо завдання й повернемося з оцінкою та планом робіт: етапи, що змінюємо в конвеєрі, як перевіряємо результат. Якщо якихось даних немає, підкажемо, де їх узяти.
