CVE Lite CLI для JavaScript и TypeScript: локальная проверка зависимостей без ИИ

Инструмент с поддержкой OWASP локально сканирует lockfile-файлы JavaScript и TypeScript и помогает находить и устранять риски зависимостей до сбоев CI.

По мере того как ИИ-ассистенты для написания кода ускоряют разработку, один open-source проект при поддержке OWASP утверждает, что инструменты безопасности зависимостей по-прежнему приходят слишком поздно, чтобы быть по-настоящему полезными.

CVE Lite CLI — сканер уязвимостей зависимостей для JavaScript и TypeScript, ориентированный на локальный анализ lockfile-файлов, — строится вокруг простой идеи: разработчики должны видеть риски зависимостей в момент написания кода, а не спустя часы, когда CI-пайплайн уже падает.

«Чего не хватает разработчикам, так это ранней обратной связи в точке, где принимается решение о зависимости», — сказал CSO создатель и мейнтейнер проекта Sonu Kapoor. По его словам, традиционные workflow, завязанные на CI, часто разрывают связь между разработчиком и выбором зависимостей, который и создал риск.

CVE Lite CLI сканирует lockfile-файлы npm, pnpm и Yarn, используя данные об уязвимостях OSV, и, как утверждается, уделяет особое внимание рекомендациям по исправлению: разделяет прямые и транзитивные уязвимости, проверяет целевые версии обновления и предлагает практичные пути устранения проблемы.

Проект подается как developer tool в формате «local-first», а не как замена корпоративным платформам software composition analysis (SCA). Логика здесь похожа на то, как разработчики уже запускают ESLint или unit tests локально до того, как CI прогонит их снова.

CVE Lite CLI нацелен на недооцененную проблему рабочего процесса

CVE Lite CLI по сути пытается решить проблему процесса, с которой, по словам Kapoor, тихо сталкиваются многие разработчики. Проверки безопасности зависимостей часто приходят уже после того, как работа завершена.

Инструмент локально сканирует lockfile-файлы JavaScript и TypeScript в проектах npm, pnpm и Yarn, чтобы разработчики могли понимать риск зависимостей, пока они еще пишут код, а не после сбоя CI-пайплайна. Вместо того чтобы ограничиваться только обнаружением, инструмент, как утверждается, отвечает и на последующие вопросы: уязвимость прямая или транзитивная, существует ли чистый путь обновления, действительно ли обновление одного пакета убирает уязвимую зависимость.

«В одном реальном случае CVE Lite CLI пропустил 27 версий пакета, прежде чем нашел более безопасную версию для рекомендации», — сказал Kapoor, объясняя детализацию инструмента. «Именно такую работу разработчикам не следует делать вручную, читая логи и по одной пытаясь обновлять пакеты».

Kapoor сказал, что инструмент можно настроить для вывода в формате JSON, SARIF или HTML, а также встроить в CI-workflow как GitHub Action.

ИИ может только усугублять проблему

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

Kapoor сказал, что такая скорость меняет саму природу риска зависимостей. «ИИ-ассистенты для кода сделали это еще важнее, а не менее важным», — сказал он. «Скорость полезна, но она также означает, что решения по зависимостям могут приниматься быстро и иногда без того же уровня ручной проверки. Я не считаю, что ИИ-ассистенты отменяют необходимость проверок безопасности».

Напротив, они повышают потребность в быстрых, локальных и объяснимых проверках, которые можно запускать прямо во время работы, добавил он.

Один из приведенных примеров касался сканирования lint-staged, широко используемого JavaScript-пакета для tooling. По словам Kapoor, стандартный workflow «npm audit –omit=dev» не показал проблему в production-зависимости, которую CVE Lite CLI позже выявил с помощью анализа lockfile. «Честно говоря, я не думаю, что большинство разработчиков в деталях понимают эти слепые зоны, и это не критика разработчиков», — сказал он. «Граф зависимостей в современном JavaScript-проекте чрезвычайно шумный».

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

CVE Lite CLI не поддается ИИ

Проект также сознательно не превращается в более широкую AppSec-платформу, несмотря на растущее давление отрасли в пользу консолидации security-инструментов в экосистему с поддержкой ИИ.

«Я действительно считаю, что security tooling стал слишком тяжелым для повседневного workflow разработчика», — сказал Kapoor. «Это не значит, что такие платформы плохие. Это значит, что они часто лучше служат security-командам, чем отдельному разработчику, который пытается принять безопасное решение по зависимости во время обычной сессии кодинга».

Та же философия распространяется и на подход проекта к самому ИИ. Хотя CVE Lite CLI включает интеграции, помогающие ИИ-ассистентам для кода интерпретировать результаты сканирования, Kapoor сказал, что базовый анализ уязвимостей намеренно остается детерминированным.

«Я не считаю, что ИИ должен решать, существует ли CVE», — сказал он. «Эта часть должна быть скучной, повторяемой и поддающейся аудиту».

Вместо этого проект использует ИИ как, по словам основателя, «слой объяснения и рабочего процесса» вокруг результатов сканирования, а не как сам сканер. «CVE Lite CLI включает навыки для ИИ-ассистентов, которые учат инструменты вроде Claude Code, Codex CLI, Gemini CLI, Cursor и GitHub Copilot запускать CVE Lite CLI, читать его структурированный вывод и помогать разработчику понимать или приоритизировать план исправления», — пояснил Kapoor.

Осторожность в отношении расширения

Kapoor сказал, что получает положительные отзывы от компаний и разработчиков, использующих CVE Lite CLI в реальных workflow, и его спрашивают, сможет ли тот же подход поддержать экосистемы .NET или Python.

«Этот интерес обнадеживает, потому что показывает: local-first модель, ориентированная на исправление, находит отклик и за пределами исходного сценария для JavaScript и TypeScript», — сказал он. «Но я осторожно отношусь к слишком широкому расширению текущего инструмента».

Объяснение, которое он привел, простое: у каждой экосистемы, по его мнению, свое поведение package manager, формат lockfile, семантика графа зависимостей, источники advisory и паттерны remediation. «Если добавить все это напрямую в CVE Lite CLI, инструмент может стать тяжелее и менее понятным для разработчиков JavaScript и TypeScript, которым он изначально предназначался помочь». Теперь проект принят в экосистему OWASP foundation как официальный проект OWASP и доступен разработчикам бесплатно на GitHub.

Материал впервые был опубликован на CSO.

Материал — перевод статьи с английского.

Оригинал: As AI speeds coding, CVE Lite CLI keeps security deliberately AI-free