Регламент безопасной разработки отвечает на вопрос «как мы работаем». Проверки кода отвечают на другой вопрос: «как мы находим опасные ошибки и следим за их устранением». В ГОСТ Р 56939-2024 таких процессов шесть: экспертиза кода, статический анализ, динамический анализ с фаззингом, композиционный анализ, функциональное и нефункциональное тестирование. К ним примыкают проверка кода на секреты и антивирусная проверка кода, полученного от поставщиков.
Эта статья — о том, что стандарт требует от каждой проверки, что записать в её регламент и какие отчёты потом показать проверяющему. Как устроено руководство в целом и откуда берётся обязанность, разобрано в статье Регламент безопасной разработки ПО по ГОСТ Р 56939-2024.
Кому нужны эти проверки
Оператору государственной информационной системы, который сам пишет ПО. Пункт 50 Требований, утверждённых приказом ФСТЭК России от 11.04.2025 № 117, обязывает такого оператора реализовать меры разделов 4 и 5 ГОСТ Р 56939-2024. Все шесть проверок входят в раздел 5. Если программу пишет подрядчик, требования стандарта можно включить в техническое задание.
Субъекту КИИКритическая информационная инфраструктура — Информационные системы и сети госорганов и организаций ключевых отраслей; режим защиты установлен 187-ФЗ., который создаёт или модернизирует значимый объект. Пункт 29.3 Требований, утверждённых приказом ФСТЭК России от 25.12.2017 № 239, касается прикладного ПО, которое внедряют при создании, модернизации, реконструкции или ремонте значимого объекта и которое обеспечивает его функции. Для такого ПО подпункт 29.3.2 требует статический анализ исходного кода и фаззинг-тестирование, а для объектов первой категории — ещё и динамический анализ кода. Это требование к самой программе: оно действует, кто бы её ни писал. Выполнение оценивают на этапе проектирования по материалам разработчика, а результаты оценки включают в проектную документацию (пункт 29.4).
Разработчику на заказ. Объём обязательств задают договор и техническое задание. Если документ требует соответствия стандарту целиком, выполняются все его требования, кроме рекомендуемых (пункт 4.14). Для научно-исследовательских и опытно-конструкторских работ процессы перечисляют в техническом задании явно и могут ограничить их объём (пункт 4.15).
Шесть проверок и что каждая ищет
Проверки не заменяют друг друга. Каждая ловит свой класс ошибок, и у каждой есть слепые зоны, которые закрывает соседняя.
| Проверка (пункт ГОСТ) | Что ищет | Когда удобно проводить | Главное доказательство |
|---|---|---|---|
| Экспертиза кода (5.9) | Логические ошибки, отступления от правил кодирования, подозрительные конструкции, которые не видит анализатор | При слиянии изменений в основную ветку | Результаты экспертизы: что смотрели, что нужно изменить, вопросы к коду |
| Статический анализ (5.10) | Опасные конструкции и типовые ошибки в исходном коде без его запуска | На каждое изменение кода в конвейере сборки | Отчёт анализатора со всеми срабатываниями и их разметкой |
| Динамический анализ и фаззинг (5.11) | Ошибки, которые проявляются только при выполнении: аварийные завершения, зависания, ошибки работы с памятью | Регулярно и после изменений модулей поверхности атаки | Отчёты динамического анализа и фаззинга с разбором аварийных завершений |
| Композиционный анализ (5.16) | Известные уязвимости в заимствованных библиотеках и компонентах | Непосредственно перед сборкой и при появлении новых сведений об уязвимостях | Перечень зависимостей и результаты его проверки |
| Функциональное тестирование (5.18) | Ошибки в работе функций, в том числе функций защиты: входа, разграничения доступа, журналирования | Перед выпуском версии | План, отчёт и журналы тестирования, записи в системе управления ошибками |
| Нефункциональное тестирование (5.19) | Недостатки, которыми может воспользоваться нарушитель: интерфейсы, сетевые взаимодействия, обработка чужих данных | Перед выпуском значимых версий и по графику | Отчёт с найденными уязвимостями и сверка с моделью угроз |
Подпункт 5.15 о секретах стоит рядом. Это не испытание программы, а проверка того, что в код и файлы настроек не попали пароли, ключи и токены.
Что общего у всех проверок
Набор артефактов у процессов разный: у экспертизы — регламент и результаты, у функционального тестирования — план, отчёт, журналы и записи об ошибках. Но если отойти на шаг, у большинства проверок видна одна схема. Её удобно держать в голове при написании регламентов.
- Регламент. Кто проводит проверку, по каким правилам выбирают инструменты и проверяемые модули, что считается ошибкой, которую надо исправить, и когда проверку повторяют. Регламенты всех проверок можно включить в одно руководство по разработке безопасного ПО (пункт 4.12).
- Перечень инструментов. Название, версия и к чему инструмент применим: к какому языку или модулю.
- Отчёт с разбором. Не просто выгрузка инструмента, а решение по каждой находке: ошибка или ложное срабатывание, исправлять или нет, когда.
- Повтор. Проверку повторяют после исправлений и после изменений, которые могли повлиять на результат. Для статического анализа поводы повтора названы в самом стандарте, регламент их уточняет, но не отменяет.
Проверяющий сверяет регламент с отчётами. Регламент, который обещает анализ каждого изменения, без отчётов за последние месяцы сам указывает на нарушение. Периодичность в регламенте должна быть такой, которую вы действительно выдерживаете, и при этом не ниже того, что требует стандарт.
Экспертиза исходного кода (5.9)
Экспертиза — это чтение кода человеком. Стандарт имеет в виду анализ кода разработчиком, который сам этот код не писал. Экспертиза нужна и там, где для языка нет инструментов статического анализа, и там, где выводы анализатора нужно подтвердить.
Что проверять в первую очередь. Модули, которые составляют поверхность атаки: всё, что принимает данные извне, отвечает за вход и права, работает с файлами и сетью. Стандарт прямо называет их приоритетом (подпункт 5.9.2.2).
Что записать в регламент (подпункт 5.9.3.1):
- кто участвует в экспертизе и кто за что отвечает;
- базовые правила: сколько участников, какие области кода, какие инструменты;
- основные проверки — сценарии, шаблоны или чек-листы.
Что должно остаться в результатах (подпункт 5.9.3.2): какие модули смотрели, какие изменения нужны, какие места кода непонятны и требуют объяснений, что можно улучшить.
Удобнее всего проводить экспертизу через запросы на слияние в системе контроля версий. Стандарт это рекомендует (подпункт 5.9.2.3). Тогда результаты сохраняются сами: комментарии, решения и исправления привязаны к изменению кода.
Экспертиза помогает найти подозрительную логику, которую пропускают автоматические средства. Анализатор вряд ли отличит скрытую служебную роль, которая включается по «секретному» значению параметра, от обычной функции. Человек, который не писал этот код и спрашивает «зачем это здесь», имеет больше шансов это заметить.
Статический анализ (5.10)
Статический анализатор разбирает исходный код, не запуская программу. Он ищет опасные конструкции и типовые ошибки: непроверенный ввод, переполнения, утечки ресурсов, небезопасные функции. Цель по стандарту — не допустить в программу опасных конструкций и ошибок, в том числе из заимствованного кода.
Что записать в регламент (подпункт 5.10.3.1):
- роли и обязанности;
- как выбирают инструменты;
- какие программы и модули анализируют;
- как обрабатывают срабатывания;
- какие типы ошибок и какой критичности обязательно устраняют и в каком порядке;
- периодичность анализа или события, после которых его повторяют;
- когда пересматривают настройки инструментов.
Каждый язык под анализом. Инструменты подбирают так, чтобы был покрыт каждый язык программирования в составе ПО (подпункт 5.10.2.2). Один инструмент может поддерживать несколько языков. Но если система написана на Java, а отчёты собираются скриптами на Python, анализ одной Java оставляет дыру. В перечне инструментов указывают название, версию и языки (подпункт 5.10.3.2).
Все срабатывания регистрируются. Стандарт требует фиксировать все предупреждения анализатора (подпункт 5.10.2.4), а отчёт должен содержать и сами срабатывания, и их разметку (подпункт 5.10.3.4). Разметка — это решение по каждому срабатыванию: истинная ошибка или ложное срабатывание. Отчёт без разметки показывает, что анализатор запускали, но не показывает, что результаты кто-то разбирал.
Ложные срабатывания неизбежны. Анализатор ошибается в обе стороны: сообщает о проблемах, которых нет, и пропускает настоящие. Слишком строгая настройка тонет в шуме, и команда перестаёт читать отчёты. Слишком мягкая пропускает ошибки. Поэтому настройки фиксируют и пересматривают при заданных событиях: смене правил сборки, обновлении анализатора, появлении сведений о новых уязвимостях (подпункт 5.10.2.5).
Когда повторять. После исправления найденных ошибок, после изменений кода, при смене версии компилятора или среды выполнения и при обновлении самого анализатора (подпункт 5.10.2.6). На практике анализ встраивают в конвейер сборки и запускают на каждое изменение, а полный прогон делают перед выпуском версии.
Динамический анализ и фаззинг (5.11)
Динамический анализ исследует программу во время работы. Стандарт допускает разные методы: подачу заведомо некорректных данных, профилирование, отладку, поиск защищаемой информации в памяти, санитайзеры и двоичное инструментирование. Санитайзеры — это датчики, которые компилятор встраивает в программу. Они останавливают её на ошибке работы с памятью, неопределённом поведении или гонке потоков, которые иначе прошли бы незаметно.
Фаззинг — частный случай динамического анализа. Фаззер подаёт на вход программе огромное число изменённых входных данных и следит за реакцией. Распространённые фаззеры работают с обратной связью по покрытию: если вход ведёт программу по новому пути выполнения, фаззер сохраняет его и меняет дальше. Если программа падает или зависает, вход сохраняют для разбора. Стандарт требует фаззинг отдельно (подпункт 5.11.2.7).
Что записать в регламент (подпункт 5.11.3.1):
- роли и обязанности;
- как выбирают инструменты, методы и проверяемые модули;
- какие срабатывания требуют разбора — например, аварийная остановка или зависание;
- как устраняют найденные ошибки;
- когда повторяют динамический анализ;
- как часто проводят фаззинг и когда его считают завершённым.
Перечень модулей и сценарии. Нужен перечень модулей, которые подвергают динамическому анализу и фаззингу, с наименованием и идентификатором каждого (подпункт 5.11.3.3). Для каждого модуля описывают сценарий: какой инструмент, с какими настройками, когда запускать и когда останавливать (подпункт 5.11.3.4). Начинать стоит с модулей поверхности атаки: разборщиков форматов, обработчиков сетевых запросов, загрузки файлов.
Начальный набор входных данных. Большинство фаззеров работает от коллекции входных данных — набора файлов или запросов, которые он будет менять. Если инструмент использует коллекцию, стандарт требует, чтобы она задействовала разные возможности модуля (подпункт 5.11.2.8). Фаззер с одним примером входа долго ходит по одной и той же ветке кода.
Критерий завершения. Фаззинг может идти бесконечно, поэтому регламент задаёт, когда его останавливать. Обычно это минимальная длительность и отсутствие новых путей выполнения в течение заданного времени. Конкретные числа стандарт не устанавливает — их выбирает разработчик и обосновывает в регламенте.
Что должно быть в отчётах. Отчёт динамического анализа содержит срабатывания и результаты их разбора (подпункт 5.11.3.5). Отчёт фаззинга — длительность, число аварийных завершений, число найденных путей выполнения и разбор каждого аварийного завершения (подпункт 5.11.3.6). Найденные ошибки устраняют по принятым процедурам (подпункт 5.11.2.9), а модуль проверяют повторно (подпункт 5.11.2.6).
Композиционный анализ (5.16)
Современная программа во многом состоит из чужого кода: библиотек, фреймворков, пакетов. Вместе с ними в программу приходят их уязвимости и, в худшем случае, закладки. Композиционный анализ отвечает на вопрос, из чего собрана программа и нет ли в этих компонентах известных уязвимостей.
Перечень зависимостей. Основа анализа — перечень заимствованных компонентов с версиями и источником каждого (подпункт 5.16.3.2). Учитывайте не только прямые зависимости, но и транзитивные: библиотеки, которые подтянули ваши библиотеки. Перечень удобно формировать автоматически в машиночитаемом формате спецификации компонентов (SBOMSoftware Bill of Materials — перечень компонентов ПО — Список заимствованных компонентов программы с версиями; основа композиционного анализа.), например CycloneDX или SPDX.
Проверка перед сборкой. Заимствованные компоненты, которые входят в поверхность атаки, проверяют на известные уязвимости непосредственно перед сборкой (подпункт 5.16.2.4). Проверка раз в квартал этого требования не выполняет: между проверками в сборку попадёт библиотека с уязвимостью, опубликованной вчера.
Где искать уязвимости. В Банке данных угроз безопасности информации ФСТЭКФедеральная служба по техническому и экспортному контролю — Регулятор технической защиты информации (ИСПДн, ГИС, КИИ); ведёт реестр сертифицированных СЗИ. России и в международных базах CVE и OSV. Сведения в базах отличаются: уязвимость может быть описана в одной базе и отсутствовать в другой. Поэтому разумно сверяться с несколькими.
Что записать в регламент (подпункт 5.16.3.1): роли, как отслеживают уязвимости заимствованных компонентов, как проводят анализ, какие компенсирующие и защитные меры принимают, как часто проводят анализ.
Что делать с найденной уязвимостью. Корректирующие действия обязательны (подпункт 5.16.2.5), а правила компенсирующих мер записывают в регламент. Каким может быть содержание этой работы, стандарт показывает на примере (подпункт 5.16.3.5). Сначала оценивают, применима ли уязвимость к вашей программе: используется ли уязвимая функция и достижима ли она для нарушителя. Если применима — обновляют компонент. Для компонента с закрытым кодом обращаются к поставщику и обновляют компонент, когда выйдет исправление; до этого принимают компенсирующие меры. Для компонента с открытым кодом, если обновить версию нельзя, исправляют его своими силами. Каждое решение полезно записывать, включая решение «не применимо» с обоснованием.
Что показать проверяющему: перечень зависимостей, описание того, как он поддерживается в актуальном виде и какими инструментами, журналы его обновлений, результаты анализа с критичностью найденного и результаты корректирующих действий (подпункты 5.16.3.2–5.16.3.5).
Секреты в коде (5.15)
Пароль к базе данных, ключ доступа к облаку или токен, записанные прямо в код, видны каждому, у кого есть доступ к репозиторию, и остаются в истории изменений и её копиях. Утечка исходного кода превращается в утечку доступа к боевым системам.
Стандарт предлагает три меры: регламент использования секретов, проверку кода и файлов настроек на секреты при каждом изменении и систему управления секретами для их хранения и выдачи (подпункты 5.15.2.1–5.15.2.4). У подраздела есть особенность: его требования применяются по усмотрению и в нужном объёме. Но проверка изменений на секреты дешева и легко встраивается в конвейер, поэтому отказываться от неё неразумно.
В регламенте полезно описать типы секретов и сроки их действия, порядок выдачи доступа, порядок смены и действия при компрометации (подпункт 5.15.3.1). Если секрет всё же попал в репозиторий, удалить его из кода недостаточно: его надо сменить, потому что старое значение осталось в истории.
Код от поставщиков (5.17)
Отдельный процесс касается кода, полученного через цепочки поставок: библиотек, предсобранных компонентов, инструментов. Его проверяют на внедрение вредоносного ПО (подпункт 5.17.2.5). Результаты должны содержать как минимум отчёты антивирусного сканирования (подпункт 5.17.3.5). Проверку удобно встроить туда же, где выполняется композиционный анализ: перед сборкой.
Функциональное тестирование (5.18)
Функциональное тестирование проверяет, что программа делает то, что должна. Для безопасности важны прежде всего функции защиты: идентификация и аутентификация, разграничение доступа, журналирование событий, контроль целостности. Требования к ним берутся из задания на разработку и из мер защиты информационной системы, в которой программа будет работать.
План тестирования (подпункт 5.18.3.1) содержит роли, описание тестового стенда, сценарии для каждой функции, критерии повторного тестирования, критерии завершения и остановки. Сценарий описывает проверяемое требование, действия, ожидаемый результат и критерий успеха. Удобно связать каждый сценарий с требованием, которое он проверяет: тогда видно, какие требования остались без тестов.
Уровни. Тестируют отдельные модули, подсистемы и программу целиком (подпункт 5.18.2.3). Отчёт должен позволять понять, какие тесты на каком уровне выполнены.
Отчёт (подпункт 5.18.3.2) содержит версию и номер сборки, среду, выполненные сценарии и их порядок, что не проверялось, полученные результаты, найденные и исправленные ошибки, выводы.
Журналы и система управления ошибками. Ход тестирования регистрируют: время запуска и завершения сценария, результат, изменения тестируемой программы, сбои (подпункт 5.18.3.3). Найденные ошибки ведут в системе управления ошибками. По каждой записывают дату, сценарий, модуль, категорию, принятое решение, подтверждение разработчика и сведения об исправлении (подпункт 5.18.3.4). Обычный трекер задач с этими полями подходит.
Нефункциональное тестирование (5.19)
Нефункциональное тестирование — это проверки, которые не относятся к функциям программы. Оно может включать проверки, характерные для тестирования на проникновение: попытки воспользоваться программой так, как это сделал бы нарушитель. Стандарт приводит примерный перечень: сетевые взаимодействия, локальные интерфейсы, операции с высокими привилегиями, работа с конфиденциальными данными, файловые операции, механизмы аутентификации и авторизации, обработка данных от нарушителя, логика работы программы, производительность (примечание к подпункту 5.19.2.1).
Объём определяет разработчик (подпункт 5.19.2.1). Это не разрешение ничего не делать: выявлять интерфейсы, выполнять тесты с имитацией нарушителя и уточнять по их итогам модель угроз всё равно нужно (подпункты 5.19.2.3–5.19.2.5). Выбор объёма полезно обосновать в регламенте.
Что записать в регламент (подпункт 5.19.3.1):
- какие версии тестируют и как часто;
- методы и средства;
- роли и обязанности;
- типовые сценарии тестирования;
- возможности и мотивацию нарушителя по результатам моделирования угроз;
- типовые сценарии атак для основных режимов работы программы.
Связь с моделью угроз. У нефункционального тестирования две цели. Первая — найти недостатки. Вторая — подтвердить, что описание поверхности атаки, модель угроз и архитектура полны (подпункт 5.19.1.1). Если тестировщик нашёл интерфейс, которого нет в описании поверхности атаки, исправляют не только программу, но и описание. Результаты сравнения и перечень изменений — отдельный артефакт (подпункт 5.19.3.3).
Для веб-приложений типовой набор проверок — внедрение команд SQL, межсайтовый скриптинг, подделка межсайтовых запросов, выход за пределы каталога при работе с файлами, обход авторизации. Защита от них известна: параметризованные запросы вместо склейки строк, экранирование вывода и политика безопасности содержимого, токены против подделки запросов, нормализация и белые списки путей.
Отчёт (подпункт 5.19.3.2) содержит описание программы и её инфраструктуры, выполненные сценарии и цели, что не проверялось, результаты со снимками экрана и рабочими файлами инструментов и выводы: найденные уязвимости, как их нашли, насколько они опасны, к чему может привести их использование и как их устранить.
Как встроить проверки в работу
Проверки, которые запускают вручную от случая к случаю, не выдерживают первой срочной задачи. Надёжнее встроить их в конвейер сборки, который стандарт и так требует (раздел 4). Один из рабочих вариантов:
| Момент | Что запускается |
|---|---|
| Каждое изменение кода | Статический анализ, проверка на секреты, экспертиза через запрос на слияние |
| Каждая сборка | Композиционный анализ зависимостей поверхности атаки |
| По графику (например, ночью) | Фаззинг модулей поверхности атаки, полный композиционный анализ |
| Перед выпуском версии | Функциональное тестирование, нефункциональное тестирование в объёме из регламента, повторный разбор неустранённых срабатываний |
| Новые сведения об уязвимости | Внеплановый композиционный анализ и пересмотр настроек анализаторов |
Важно, чтобы конвейер сохранял результаты. Отчёт, который был на экране и исчез, проверяющему не покажешь. Настройте хранение отчётов вместе с номером сборки.
Инструменты без затрат на лицензии
Требования ГОСТ Р 56939-2024 к этим процессам не называют конкретных продуктов и не требуют сертификации инструментов анализа. Требует он другого: инструмент подходит к языку и модулю, описан в регламенте с версией, а его результаты разбираются. Начать можно со свободных инструментов.
| Проверка | Свободные инструменты |
|---|---|
| Статический анализ | Semgrep, SonarQube Community Build, Cppcheck, Clang Static Analyzer; для отдельных языков — gosec, Bandit, SpotBugs |
| Динамический анализ и фаззинг | AFL++, libFuzzer, встроенный фаззинг Go, Jazzer для Java, Atheris для Python, cargo-fuzz для Rust; санитайзеры ASan, UBSan, TSan, MSan |
| Композиционный анализ | OWASP Dependency-Check, OWASP Dependency-Track, Trivy; для перечня компонентов — Syft, cdxgen |
| Секреты | Gitleaks, detect-secrets; для хранения — HashiCorp Vault, OpenBao |
| Нефункциональное тестирование | OWASP ZAP, sqlmap, Nmap — только на своём тестовом стенде |
Проверьте лицензию и условия использования каждого инструмента. Для систем, где применяются только средства из российских реестров или сертифицированные средства, выбор инструментов определяют эти требования, а не удобство.
Частые ошибки
- Анализатор есть, разметки нет. Отчёт с тысячей срабатываний без решений по ним не подтверждает процесс.
- Один инструмент на всё. Анализатор основного языка не видит скрипты, шаблоны и код на втором языке.
- Фаззинг без коллекции входных данных и без критерия остановки. Запустили на пять минут на одном примере и записали «проведено».
- Перечень зависимостей только из прямых зависимостей. Уязвимость нередко сидит в библиотеке, которую подтянула ваша библиотека.
- Секрет удалили из кода, но не сменили. Старое значение осталось в истории репозитория.
- Тестирование на проникновение, отделённое от модели угроз. Найденное не возвращается в описание поверхности атаки, и следующая модель угроз повторяет старые пробелы.
- Регламент обещает больше, чем делается. Периодичность в регламенте должна совпадать с той, что видна в отчётах.
Если вы сертифицируете процессы разработки
Изготовитель средств защиты информации может сертифицировать сами процессы безопасной разработки. Порядок установлен приказом ФСТЭК России от 01.12.2023 № 240. Орган по сертификации, кроме документов, проверяет артефакты процессов, наличие средств статического, динамического и композиционного анализа и проводит инструментальный контроль среды разработки (пункт 19 Порядка). Подробности — в статье Сертификация процессов безопасной разработки ПО.
Частые вопросы
Можно ли обойтись без фаззинга, если есть статический анализ? Нет. Стандарт требует оба вида анализа, и для ПО значимого объекта КИИ подпункт 29.3.2 приказа № 239 называет фаззинг отдельно. Статический анализ не видит ошибок, которые проявляются только при выполнении, а фаззинг не доходит до редких веток кода.
Нужно ли устранять все срабатывания анализатора? Нет. Каждое срабатывание нужно разобрать. Какие ошибки и какой критичности устраняются обязательно и в каком порядке, определяет регламент (подпункт 5.10.3.1). Ложные срабатывания помечают с обоснованием.
Сколько должен длиться фаззинг? Стандарт срока не устанавливает. Он требует, чтобы регламент задавал периодичность и критерии завершения, а отчёт показывал длительность и результат. Распространённый критерий — нет новых путей выполнения за заданное время.
Мы используем готовую библиотеку с открытым кодом. Нужно ли её анализировать статически? Стандарт относит к статическому анализу и заимствованный код: цель процесса — не допустить и опасных конструкций из заимствованного кода (подпункт 5.10.1.1). Какие модули анализировать, определяет регламент. Известные уязвимости библиотеки ищут композиционным анализом.
Подходит ли обычный трекер задач как система управления ошибками? Да, если в нём записываются сведения из подпункта 5.18.3.4: дата, сценарий, модуль, категория, решение, подтверждение и исправление.
Подрядчик пишет программу для значимого объекта КИИ. Кто проводит проверки? Проверки проводит разработчик программы. Выполнение требований оценивает лицо, которое создаёт, модернизирует или защищает значимый объект, на этапе проектирования по материалам разработчика, представленным по техническому заданию (пункт 29.4). Поэтому состав материалов о проверках закладывают в техническое задание.
Проверить себя можно бесплатными калькуляторами: нужен ли вам ГОСТ Р 56939-2024 и на каком основании, и самооценка по 25 процессам — готовность и недостающие артефакты.
Главное
В ГОСТ Р 56939-2024 шесть процессов проверки кода: экспертиза, статический анализ, динамический анализ с фаззингом, композиционный анализ, функциональное и нефункциональное тестирование. У каждого свои регламент и отчёты, а у большинства — перечень инструментов и правило повтора. Проверяющий смотрит не на список инструментов, а на то, как результаты разбираются и устраняются. Встройте проверки в конвейер сборки, сохраняйте отчёты с номером сборки и пишите в регламенте ту периодичность, которую действительно выдерживаете.