Очередное исследование компании Positive Technologies, представленное 2 сентября прессе, было посвящено теме DevSecOps, и обсуждение этого исследования началось с оговорок экспертов о возможности разных интерпретаций содержания понятия DevSecOps. Что, впрочем, не помешало (а может быть и способствовало?) почти двухчасовому обсуждению вопроса.
По данным исследования (данные которого экспертами не оспаривались) более половины респондентов опроса Positive Technologies не являются, образно говоря, «фанатами» методологии DevSecOps. А развивают соответствующую практику менее 40% опрошенных.
Эти и другие цифры отчёта Positive Technologies и выступления, комментарии и реплики в связи с обсуждением результатов исследования вроде бы демонстрируют, что нельзя говорить о победном шествии методологии (практики) DevSecOps в отечественном ИТ-пространстве. Результаты суммирования ответов респондентов не дают оснований для оптимизма по части перспектив превращения информационной и киберзащиты приложений из набора «заплаток» в продуманную и встроенную ещё на этапе разработки «иммунную систему».
Даже если сделать скидку на то, что из опубликованных результатов опроса «что думают о безопасной разработке в российских компаниях» не совсем ясно, какие цифры отражают частное мнение сотрудников, а какие – политику компании.
Но в чём причины ситуации кажущегося «саботажа» DevSecOps? И можно ли говорить о непопулярности DevSecOps без чёткого определения этого понятия?
В материалах, использованных в ходе встречи в Positive Technologies 2 сентября, утверждается, что «методология DevSecOps подразумевает безопасную разработку на всех технологических этапах и шагах производственного CI/CD-конвейера.
…security-процесс и контроль безопасности должны происходить параллельно и непрерывно, как и разработка, развертывание, тестирование и доставка. А инструменты, обеспечивающие безопасность, рекомендуется внедрять на каждом этапе производственного конвейера.
…сканеры кода должны быть интегрированы в продуктовый конвейер непосредственно на этапе разработки и сборки компонентов продукта.
…добиться такой интеграции без тесного сотрудничества специалистов по ИБ (Sec), разработчиков (Dev) и инженеров по инфраструктуре и эксплуатации (Ops) практически невозможно.
…суть термина DevSecOps (или SecDevOps) подразумевает сотрудничество специалистов разных направлений».
Согласитесь, трудно понять, что в этом наборе черт методологии DevSecOps ключевым может оказаться фрагмент, в котором упомянуты «сканеры кода».
Но возможно, что это именно так. Ведь, например, описание ключевых особенностей DevSecOps на сайте IBM включает следующие тезисы:
«…Ранее задачи безопасности «достраивались» в конце жизненного цикла разработки ПО как нечто второстепенное, при этом за обеспечение и тестирование (QA) безопасности отвечали отдельные команды специалистов.
…С появлением методик Agile и DevOps, направленных на сокращение длительности циклов разработки ПО до нескольких недель или даже дней, традиционная стратегия «достраивания» безопасности стала неприемлемой.
…DevSecOps… АВТОМАТИЗИРУЕТ интеграцию задач безопасности на всех этапах жизненного цикла разработки программного обеспечения, от проектирования до интеграции, тестирования, развертывания и доставки ПО».
Если принять определение сайта IBM и сделать предположение о том, что респонденты опроса Positive Technologies опирались при подготовке ответов именно на подобное определения, то предположение о «саботаже» DevSecOps в отечественном ИТ-сообществе вполне может оказаться несостоятельным.
Во-первых, возможно совершенно правы те 45%, которые считают, что DevSecOps – полезная практика, но не для всех компаний.
Ведь не все отечественные компании являются «пользователями» Agile и DevOps, «направленных на сокращение длительности циклов разработки ПО до нескольких недель или даже дней» и выпускают релизы ежедневно или еженедельно. Особенно, если речь идёт о «самописных» разработках исключительно для внутреннего потребления.
И поэтому возможно вполне логична позиция тех 51% респондентов, которые считают, что у них нет необходимости в DevSecOps (37%) и тех, кто уверен, что «за DevSecOps будущее, но не в их компании» (14%).
Ведь среди опрашиваемых были не только вендоры, которые могут понести серьёзные финансовые и репутационные потери из-за ИБ-прорех в предлагаемых рынку программных продуктах, но и внутренние коллективы разработчиков, оценки неудач которых вполне могут «замыливаться» суетой дней.
И к тому же, если масштаб бизнеса вендоров позволяет эффективно внедрять автоматизацию «жизненного цикла разработки программного обеспечения, от проектирования до интеграции, тестирования, развертывания и доставки ПО»,
то для внутренних коллективов разработчиков «самописных» приложений такая автоматизация может оказаться неподъёмной.
Неподъёмной и вследствие экономической неэффективности эксплуатации DevSecOps-средств автоматизации, и вследствие методических проблем с введением в эксплуатацию соответствующих оборудования/приложений автоматизации.
В то же время в исследовании Positive Technologies объективно разочаровывает цифра в 50% респондентов, которые готовы принять идеологию DevSecOps лишь в том случае, «если появиться понимание, что DevSecOps позволит защитить разрабатываемый продукт от хакеров».
Эти данные могут свидетельствовать о высоком проценте «засорённости» среды разработчиков персонажами, ментально схожими с двумя мужиками «из ларца», которые в известном мультфильме про «Вовку в тридевятом царстве» были предложены главному герою в качестве мощного дополнительного ресурса для повышения производительности труда, но делали всё настолько «тяп-ляп», что за ними всё приходилось переделывать.
Для того, чтобы такие «двое из ларца» хотя бы уравновешивались той второй половиной респондентов, что готовность работать «на тройку» не очевидна, но у которой нет возможностей для изучения DevSecOps, было бы неплохо перейти от академических рассуждений о DevSecOps, как о «полезной практике» или как об «очередном тренде», к активной популяризации «практических историй внедрения DevSecOps» и методических документов «о процессах», «об инструментах», «о формальных историях внедрений и архитектуре DevSecOps».
При этом, возможно, развитие процессов DevSecOps должно идти не только по линии поддержки методологии Agile, но и в интересах сопровождения менее «высокоскоростных» технологий разработки. И для такой ветви методологии DevSecOps определение её сути уже не будет делать упор на автоматизацию, а на первое место выведет «сотрудничество специалистов по ИБ (Sec), разработчиков (Dev) и инженеров по инфраструктуре и эксплуатации (Ops)».
В связи со сказанным уместно провести аналогии с деятельностью таких регуляторов, как Банк России и ФСТЭК при внедрение ряда Положений Центробанка, касающихся обеспечения ИБ финансовой сферы, и закона федерального уровня ФЗ 187.
Эта деятельность сопровождалось не только вполне обоснованными декларациями о полезности и достоинствах предлагаемых упомянутыми документами мер, но и широко развёрнутой методической работой, включающей и полемику с участниками рынка, и прямые разъяснения тех мест «нормативки», которые наталкивались на непонимание её пользователей, но были вполне обоснованными с точки зрения регулятора, обладающего более широким взглядом на проблемы, нежели отдельные игроки рынка.
А необходимость внедрения DevSecOps очевидна не только исходя из внутрикорпоративного масштаба выгод вследствие применения приложений, созданных с использованием проактивных подходов к обеспечению безопасности, но и вследствие фиксируемого ныне роста рисков успешности кибератак «через поставщиков» (по-видимому, именно так правильно переводить иностранный термин, который часто переводится голимым подстрочником «атаки на цепочки поставок»?).
Именно атаки «через поставщиков» приводят к пониманию недопустимости подхода, при котором использование небезопасных приложений считается допустимым в том случае, если «бизнес готов принять риски» их эксплуатации.
Ведь в условиях тесной интеграции цифровых информационных и коммуникационных инфраструктур готовность одного участника цепочки партнёров принять киберриски совсем не означает готовность других участников объединённого киберпространства эти риски разделить.
