Цепочки поставок приложений являются главной мишенью для кибератак, именно поэтому DevSecOps — обеспечение безопасности приложений в процессе разработки от начала до конца — так важно. Фактически, новая стратегия модернизации ИТ Пентагона будет частично основана на новом руководстве DevSecOps 2.0, пишет на портале TechBeacon Кирстен Ньюкомер, старший главный менеджер по продуктам Red Hat.

Есть DevOps плюс безопасность, а есть DevSecOps. В чем разница? В первом случае безопасность является третьим лишним. Во втором случае это одна из ножек табуретки с тремя ножками — неотъемлемая часть системы, которая почти незаметна, пока не пропадет. Действительно, чтобы быть эффективной, безопасность должна быть везде — на протяжении всего конвейера, используемого для создания и развертывания, а также в среде выполнения.

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

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

1. Нулевое доверие

Термин «нулевое доверие» (zero trust) лаконично передает то, что многие из нас понимают уже давно: не существует такого понятия, как 100%-ная безопасность, когда речь идет о ПО. Нулевое доверие — зонтик для всего, что я обсуждаю в этой статье — не означает блокировку всех и вся, а скорее означает никогда не доверять и всегда проверять.

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

2. Автоматизация

Во избежание человеческих ошибок и для обеспечения баланса между безопасностью и производительностью важно автоматизировать все, что можно эффективно автоматизировать. Действительно, без автоматизации не может быть DevSecOps. Автоматизация также улучшает проверяемость, а проверки — это ключевой источник инсайтов.

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

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

3. Аттестация и цифровая подпись

Сегодняшняя цепочка поставок ПО на самом деле больше похожа на паутину: разработчики пишут свой собственный код, но они также черпают его из многочисленных сторонних источников, Open Source-проектов, реестров и т. д. Откуда им знать в среде DevSecOps, что то, что они берут в кодовую базу, безопасно?

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

По словам Люка Хиндса, ведущего инженера по безопасности в офисе технического директора Red Hat, цифровая подпись — это ответ на вопрос о защите цепочек поставок ПО. Но он обеспокоен тем, что Open Source-среда не способствует внедрению цифровой подписи (из-за дополнительных расходов и снижения производительности). Поэтому он создал новый Open Source-проект sigstore, который в настоящее время насчитывает более 465 участников и более 20 организаций. Он обещает более эффективно согласовать инновационный механизм Open Source с защитой методом цифровой подписи, включая журнал прозрачности подписи. Сейчас sigstore находится под эгидой Linux Foundation при поддержке Google и Red Hat.

4. Оценка уязвимостей/рисков

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

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

5. Корпоративная культура

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

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

Ищите оптимальное решение

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

Лучше всего — это ключевое слово, потому что то, что работает лучше всего, отличается от того, что работает идеально. Поэтому создавайте свою платформу DevSevOps с пониманием того, что ничто и никто не находится в полной безопасности (нулевое доверие), что многие части цепочки поставок ПО теперь находятся вне вашего контроля (аттестация и цифровая подпись) и что почти наверняка ваш бизнес подвергнется какому-либо виду вредоносной атаки (оценка уязвимостей/рисков). Если вы сможете внедрить автоматизацию и культуру компании, ориентированную на безопасность, в решения, основанные на этих реалиях, у вас будут все шансы перейти от DevOps плюс безопасность к настоящему DevSecOps.