Безопасная разработка по ISO 27001: SDLC без торможения релизов

Версия стандарта 2022 года усилила требования к разработке: появился отдельный контроль о безопасном кодировании. Для ИТ-компаний это важнейшая часть Приложения A — и одновременно та, где легче всего встроить безопасность в существующие процессы, ничего не тормозя.

Что ожидает стандарт

Правила безопасной разработки: зафиксированные принципы — от валидации ввода до работы с секретами;
безопасность в жизненном цикле: требования безопасности учитываются на дизайне, а не после пентеста;
разделение сред: дев, тест и продакшн — отдельно, с разными доступами;
тестовые данные: продакшн-данные в тесте — только обезличенные;
контроль изменений: код-ревью и прослеживаемость от задачи до релиза.

Как это выглядит в живом процессе

Хорошая новость: современный DevOps уже содержит 80% необходимого. Pull request + обязательное ревью = контроль изменений. CI со сканером зависимостей и секретов = технические проверки. Защищённые ветки, подписанные релизы, IaC — всё это доказательства для аудитора. Моя работа на аудите — не требовать новых инструментов, а показать, как задокументировать существующие.

Два самых частых пробела

Секреты в коде — несмотря на все инструменты, нахожу их постоянно; сканер в CI и менеджер секретов закрывают вопрос (см. политику криптографии). Зависимости: уязвимость в сторонней библиотеке — ваша уязвимость; автоматические обновления безопасности и разбор критичных алертов должны быть кем-то «owned».

Что ожидает стандарт

Как это выглядит в живом процессе

Два самых частых пробела

Читайте также