Новая версия Solar appScreener позволит снизить затраты на DevSecOps на 15%

Новая версия Solar appScreener позволит снизить затраты на DevSecOps на 15%

Новая версия Solar appScreener позволит снизить затраты на DevSecOps на 15%

Группа компаний «Солар» представила обновленную версию платформы для анализа кода Solar appScreener. Улучшенные алгоритмы позволяют повысить эффективность процессов DevSecOps и оптимизировать использование ресурсов.

По данным опроса среди пользователей платформы, внедрение решения способствует снижению совокупной стоимости владения (ТСО) безопасной разработки до 15%.

Использование инструментов анализа кода в процессе разработки помогает сократить риски, связанные с уязвимостями мобильных и веб-приложений. Согласно данным Центра исследования киберугроз Solar 4RAYS, за первое полугодие 2024 года 43% хакерских атак на корпоративную инфраструктуру были связаны с уязвимостями в приложениях.

Среди наиболее распространенных проблем — недостатки контроля доступа (75% для веб-приложений и 60% для мобильных), раскрытие отладочной и конфигурационной информации (73% и 60% соответственно), межсайтовый скриптинг (XSS), а также утечка данных из исходного кода мобильных приложений (33%).

«Рост стоимости владения программным обеспечением в корпоративном сегменте оценивается в 10–20% ежегодно. На это влияют сложности с закупкой оборудования, инвестиции в импортозамещение и кадровый дефицит. В обновленной версии Solar appScreener мы сосредоточились на оптимизации использования ресурсов без ущерба для качества и безопасности кода. Это позволяет разработчикам встроить платформу в цикл разработки, снизить риски при работе с приложениями и обеспечить защиту пользовательских данных», — отмечает Владимир Высоцкий, руководитель направления Solar appScreener.

Обновленная версия предлагает новые механизмы управления агентами сканирования, что позволяет ИТ-командам параллельно анализировать несколько проектов с учетом их приоритетов.

Оптимизированы модули анализа, включая использование вычислительных ресурсов, что особенно актуально для крупных проектов с объемом кода в миллионы строк. В ходе тестирования зафиксировано сокращение времени сканирования на 15–35%.

Также переработан дистрибутив системы, что упрощает установку и снижает требования к квалификации специалистов. В целях ускорения DevSecOps-процессов добавлена возможность регулирования глубины анализа кода — например, анализ только прямых зависимостей или отключение перекрестных библиотек в рамках SAST-анализа.

Кроме того, в новой версии усовершенствованы механизмы статического и динамического анализа кода. База правил SAST-модуля пополнилась 500 новыми сигнатурами поиска уязвимостей, а в модуле DAST расширены возможности аутентификации, включая поддержку протокола NTLM и интеграцию с расширенными API-спецификациями тестируемого ПО.

Зачем Яндекс Go создал отдельный язык для расчёта стоимости поездок

Цена поездки в Яндекс Go — это не расстояние, умноженное на минуты и километры. В расчёт вмешиваются геозоны, спрос, скидки, платные дороги, дополнительные остановки и требования вроде перевозки кота, велосипеда или лыж. Чтобы управлять этим хозяйством без бесконечных деплоев, разработчики вынесли алгоритм ценообразования из кода сервиса в собственный язык.

Как объяснили разработчики в статье на Хабре, прайсинг работает не только при заказе машины.

Он пересчитывает стоимость при смене маршрута или способа оплаты, завершении поездки, обращении в поддержку и проверке данных аналитиками. Цена при этом может быть фиксированной, интервальной или считаться по таксометру.

 

Сначала сервисы параллельно собирают параметры поездки: тарифную категорию, геозоны, скидки, повышенный спрос и дополнительные услуги. Зависимости между источниками выстраиваются в граф, а запросы выполняются асинхронно на базе userver. Если некритичный источник не ответил, весь расчёт не падает.

 

Сам алгоритм раньше можно было бы держать в C++, но он меняется в среднем дважды в неделю. Выкатка сервиса на 50 подов занимает около 40 минут, а лес динамических конфигов быстро превратил бы код в музей условных операторов.

Поэтому Яндекс разработал собственный DSL. В нём есть условия, функции, неизменяемые значения и fold вместо циклов. Правила собираются в последовательную цепочку: каждое преобразование получает текущую цену и параметры, а возвращает новый результат с метаданными. Грамматику описали через ANTLR 4, а верификатор Z3 проверяет, что программа не выдаст некорректную цену.

 

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

 

В итоге прайсинг превратился в отдельную платформу, которой уже пользуются Такси, Доставка и сервис зарядки электромобилей.

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