Мы выпустили NEOMSA APIM 4.6.0. Основной фокус этого релиза — повышение безопасности состава поставки платформы.
В рамках процессов безопасной разработки (SSDLC) мы сформировали SBOM, проверили компоненты и их зависимости на известные уязвимости (SCA), сопоставили результаты с БДУ ФСТЭК России и обновили проблемные библиотеки. По итогам повторной проверки количество зарегистрированных находок сократилось с 57 до 7. Уязвимостей уровней Critical и High в финальной сборке не осталось.
В статье рассказываем, как устроена проверка NEOMSA APIM перед выпуском и какой критерий безопасности мы используем для принятия решения о готовности релиза.
Коротко о NEOMSA APIM
NEOMSA APIM (НЕОМСА APIM) — отечественная On-Premise платформа управления API и шлюз API (API Gateway).
Она включает:
● API Gateway;
● Публикацию, версионирование и управление жизненным циклом API;
● Аутентификацию и авторизацию;
● Управление политиками и лимитами (Rate Limiting);
● Аналитику трафика;
● Портал разработчика (Developer Portal).
Платформа поддерживает OAuth 2.0, JWT и mTLS, работает с контрактами OpenAPI и разворачивается в инфраструктуре заказчика, включая Kubernetes. NEOMSA APIM функционирует автономно и не требует передачи технологических данных и API-трафика в облако производителя.
Продукт входит в реестр российского ПО и применяется при импортозамещении зарубежных API Management-платформ (WSO2 API Manager, Google Apigee, Kong Enterprise, MuleSoft), в том числе на объектах критической информационной инфраструктуры (КИИ).
Почему обновление зависимостей — это часть безопасности продукта
Современная программная платформа состоит не только из собственного кода. В её состав входят сторонние библиотеки, фреймворки и транзитивные зависимости, отвечающие за работу с HTTP, XML, сериализацией, криптографией, логированием и другими функциями.
По мере эксплуатации в таких компонентах обнаруживаются новые уязвимости. Среди типовых примеров:
● Небезопасная десериализация;
● Обработка XML с возможностью XXE-атак;
● Уязвимости веб-компонентов;
● Ошибки в устаревших библиотеках логирования;
● Обход отдельных механизмов проверки и авторизации.
Поэтому обновление и замена уязвимых библиотек для нас — не отдельная техническая задача, а часть DevSecOps-конвейера и обязательный этап подготовки релиза.
Как мы проверяем релизную сборку
Проверка встроена в процесс подготовки релиза и выполняется по единому маршруту — от формирования состава поставки до итогового отчёта по безопасности.
1. Формируем релизную сборку. Сначала собираем версию продукта с зафиксированным набором компонентов и зависимостей. Проверяется именно тот состав, который планируется передавать заказчикам.
2. Создаём SBOM. Для сборки формируется SBOM в формате CycloneDX. Это машиночитаемая опись компонентов продукта с указанием их версий и связей между зависимостями. SBOM позволяет определить состав поставки и воспроизводимо проверять её при каждом следующем выпуске.
3. Проверяем компоненты с помощью Grype. Сканер Grype сопоставляет компоненты и версии из SBOM с базами известных уязвимостей (CVE, GHSA). На этом этапе формируется перечень находок, связанных с конкретными библиотеками.
4. Сопоставляем результаты с БДУ ФСТЭК. Отдельный этап — сопоставление найденных уязвимостей с актуальной выгрузкой Банка данных угроз безопасности информации ФСТЭК России. Для каждой находки мы определяем уровень критичности, уязвимый компонент, наличие исправленной версии, показатель риска и статус обработки.
5. Применяем критерий готовности релиза. Главный блокирующий критерий (Security Gate) для NEOMSA APIM 4.6.0: в финальной сборке не должно оставаться уязвимостей уровней Critical и High, зарегистрированных в БДУ ФСТЭК. Пока такие находки присутствуют, сборка не считается готовой к выпуску. Команда обновляет или заменяет проблемные зависимости, после чего повторно формирует SBOM и запускает проверку.
Уязвимости уровней Medium и Low также фиксируются в отчёте. Для них учитываются затронутый компонент, наличие безопасной версии, риск эксплуатации и возможность устранения в последующих циклах обновления. Однако по принятой методике они не являются автоматическим блокирующим критерием релиза.
Как мы считаем уязвимости
В таблице ниже приведено количество находок, которые были сопоставлены с записями БДУ ФСТЭК, с распределением по уровню критичности. Сравниваются исходная и финальная сборки NEOMSA APIM 4.6.0. Результат отражает состояние используемой выгрузки БДУ ФСТЭК на дату формирования релизного отчёта.
По результатам обновления зависимостей:
● Устранены все 10 находок уровня Critical
● Устранены все 24 находки уровня High
● Количество Medium-находок сократилось с 19 до 7
● Устранены все 4 находки уровня Low
Таким образом, основной критерий безопасности релиза выполнен: в составе финальной сборки NEOMSA APIM 4.6.0 отсутствуют Critical- и High-уязвимости, зарегистрированные в БДУ ФСТЭК на дату проверки.
Что происходит с оставшимися Medium-находками
Оставшиеся семь находок имеют уровень Medium и не являются блокирующими для выпуска по принятому критерию.
Они не исключаются из процесса: информация о них сохраняется в релизном отчёте вместе с данными о затронутом компоненте, доступной безопасной версии и показателе риска. Находки продолжают отслеживаться и учитываются при подготовке следующих обновлений зависимостей.
Важно учитывать, что БДУ ФСТЭК и другие базы уязвимостей регулярно обновляются. Поэтому результаты проверки относятся к конкретному составу релизной сборки и состоянию баз на дату формирования отчёта. Проверка выполняется повторно при подготовке каждого следующего релиза.
Что это даёт заказчикам
Для заказчика результат релиза — это не просто обновлённые версии библиотек, а контролируемый и проверяемый состав поставки:
● Компоненты и их версии зафиксированы в SBOM
● Известные уязвимости сопоставлены с БДУ ФСТЭК
● Critical- и High-находки полностью устранены
● Результаты проверки собраны в едином отчёте по безопасности
● Выпуск продукта проходит через формализованный security gate
Такой подход повышает прозрачность состава платформы и упрощает взаимодействие с подразделениями информационной безопасности при внедрении и обновлении NEOMSA APIM.
Документация, демонстрация и дополнительная информация о продукте доступны на сайте neomsa.ru.
Вопросы по релизу NEOMSA APIM 4.6.0 и процессу проверки безопасности можно оставить в комментариях — ответим сами.
ссылка на оригинал статьи https://habr.com/ru/articles/1067784/