Недавно была на методическом сборе ФСТЭК России для разработчиков СЗИ от НСД. Главная мысль, с которой ушла: безопасность продукта не получится включать только на время сертификации. Она должна быть частью ежедневной работы команды.

Хороший пример — заимствованные компоненты. Вопрос не в том, чтобы отказаться от чужого кода. Вопрос в том, понимаем ли мы, что включили в продукт, зачем оно нужно и как будем это сопровождать. Поэтому перечень компонентов — не очередной документ для регулятора, а инструмент работы с уязвимостями. Если он неактуален, ориентироваться на него уже нельзя.

С РБПО похожая история. Написать регламент безопасной разработки — не то же самое, что ее организовать. Анализ кода, проверка зависимостей и работа с результатами должны быть встроены в процесс, а не начинаться перед испытаниями. Нравится, что развивается и практическая поддержка: Унифицированная среда разработки, инструменты и материалы на РБПО.рф. Есть на что опереться, не начиная все с чистого листа.

Также упомянули ИИ — в самих СЗИ и при их разработке. Параллельно готовятся требования к защите систем ИИ и стандарт по безопасной разработке ПО с такими технологиями. Для меня это про баланс: использовать новые возможности, но не терять понимание того, как работает решение и как проверять его безопасность.

И здесь снова возвращаюсь к «бумажному инфобезу». Перечень должен отражать состав продукта. Регламент — действия команды. Результаты анализа — объяснять, что проверили и почему приняли конкретное решение.

Разработка, сопровождение и сертификация не должны знакомиться друг с другом перед испытаниями. Чем раньше между ними выстроена связь, тем меньше приходится восстанавливать ее в авральном режиме.