Google Cloud DORA: обеспечение безопасности цепочки поставок начинается с культуры

Компании, которые сосредоточены на доверии к своим разработчикам, не видят виноватых и стремятся к тесному сотрудничеству, как правило, чаще принимают меры, которые способствуют более безопасным цепочкам поставок программного обеспечения.

Согласно ежегодному отчету Accelerate State of DevOps за 2022 год, опубликованному 28 сентября командой Google Cloud по исследованиям и оценке DevOps (DORA), также было обнаружено, что команды DevOps, которые сосредоточились на передовых методах обеспечения безопасности, имели более низкий уровень выгорания, а команды с низким уровнем безопасности — 1.4. раз больше шансов озвучить высокий уровень стресса.

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

Например, опрос DORA, лежащий в основе отчета, измеряет приверженность команд DevOps 13 различным аспектам, измеряемым структурой безопасности «Уровни цепочки поставок для программных артефактов» (SLSA), которая требует создания выпусков продуктов с использованием централизованной непрерывной интеграции/непрерывной разработки. (CI/CD), хранение истории изменений на неопределенный срок, определение сборки программного обеспечения с помощью сценариев и изоляция процесса сборки. И хотя большинство компаний полностью или частично внедрили все 13 практик, те, в которых культура сотрудничества была более тесной и менее ориентированной на вину, добились большего успеха, как показало исследование DORA.

«Более открытые, генеративные культуры… как правило, оказывают положительное влияние на эффективность организации, а также на людей, которые в ней работают», — говорит Тодд Кулеша, один из авторов отчета и старший исследователь пользовательского опыта (UX) в Google Cloud. . «Что мы хотим видеть, так это то, что если есть проблема с безопасностью, мы хотим, чтобы инженеры чувствовали себя в безопасности и могли привлечь к этому внимание. Вы не хотите, чтобы ваши разработчики заметали вещи под ковер, особенно с точки зрения безопасности».

К сожалению, исследование показало, что в области совместной работы есть над чем поработать: многие разработчики программного обеспечения считают, что существует пропасть между программистами и командами, отвечающими за безопасность приложений.

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

Безопасность цепочки поставок: важнейший барометр производительности DevOps

В восьмой год Годовой отчет команды DevOps Research and Assessment (DORA) стремится определить лучшие практики среди команд, использующих подход DevOps к разработке программного обеспечения. В 2021 году группа DORA обнаружила, что безопасность цепочки поставок программного обеспечения стала важнейшим компонентом высокоэффективных организаций DevOps, поэтому в этом году исследователи сосредоточились на определении того, что привело к успешным результатам на этом фронте.

В опросе Google сосредоточился на внедрении методов обеспечения безопасности, которые являются частью цепочек поставок.

В дополнение к тому, что команды DevOps придерживаются структуры SLSA, в опросе разработчиков спрашивали, в какой степени они соблюдают десятки методов обеспечения безопасности, которые формируют платформу безопасной разработки программного обеспечения (SSDF), созданную Национальным институтом стандартов и технологий США (NIST). .

Организации, в которых были высоко сотрудничающие команды, которые разделяли риски и обязанности и отдавали предпочтение обучению, а не обвинению — так называемые «генеративные» культуры — с большей вероятностью примут более двух десятков этих методов обеспечения безопасности, как показал опрос практиков DevOps.

«Многие из этих практик — я не собираюсь утверждать, что они на 100 % внедрены в организациях, — но многие из этих практик имеют 50 или более процентов практиков, сообщающих, что они внедрены или очень хорошо зарекомендовали себя», — говорит Джон Спид. Мейерс, соавтор отчета и специалист по безопасности в компании Chainguard, занимающейся безопасностью цепочки поставок программного обеспечения. «Есть много возможностей для улучшения, но эти вещи не настолько сложны, чтобы ими никто не занимался».

Опрос также измерял выгорание разработчиков, основываясь на том, насколько высоко они оценили свое согласие с такими утверждениями, как «мои чувства по поводу работы негативно влияют на мою жизнь вне работы» и «я безразличен или циничен по отношению к своей работе». Команды, которые не уделяли внимания безопасности, на 40% чаще соглашались или полностью соглашались с этими утверждениями.

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