Гитлаб спонсировал этот пост.
Разрыв между командами безопасности и инженеров уже давно стал точкой напряженности в командах DevSecops. Недавние исследования Gitlab выявили несколько вопросов, связанных с организационной культурой, которые могли бы предотвратить более глубокое согласование между инженерами и группами безопасности.
Большинство респондентов (58%) заявили, что им трудно получить разработку для определения приоритетов восстановления уязвимостей, и 52% сообщили, что красная лента часто замедляет свои усилия по быстрому исправлению уязвимостей. Кроме того, респонденты безопасности указали на несколько конкретных разочарований, связанных с их работой, включая трудности с пониманием результатов безопасности, чрезмерные ложные позитивы и тестирование, происходящие в конце процесса разработки программного обеспечения.
Devsecops обещает лучшую интеграцию между инженерией и безопасностью, но ясно, что разочарование и смещение сохраняются. Это потому, что эти проблемы являются симптомами более широкой проблемы с тем, как организации рассматривают безопасность, а также как команды работают вместе и выделяют время для безопасности.
Свободный от бесконечного цикла уязвимости
Сканирование уязвимости поверхности всех потенциальных уязвимостей; Тем не менее, то, что пакет программного обеспечения имеет общую уязвимость или экспозицию (CVE), не означает, что он доступен или эксплуатируется. Команды безопасности и разработчики по -прежнему уступают и фильтруют результаты уязвимости, которые выросли в геометрической прогрессии за эти годы с момента аутентифицированного сканирования уязвимости стали нормой.
Движение к аутентифицированному сканированию во многих отношениях повысило эффективность программ безопасности, но также поставило разработчиков на бесконечное колесо хомяка, чтобы исправить вещи, которые не имеют значения. Когда команды тратят свои усилия на участки, которые не обращаются к эксплуатационной уязвимости, они отвлекаются от более важных задач, таких как исправление уязвимых и эксплуатационных недостатков. Это источник большей части подразделения между командами безопасности и инженеров сегодня.
Итак, как организации могут решить основную причину этих проблем и способствовать лучшей интеграции между инженерией и безопасностью? Вот три способа предотвратить общие разочарования в безопасности на источнике.
Сосредоточьтесь на действенных, высоких сигналах
Чрезмерные ложные срабатывания были вторым по величине разочарованием, выявленным респондентами безопасности в опросе Гитлаба. Ложные позитивы, безусловно, являются проблемой, но они часто замаскировали проблему управления уязвимостью.
Если организация видит много ложных срабатываний, это может быть признаком того, что они не сделали все возможное, чтобы их выводы безопасности были высокой верностью. Организации должны сузить центр своих усилий по безопасности до того, что имеет значение. Это означает, что традиционные решения для обеспечения безопасности приложений (SAST), вероятно, недостаточны. SAST является мощным инструментом, но он теряет большую часть своей ценности, если результаты неуправляемы или не имеют соответствующего контекста. Чтобы SAST был наиболее эффективным, его необходимо бесплатно использовать с другими инструментами безопасности и разработки и быть доступными для разработчиков.
Опросить наборы инструментов и уменьшить потенциальную поверхность атаки
Сосредоточение внимания на том, что имеет значение, не только применяется к тестированию безопасности. Это должно начинаться с того, как организация создает программное обеспечение в первую очередь.
Хотя ИИ обещает помочь упростить процессы разработки программного обеспечения, многие организации по -прежнему имеют долгий путь вперед. Фактически, респонденты, которые используют ИИ, были значительно чаще, чем те, которые не используют ИИ, чтобы захотеть консолидировать свой набор инструментов, что позволяет предположить, что пролиферация различных точечных решений, работающих с различными моделями ИИ
Постоянно растущая сложность технических стеков организаций является основным участником разочарований в области безопасности. Некоторая сложность неизбежно при создании больших многогранных программных систем. Тем не менее, организации должны предпринять шаги, чтобы избежать сложности, возникающих в результате неоптимальных проектных решений, таких как сложный кодекс и избыточные зависимости. Эта ненужная сложность создает большую поверхность атаки и генерирует больше результатов сканирования безопасности, чтобы команды могли разобраться, расставлять приоритеты и адрес.
Организации должны подходить к разработке через призму минимизации программного обеспечения, то есть преднамеренное относительно инструментов, которые они используют и что они решают встроить в свои кодовые базы. Это поможет минимизировать зависимости, улучшить безопасность цепочки поставок программного обеспечения, уменьшить шум сканера и облегчить бремя для разработчиков для решения некритических проблем.
Подход «мощеных дорог»
Тестирование безопасности, происходящее слишком поздно в жизненном цикле разработки программного обеспечения, было еще одним из лучших разочарований, выявленных нашими респондентами. Команды могут быть разочарованы, когда они хотят что -то отправить, и это откладывается, потому что уязвимость обнаруживается поздно, но во многих случаях, возможно, невозможно было обнаружить эту уязвимость ранее. Однако, что возможно, является выполнением легко развертываемой, многократных компонентов безопасности, ограничивая переменные и потенциальные уязвимости.
Команды могут избежать сюрпризов на поздней стадии, используя тестируемые и гарантированные модели проектирования на основе повторяемых вариантов использования: подхода «мощеных дорог». Мощная дорога-это рекомендуемый путь, в том числе кураторский набор инструментов, процессов и компонентов, которые команды могут следовать, чтобы более эффективно создавать безопасные приложения-например, с использованием GITOPS для версии и развертывания хорошо продуманной и протестированной инфраструктуры в качестве кода (IAC), которые развертывают в масштабе для всех рабочих нагрузок.
Принятие мощеных дорог потенциально устраняет некоторую гибкость, но в конечном итоге снижает оперативное бремя и переделку в инженерных командах и повышает безопасность. Это должно быть совместным усилием безопасности и развития. Безопасность может помочь в разработке мощеных дорог, но инженерия должна быть вовлечена для работы и поддержания их в рамках кодовой базы.
Безопасность: домен, а не отдел
Мы уже рассматриваем безопасность как практический переход на инженерные команды, и мы можем ожидать, что границы между ними будут продолжать размыться. Тем не менее, с помощью быстрого внедрения ИИ и соответствующего ускорения разработки программного обеспечения — 66% наших респондентов заявили, что они выпускают программное обеспечение в два раза быстрее или быстрее, чем в прошлом году — для организаций будет иметь решающее значение для создания систем и структур, которые оптимизируют для наибольшей выгоды безопасности.
Вот почему идея культурного разрыва между развитием и безопасностью не является всей историей. Содействие культуре сотрудничества имеет важное значение, но команды безопасности и инженерии также должны работать вместе, чтобы переосмыслить основополагающие аспекты разработки программного обеспечения, такие как оптимизация существующих кодовых баз и создание масштабируемых инженерных решений, которые могут быть беспрепятственно приняты техническими группами по всей организации.
Gitlab является самой полной платформой Devsecops с AI Devsecops для инноваций в программном обеспечении. Gitlab позволяет организациям повысить производительность разработчиков, повысить эффективность эксплуатации, снизить риск безопасности и соответствия, а также ускорить цифровые преобразования. Узнайте больше последних из Gitlab Trending Stories YouTube.com/ThenewStack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Джош Лемос является главным информационным безопасностью в Gitlab Inc., где он приносит 20 -летний опыт ведущего команд информационной безопасности на свою роль. Джош возглавил команды безопасности в многочисленных технологических компаниях с высоким ростом, включая ServiceNow, Cylance и совсем недавно … Подробнее от Josh Lemos
