Одна из постоянных проблем создания современных приложений - сделать их более безопасными без нарушения высокоскоростных процессов DevOps или ухудшения качества работы разработчиков. Современный ландшафт киберугроз изобилует изощренными атаками, нацеленными на все различные звенья цепочки поставок программного обеспечения, и для организаций-производителей программного обеспечения как никогда актуальна необходимость внедрения практик DevSecOps, которые глубоко интегрируют безопасность на протяжении всего жизненного цикла разработки программного обеспечения.
Однако решающее значение имеет то, КАК организации это делают. Например, блокировка платформы разработки, внедрение исчерпывающих проверок кода и принудительное выполнение сложных процессов утверждения могут улучшить состояние безопасности конвейеров и кода, но не рассчитывайте на то, что команды разработчиков приложений будут работать достаточно плавно для внедрения инноваций. То же самое касается тестирования безопасности приложений; обнаружение горы уязвимостей не приносит никакой пользы, если у разработчиков недостаточно времени или рекомендаций для их устранения.
Создание и запуск практики DevSecOps на высоком уровне означает, что ваша организация способна управлять безопасной платформой доставки, тестировать программное обеспечение на наличие уязвимостей, определять приоритеты и устранять уязвимости, предотвращать выпуск небезопасного кода и обеспечивать целостность программного обеспечения и всех его артефактов.
Но создание и запуск высокоэффективной практики DevSecOps означает достижение всех этих целей при той же (или более высокой) скорости разработки и общем уровне удовлетворенности разработчиков. Следующие пять руководящих принципов необходимы для достижения этой цели.
Принцип 1: Создание культуры сотрудничества, ориентированной на безопасность
Сильная и продуктивная культура необходима для успеха любой команды, но это также самый сложный элемент, который нужно сделать правильно. Это особенно верно для DevSecOps, о чем свидетельствует недавнее отраслевое исследование, показавшее, что "более половины (51%) лиц, принимающих решения в области ИТ, сообщают о явном сопротивлении изменениям в своих командах, в то время как 47% говорят о недостаточном межкомандном сотрудничестве".Не следует недооценивать важность культуры для успешного проведения DevSecOps, и она начинается с признания безопасности приоритетом для всех заинтересованных сторон.
Сделайте безопасность общей ответственностью
Если ваша организация создает, продает или потребляет программное обеспечение (а сегодня это делают все мыслимые организации на планете), то каждый отдельный сотрудник оказывает влияние на общую систему безопасности, а не только те, у кого в названии есть слово "безопасность". По своей сути DevSecOps - это культура совместной ответственности, и работа с общим мышлением, ориентированным на безопасность, определяет, насколько хорошо процессы DevSecOps вписываются в систему и могут способствовать более эффективному принятию решений при выборе платформ DevOps, инструментов и индивидуальных решений для обеспечения безопасности.Менталитет не меняется в одночасье, но согласованности действий и чувства ответственности за безопасность можно добиться с помощью следующего:
- Приверженность регулярному обучению внутренней безопасности, разработанному специально для DevSecOps, в которое входят разработчики, инженеры DevOps и инженеры по безопасности. Пробелы в навыках и потребности не следует недооценивать.
- Внедрение разработчиками безопасных методологий и ресурсов для кодирования
- Разработка систем безопасности вносит свой вклад в архитектуру приложений и среды, а также в обзоры дизайна. Всегда проще выявлять и устранять проблемы безопасности на ранних этапах жизненного цикла разработки программного обеспечения.
Устраните разрозненность функций и продолжайте сотрудничать
Поскольку DevSecOps является результатом слияния разработки программного обеспечения, ИТ-операций и безопасности, для успеха крайне важно устранить разрозненность и активно сотрудничать на постоянной основе. Как правило, организации, ориентированные на DevOps, работающие без каких-либо официальных рамок DevSecOps, рассматривают безопасность как нежелательного участника, нарушающего правила. Внезапные изменения процесса или инструментария (в отличие от совместно выбранных и созданных экземпляров) неизменно приводят к трениям в процессе разработки и ненужному трудозатратам для разработчиков. Распространенный сценарий предполагает, что служба безопасности требует дополнительных проверок безопасности приложений без учета их размещения в конвейере или объема рабочей нагрузки, необходимой для обработки выходных данных сканера и устранения уязвимостей, что неизбежно ложится на плечи разработчиков.
Стимулирование сотрудничества и работа в качестве сплоченной команды DevSecOps включает:
- Определение и согласование набора измеримых целей безопасности, таких как:
- снижение количества инцидентов безопасности приложений на %
- сокращение времени, затрачиваемого на аудит, на %
- увеличение частоты развертывания на %
- снижение частоты отказов при внесении изменений на %
- снижение количества уязвимостей, внедряемых в производство, на %
- % артефактов, запущенных в производство с помощью SBOM / SLSA
- Сокращение времени подготовки к устранению уязвимостей в течение нулевого дня
- Вовлечение разработчиков программного обеспечения и команд DevOps в процессы оценки и закупки новых средств безопасности
- Обеспечение того, чтобы ни один процесс DevSecOps не имел единого функционального гейткипера
- Итеративная оптимизация выбора инструментов и методов обеспечения безопасности для повышения производительности и скорости разработки
Принцип 2: Перенесите информацию о безопасности влево, а не рабочую нагрузку на безопасность
Затрагивая тему DevSecOps, невозможно не упомянуть "сдвиг влево". Мантра о безопасности "сдвиг влево" настолько распространена в текущих статьях, блогах и маркетинговых материалах, ориентированных на DevSecOps, что легко подумать, что, просто переместив проверки безопасности дальше вверх по жизненному циклу разработки программного обеспечения, вы получите работающую программу DevSecOps. Реальность такова, что то, что вы сдвигаете влево, создает или разрушает ваш успех в DevSecOps.Система безопасности Shift left основана на проверенной идее о том, что выполнение тестов безопасности приложений на ранних этапах конвейеров разработки программного обеспечения (в отличие от непосредственно перед производством) повышает общую вероятность обнаружения известных уязвимостей в коде и артефактах и своевременного их устранения. Однако, если разработчики в одиночку несут все бремя выполнения тестов, сбора выходных данных сканера и определения приоритетов уязвимостей в дополнение к их устранению, возникающая в результате умственная нагрузка и тяжелый труд, несомненно, повлияют на скорость производства. Вместо этого наилучший подход заключается в следовании этим рекомендациям:
- Служба безопасности должна самостоятельно организовывать и автоматизировать тесты безопасности приложений по всем конвейерам CI и CD
- Снимите с разработчиков бремя дедупликации и приоритизации обнаруженных уязвимостей. Вместо этого служба безопасности должна обеспечивать своевременное получение разработчиками полностью обработанного списка уязвимостей
- Ускорьте исправление, подготовив практическое руководство, ориентированное на разработчиков, для понимания и устранения каждой уязвимости
РИСУНОК 1: Распределение тестов безопасности приложений по всему конвейеру разработки программного обеспечения
Принцип 3: Поддерживайте надлежащее управление и ограждения
Поскольку в мире DevOps все происходит быстро, легко допустить ошибку. Но даже небольшие ошибки или упущения, такие как пропущенный CVE (распространенные уязвимости и подверженности риску) или несанкционированное изменение конфигурации в рамках конвейера разработки, могут сопряжены со значительным риском для безопасности и соответствия требованиям. По этой причине ценность комплексного управления и строгих ограничений во всей среде разработки трудно переоценить. Если ваша практика DevSecOps эффективна, значит, вы упростили для заинтересованных сторон выполнение правильных действий и затруднили для них выполнение неправильных. Этого можно достичь с помощью следующих рекомендаций:- Внедрите детализированный контроль доступа на основе ролей (RBAC) во всей среде разработки для обеспечения надлежащего использования и эксплуатации. Общий RBAC обычно основан на одном свойстве (роли), но детализированный RBAC обеспечивает более надежную безопасность за счет учета множества свойств, таких как время суток, группы пользователей, иерархия организации и т.д.
- Накладывать политики поверх конвейеров, чтобы разработчики могли контролировать свои конвейеры и предоставлять группам безопасности и соответствия требованиям возможность требовать проверок безопасности. Стандарт Open Policy Agent (OPA) является отличным подходом "политика как код" для этого.
- Используйте шаблоны везде, где это возможно, для устранения непреднамеренных ошибок, которые приводят к риску для безопасности и соответствия требованиям. Шаблоны должны содержать рекомендации по безопасности, особенно касающиеся выполнения проверок безопасности. Использование шаблонов должно обеспечиваться с помощью политик, обеспечивающих выполнение проверок безопасности.
Принцип 4: Сосредоточьтесь на обеспечении безопасности цепочки поставок программного обеспечения (а не только вашего собственного исходного кода)
Задача обеспечения безопасности современных приложений становится все более сложной, во многом из-за огромного количества компонентов программного обеспечения с открытым исходным кодом (OSS) и других артефактов сторонних производителей, которые производители программного обеспечения используют для создания своих приложений. Каждый из этих компонентов привносит новые потенциальные уязвимости в конечный продукт, что подвергает риску заказчиков программного обеспечения. Общий риск безопасности приложения и соответствия требованиям является функцией всего кода, людей, систем и процессов, которые вносят вклад в разработку и доставку программных артефактов этого приложения, как внутри организации, так и за ее пределами.
Таким образом, артефакты программного обеспечения с открытым исходным кодом являются желанной целью для кибератакующих, о чем свидетельствуют громкие взломы, скомпрометировавшие Solarwinds, Log4j и Codecov. Скомпрометируйте один программный строительный блок, и это потенциально может нанести ущерб десяткам или сотням тысяч конечных потребителей этого компонента. По этой причине фокус DevSecOps должен выходить за рамки исходного кода организации и охватывать всю цепочку поставок программного обеспечения, которая представляет собой СОВОКУПНОСТЬ всего кода, людей, систем и процессов, способствующих разработке и поставке программных артефактов, как внутри организации, так и за ее пределами.
Для критически важной цели обеспечения целостности любого программного обеспечения, производимого организацией, команды DevSecOps должны применять инструменты и практики в соответствии с структурой SLSA и с Исполнительным приказом 14028.
Обеспечение безопасности цепочки поставок программного обеспечения требует от команд DevSecOps:
- Регламентируют использование программных компонентов с открытым исходным кодом во всех конвейерах CI и CD. Этого лучше всего достичь с помощью подхода "политика как код" (основанного на стандарте OPA), который позволяет разрабатывать индивидуальные политики, учитывающие широкий спектр атрибутов артефакта OSS, таких как версия, лицензия, исходная информация и поставщик, наряду с ведущими показателями риска. Независимо от того, является ли целью обеспечение надлежащего использования библиотек с открытым исходным кодом или блокирование использования определенных артефактов OSS по соображениям безопасности, необходимо строгое управление.
- Внедряйте комплексные возможности для создания спецификаций программного обеспечения, управления ими и анализа программных артефактов. SBOM необходим для понимания компонентов и зависимостей в приложении, что, в свою очередь, позволяет организациям эффективно управлять программными рисками. Все больше организаций, использующих программное обеспечение, требуют от поставщиков подробных спецификаций в соответствии с Указом Президента 14028.
- Создавайте и проверяйте соответствие SLSA сверх минимальных требований уровня 1. Платформа SLSA является высокоэффективным средством защиты от несанкционированного использования артефактов. Это позволяет создавать проверяемые записи по всей цепочке поставок с информацией, которая связывает идентификаторы и системы с программным обеспечением. Эта информация может быть проверена и подписана на протяжении всего жизненного цикла разработки программного обеспечения. Чем выше уровень, тем надежнее гарантия целостности.
- Создайте полную цепочку хранения всех программных артефактов. В сфере программного обеспечения цепочка поставок - это подробное свидетельство всего, что происходит с программным артефактом на всех этапах разработки, включая то, кто создал или модифицировал артефакт, какие тесты безопасности он прошел и каковы были результаты тестирования. Обеспечение полной цепочки поставок во многом зависит от базовой платформы CI / CD плюс интегрированного конвейерного инструментария, и это имеет решающее значение для поддержания надежности программного обеспечения от разработки до развертывания. Наличие подробной цепочки поставок программного обеспечения также существенно ускоряет устранение уязвимостей, которое в противном случае представляет собой изнурительный процесс ручного анализа журналов и сбора неполной информации для отслеживания новой уязвимости вплоть до затронутых программных компонентов.
Принцип 5: Обеспечение "непрерывной безопасности" с помощью автоматизации и искусственного интеллекта
DevOps стал синонимом практики непрерывной интеграции и непрерывного развертывания, поэтому само собой разумеется, что DevSecOps должна обеспечивать постоянную безопасность. Большая часть успеха DevSecOps заключается в способности идти в ногу со скоростью разработки приложений (и даже опережать ее). Хотя зарождающейся программе DevSecOps неизменно требуется время для повышения гибкости в дополнение к эффективности, ключом к ускорению зрелости DevSecOps является использование интеллектуальной автоматизации и искусственного интеллекта. Вот несколько важных рекомендаций о том, как и где их применять:
- Организуйте проверки безопасности по всем конвейерам. Этого проще всего достичь с помощью платформенного подхода, при котором базовая платформа DevOps интегрируется с различными инструментами сканирования SAST, SCA, контейнеров и DAST и выполняет сканирование при запуске конвейера. Управление политикой как кодом - это еще одна родственная форма автоматического смягчения последствий. Например, политика OPA может быть принудительно применена для сбоя конвейера, если не соблюдены определенные критерии безопасности.
- Автоматизируйте дедупликацию списков уязвимостей и расстановку приоритетов для разработчиков. Одной из самых больших проблем для разработчиков является работа с огромным количеством необработанных выходных данных сканера. В целях оптимизации времени на устранение критических уязвимостей (наряду с сохранением производительности и опыта разработчиков) автоматизация процесса дедупликации и приоритизации уязвимостей является обязательной.
- Создавайте рекомендации по исправлению с помощью искусственного интеллекта. Чтобы еще больше повысить скорость исправления и свести к минимуму трудозатраты разработчиков, огромное преимущество для разработчиков - предоставление сгенерированных ИИ объяснений уязвимостей и директивных рекомендаций по исправлению.
Заключение
Хотя нет сомнений в важности высокоэффективных практик DevSecOps для организаций, производящих программное обеспечение, существует очень мало четких стандартов о том, как создать систему, которая укрепит общую безопасность приложений, не усложняя и не ухудшая опыт разработчиков.Пять основных принципов DevSecOps (вместе с соответствующими наборами рекомендаций), обсуждаемых в этом документе, позволяют командам DevSecOps создавать и поддерживать прочную операционную основу. Поскольку современные технологии и практики DevOps продолжают стремительно развиваться, всегда будут возникать неизведанные проблемы безопасности, требующие решения. Пока разработчики, инженеры DevOps и специалисты по безопасности работают вместе как единое целое, путь к совершенству DevSecOps намного понятнее. Если вы заинтересованы в дальнейшем глубоком изучении этих концепций, я рекомендую вам загрузить Полное руководство по безопасной доставке программного обеспечения.
