Образец регламента композиционного анализа программного обеспечения
Большая часть кода в современной программе — чужая: библиотеки, каркасы, образы контейнеров. Стандарт ГОСТ Р 56939-2024 требует регламент композиционного анализа, перечень зависимостей, его контроль на известные уязвимости, анализ компонентов поверхности атаки непосредственно перед сборкой и корректирующие действия по результатам (пункт 5.16). Наличие средств композиционного анализа проверяет орган по сертификации (пункт 19 Порядка, утверждённого приказом ФСТЭК России от 01.12.2023 № 240).
Как получить документ
Два пути: сформировать в кабинете или купить готовый образец за 600 ₽.
Регламент композиционного анализа программного обеспечения по вашим данным
Документ собирается по самооценке процессов и перечню инструментов из мастера режима «Разработка безопасного ПО» — их ведут в кабинете. Анкета образца этого не посчитает, поэтому под вашу организацию он собирается в кабинете.
Что даёт кабинет
- ✓Документы с реквизитами и сведениями вашей организации, готовые к подписи
- ✓Сведения подставляются из того, что вы уже ввели, а пробелы видны до скачивания
- ✓Образцы заполнения во всех вариантах — для просмотра на платном тарифе, с файлами — при покупке документа
Раздел входит в тариф «Полный».
Что должно быть в документе
- порядок формирования перечня зависимостей;
- инструменты композиционного анализа и источники сведений об уязвимостях;
- когда проводится анализ — при сборке, перед выпуском, периодически;
- порядок оценки применимости уязвимости;
- сроки и способы устранения по критичности: обновление, исправление, обращение к поставщику;
- порядок контроля актуальности перечня.
Как оформить
- Сформируйте перечень зависимостей инструментом прямо из сборки.
- Подключите анализ к каждой сборке выпуска.
- Установите сроки устранения по уровням критичности.
- Опишите, как обосновывается неприменимость уязвимости.
- Утвердите регламент.
Сформируйте этот документ под свой профиль — с подстановкой реквизитов и без ошибок.
Сформировать в ГрамотаИБЧастые вопросы
Что делать, если уязвимость в зависимости неприменима?
Записать обоснование в отчёт: почему уязвимый код не вызывается или условия эксплуатации не выполняются. Анализ применимости и реализуемости уязвимости — часть результатов устранения уязвимостей в зависимостях (пункт 5.16.3.5 ГОСТ Р 56939-2024).
Можно ли формировать перечень зависимостей вручную?
Стандарт способ не устанавливает, но вручную перечень быстро устаревает. Инструменты формирования перечня компонентов из сборки снимают эту проблему и сразу дают данные для анализа уязвимостей.
Документы того же комплекта
Входит в полный комплект
- Полный комплект документов по безопасной разработке программного обеспечения — 45 документов с образцами за одну организацию, 8 900 ₽
Все образцы раздела: Безопасная разработка ПО (ГОСТ Р 56939-2024).
Нормативная основа: ГОСТ Р 56939-2024 (разработка безопасного ПО). Подробный разбор — в статье «Проверки кода по ГОСТ Р 56939-2024: статический и динамический анализ, фаззинг, тестирование».
Материал носит справочный характер и не заменяет юридическую оценку под конкретную ситуацию.