Внедрить DevSecOps и не сойти с ума: команды с разными процессами, неоднородный стек и ограниченный бюджет
Внедрение DevSecOps становится серьезным конкурентным преимуществом, доказывающим заботу бренда о клиентах и партнерах. Мы это знаем, вы это знаете, но когда доходит до дела — процесс рассыпается.
В этой статье разберём:
- Почему DevSecOps вызывает отторжение у разработчиков и как с ними договориться
- Как сделать так, чтобы безопасники не тормозили дату релиза
- Как встроить компоненты DevsecOps в процесс разработки - поэтапно.
Что такое DevSecOps?
Понятие складывается их трех элементов: Dev (Development) — разработка ПО, Sec (Security) — безопасность продукта, Ops (Operations) — операции с создаваемым программным обеспечением. По сути эта методология — новый этап эволюции подхода DevOps, подразумевающего тесное взаимодействие разработчиков и специалистов по информационной безопасности.
В рамках «стандартного» подхода офицеры безопасности тоже участвуют в разработке, но вступают в игру только перед релизом продукта. Подход DevSecOps предполагает интеграцию безопасности на самом старте проекта.
Пример из жизни: вы же не будете клеить обои до того, как заменили проводку в помещении? Так и с приложением — нужно подключаться в самом начале, чтобы не было мучительно больно потом.
Что делать, чтобы DevSecOps не тормозил процесс
Частая история: разработчики запилили фичу и готовы выкатывать. Приходит безопасник и говорит, что нужна проверка и тут начинается: отправка на аудит, неделя ожидания, найдены “проблемы”, которые никто не объяснил.Что получаем в итоге: time-to-market страдает, команда раздражается, безопасность воспринимается как враг.
Что делать?
- Интегрировать проверки безопасности в CI/CD.
- Использовать автоматические сканеры: SAST, DAST, SCA.
- Создать конвейер, в котором безопасность не блокирует, а сопровождает.
ПРИГЛАШАЕМ НА ВЕБИНАР ПО БЕЗОПАСНОЙ РАЗРАБОТКЕ
📅 Дата: 23 апреля 2025 года, 10:00 (МСК)
🎓 Формат: онлайн, участие бесплатное
Встреча с экспертами Positive Technologies, Axoft, Максофт: — Обсудим реальные кейсы, покажем, как адаптировать подход под команду и бизнес-задачи.
Регистрация
Какие инструменты использовать
Под инструментами понимают алгоритмы и технологии, позволяющие работать над безопасностью и качеством программного обеспечения. Например, в цикле безопасной разработки фигурируют несколько видов анализа кода, которые необходимы для обеспечения безопасности ПО. Обсудим особенности, преимущества и недостатки некоторых из них.
SAST
SAST— статический анализ кода (Static Application Security Testing), выполняемый без запуска приложения. Такую проверку можно применять как для разрабатываемого ПО, так и для готового.
Статический анализ — одна из ключевых практик безопасности ПО. Его иначе называют анализом «белого ящика», поскольку он подразумевает доступ к исходному коду проекта и осведомленность о компонентах проверяемого приложения.
К преимуществам статического анализа можно отнести:
- Покрытие всего кода, что значительно повышает шансы обнаружить все проблемы и уязвимости, в том числе пропущенные в ходе других видов анализа.
- Отсутствие необходимости в больших вычислительных мощностях и отдельных виртуальных средах. Благодаря такой особенности SAST-сканирования могут проводиться даже в небольших компаниях.
- Беспроблемную интеграцию в процесс разработки ПО. Чтобы провести анализ, не нужно приостанавливать рабочие процессы и вносить изменения в ИТ-инфраструктуру.
У статического тестирования есть один весомый недостаток — ложные срабатывания (обычно ложноположительные). То есть автоматический анализатор дает сигнал о потенциальных уязвимостях, а по факту проблем нет. В результате приходится вручную проверять информацию, поэтому тестирование затягивается.
Проблему с ложными срабатываниями легко решить с помощью правильно выбранных SAST-анализаторов.
DAST
DAST — динамическое тестирование (Dynamic Application Security Testing), в рамках которого имитируются атаки на готовое работающее программное обеспечение с целью проэксплуатировать имеющиеся уязвимости. Такая проверка позволяет обнаружить проблемы безопасности раньше, чем продукт уйдет в эксплуатацию.
DAST по факту является тестированием по методу «черного ящика». В отличие от SAST оно не требует знаний о внутреннем устройстве анализируемого ПО, а доступ к исходному коду приложения не обязателен.
Преимущества сканирования с помощью DAST:
- Возможность увидеть, как программное обеспечение ведет себя в рабочей среде.
- Подсвечивание проблем, которые не были выявлены ранее или вообще не обсуждались командой как вероятные.
- Обнаружение уязвимостей, которые сложно увидеть в процессе других видов тестирования.
Теперь о минусах DAST. Во-первых, в ходе такого нет возможности досконально проанализировать внутреннюю структуру программного обеспечения и обнаружить ошибки программирования, то есть покрытие кода неполное. Во-вторых, без результатов SAST-анализа сложно оценить объективность динамического тестирования, поэтому желательно комбинировать эти методы анализа кода.
SCA
SCA-анализ, или анализ состава ПО, – проверка приложений с целью нахождения фрагментов с открытым исходным кодом (Open Source Software) и их дальнейшей проверки на уязвимости и недекларированные возможности.
Этот вид анализа важен, поскольку он помогает проверить безопасность используемых сторонних компонентов, которые применяются в большинстве разрабатываемых приложений во всех компаниях, а значит, несут потенциальную угрозу для компаний, которые их используют.
Как правильно использовать инструментарий
Вы запускаете статический анализатор кода (например, SonarQube или Checkmarx). И получаете тысячи уязвимостей, из них 30% — ложные срабатывания, 50% — малозначимые, 20% — критические, но никто не знает, как их чинить.
Что происходит? Разработчики теряются, никто не берётся за разбор, репорт прикладывается к документации — и забывается.
Проблема не в инструментах. Проблема в отсутствии приоритезации.
Настройте базовый уровень и фильтры по критичности
Интегрировать отчёты в трекер задач (Jira, YouTrack)
Проводить триаж уязвимостей: вместе — разработчики + ИБ
Вводить правила: критичные — исправляем сразу, остальное — в план
Также стоит обучить команду XSS, CSRF, SQLi, как не допускать этих уязвимостей в коде и как фиксить их быстро.
Не делайте DevSecOps формальностью
“У нас DevSecOps” — говорит команда. А на деле: один сканер в CI/CD, формальная “галочка” в документации, архитектура без учёта рисков.
Разработчики трудятся, но знакомы с DevSecOps номинально.
Что делать?
📌 Встраивать безопасность на этапе проектирования
📌 Проводить моделирование угроз с командой
📌 Создать security champions внутри разработки
📌 И главное — строить культуру общей ответственности
Когда каждый в команде понимает, что безопасность — это его зона ответственности, а не проблема других, DevSecOps действительно начинает работать.
✅ Что делать, чтобы DevSecOps работал
🔹 Перестать воспринимать ИБ как «последний шаг»🔹 Внедрить автоматические инструменты, а не ручные блокировки🔹 Объяснить команде: безопасность = качество🔹 Настроить процесс, а не просто установить сканер🔹 Поддерживать безопасность не отчётами, а действиями
Узнайте больше о DevSecOps от экспертов сферы
Этот подход не только про безопасность, но и в целом про оптимизацию работы над приложениями. Что он дает:
- Улучшение коммуникации между разработчиками и безопасниками.
- Обнаружение уязвимостей в создаваемом продукте до его развертывания.
- Сокращение срока выхода на рынок.
- Соответствие готового ПО нормативным требованиям.
- Формирование культуры информационной безопасности в команде.
Чтобы перейти от разговоров о DevSecOps к устойчивой практике, важно увидеть, как это работает в живых проектах. Без надуманных сложностей и без формального подхода. Приглашаем на бесплатный вебинар, где по делу разберём, как встроить безопасность в процессы разработки так, чтобы она поддерживала команду, а не мешала ей.
📅 Дата: 23 апреля 2025 года, 10:00 (МСК) 🎓 Формат: онлайн, участие бесплатное
Этот разговор будет полезен тем, кто отвечает за безопасность, управляет продуктами или командами, кто ищет способы выстроить устойчивые и понятные процессы без перегибов и формальностей.
В вебинаре участвуют: — Алексей Федулаев, руководитель направления Cloud Native Security — Артём Пузанков, руководитель группы внедрения практик безопасной разработки, Positive Technologies — Денис Фокин, руководитель отдела консалтинга и инженерной поддержки направления ИБ, компания Axoft
Обсудим реальные кейсы, покажем, как адаптировать подход под команду и бизнес-задачи. Если вы в поиске работающего DevSecOps — подключайтесь.
🔗 Региструйтесь, участие бесплатное.