Solar appScreener 3.1 и рекордное число языков программирования

Solar appScreener 3.1 и рекордное число языков программирования

Solar appScreener 3.1 и рекордное число языков программирования

Компания Ростелеком-Solar выпустила новую версию анализатора защищенности приложений Solar appScreener 3.1. Теперь система поддерживает 26 языков программирования – больше, чем любое конкурирующее решение.

Среди новых языков, взятых на вооружение в этой версии, – TypeScript и VBScript, что существенно расширяет охват сегмента веб-приложений, доступных для анализа с помощью Solar appScreener. Кроме того, в анализаторе реализована поддержка Apeх – языка самой популярной в мире CRM-системы Salesforce. Это позволит компании Ростелеком-Solar увеличить продажи на зарубежных рынках.

Даниил Чернов, руководитель направления Solar appScreener:

«В развитии своего продукта мы делаем ставку на две принципиально важные составляющие – совершенствование функциональности анализатора и повышение удобства работы с системой. От версии к версии можно проследить, как Solar appScreener планомерно укрепляет технологическое лидерство, во многом не только не уступая, но и превосходя самые передовые зарубежные разработки этого класса. Версия 3.1, благодаря поддержке ряда новых языков, позволит нашим заказчикам расширить спектр защищаемых приложений. С каждой новой версией проверка ПО на уязвимости и НДВ становится все проще и эффективнее».

В Solar appScreener 3.1 появился ряд новых возможностей для более тонкой настройки под нужды заказчика. В частности, теперь можно отслеживать изменения в участках кода, содержащих уязвимости или недекларированные возможности, сравнивая результаты сканирований за любой промежуток времени (ранее сравнение было доступно лишь для двух последних сканирований). Это позволяет проводить полный ретроспективный анализ с пониманием, когда были обнаружены уязвимости и какие действия предпринимались в их отношении. Возможность указать прямую ссылку на участок кода значительно упрощает и ускоряет взаимодействие ИБ-специалиста с командой разработки, способствуя оперативному устранению уязвимостей.

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

В Solar appScreener 3.1 продолжена доработка внешнего вида и эргономики пользовательского интерфейса. Кроме того, новая версия легче встраивается в жизненный цикл разработки ПО благодаря улучшению функциональности плагина для интеграции с Jenkins и расширенным возможностям для интеграции с Jira. Также разработчики системы значительно дополнили базу правил поиска уязвимостей и доработали алгоритмы анализа для более эффективного выявления уязвимостей и дальнейшего снижения количества ложных срабатываний.

Почему не стоит входить с помощью Google в важные аккаунты

Кнопка «Войти с аккаунтом Google» долго казалась удобным решением, ибо не нужно придумывать новый пароль, заполнять профиль и помнить ещё одни учётные данные. Но у такого удобства есть обратная сторона. Главный риск — зависимость от одного аккаунта.

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

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

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

В таком случае злоумышленник может получить доступ к аккаунту даже при включённой двухфакторной аутентификации. Чем чаще пользователь входит в разные сервисы через всплывающие окна Google, тем выше риск попасть на такую подделку.

Ещё один минус — недостаток конфиденциальности. Когда разные сервисы привязаны к одному Google-аккаунту, компания получает более цельную картину цифровой активности пользователя: какие приложения он использует, как часто и в каких сценариях. Даже если данные обрабатываются в агрегированном виде, это всё равно расширяет цифровой след.

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

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

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