Цели девятого процесса по ГОСТ Р 56939-2024:
Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.
Хотя это явно не сказано в стандарте, но, как я понимаю, здесь подразумевают три схожих, но не идентичных направления работ.
Первый вид работ — экспертиза кода, создаваемого в компании штатными разработчиками. Другими словами, это классические обзоры кода (code review), только более упорядоченные, чем обычно это бывает при разработке ПО. Именно к этому относятся артефакты из п 5.9.3., такие как "описание основных проверок (например сценариев, шаблонов, чек-листов) и т.д. К этой теме я вернусь в следующей части.
Про второй и третий вид работ говорит вот этот комментарий:
Требования настоящего подраздела затрагивают анализ исходного кода ПО разработчиком, непосредственно не участвовавшем в разработке анализируемого кода ПО, а также анализ кода ПО, для которого отсутствуют инструменты статического анализа или результаты их работы нуждаются в подтверждении.
Второй вид работ — экспертиза стороннего кода, который команда включает в проект. Понятно, что нереально проводить полноценный обзор кода подключаемых библиотек. Здесь скорее идёт речь о таких вещах, как определение для заимствованного кода поверхности атаки (см. процесс 7) с помощью инструментов и привлечения экспертов.
В случае, если стоит выбор среди несколько схожих по функциональности библиотек (компонентов), то экспертиза кода экспертом и с помощью статического анализа поможет выбрать наиболее качественную, а значит более безопасную реализацию. См. также статью "Почему важно проводить статический анализ открытых библиотек, которые вы добавляете в свой проект".
Третий вид работ — дополнительный ручной анализ собственного кода, для которого отсутствует инструменты статического анализа. Т.е. если у вас есть немного кода на языке, для которого нет анализатора, то вы должны вручную проверить всё то, что проверял бы анализатор. В принципе, этот тот же обор кода, но чек-лист в этом случае может содержать больше пунктов. Например, если в других частях проекта анализаторы кода следят за правилами именования переменных, то на обзоре кода вы должны следить за этим сами. Если непокрытого анализатором кода много, то у вас проблема, с которой предстоит что-то сделать.
Что делать, если подключается сторонняя библиотека на языке, для которого у вас нет анализатора? Смотрите, с точки зрения РБПО, если вы включили в проект сторонний код, то теперь это ваш код, за который вы ответственны. Следовательно, вы должны выбрать дополнительный инструмент статического анализа и включить его в свои процессы разработки.
Что делать, если библиотека обязательно нужна большая (ручной обзор невозможен) и при этом она на языке, для которого статического анализатора не существует в природе? Вот тут даже не знаю, что ответить. Понятно, что есть проблема, но как её решить затрудняюсь подсказать. Возможно, надо подумать в сторону каких-то компенсационных мер... Хз. Может, кто-то в комментариях подскажет, что следует делать в таком случае.