🆙 Функции AppSec.Track, о которых вы могли не знать

Сегодня поговорим о главных фичах платформы AppSec.Track.

▶️ OSA Firewall (доступен с версии 4.2.0)
Это внешний прокси-шлюз для OSA, который перехватывает загрузку пакетов и проверяет их через AppSec.Track. Поддерживает Java, npm, PyPI и NuGet и позволяет блокировать небезопасные пакеты до попадания в проект.

Подробнее —>

▶️ MCP — проверка AI-кода на уязвимости (доступен с версии 4.0.0)

AppSec.Track стал первым российским SCA-анализатором для прямой проверки кода AI. MCP (Model Context Protocol) выявляет небезопасные или устаревшие пакеты до их внедрения в проект. Что входит:

- Автоматизированная проверка зависимостей
- Интеграция с AI-ассистентами
- Журнал запросов для контроля и аудита

Подробнее —>

▶️ Новые языки и форматы

- Objective-C, Swift, Perl, R, DART, Rust, Conda, Alpine, C/C++;
- Поддержка Hugging Face и сканирование AI/ML-компонентов;
- Поддержка Harbor;
- Сканирование Docker-образов по слоям.

🗓 Планы на ближайшее будущее

- Переход с AST ID → Публичный идентификатор.
- Кастомные метки окружений.
- Оптимизация и ускорение работы.
- Гибкие политики для удобства настроек.
- Отложенная блокировка компонентов.

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

AppSec.Track строится вокруг другой идеи — безопасность должна помогать принимать решения, а не создавать шум.

Мы фокусируемся на контроле цепочки поставок ПО: собираем данные, обогащаем их контекстом и превращаем в конкретные приоритеты для команды.
Это позволяет перейти от реакции на уязвимости
к управлению риском.

В новом релизе — развитие этой модели:
мы усилили возможности продукта как платформы, которая не просто находит проблемы, а помогает системно с ними работать.

— поделился Михаил Макаров, руководитель продукта AppSec.Track.

Следите за обновлениями! 😉

🔠 Рассылка | MAX

#AppSecTrack

⚠️ Атака на пакет Axios в реестре npm затронула системы macOS, Windows и Linux

Популярная JavaScript-библиотека Axios подверглась атаке на цепочку поставок: злоумышленник получил доступ к учетной записи npm одного из мейнтейнеров и опубликовал две скомпрометированные версии пакета — axios@1.14.1 и axios@0.30.4.

Что произошло
В зараженные версии Axios была добавлена скрытая зависимость plain-crypto-js@4.2.1, содержащая вредоносный код, который выполнялся через postinstall-скрипт. Этот скрипт устанавливал соединение с управляющим сервером, загружал полезную нагрузку, адаптированную под конкретную ОС, и затем пытался удалить следы своей активности.

Скомпрометированные версии затронули обе ветки Axios и были нацелены на macOS, Windows и Linux. Вредоносная активность маскировалась под системные процессы. Публикация пакетов происходила напрямую через npm, без изменений в исходном репозитории GitHub и без прохождения стандартных CI/CD-процессов.

Хронология:
— Установка зараженных версий через npm, Yarn или Bun.
— Выполнение postinstall-скрипта при установке пакета.
— Запуск дроппера, устанавливающего соединение с C2-сервером sfrclak.com (142.11.206.73).
— Загрузка и выполнение вредоносной нагрузки (RAT), обеспечивающей удаленное управление системой, сбор данных и загрузку дополнительного кода.
— Попытка удаления следов активности и модификация package.json для усложнения обнаружения.

🛡 Как мы отбили атаку у клиентов

В инциденте с компрометацией Axios ключевую роль сыграл не только факт появления вредоносных версий, но и скорость их попадания в зависимости проектов. Именно здесь сработали политики платформы AppSec.Track.

В продукте реализована политика по дате (time-based quality gate), которая позволяет ограничивать использование новых версий компонентов до момента их «выдержки» во времени. Это означает, что зависимости, опубликованные недавно, автоматически считаются недоверенными и не допускаются в сборку до прохождения заданного временного окна.

В случае с атакой на Axios скомпрометированные версии были опубликованы в npm и начали распространяться через стандартные механизмы установки. Однако благодаря политике по дате такие версии блокируются на этапе подключения зависимостей — ещё до того, как они попадают в среду разработки или CI/CD.

✔️ Таким образом, даже без наличия сигнатур, CVE или внешних индикаторов компрометации, AppSec.Track позволяет проактивно снижать риск supply chain атак. Это пример того, как простая, но правильно реализованная политика может эффективно защищать от zero-day угроз в экосистеме зависимостей.

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

— прокомментировал Михаил Макаров, руководитель продукта AppSec.Track.

➡️ Контролируйте безопасность стороннего кода и защищайте цепочку поставок с AppSec.Track.

🔠 Рассылка | MAX

#Экспертиза_AppSec #AppSecTrack

🔄 AppSec Update: итоги квартала

Рассказываем про главные обновления продуктов AppSec Solutions: ускорение работы, новые фичи и улучшение интеграций.

▶️ AppSec.Hub 2025.4.2 — 2026.1.2

• Новые интеграции с Яга и AppSec.Wave, улучшение других интеграций.

• Автоматическое закрытие и переоткрытие дефектов, новые статусы False Positive и Accepted Risk.

• Расширенная фильтрация уязвимостей по сканам, импортам и веткам, управление командами.

• Оптимизация фронтенда, доработки Hub CLI и улучшения UX.

Подробнее —>

▶️ AppSec.Track 4.1.0 — 4.2.0

• Новый модуль OSA Firewall.

• Полноценный триаж.

• История сканирования всех приложений.

• Поддержка Bitbucket.

• Интерактивный граф зависимостей.

• Шаблоны отчетов.

Подробнее —>

▶️ AppSec.Wave 26.1.1 — 26.1.3

• Расширенная статусная модель сканирования.

• Групповая обработка уязвимостей стала проще.

• Оптимизация агентов и ускорение формирования отчетов.

• Интеграционное API для внешних сервисов.

• Кастомные отчеты, история изменений и отображение языков в срабатываниях.

Подробнее —>

▶️ AppSec.Code 26.1.1

• Обновленное ядро 18.7.

• Повышена производительность и стабильность (Docker/Kubernetes).

• Новые логи, статусы пайплайнов, доработанные виджеты и уведомления.

• Расширенные права доступа и контроль критичных операций.

Подробнее —>

Обновляйтесь и пробуйте новые возможности!

🔠 Рассылка | MAX

#AppSec_updates

🛡 Как защититься от supply chain-атак

В конце марта была зафиксирована одна из наиболее опасных атак на цепочку поставок за последнее время (CVE-2026-33634). Злоумышленники смогли скомпрометировать не просто библиотеки, а доверенные инструменты безопасности и CI/CD — включая Trivy, Checkmarx и LiteLLM.

Атака длилась всего несколько часов, но этого оказалось достаточно: вредоносные версии успели распространиться через GitHub Actions, Docker-образы и PyPI. В результате тысячи CI/CD-пайплайнов могли запускать зараженный код, приводя к утечке секретов, компрометации облачной инфраструктуры и закреплению в Kubernetes-кластерах.

С точки зрения защиты, подобные атаки хорошо показывают, почему классический SCA уже недостаточен: проверять только библиотеки — неэффективно, когда атакуются инструменты разработки и CI/CD-компоненты.

В этом контексте подход, реализованный в AppSec.Track, позволяет закрывать сразу несколько ключевых векторов, использованных в этой атаке.

— отмечает Михаил Макаров, руководитель продукта AppSec.Track.

Советы эксперта, на что делать упор в защите:

▶️ Контроль по дате и происхождению артефактов. В подобных инцидентах вредоносные версии появляются внезапно и «живут» короткое время. Политики безопасности (quality gates) по дате публикации позволяют автоматически блокировать такие обновления до их верификации. Это фактически разрывает начальную стадию атаки — доставку вредоносного компонента в контур разработки или в пайплайн.

▶️ Анализ не только продуктовых зависимостей, но и инструментов сборки. AppSec.Track рассматривает их как полноценную часть поверхности атаки (включая CLI-утилиты, GitHub Actions, контейнерные образы), что позволяет обнаруживать риск даже тогда, когда компрометирован не код приложения, а инфраструктурный компонент.

▶️ Работа с актуальной информацией по угрозам. Важным направлением развития является учет сигналов о реально эксплуатируемых уязвимостях и активных атаках, а не только формальных метрик вроде CVSS. Это позволяет смещать фокус приоритизации на те компоненты, которые представляют практический риск «здесь и сейчас».

Такой подход особенно критичен в сценариях целевых кампаний с горизонтальным перемещением (lateral movement), где скорость реакции и правильная приоритизация напрямую влияют на масштаб инцидента.

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

➡️ Контролируйте безопасность стороннего кода и защищайте цепочку поставок с AppSec.Track.

🔠 Рассылка | MAX

#Экспертиза_AppSec #AppSecTrack

🔗 Как выбрать SAST-инструмент и не пожалеть

Статический анализ давно превратился в обычный инструмент для безопасной разработки, как линтер или CI. Но ожидания от него изменились: нужен не просто сканер уязвимостей, а решение, которое вписывается в процессы и реально снижает риски.

На что стоит смотреть при выборе:

▶️ Скорость и готовность из коробки. Развернули, подключили проект и через несколько минут получили первый осмысленный отчёт. Анализ на каждый merge request, без боли для CI.

▶️ Качество детектирования. Тысячи находок, которые нужно разбирать вручную, убивают ценность инструмента. Важны покрытие реальных дефектов, минимум ложных срабатываний и фокус на тех местах, где уязвимость действительно эксплуатируема.

▶️ Поддержка языков и стеков. Реальные проекты живут на зоопарке технологий. Хороший SAST должен одинаково хорошо работать с монолитами, микросервисами, фронтендом и бэкендом и поддерживать основные языки программирования.

▶️ Интеграция с процессами. SAST, который живет сам по себе, быстро превращается в мёртвый инструмент. Инструмент должен запускаться в пайплайне, давать фидбек прямо в IDE и легко отдавать результаты в нужном формате.

▶️ Управление правилами и перенос экспертизы. Важно, чтобы решение позволяло адаптировать правила под свои нужды и переносить накопленную экспертизу из других сканеров.

Именно на этих принципах мы строили SAST-сканер AppSec.Wave: быстрый старт (~20 минут), высокая скорость анализа, 14 000+ правил и интеграция с привычными инструментами разработки.

Подробнее о критериях выбора инструмента и нашем подходе читайте в статье. 🖥

🔠 Рассылка | MAX

#Экспертиза_AppSec #AppSecWave #SAST