ГК Солар выпустила облачный инструмент для проверки Open Source

ГК Солар выпустила облачный инструмент для проверки Open Source

ГК Солар выпустила облачный инструмент для проверки Open Source

Группа компаний «Солар» представила облачный инструмент для анализа безопасности сторонних библиотек и компонентов с открытым исходным кодом. Решение разработано на базе платформы Solar appScreener и ориентировано на небольшие команды разработки — как внутри крупных компаний, так и в ИТ-стартапах — особенно тех, кто занимается заказной разработкой.

Причина появления продукта довольно понятна: рынок растёт. По данным Росстата, в 2024 году число российских ИТ-компаний увеличилось на 14%, а объёмы разработки — на 40% по сравнению с 2023 годом.

При этом всё больше команд встраивают в свои решения компоненты с открытым исходным кодом — по разным оценкам, такие элементы составляют до 80% кода современных приложений.

Проблема в том, что далеко не все эти библиотеки регулярно обновляются. Около 79% сторонних компонентов — «заброшенные», уязвимости в них не устраняются, а новые баги всё равно появляются. При этом число уязвимостей в Open Source за 2024 год выросло почти вдвое, тогда как самих библиотек стало больше только на 25%. То есть потенциальные угрозы растут быстрее, чем сам код.

Особенно остро эта проблема стоит для компаний, использующих внешних подрядчиков. В разработке критичных систем (например, тех, где обрабатываются персональные данные или финансы) часто участвуют несколько команд. Контролировать безопасность на всех этапах — задача нетривиальная.

Новое облачное решение от «Солара» как раз и рассчитано на такие ситуации. Оно включает модуль OSA (анализ состава ПО), который выполняет SCA-проверку: ищет уязвимости в сторонних библиотеках, отслеживает зависимости и потенциальные риски. Кроме того, есть инструмент для оценки лицензионных ограничений и анализ SCS — он помогает выявить риски даже в тех компонентах, где уязвимости пока официально не найдены. В расчёт берутся такие параметры, как частота обновлений, активность авторов и даже их публичные высказывания, которые могут намекать на возможные закладки или «чёрные ходы».

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

Разработчики утверждают, что облачная версия соответствует требованиям российских регуляторов — от ГОСТов по кибербезопасности до приказа ФСТЭК №239 — и включена в Реестр отечественного ПО.

Хакеры спрятали команды для WordPress-зловреда в комментариях Steam

Исследователи GoDaddy обнаружили необычную вредоносную кампанию, жертвами которой стали почти 2000 сайтов на WordPress. Вместо традиционной инфраструктуры управления злоумышленники использовали комментарии в профилях Steam Community.

Схема выглядит настолько странно, что сначала напоминает шутку. Однако всё вполне серьёзно.

После заражения WordPress-сайта вредоносный код обращался к определённым профилям Steam и считывал комментарии пользователей. На первый взгляд они выглядели как обычный текст или даже ASCII-арт. Но внутри были спрятаны невидимые Unicode-символы.

 

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

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

После расшифровки сайт получал адрес внешнего сервера и загружал оттуда JavaScript под видом обычных библиотек. Для маскировки использовались названия вроде asahi-jquery-min-bundle или lodash.core.min.js, чтобы не вызывать подозрений у администраторов.

 

Финальной стадией атаки становилась установка бэкдора. Он позволял злоумышленникам удалённо выполнять PHP-код через специально сформированные POST-запросы и фактически получать контроль над сайтом.

По данным GoDaddy, кампания действует как минимум с июля 2025 года. Всего специалисты обнаружили признаки заражения примерно на 1980 WordPress-ресурсах.

Как именно происходило первоначальное заражение, пока неизвестно. Среди возможных вариантов называются украденные учётные данные администраторов, компрометация доступа по FTP / SFTP, уязвимости в темах и плагинах WordPress или атаки через цепочки поставок.

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

RSS: Новости на портале Anti-Malware.ru