Место безопасности в новой парадигме цифрового бизнеса

Рынок сегодня становится более требовательным и насыщенным, растет конкурентное давление, что приводит к "гонке инноваций", соревнованию за внимание потребителя. Современная экономика переживает стадию цифровизации: цифровыми становятся не только услуги, но и многие традиционные продукты. Компании, организованные традиционным образом, не всегда вписываются в этот диктуемый рынком формат из-за консерватизма и бюрократизации процесса иерархического управления.

Автор: Андрей Акинин, генеральный директор компании Web Control

Наиболее адекватным ответом на эти вызовы стал подход Business Agility. Недостаточно быстро вывести продукт на рынок, продукт должен быть качественным, надежным и безопасным, а вопросы обеспечения безопасности с учетом сжатых сроков разработки должны быть учтены в момент формирования продуктового функционала, то есть потребительской ценности. Какое место у безопасности кода в подходе Business Agility?

Перефразируя Льюиса Кэрролла, сегодня нужно бежать со всех ног, чтобы сохранить свои позиции в бизнесе, а чтобы обгонять конкурентов, надо бежать еще быстрее. При этом важно быть не только быстрым, но и гибким, ведь выживает не сильнейший, а тот, кто способен быстрее адаптироваться к требованиям рынка и эволюционировать.

Гибкость присуща молодым компаниям, но по мере их развития консерватизм и бюрократия, свойственные иерархической модели управления, сокращают возможности быстро изменяться, замедляют реагирование на новые вызовы и, соответственно, снижают конкурентоспособность. Иерархическая модель управления хорошо работает в условиях стабильности, однако в условиях piriculum in mora, а говоря проще, "беги или умри", управление современной компанией требует других принципов.

От Agile для разработчиков к Business Agility

Золотым стандартом разработки сегодня стал Agile, который направлен на дебюрократизацию процессов разработки, снижение рисков разработки, создание продукта в сотрудничестве с заказчиком и увеличение скорости вывода продукта на рынок. Доказав свою эффективность, Agile вышел за пределы команд разработчиков, эволюционировав сначала в Scaled Agile, а затем и в Business Agility. Business Agility – это новый прогрессивный подход к управлению всей компанией, а не только разработкой, вобравший в себя принципы Lean Management, Agile, системного мышления и, наконец, клиент-ориентированного подхода в управлении, который позволяет сохранить гибкость и адаптивность бизнеса на любом этапе зрелости компании в условиях высокой неопределенности бизнес-окружения и переменчивости (волатильности) рынка. Почему это происходит?

Внедряющие Business Agility компании демонстрируют:

• улучшения в коммуникации и совместной работе команд за счет устранения разобщенности;
• повышение вовлеченности сотрудников и, соответственно, скорости вывода продуктов на рынок и возврата инвестиций;
• повышение мотивации сотрудников за счет понимания общей цели.
• Об этом нам говорит успех таких компаний, как Amazon, Apple, Facebook, Google, Microsoft, Netflix и Salesforce.

Пандемия 2020 г., заставившая бизнес выйти из зоны комфорта и пересмотреть свои организационные процедуры, способствовала активному переходу компаний к более гибкому управлению на основе распределенных самоорганизующихся кросс-функциональных команд.

Управление потоком создания ценности

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

Компания сохраняет традиционную иерархию, но на нее органично накладывается виртуальная структура Value Stream Management. При этом потоки ценности могут быть как производственными, а именно создающими продукт (Development Value Streams), то есть непосредственно разработка ПО, так и операционными, обеспечивающими доставку продукта (Operational Value Streams), – маркетинг приложения, например. Это позволяет применить гибкий подход в управлении не только к разработке, но и ко всем процессам в компании, требующим такого подхода.

Не существует единых практик и методов, которые могли бы помочь трансформировать организационную структуру компании из любой отрасли, однако в крупных цифровых компаниях наиболее проработанной методологией управления компанией в условиях Business Agility стал фреймворк SAFe (Scaled Agile Framework).

Причем его используют не только разработчики ПО, но и финансовые организации, государственные органы и даже многие производственные компании, выпускающие вполне материальную продукцию – автомобили, самолеты, медикаменты и электронику. Этот фреймворк представляет собой набор шаблонов, практик и знаний, включая структурированное руководство по ролям и обязанностям, способы планирования работы и управления ею, которые опираются на принципы, ценности и компетенции.

Поиск новых подходов к управлению связан с необходимостью ускорения поставки ПО, и здесь возникает вопрос: безопасность продукта – это опция, за которую надо платить отдельно, или производственный стандарт, неотделимый от других требований к качеству продукта?

Ремень безопасности: опция или стандарт?

Ремень безопасности был запатентован в начале XIX века, но не получил широкого применения из-за неудобства его использования. Каких только отговорок не приводили противники этого инструмента безопасности! Все изменилось в середине XX века, но, как ни странно, не из-за возросших рисков вследствие роста дорожного трафика.

Толчком стало изобретение инженером компании Volvo современного динамического трехточечного ремня безопасности, которым стало удобно пользоваться. Сегодня им оборудуется каждый автомобиль, обязательность его использования установлена на законодательном уровне, и мы уже не представляем, что когда-то было иначе.

Использование ремня безопасности стало частью нашей культуры пользования автомобилем.

То же самое сейчас происходит в разработке продуктов. Способность компании быстро поставить новый продукт или новый функционал требует непрерывной циклической разработки, и традиционные подходы к сканированию релизного кода на наличие уязвимости существенно тормозят этот ритмичный процесс. Они, по сути, являются тем архаичным ремнем безопасности, существовавшим в автомобилях до изобретения инженера Volvo.

Для обеспечения Business Agility пора переходить к новым инструментам и подходам в обеспечении безопасности программных продуктов, необходимо отходить от проверки на уязвимость в одной или двух точках к повышению уровня доверия ко всему процессу создания программных продуктов, того же от нас требуют и регуляторы.

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

Природа успешности хорошего продукта

Коммерческий успех заведомо хорошего продукта критически зависит от трех факторов: скорости его выхода на рынок, стоимости его производства и непрерывного повышения его качества. И все они, в свою очередь, связаны с тем, насколько продукт безопасен по природе. Подход к обеспечению безопасности по природе помогает избежать затрат, связанных с задержкой поставки ПО, переделкой кода и исправлением уязвимостей. Принцип безопасность по природе означает, что:

• вопросы безопасности учитываются на всех этапах, начиная с продумывания архитектуры и функционала;
• продукт разрабатывался в среде, которая исключает или минимизирует риск ошибки;
• происходит непрерывное тестирование качества продукта.

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

Современный уровень развития инструментов оркестрации релизов вполне позволяет безопасности по природе безболезненно встраиваться в конвейер разработки при использовании передовых практик DevOps и управления разработкой на основе потоков создания ценности.

DevOps, оркестрация релизов, Shift Left и безопасность

DevOps предназначен, по сути, для ускорения разработки и развертывания за счет автоматизации и слаженной работы разработчиков и инженеров.

Фактически это именно те рельсы, по которым движется поезд создания ценности. Подход Business Agility основан на принципах Lean Agile (бережливый Agile, как бы непривычно это ни звучало), нацеленных на устранение непродуктивной деятельности, к которой относится и переделка кода, в том числе по причине его уязвимости и небезопасности.

Подход Shift Left позволяет обеспечивать качество кода, включая его безопасность, на максимально ранних этапах разработки, начиная с выбора архитектуры, определения исходных пакетов разработки и программных библиотек и даже на этапе планирования функционала, значительно снижая цену ошибки в ходе разработки.

DevOps, оркестрация релизов и Shift Left, объединившись в единый подход, позволяют интегрировать автоматизированные инструменты безопасной разработки на каждом этапе конвейера DevOps, гибко подходить к тестированию, используя только необходимые инструменты, и обеспечивать безопасность продукта на максимально ранних этапах. Такая комбинация дает возможность избежать не только задержек выхода на рынок, но и финансовых потерь в разработке, связанных с рефакторингом и устранением уязвимостей.

Цикл безопасной разработки

Обычно, говоря о DevOps, думают о CI/CD. Однако я считаю более правильным взгляд на DevOps как на процесс обеспечения всего жизненного цикла продукта, от идеи до вывода из эксплуатации. Именно этот взгляд мы можем увидеть в одном из наиболее проработанных фреймворков Lean Agile – Scaled Agile Framework (SAFe), который хорошо подходит как средним компаниям, так и транснациональным корпорациям и даже государственным структурам. Обратите внимание, Continuous Security (непрерывная безопасность) это не фаза DevOps, а его фундаментальный принцип, так же как контроль версий и непрерывное качество. Подумайте об этом… Современный подход говорит о четырех фазах DevOps:

• Continuous Exploration (CE, непрерывное исследование), включающее исследование нужд потребителя и определение разрабатываемого функционала;
• Continuous Integration (CI, непрерывная интеграция), в ходе которой происходит создание продукта;
• Continuous Deployment (CD, непрерывное развертывание), во время которого разработанный функционал попадает в продсреду без участия инженеров;
• Release on Demand (RD, релиз по требованию), то есть выпуск продукта тогда, когда возникает потребность в очередном релизе.

Рис. 1. DevOps – это основа конвейера непрерывной поставки ПО. Источник: www.scaledagileframework.com/devops/ 

Continuous Exploration

Большинство мер эффективно и целесообразно применять непосредственно на этапе разработки CI. Но при этом на этапе Continuous Exploration при разработке архитектуры критически важно смоделировать угрозы. Если моделирование угроз делать на более позднем этапе, то любые изменения кода или архитектуры потребуют намного больше времени или будут невозможны без глубокой переработки продукта. А это деньги!

Continuous Integration

На этапе Continuous Integration обеспечение безопасности приложения начинается с инструментов SCA – анализа композиции кода Open Source, который должен стать первым шагом на пути к "безопасности по природе". Такие инструменты могут применяться на различных фазах разработки. Обычно проверки встраивают на входе в репозиторий или в скрипты сборки, но они могут встраиваться в IDE разработчика и предоставлять разработчикам обратную связь уже на стадии первичного кодирования. SCA – это универсальный инструмент декомпозиции, инвентаризации и контроля компонентов исходного кода, его можно использовать при любом уровне зрелости процессов обеспечения безопасной разработки. На начальных уровнях зрелости его применяют для анализа исходного кода во время статического тестирования и проверки всего кода Open Source. На более высоком уровне зрелости такие инструменты предоставляются каждому разработчику, они интегрируются в IDE разработчика, и анализ компонента Open Source происходит в момент добавления его в локальный репозитарий разработчика.

Конечно же, кроме SCA, на этапе Continuous Integration должны использоваться различные инструменты и подходы, такие как плагины Security IDE, Security Code Review, парная работа разработчиков, статический и динамический анализ кода, фаззинг-тестирование, подписание кода, мониторинг инфраструктуры, антивирусная защита инфраструктуры и станций разработчика. Но, по моему мнению, невозможно выстроить адекватные процессы управления безопасностью, не поняв, из чего состоит система, то есть без полноценной инвентаризации исходного кода.

Continuous Deployment

На этапе Continuous Deployment во время предрелизного тестирования очевидна потребность в тесте на проникновение.

Пентестинг – это одна из немногих практик, которую сложно или практически невозможно полностью автоматизировать и реализовать на более ранних этапах разработки. Тем не менее даже здесь можно порекомендовать включить профессиональных пентестировщиков в команду разработки для проведения тестирования уже в Staging-среде на этапе Continuous Integration, а использование инструментов оркестрации релизов позволит значительно снизить транзакционные издержки при смещении Security Quality Gate на эту стадию..

Release on Demand

На этапе Release on Demand безопасность готового продукта поддерживается посредством непрерывного мониторинга безопасности с помощью SIEM-решений и обработки данных командами ИБ. На этом этапе задействуются SOC, реагирование на инциденты, непрерывный мониторинг угроз, внешний аудит уязвимостей.

Кроме специализированных есть инструменты, которые решают ряд смежных задач. В качестве примера такого комплексного инструмента можно назвать российский продукт CodeScoring, который не только выполняет традиционные функции SCA-инструмента для ИБ и юристов, но и контролирует вопросы качества и эффективности для разработчиков. Он одновременно обеспечивает контроль использования Open Source, его безопасность и контролирует использование интеллектуальной собственности компании через автоматическое отслеживание использования программных компонентов собственной разработки, а также дает оценку качества кода в разрезе команд и потоков создания ценности, как и качество и полноту самих команд.

CodeScoring может быть использован на всех этапах конвейера DevOps:

• на этапе Continuous Exploration он контролирует технический долг и анализирует состояние команды;
• на этапе Continuous Integration/Continuous Deployment он идентифицирует лицензионные нарушения и контролирует количество и качество заимствованного кода;
• на этапе Release on Demand CodeScoring предупреждает о новых уязвимостях, обнаруженных в компонентах Open Source уже после выхода продукта, и контролирует сложность решения с точки зрения управления рефакторингом продукта.

В заключение

Безопасность по природе (Security by Nature) является фундаментом, обеспечивающим дальнейшую прочность и надежность продукта. Сегодня она становится частью культуры разработки организации, помогает избежать дополнительных затрат на безопасность, связанных с задержкой поставки ПО, переделкой кода и устранением уязвимостей, которых все так боятся. Этому способствуют, конечно же, и требования регуляторов обеспечению соответствующего уровня доверия к процессу разработки, и рост инцидентов кибербезопасности, и необходимость сокращения стоимости релиза, что, в том числе, является результатом своевременного контроля качества кода, неотъемлемой частью которого является контроль его безопасности. Я уверен, что нельзя рассматривать требования безопасности кода в отрыве от остальных требований к качеству разработки. Только при целостном и согласованном подходе к качеству, надежности и безопасности кода можно говорить о продуктах, качественных по природе. При использовании передовых практик DevOps и инструментов автоматизации интеграция в разработку требований к его безопасности происходит органично и необременительно.