Важный, можно сказать, экзистенциальный пункт внедрения процессов для разработки безопасного ПО. Невозможно просто собрать коллег и сказать им: "С завтрашнего дня у нас РБПО по ГОСТ Р 56939-2024, приступайте". Вернее, сделать так можно, но ничего не произойдёт, или всё выльется в сплошную видимость. Внедрение РБПО требует планирования как с точки зрения регламентов и изменений в работе, так и с точки зрения планирования бюджетов.
Обеспечение потребностей в ресурсах, необходимых для реализации процессов разработки безопасного ПО (п. 5.1.1.1).
Некоторые эксперты в публикациях озвучивают оценку, что внедрение РБПО увеличивает стоимость разработки на 10-15%. На мой взгляд, оценка правдоподобна. Эти наценка складывается из приобретения лицензий на различные дополнительные инструментальные средства и из времени, которое будут затрачивать сотрудники на новые процессы и обязанности.
Необходимо ответственно спланировать работы по внедрению процессов, описанных в ГОСТ Р 56939-2024, так как, скорее всего, вам будет предстоять большая работа: утвердить новый бюджет, роли сотрудников и заложить время на необходимую работу.
План реализации процессов разработки безопасного ПО должен содержать цели, сроки и этапы внедрения процессов разработки безопасного ПО; перечень необходимых ресурсов; информацию об ответственных за внедрение процессов сотрудниках (п. 5.1.3.4).
Как уже было сказано, РБПО увеличивает бюджет. Если вы работаете в большой компании, разрабатывающей различные проекты, то есть смысл провести ревизию и определить, где нужно внедрение РБПО, а где нет. Скорее всего, нерационально внедрять РБПО по ГОСТ в тех командах, где не пишут критическое ПО, которое будет проходить сертификацию.
В стандарте описаны полезные практики, которые улучшат качество любого проекта. Но вопрос: насколько глубоко их стоит реализовывать с точки зрения затрат? Одно дело — воодушевиться чтением ГОСТ и внедрить в некритический проект несколько практик для повышения качества кода, и другое дело — внедрять его всеобъемлюще на уровне, предполагающем дальнейшую сертификацию в ФСТЭК.
Описание области применения процессов разработки безопасного ПО должно содержать состав ПО (версии, модули, компоненты, функциональные подсистемы и т. п.), в отношении которого должны быть реализованы процессы разработки безопасного ПО, с обоснованием выбора указанного состава ПО (п. 5.1.3.5).