Джек М. Жермен
17 ноября 2020 г., 5:00 по тихоокеанскому времени
Отсутствие стандартных практик в сообществах DevOps вызывает растущие трения, поскольку группы безопасности объединяются против разработчиков. Это внутреннее противоречие делает программное обеспечение, которое они разрабатывают, и организации, использующие эти приложения, уязвимы для атак и взломов.
Отчет, выпущенный 30 сентября компанией WhiteSource, занимающейся безопасностью и лицензированием с открытым исходным кодом, исследует различные факторы, влияющие на культуру разрозненной разработки программного обеспечения, и какие шаги необходимы для достижения гибкой, зрелой практики DevSecOps, которая включает интеграцию ИТ-безопасности как общая функция среди всех команд DevOps.
Отчет показывает, что группы разработчиков программного обеспечения испытывают растущее давление, заставляющее их игнорировать функции безопасности, чтобы выдержать короткий жизненный цикл разработки.
Этот вывод особенно важен в свете разоблачений, согласно которым более половины всех разработчиков, опрошенных в отчете, заявили, что у них либо нет обучения безопасному программированию, либо они проводятся только ежегодно. Добавьте к этому отсутствию подготовки программистов по вопросам безопасности то, что менее одной трети организаций имеют определенный согласованный процесс приоритизации уязвимостей.
Содержание статьи
DevSecOps Showdown
Возможно, еще более тревожная дилемма заключается в том, что в среднем только половина организаций имеет в своих командах чемпиона по AppSec. Еще одним свидетельством разрыва в безопасности между командами является то, что даже когда профессионалы по безопасности говорят, что он есть, разработчики не всегда соглашаются, согласно отчету, озаглавленному «WhiteSource DevSecOps Insights, безопасность против разработчиков: битва DevSecOps». ] «Если разработчики чувствуют, что пренебрегают безопасностью для соблюдения графика, что-то в процессе DevSecOps нарушается», — предупреждают составители отчета.
WhiteSource опросил более 560 специалистов по безопасности приложений и разработчиков программного обеспечения. Эти результаты показывают, что, хотя большинство профессионалов в области безопасности и разработчиков считают, что их организации находятся в процессе внедрения DevSecOps, большинству организаций еще предстоит проделать путь, по словам Рами Сасса, генерального директора и соучредителя WhiteSource. Он отметил, что пройденное расстояние особенно велико, когда дело доходит до разрушения разобщенности, разделяющей разработки в группах безопасности.
«Полная зрелость DevSecOps требует, чтобы организации внедряли DevSecOps повсеместно. Процессы, инструменты и культура должны развиваться, чтобы разрушить традиционные разрозненные структуры и гарантировать, что все команды разделяют ответственность как за безопасность, так и за гибкость», — сказал Сасс.
Другие ключевые результаты
Цель отчета WhiteSource — лучше понять уровень зрелости DevSecOps внутри организаций. Многие результаты показывают, что процесс DevSecOps пока незрелый и небезопасный.
В отчете было обнаружено, что для соблюдения коротких циклов развертывания 73 процента специалистов по безопасности и разработчиков чувствуют себя вынужденными пойти на компромисс в отношении безопасности. Кроме того, компании приобретали инструменты AppSec, чтобы «поставить галочку», игнорируя потребности и процессы разработчиков. В результате инструменты покупаются, но не используются.
DevSecOps может быть не более чем модным словом для организаций.
Серьезная проблема «пробелов в знаниях и навыках AppSec» существует во многих группах организаций. Отчет показал, что организации в значительной степени игнорируют этот пробел в знаниях.
Главная задача специалистов по безопасности — это расстановка приоритетов, по крайней мере, теоретически. Но на практике, согласно отчету, организациям не хватает стандартизированных процессов для оптимизации приоритезации уязвимостей.
Глубокое погружение в культуру DevOps
TechNewsWorld обсудил с Дэвидом Хабуша, вице-президентом по продукту WhiteSource, состояние DevSecOps в свете отчета.
TechNewsWorld: Чем изолированная культура отличается от других культур программного обеспечения?
Дэвид Хабуша: Разрозненный подход является наследием методологии водопада. В изолированной культуре критические элементы жизненного цикла разработки программного обеспечения, такие как безопасность, рассматриваются как специализированная область, находящаяся в ведении специальной группы и рассматриваемая на одном конкретном этапе разработки. Когда дело дошло до безопасности, этим занялись ближе к концу жизненного цикла разработки программного обеспечения.
Термин «водопадная методология» часто применяется к процессу разработки программного обеспечения. Он следует линейному подходу к управлению проектом, при котором требования заинтересованных сторон и клиентов собираются в начале проекта. Затем группа разработчиков применяет последовательный план проекта для удовлетворения этих требований.
Большинство организаций сегодня понимают, что безопасность должна рассматриваться на протяжении всего конвейера DevOps, начиная с самых ранних стадий разработки. Для этого необходимо разделить разрозненность и разделить ответственность за безопасность приложений между командами. Таким образом, проблемы безопасности не решаются только на поздних стадиях разработки, когда их устранение обходится дороже и часто задерживается выпуск.
TNW: Какие факторы способствуют разобщенной культуре?
Хабуша: Изолированная культура — это устойчивый унаследованный унаследованный подход. Хотя большинство организаций понимают, что необходимо разрушить стены между разработкой и безопасностью, многие изо всех сил пытаются реализовать это понимание на практике.
Есть много факторов, которые затрудняют организацию полного отказа от изолированной культуры. Для того, чтобы организации успешно сдвинули вопросы безопасности и помогли командам разработчиков разделить ответственность за безопасность, им необходимо изменить культуру организации, обновить свои процессы и внедрить автоматизированные инструменты.
В настоящее время разработчикам по-прежнему не хватает знаний и навыков AppSec, которые им необходимы для обеспечения безопасности. Им также нужны инструменты безопасности, которые интегрируются в их процессы и среды разработки, чтобы они могли легко обнаруживать, расставлять приоритеты и исправлять проблемы безопасности, не замедляя разработку.
Отсутствие связи между командами также является огромным препятствием для совместной работы групп безопасности и разработки, разделения ответственности и владения безопасностью приложений на протяжении всего конвейера DevOps.
TNW: Какие шаги необходимо предпринять для достижения гибких, зрелых практик DevSecOps?
Хабуша: Нет волшебного ключа к достижению зрелости DevSecOps. Это требует множества изменений и корректировок традиционных подходов к жизненному циклу разработки программного обеспечения. Это включает в себя обновление нашего отношения, набора навыков, процессов, инструментов, которые мы используем, способов общения, структуры наших команд и т. Д. Зрелость DevSecOps — это марафон, а не гонка.
Одним из основных шагов, которые помогают достичь зрелости DevSecOps, является преодоление пробела в знаниях о безопасности приложений путем предоставления разработчикам непрерывного обучения AppSec, включая безопасное кодирование. Это отличный способ решить проблему AppSec с самого начала, обучая разработчиков тому, как избежать проблем с безопасностью приложений на самых ранних этапах кодирования.
Назначение чемпионов AppSec в команды разработчиков — еще одна разумная и эффективная стратегия преодоления разрыва между командами безопасности и разработки. Это расширяет знания и навыки разработчиков в области AppSec и открывает возможности для общения между командами.
Третий важный шаг — интеграция инструментов безопасности AppSec в конвейер DevOps. При выборе этих инструментов крайне важно, чтобы лица, принимающие решения, приобрели инструменты, которые легко интегрируются в среду разработчиков и которые разработчикам будет легко принять.
TNW: Как это создает ощущение совместной собственности между конкурирующими факторами среди команд?
Хабуша: Чтобы культивировать культуру совместной собственности над безопасности, организациям важно создать комплексную политику безопасности приложений, которую должны поддерживать все команды. Это помогает всем командам разделять чувство ответственности за безопасность приложений.
TNW: Как это влияет на разработку DevOps?
Хабуша: Когда организации инвестируют в шаги к зрелости DevSecOps, безопасность интегрируется в конвейер DevOps с самых ранних стадий развития. Это означает, что группы безопасности и разработки работают вместе, чтобы решать проблемы безопасности с самого начала.
Интеграция безопасности в разработку DevOps означает предоставление разработчикам всей необходимой им поддержки для решения задач безопасности приложений без замедления разработки. Сюда входят автоматизированные инструменты безопасности, которые помогают разработчикам обеспечивать безопасность на протяжении всего процесса разработки, иметь общую политику безопасности приложений для всех команд, а также обеспечивать и поощрять открытое общение между группами безопасности и разработки.
TNW: Каковы наиболее важные выводы из последнего отчета WhiteSource DevSecOps Insights Report?
Хабуша: Самый важный вывод из нашего отчета DevSecOps Insights: Хотя большинство организаций считают, что они находятся в процессе достижения зрелости DevSecOps, им еще предстоит пройти путь. Это очевидно из того факта, что большинство специалистов по безопасности и разработчиков — 73 процента из 560 с лишним профессионалов и разработчиков AppSec, которых мы опрошены, чувствуют себя вынужденными пойти на компромисс в отношении безопасности. Когда мы смотрим на данные из отчета, легко увидеть множество препятствий на пути внедрения DevSecOps.
TNW: Какую роль могут сыграть специализированные инструменты безопасности в преодолении трений между командами, связанными с улучшением безопасности?
Хабуша: Мы обнаружили, что профессионалов в области безопасности практически не существует. при выборе инструментов AppSec учитывайте принятие разработчиками. Это объясняет другую реальность, которую мы обнаружили: многие из приобретенных инструментов AppSec не используются разработчиками. Когда инструменты DevSecOps приобретаются только для того, чтобы «поставить галочку», а не поощрять внедрение разработчиками, безопасность не может быть успешно интегрирована на протяжении всей разработки.
TNW: Могут ли автоматизированные инструменты DevOps сосуществовать с повышенным вниманием к надежной безопасности программного обеспечения?
Хабуша: Лучшие автоматизированные инструменты DevOps предлагают решения безопасности, чтобы команды может легко встроить безопасность в разработку, начиная с самых ранних этапов конвейера DevOps. Это новое поколение инструментов DevSecOps.
Инструменты DevSecOps могут быть легко интегрированы в среду разработки, чтобы они могли легко обеспечивать безопасность на протяжении всего процесса разработки. Сегодняшние инструменты DevSecOps могут пойти гораздо дальше, чем обнаружение уязвимостей.
Вместо того, чтобы просто предоставить командам безопасности и разработки огромный список уязвимостей системы безопасности, которые им необходимо устранить, передовые инструменты DevSecOps интегрируются в конвейер DevOps и предлагают разработчикам и технологии определения приоритетов безопасности.
Автоматическая расстановка приоритетов помогает командам избежать трений и гарантирует, что они в первую очередь решают наиболее важные проблемы, чтобы не тратить драгоценное время на обсуждение того, что исправить в первую очередь, или на решение проблем, которые не влияют на их проекты.
В дополнение к автоматической расстановке приоритетов расширенные инструменты DevSecOps также могут предлагать действенные аналитические данные по исправлению и автоматическому обновлению версий, дополнительно помогая организациям гарантировать, что безопасность не замедлит разработку.
TNW: Какие еще препятствия необходимо преодолеть командам DevOps?
Хабуша: Дополнительным препятствием для DevSecOps, которое мы обнаружили, было то, что большинство разработчиков не понимают Обучение AppSec, в котором они нуждаются, даже несмотря на то, что специалисты по безопасности заявили, что одной из основных проблем, с которыми они сталкиваются, является нехватка квалифицированного персонала AppSec.
TNW: Почему для организаций важно иметь определенный и согласованный процесс приоритизации уязвимостей?
Хабуша: Приоритизация уязвимостей является главной проблемой для профессионалы в области безопасности. У большинства групп разработки и безопасности до сих пор отсутствует стандартизированный процесс. Команды часто полагаются на специальные методы или отдельные руководства.
Отсутствие согласованного процесса приоритезации уязвимостей задерживает исправление уязвимостей системы безопасности. Это также вызывает дальнейшие трения между службами безопасности и разработчиками.
TNW: Почему безопасность программного обеспечения по-прежнему считается вторичной по отношению к скорости разработки?
Хабуша: Большинство организаций понимают необходимость инвестировать в безопасность приложений. К сожалению, многие до сих пор считают, что интеграция безопасности в конвейер DevOps замедлит развитие.
Это не обязательно. Одна из основных причин этого неправильного восприятия — способ устранения уязвимостей безопасности с помощью водопадной методологии. Затем, после разработки, группа безопасности приходила, анализировала и тестировала проект и возвращалась к разработке с длинным списком проблем безопасности, которые необходимо было решить перед выпуском продукта.
Этот процесс обнаружения уязвимостей безопасности на поздних этапах жизненного цикла разработки программного обеспечения был очень дорогостоящим и замедлял разработку. Подход DevSecOps предлагает более быстрый, дешевый, безопасный и универсальный более эффективный способ обеспечения безопасности на протяжении всей разработки, при этом сохраняя все более короткие циклы выпуска. 
