Криптографические риски в SBOM: как найти уязвимости до атаки

Программный продукт редко создают полностью с нуля. В нём работают внешние библиотеки, SDK, фреймворки и транзитивные зависимости. Криптографический пакет может попасть в продукт через несколько уровней зависимостей.

SBOM (Software Bill of Materials) показывает состав такого продукта. Это машиночитаемый перечень компонентов, их версий и связей. Он ускоряет поиск известных проблем, но не заменяет полноценную проверку защиты.

Криптографический риск возникает не только из-за записи CVE. Опасность также создают слабый алгоритм, короткий ключ, ошибка проверки сертификата или неправильная работа с секретом. Поэтому проверка должна начинаться со SBOM, но не заканчиваться на нём.

🔍 Что именно показывает SBOM

SBOM связывает продукт с конкретными компонентами. В записи обычно есть название, версия и поставщик. Также встречаются зависимости, хеш-суммы и сведения о лицензиях.

Для идентификации применяют PURL и CPE. PURL описывает пакет и его источник в едином виде. CPE помогает сопоставлять продукт с записями об уязвимостях. Чем точнее идентификатор, тем меньше ошибок при поиске.

В SBOM видна и структура зависимостей. Это важно для криптографии. Приложение может напрямую не использовать библиотеку шифрования, но получать её через другой пакет. Такой компонент называют транзитивной зависимостью.

Форматы SPDX и CycloneDX делают перечень удобным для автоматической обработки. Система анализа состава ПО загружает файл и сравнивает его содержимое с базами уязвимостей. Затем специалист проверяет результат вручную.

• Название и версия показывают, какой компонент установлен.
• PURL и CPE помогают найти нужную запись в базе.
• Граф зависимостей показывает скрытые криптографические пакеты.
• Хеш-сумма помогает сравнить заявленный и фактический файл.

Что сделать сейчас: сформируйте SBOM для каждого собираемого продукта. Сохраните исходный файл рядом с артефактом сборки. Проверьте наличие версий, PURL, CPE и транзитивных зависимостей.

🧩 Как связать компонент с уязвимостью

Сам SBOM не содержит полной оценки риска. Он даёт исходные данные для сопоставления. Система SCA (анализ состава ПО) использует версии компонентов и их идентификаторы.

Результат сопоставления может включать CVE. CVE — это единый идентификатор известной уязвимости. Но запись CVE ещё не доказывает, что проблема реально затрагивает ваш продукт.

Одна библиотека может присутствовать в SBOM, но не использовать опасную функцию. Уязвимость может требовать особой настройки. Её также может закрывать дополнительный защитный слой.

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

Для каждой найденной записи нужно установить точную версию. Затем проверьте, используется ли затронутая функция. После этого оцените доступность кода и условия эксплуатации.

Что сделать сейчас: запретите автоматическое закрытие задачи только по совпадению CVE. Добавьте ручную проверку фактического использования уязвимого компонента.

⚠️ Какие криптографические риски ищет SBOM

Первый риск связан с уязвимой версией криптографической библиотеки. В продукте может работать OpenSSL или другой пакет шифрования. Ошибка в таком компоненте влияет сразу на множество функций.

SBOM помогает быстро найти продукты с нужной версией. Он показывает, где компонент установлен напрямую. Граф зависимостей помогает найти его и в составе другого пакета.

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

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

• Уязвимая версия библиотеки шифрования.
• Слабая хеш-функция или устаревший протокол.
• Короткие ключи и предсказуемые случайные значения.
• Ошибки проверки сертификатов.
• Неверное управление ключами и секретами.
• Побочные каналы, которые раскрывают сведения во время работы.

Отдельно проверяйте функции проверки сертификатов. Библиотека может быть обновлена, но приложение всё равно принимать неподходящий сертификат. Такая ошибка находится на уровне применения, а не состава пакета.

Проверяйте и управление ключами. SBOM не показывает, где продукт хранит секрет. Он также не показывает, как долго живёт ключ и кто получает к нему доступ.

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

🛠️ Как построить автоматический конвейер проверки

Проверка начинается на этапе сборки. Сначала система создаёт SBOM для исходного продукта. Затем она сохраняет список компонентов вместе с конкретным артефактом.

После генерации файл нужно нормализовать. Одинаковые компоненты могут иметь разные названия. PURL и CPE помогают привести записи к единому виду. Нормализация уменьшает число пропусков и ложных совпадений.

Следующий шаг — сопоставление с базами уязвимостей. Система ищет записи по компоненту и версии. Результат нужно разделить на прямые и транзитивные зависимости.

Затем запускается проверка конфигураций. Она ищет включённые протоколы, алгоритмы и режимы. Здесь же проверяют сертификаты, ключи и правила доступа к секретам.

1. Сформировать SBOM в SPDX или CycloneDX.
2. Проверить полноту версий и идентификаторов.
3. Нормализовать названия компонентов.
4. Сопоставить компоненты с базами CVE.
5. Проверить криптографические настройки отдельно.
6. Оценить влияние проблемы на конкретный продукт.
7. Исправить компонент, настройку или архитектурное решение.
8. Повторить сканирование и сохранить новый результат.

Конвейер должен запускаться после изменения зависимостей. Одного запуска перед выпуском недостаточно. Компонент может измениться при следующей сборке.

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

Что сделать сейчас: добавьте генерацию SBOM и проверку состава в CI/CD. Остановите выпуск при критичном риске, но оставьте ручное подтверждение для спорных случаев.

📊 Как расставить приоритеты после сканирования

Список найденных проблем редко показывает реальный порядок действий. Приоритет зависит от версии компонента. Он также зависит от того, доступен ли опасный код извне.

Проверяйте условия эксплуатации. Уязвимость в неиспользуемой функции отличается от проблемы в открытом сервисе. Важна и роль компонента в продукте.

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

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

• Подтвердите точную версию компонента.
• Проверьте, загружается ли опасная функция.
• Определите, доступен ли компонент через внешний интерфейс.
• Уточните, работает ли он с ключами или сертификатами.
• Проверьте, есть ли временная мера защиты.
• Назначьте срок исправления и повторной проверки.

Важна и доступность исходного кода. Она помогает подтвердить путь выполнения и понять реальное влияние. Но открытый код сам по себе не делает компонент безопасным.

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

Что сделать сейчас: добавьте в карточку риска четыре поля: версия, доступность, использование криптографии и влияние на ключи. Приоритизируйте задачи по этим данным.

🔒 Почему одного SBOM недостаточно

SBOM может быть неполным. Инструмент генерации иногда не видит динамически загружаемый модуль. Он также может пропустить зависимость, которая появляется только во время работы.

Файл может устареть после изменения сборки. Если команда обновила компонент, старый SBOM уже не описывает продукт. Такой перечень создаёт ложное чувство контроля.

Ошибки идентификации тоже влияют на результат. Разные имена могут указывать на один пакет. Один идентификатор может привести не к той версии.

SBOM не показывает происхождение артефакта. Он не доказывает, что пакет собрала доверенная система. Он также не защищает сам процесс CI/CD.

Отдельная проблема — рабочее состояние продукта. SBOM не сообщает, какие настройки включены во время запуска. Он не показывает, какой протокол выбирает соединение.

• Проверяйте полноту прямых и транзитивных зависимостей.
• Сверяйте перечень с фактическим содержимым артефакта.
• Обновляйте SBOM после каждой смены состава.
• Ищите динамические модули и загрузку во время работы.
• Защищайте SBOM от подмены и несанкционированного изменения.

Сам SBOM тоже становится ценным объектом. В нём видна внутренняя структура продукта. Злоумышленник может использовать эти сведения для выбора цели.

Поэтому доступ к файлам нужно ограничивать. Хеш-суммы помогают проверить целостность. Хранение рядом с артефактом упрощает контроль версии.

Что сделать сейчас: сравните последний SBOM с фактическим образом продукта. Отдельно проверьте динамические модули, секреты и доступ к файлу перечня.

🎯 Что показывает реальная атака на сторонний продукт

Недавняя атака на криптобиржу Bitget показывает риск внешней зависимости. Злоумышленники использовали 0-day-уязвимость в стороннем продукте информационной безопасности. Название продукта не раскрывается.

Через уязвимость атакующие получили доступ к внутренней системе управления. Затем они использовали учётные данные с высокими привилегиями. Поддельные команды на вывод средств выглядели для бэкенд-сервисов легитимными.

Атака началась 24 сентября в 18:31 UTC. Сначала злоумышленники провели две небольшие тестовые транзакции. Их суммы оказались ниже порога контроля рисков.

Примерно через полчаса начался основной вывод средств. Общий ущерб составил 387,5 млн долларов. Холодные кошельки не пострадали, а приватные ключи, по данным компании, не скомпрометированы.

После обнаружения атаки специалисты изолировали затронутые системы. Они отозвали и перевыпустили внутренние учётные данные. Уязвимые функции отключили.

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

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

Что сделать сейчас: составьте перечень сторонних защитных продуктов и их зависимостей. Проверьте их привилегии, функции управления и независимые подтверждения критичных операций.

🧪 Как проверять криптографию без ложного спокойствия

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

Затем сравните версии с базами уязвимостей. Совпадение нужно подтвердить по точному компоненту. Не переносите риск на продукт автоматически.

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

Проверьте путь сертификата. Приложение должно корректно подтверждать доверие. Ошибка в проверке может сохраняться после обновления библиотеки.

• Опишите каждую криптографическую функцию простыми словами.
• Укажите компонент, версию и транзитивный путь.
• Зафиксируйте алгоритм, режим и длину ключа.
• Проверьте источник случайных значений.
• Проверьте выпуск, хранение и отзыв ключей.
• Проверьте сертификаты и доверенные центры.
• Ограничьте доступ к журналам с криптографическими сведениями.
• Повторите проверку после изменения конфигурации.

Проверяйте и побочные каналы. Время операции, ошибки и другие внешние признаки иногда раскрывают секретные данные. SBOM не видит такие эффекты.

Для российских продуктов отдельно оценивайте применимые требования и профили защиты. Соответствие стандарту не доказывает отсутствие уязвимостей. Оно задаёт рамки проверки, но не заменяет тестирование.

Не считайте отсутствие CVE положительным заключением. Новая проблема может ещё не иметь идентификатора. Ошибка настройки обычно вообще не выглядит как уязвимость компонента.

Что сделать сейчас: оформите карту криптографии продукта. Обновляйте её вместе с SBOM и проверяйте после каждого изменения кода или конфигурации.

✅ Чек-лист для разработчика и специалиста по безопасности

Разработчик отвечает за точный состав сборки. Он должен фиксировать версии и зависимости. Это снижает риск неизвестного изменения компонента.

Специалист по безопасности проверяет не только список CVE. Он изучает путь использования библиотеки. Он также сравнивает настройки с назначением продукта.

1. Создайте SBOM в SPDX или CycloneDX.
2. Укажите версии всех прямых зависимостей.
3. Добавьте транзитивные зависимости.
4. Проверьте PURL и CPE для компонентов.
5. Найдите криптографические библиотеки.
6. Сопоставьте версии с базами CVE.
7. Проверьте алгоритмы, протоколы и длину ключей.
8. Проверьте генератор случайных чисел.
9. Проверьте сертификаты и управление ключами.
10. Ограничьте привилегии сторонних компонентов.
11. Защитите SBOM от подмены.
12. Повторите проверку после исправления.

Если система находит проблему в библиотеке, сначала подтвердите её влияние. Уточните версию и точку использования. Затем выберите обновление или временное ограничение.

Если CVE не найдена, не закрывайте проверку. Продолжайте анализировать настройки, ключи и протоколы. Именно там часто скрывается риск, который не описывает перечень компонентов.

Что сделать сейчас: проведите такую проверку для одной критичной сборки. Зафиксируйте пропуски и превратите их в правила для всех следующих выпусков.

🔮 Как превратить SBOM в постоянный контроль

SBOM приносит пользу только при регулярном обновлении. Разовая выгрузка быстро теряет ценность. Состав продукта меняется вместе с кодом и зависимостями.

Постоянный контроль связывает сборку, анализ состава и проверку настроек. Он показывает не только найденную проблему, но и момент её появления. Это ускоряет разбор изменений.

Нужно хранить историю SBOM. Сравнение двух файлов показывает новый компонент и новую версию. Такой подход помогает быстро оценить влияние обновления.

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

• Создавайте SBOM при каждой сборке.
• Сверяйте файл с фактическим артефактом.
• Проверяйте новые версии до выпуска.
• Отслеживайте криптографические настройки отдельно.
• Разделяйте привилегии компонентов.
• Добавляйте независимое подтверждение критичных операций.
• Храните результаты и доказательства исправления.

Такой процесс не обещает абсолютную защиту. Он сокращает время между появлением риска и его обнаружением. Это особенно важно для цепочки поставок.

Главный вывод прост. SBOM делает состав ПО прозрачнее. Но криптографическую безопасность создают вместе перечень, анализ версий, проверка настроек и контроль эксплуатации.

Что сделать сейчас: назначьте владельца SBOM и владельца криптографической карты. Свяжите их работу с процессом сборки и обязательной повторной проверкой.

📚 Читайте также

• Криптография в логах: как доказать целостность событий после взлома
• Как определить продукты, затронутые CVE: SBOM и ручная проверка
• Реверс-инжиниринг умных устройств: что скрывает прошивка
• Фальсификация корпоративной почты: какие журналы сохранять для суда
• Гибридная криптография: безопасный переход к постквантовой защите

📖 Термины

CVE (Common Vulnerabilities and Exposures) · SBOM · SCA (Software Composition Analysis) · Криптография · Шифрование

🔗 Источники

• Bitget связывает недавнюю атаку с уязвимостью в стороннем защитном продукте(2026-09-30 ✓)
• Как сканер уязвимостей создает иллюзию защиты(2026-09-30 ✓)
• Почему SBOM не гарантирует безопасность цепочки поставок ПО(2026-09-28 ✓)