Уязвимости зависимостей проверяют и в небольшой правке ИИ-агента

Зависимостью называют готовую библиотеку, которую использует ваш код. Она может подключать другие пакеты; эти косвенные зависимости тоже попадают в проект.

Представим задачу «добавить выгрузку отчёта». Агент подключил библиотеку для экспорта, а вместе с ней установились её пакеты. Это учебный пример: работа выгрузки и состав установки проверяются отдельно.

Первый вопрос к сдаче звучит так: что добавилось и зачем? Этот пункт стоит записать в критерий готовой задачи, чтобы список пакетов появился вместе с правкой.

Запись CVE описывает известную уязвимость. Сканер сопоставляет пакеты и версии вашего проекта с такими записями; для CTO это сигнал разобрать находку, а не сообщение о состоявшемся взломе.

Например, у npm-пакета lodash есть CVE-2021-23337. В GitHub Advisory Database затронутыми названы версии ниже 4.17.21; версия 4.17.21 исправляет эту находку. Первоисточник проверен 8 октября 2026.

В описании указан путь через функцию template. Инженер проверяет её использование и условия входа в вашем коде. Фраза «мы этой функцией не пользуемся» требует подтверждения, как и решение обновить пакет.

Тест выгрузки проверяет, получился ли нужный отчёт. Сканер зависимостей ищет известные дефекты пакетов. Зелёный результат одного не заменяет результат другого.

Проверка своего кода разбирает, как обработаны входные данные и права доступа. Галлюцинация API тоже проверяется иначе: существует ли метод и работает ли вызов. Эти ошибки можно получить с библиотекой, у которой сканер ничего не нашёл.

В документации npm прямо указано, что audit не проверяет peerDependencies. Значит, CTO нужен ответ об охвате выбранного инструмента, а не общее «мы прогнали аудит». Для проекта на другом менеджере пакетов выбирают его проверку.

Проверку новых пакетов ставят перед слиянием. GitHub Dependency Review показывает изменения прямых и косвенных зависимостей. При известной уязвимости action по умолчанию падает, а обязательная проверка останавливает слияние.

Само уведомление Dependabot не делает такую проверку обязательной. В закрытом репозитории доступность Dependency Review зависит от подключения GitHub Code Security или Advanced Security; это проверяют до выбора инструмента.

Отчёт должен относиться к сдаваемому коммиту. Если сервис проверки не ответил, у команды нет результата. Флаг pnpm, который разрешает успешный выход при ошибке реестра, для этой приёмки скрывает нужный сигнал.

Наши истории здесь про установку и сборку. Они не доказывают, что мы поймали CVE: библиотечной уязвимости в них не было.

Сбой зависимости способен сломать и сам отчёт об ошибке. В сентябрьском случае запись результата проходила через ту же неработающую команду, поэтому таблица прогонов не показала провал.

Урок для CTO: зелёная проверка полезна, когда понятно, какую поломку она ловит. Название «всё проверили» не заменяет отдельного результата по новым пакетам.

Результат сканера тоже должен быть читаемым. «Проверено» без даты, коммита и охвата не позволяет понять, что именно приняли.

Если пакет обновили, после обновления нужна проверка функции. Старая версия с известной дырой и новая с несовместимым поведением требуют разных решений; обновление не должно создавать новый технический долг.

На публичной странице машины мы показываем роль инженера: он пишет правила заранее и принимает работу по факту. Решение по риску нового пакета тоже остаётся у принимающего инженера.

Правило для агента должно задавать условие добавления пакета. Например, сперва объяснить его необходимость, проверить имеющуюся библиотеку и приложить результат сканирования выбранной версии. Это часть правил работы агентов.

Агент может подготовить обновление и повторный отчёт. Кто принимает изменение и риск, задаётся в ролях команды разработки; автор правки не должен сам снимать запрет, который остановил её сдачу.

Если находку решили временно допустить, решение сохраняют рядом с задачей. В нём нужны причина применимости или неприменимости, ответственный и дата пересмотра. Без них исключение останется навсегда.

Сначала этот порядок можно применить к одной реальной задаче вашей команды. Добавленный пакет, его версии и отчёт должны быть видны в вашем репозитории; результат не зависит от того, кто набрал код.

Если вести такую приёмку некому, на подписке на разработку тариф «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. Проверку добавленных пакетов и версий стоит включить в сдачу задач клиентского репозитория до начала работы.

Обсудить такую постановку можно через следующий шаг для руководителя. Сейчас этот адрес ведёт на страницу услуг.

Новая запись об уязвимости может появиться после выпуска. Dependabot alerts реагирует на обновление базы advisories и на изменение графа зависимостей. Вчерашний отчёт подтверждает вчерашнюю проверку.

При уведомлении инженер возвращается к установленной версии и условиям использования. После обновления он снова проверяет пакеты и функцию; так находка заканчивается проверенным изменением.

Проверка зависимостей становится частью работы команды, когда у уведомления есть адресат. Сканер без человека, который разбирает результат, оставляет CTO список сигналов вместо принятого решения.

1. Новый пакет входит в сдачу задачи: сохраните его назначение и точные версии.

2. Сканирование зависимостей дополняет тесты функции: запросите оба результата.

3. Находку разбирает инженер: у решения должны остаться причина и ответственный.

4. После исправления проверка повторяется: обновление должно сохранить функцию.

5. После выпуска наблюдение продолжается: назначьте адресата новых уведомлений.