Безпечна розробка за ISO 27001: SDLC без гальмування релізів

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

Що очікує стандарт

• Правила безпечної розробки: зафіксовані принципи — від валідації вводу до роботи з секретами;
• безпека в життєвому циклі: вимоги безпеки враховуються на дизайні, а не після пентесту;
• розділення середовищ: дев, тест і продакшн — окремо, з різними доступами;
• тестові дані: продакшн-дані в тесті — лише знеособлені;
• контроль змін: код-ревʼю і простежуваність від задачі до релізу.

Як це виглядає в живому процесі

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

Дві найчастіші прогалини

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

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

• Політика криптографії
• Пентест чи аудит
• ISO 27001:2022 — що змінилося

Автор — Кирило Проскурня (Kyrylo Proskurnya), провідний аудитор ISO та міжнародний експерт із систем менеджменту. Проводжу сертифікаційні та внутрішні аудити ISO 27001, ISO 9001, ISO 27701, ISO 42001 для компаній України, Європи та США. Про мене · Замовити консультацію