Композиционный анализ программного обеспечения

Что должен обеспечить КАПО

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

Почему это важно

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

КАПО — это не разовая проверка

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

Подготовка внедрения

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

Внедрение

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

Регулярное применение

• автоматизировать построение ППК и анализ;
• перепроверять компоненты на протяжении всего жизненного цикла;
• реагировать на нарушения политики;
• сопровождать каждую версию ПО собственным ППК.

• критерии выбора нового стороннего ПО;
• правила эксплуатации контролируемого репозитория;
• критерии отслеживания уязвимостей и лицензий;
• сроки реакции на нарушения и порядок компенсирующих мер;
• регулярность перепроверки используемых компонентов.

Запрет на обход цепочки поставки

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

Сторонний компонент без проверки — это не удобство, а неуправляемый риск для всего продукта.

• выявление заимствований и идентификация компонентов;
• построение перечня программных компонентов;
• обогащение ППК сведениями об уязвимостях и особенностях;
• актуализация и оповещение о результатах анализа.

• обязателен анализ манифестов систем управления компонентами;
• рекомендуется анализ сборочной среды и среды функционирования;
• рекомендуется идентификация по хэш-кодам;
• возможен поиск частичных включений кода и транзитивный анализ зависимостей.

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

• поддержка электронной почты и других каналов оповещения;
• наличие API для встраивания в процессы разработки и CI/CD;
• загрузка и анализ уже готовых ППК;
• автоматическое построение ППК по доступным репозиториям разработки;
• получение сведений из БДУ, NVD, OSV, OSSIndex, GHSA и иных баз.

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

Проект стандарта ориентирует разработчика на машиночитаемый формат по спецификации CycloneDX в нотации JSON. Это позволяет использовать ППК не как статичную таблицу, а как рабочий артефакт процессов CI/CD, контроля поставки и анализа уязвимостей.

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

Как модель должна использоваться

• назначение модели;
• сценарии использования вне основной сферы применения;
• сценарии неправильного или вредоносного использования.

Это приложение особенно важно для современного ПО, где модели машинного обучения становятся частью поставляемого продукта и тоже должны быть учтены в ППК.