Встраивая безопасность непосредственно в общие процессы и операции, команды разработчиков могут масштабироваться, чтобы удовлетворять свои потребности сегодня и в будущем, пишет на портале The New Stack Джош Лемос, директор по информационной безопасности GitLab.

Уже более десяти лет DevSecOps обещает повысить уровень безопасности за счет устранения разделения между командами разработки (Dev), безопасности (Sec) и эксплуатации (Ops). При правильном подходе этот подход интегрирует безопасность в весь жизненный цикл разработки, повышая скорость, снижая затраты и уменьшая количество инцидентов безопасности.

Однако организации часто думают, что они «делают DevSecOps», в то время как они просто создали новые команды (Dev, Sec и Ops) и прикрутили новые инструменты безопасности, которые не позволяют достичь интегрированного, управляемого процесса. Целый перечень инструментов безопасности (SAST, DAST, SCA, CSPM) порождает горы обнаруженных уязвимостей, для управления которыми требуются целые команды безопасности. Аналогичным образом разработчикам приходится просеивать удручающее количество шума.

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

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

Почему защищенность цепочки поставок ПО имеет значение

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

Шаблонный, повторяемый, процессный подход, основанный на сотрудничестве между платформенными командами и командами безопасности, приводит к фундаментальному изменению отношения команд к своим целям. Они переходят от концепции безопасности (security), которая обещает состояние, свободное от опасности или угрозы, к защищенности (safety), которая фокусируется на создании систем, защищенных от опасности и не способных ее создавать. Этот переход делает акцент на проактивном снижении рисков за счет продуманных, многократно используемых шаблонов проектирования и реализации, а не на реактивном снижении угроз.

Строительные блоки защиты цепочки поставок

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

  • Инфраструктурные ограждения. Практика платформенного инжиниринга обеспечивает стандартизированные шаблоны для развертывания безопасных компонентов инфраструктуры, позволяя разработчикам сосредоточиться на создании приложений. Эти шаблоны обеспечивают соблюдение мер безопасности, таких как шифрование и протоколирование, предотвращают распространенные ошибки конфигурации облака и обеспечивают наблюдаемость безопасности.
  • Функции языков и фреймворков. Современные языки программирования предлагают встроенные функции безопасности, которые при правильном использовании помогают уменьшить уязвимости. Включение таких функций, как автоматическое управление памятью и строгая проверка типов, может предотвратить многие потенциальные проблемы безопасности.
  • Сокращение трудозатрат за счет генерации и рефакторинга кода. Автоматизированные инструменты могут выявлять уязвимые библиотеки и зависимости, что облегчает устранение проблем с помощью шаблонов и минимальных базовых образов. Используя искусственный интеллект для анализа и рефакторинга кода, разработчики могут устранять ненужные зависимости, сокращая поверхность атак и нагрузку на обслуживание.
  • Абстрагирование функций безопасности. Сторонние прокси-серверы безопасности выполняют аутентификацию и авторизацию в приложениях, обеспечивая взаимодействие только авторизованных служб. Плоскость управления сервисной сетки может использоваться для централизованного управления контролем доступа, что снижает сложность кода приложений и обеспечивает постоянное соблюдение безопасности.
  • Управление программным обеспечением. Такие правила, как защита веток и двойное одобрение, могут быть реализованы программно, чтобы обеспечить проверку изменений несколькими членами команды перед слиянием кода. Эти политики, заданные в машиночитаемых форматах, должны соблюдаться платформой CI для поддержания согласованной безопасности в разных проектах.
  • Человеческий фактор. Успешное внедрение DevSecOps требует согласования стимулов и интеграции безопасности в рабочий процесс разработки. Развивая сотрудничество с помощью обучения, общих метрик и регулярных межкомандных встреч, команды могут вместе снизить операционную нагрузку и повысить отказоустойчивость ПО.

Внедрение стратегических инструментов

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

Средства обеспечения безопасности также должны быть стратегически интегрированы в конвейеры CI для использования многоуровневого подхода к сканированию, который позволяет сбалансировать скорость и аккуратность. Высокоточные и быстро выполняемые проверки, такие как обнаружение секретов, анализ состава ПО (SCA) и специальные правила для антипаттернов безопасности, должны выполняться при каждом коммите и обеспечиваться системой CI.

Дорожная карта будущего успеха, основанная на процессах

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

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