Если сотрудники не заботятся о безопасности, так как просто не знают, что это означает, не понимают, что пишут уязвимый код, то все остальные меры малоэффективны. Процессы РБПО требуют от команды определённой зрелости, осознанности решений и знаний инструментов/практик.
Малополезно просить сотрудника разработать правила кодирования (регламент оформления исходного кода и безопасного кодирования), если он понятия не имеет, что это такое, и не читал такие книги, как "Совершенный код" Стива Макконнелла и "Как написать безопасный код на C++, Java, Perl, PHP, ASP . NET" Ховарда М., Лебланка Д, Виега Д. Ну или хотя-бы "Веревка достаточной длины, чтобы выстрелить себе в ногу" Алена Голуба. Впрочем, именно эта книга мне не нравится, но это лучше, чем ничего.
Если он не в курсе обсуждаемых там подходов и рекомендаций, что он составит? Надёргает случайных рекомендаций из интернета? Просто опишет тот стиль, который сейчас у вас де-факто уже есть? Это можно сделать, но такой документ несёт формальный характер и не будет иметь отношения к безопасной разработке. Зачем тогда вообще его делать? Уж если заниматься РБПО, то надо делать это всерьёз и для реальной пользы. Нет смысла обманывать самих себя.
Чтобы заниматься безопасностью по-настоящему, надо осознавать, что и зачем делается. Если сотрудники будут понимать, как строить безопасную архитектуру и другие аспекты, это будет самым существенным вкладом в качество и надёжность. Естественно, всем всё знать невозможно, поэтому и нужны процессы обучения, чтобы в сумме знания сотрудников покрывали все необходимые аспекты (процессы) безопасной разработки.
Условно обучение сотрудников можно разделить на два типа: самообразование и внешнее обучение. Собственно, это указано и в примечании ГОСТ Р 56939-2024 (п. 5.2.):
В данном подразделе под обучением понимается совокупность методов и подходов, направленных на постоянное повышение квалификации, развитие профессиональных навыков, знаний и компетенций сотрудников разработчика, реализуемых как с привлечением сторонних организаций, так и самим разработчиком.
Быть может, достаточно просто положиться на самообразование, выделив сотрудникам определённое время на чтение книг, просмотр записей докладов и т.п.? Соблазнительный по простоте вариант, но, к сожалению, недостаточен.
Во-первых, не все сотрудники одинаково ответственны и вовлечены в работу. Как следствие, некоторые проигнорируют задачу обучения и просто скажут: "Да, регулярно учимся". Нужен механизм внутреннего подтверждения компетенций. Плюс может быть непонятно, что изучать и кому оценивать результат.
Во-вторых, может быть необходимо подтверждать компетенции сотрудников не только для себя. В случае сертификации необходимо предоставить соответствующие артефакты. Например (п.5.2.3.3):
Артефакты реализации требований, подтверждающие прохождение обучения, включают (в зависимости от учебной программы, курса) свидетельства, дипломы, отчеты обучающих платформ и иные документы и материалы, подтверждающие прохождение сотрудником обучения.
Так что "читать книги" недостаточно, чтобы считать реализованным процесс обучения. Необходим системный подход, о чём я расскажу в следующих постах.