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

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

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

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

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

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

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

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

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

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

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

Подпишитесь на новости

«В общак»: подпись к банковскому переводу может закончиться проверкой

Комментарий к переводу — не лучшее место для импровизированного стендапа. Подписи вроде «взятка», «откат» или «в общак» могут вызвать вопросы у банка и привести к ограничениям, предупредила юрист Мери Валишвили.

Как сообщает РИА Новости, доцент РЭУ имени Плеханова объяснила: автоматизированные банковские системы учитывают текст, но не обязаны понимать намерение пошутить.

При этом единого публичного списка опасных слов нет. Банки самостоятельно настраивают алгоритмы и не раскрывают полные перечни маркеров подозрительных операций. Поэтому речь не об универсальном правиле.

Внимание могут привлечь и вполне бытовые комментарии: «за маникюр», «за ЖКУ», «по договору». Сами формулировки не запрещены, однако регулярность поступлений, одинаковые суммы и другие обстоятельства могут сформировать подозрительный для комплаенс-системы паттерн.

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

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

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