Сейчас Agail применяется  там где надо и не надо. Почему-то многие, если не срабатывает традиционный подход сразу обращают свои взоры на модную технологию даже не заставив себя проанализировать, а каковы реальные причины неуспеха традиционного подхода. Но здесь не об этом, а об очень важном вопросе - вопросе безопасности продуктов разрабатываемых под Agail. И я не мог пропустить эту новость, потому что в ней есть реальный полезный опыт и его нужно применять.

Как любое новшество, использование Agile в разработке и продвижении проектов влечёт за собой большое количество новых вызовов и угроз кибербезопасности, что ставит перед специалистами по кибербезопасности несколько непростых вопросов:

1.  Как обеспечить кибербезопасность agile-проектов и реализуемых продуктов?
2.  Как можно использовать Agile при обеспечении комплексной кибербезопасности?

Разобраться с этими вопросами поможет взгляд через призму кибербезопасности на ценности и принципы, заявленные в главном документе Agile «Манифесте гибкой методологии разработки ПО» (англ. Agile Manifesto). Манифест содержит группу основных принципов (постулатов), которые условно можно разделить на правую и левую части:

Вместе с постулатами приводится и небольшая оговорка мелким шрифтом: «Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева».

 Вот здесь автор делает очень верное замечание, которое во многом объясняет  причины провалов применения технологии Agail.

У людей встречается такая особенность — «слепое пятно», когда люди не видят, не замечают какое-либо изображение или текст. Общение с командами Agile неожиданно показало, что фраза «не отрицая важности того, что справа» попала как раз в такое «слепое пятно». Команды видят только принципы, сгруппированные слева. 

 Ну и про саму безопасность.

Следующая потенциальная проблема заключается в незавершённости постулатов Agile. Вопросы защиты информации не нашли хоть какого-нибудь отражения в манифесте. Максимум, что говорится о требованиях к конечному продукту — он должен быть «работающим» и «быть готовым к изменениям». С точки зрения идеологов Agile, важнее оперативно реализовать продукт и его функциональность (так называемые «эпики» и «фичи»), пусть и в ущерб защищённости. 

 Автор делится опытом устранения этих недоработок и противоречий, и, с моей точки зрения, это очень полезный опыт, который нужно принимать на вооружение. Вот основные моменты:

Опыт работы в командах Agile в ПАО «Сбербанк» (далее — Sbergile) позволил сформулировать несколько основополагающих подходов к кибербезопрасности в Agile:

• разработку продукта осуществляют люди (от их мотивации соблюдать правила кибербезопасности зависит защищённость конечного продукта и всего процесса в целом);
• для продукта реальная защищённость важнее, чем формальное соответствие требованиям регулятора;
• общение и сотрудничество с членами команды важнее, чем формальное выполнение командой требований политик, регламентов и других регулирующих документов;
• безопасность должна быть не менее гибкой, чем продукт, защиту которого она обеспечивает. В условиях постоянных, молниеносных изменений продукта необходимо быть готовым к изменению «на лету» и мер по защите.

 и

... в Sbergile была создана роль «эксперт предметной области по кибербезопасности» или сокращённо ЭПО по кибербезопасности. Сейчас в работе трайба Sbergile участвуют 2–3 человека. ЭПО по кибербезопасности видит картину разработки продукта целиком, предлагает лучшие практики по обеспечению его безопасности, которые были наработаны в других командах. 

 Подробнее читайте в самих материалах.

По материалам www.it-weekly.ru