Ошибка №1: Не учитывать, что DevSecOps – это рабочая культура
DevSecOps – это изменение культуры компании для включения безопасности в разработку. Хотя наличие правильных инструментов и фреймворков имеет решающее значение для успеха, главная цель (и требование) состоит в том, чтобы сделать безопасность неотъемлемой частью качества программного обеспечения. Переход к DevSecOps означает серьезные изменения в том, как все работают и сотрудничают, и компании, которые не внедряют эти изменения, скорее всего, потерпят неудачу в своих усилиях.
«DevSecOps – это культура, в которой каждый в компании отвечает за высококачественный продукт», – говорит Суха Акюз, старший менеджер по безопасности приложений в Invicti. «Некоторые компании рассматривают DevSecOps как бремя, поскольку это означает добавление множества технологий, инструментов и фреймворков без универсальных стандартов или лучших практик, которым можно было бы следовать. На самом деле, лучшие практики построения DevSecOps будут разными и уникальными для каждой организации. Именно поэтому она должна быть частью более широкой культуры, где Dev, Sec, Ops и даже другие отделы работают вместе, чтобы достичь наивысшего качества программного обеспечения во всех отношениях, включая безопасность».
Ошибка №2: Попытки централизовать DevSecOps
Если организация не признает необходимость культурных изменений как предпосылку, она может попытаться внедрить DevSecOps только с помощью структурных изменений. Специалист Invicti Дэн Мерфи объясняет: «Нередко DevSecOps пытаются «решить», назначив на эту роль команду или отдел. Однако наиболее успешные внедрения DevSecOps признают, что это скорее культура и образ мышления. Разработка, безопасность и операции объединены в единую целостную роль, в идеале интегрированную на уровне команды».
Попытки внедрить DevSecOps с помощью команды «сверху-вниз» без глубоких изменений внутри команд в конечном итоге обречены на провал или, в лучшем случае, на поверхностные результаты. Одним из примеров этого, является неудачная попытка создать специальную программу по безопасности, которая бы обучала и предоставляла полномочия человеку в каждой команде разработчиков просматривать конфиденциальный код и внедрять лучшие практики безопасности. «Слишком часто о DevSecOps говорят на словах, но разработчики продолжают писать код так, будто развертывание, обслуживание и безопасность – это проблема кого-то другого».
Ошибка №3: Построение DevSecOps без точной автоматизации
Даже при наличии правильной культуры и талантливых специалистов, добавление тестирования безопасности и исправления ошибок к высокоавтоматизированному конвейеру DevOps сработает только в том случае, если этот уровень автоматизации будет соответствовать уровню компании. «Если пытаться встроить безопасность в процесс, не инвестируя в автоматизацию, команда может вручную запускать сканирование безопасности перед выпуском, – объясняет Мерфи. «Это неизбежно создает напряжение между исправлением и отправкой, что приводит к тому, что компании сознательно выпускают уязвимый код, чтобы уложиться в установленные внешние сроки».
Помимо того, что недостаточная автоматизация и интеграция ставят под угрозу безопасность в краткосрочной перспективе, они также негативно влияют на весь процесс разработки. Без правильных инструментов, которые делают тестирование и исправление неотъемлемой частью разработки приложений, проблемы будут накапливаться без четкого способа уменьшить отставание. Это особенно опасно при попытке автоматизировать некачественные результаты, которые требуют трудоемкой ручной проверки. «Неспособность автоматизировать точное сканирование безопасности как часть конвейера CI/CD приводит к накоплению проблем по безопасности», – предупреждает Мерфи.
Ошибка №4: Отсутствие постоянного процесса DevSecOps
Безопасность приложений всегда должна быть непрерывным процессом совершенствования, как с точки зрения создания более безопасного программного обеспечения, так и с точки зрения улучшения тестирования безопасности и устранения самих уязвимостей. Это особенно актуально при попытке встроить безопасность в конвейер. Суха Акюз говорит об этом прямо: «Если компании сканируют каждые три месяца, они не занимаются DevSecOps. Им нужно постоянно отслеживать результаты и ежедневно совершенствовать свой конвейер, чтобы со временем улучшить внедрение DevSecOps».
Даже при наличии непрерывного процесса тестирования безопасности, управление уязвимостями часто отходит на второй план, что опять же приводит к накоплению проблем. «Очень важно не только найти дефекты безопасности, но и правильно с ними справиться. Одних только инструментов для этого недостаточно, поэтому важно, чтобы команда инженеров безопасности координировала запуск тестов и устранение уязвимостей на протяжении всего процесса DevSecOps. Наличие непрерывной обратной связи имеет решающее значение для предотвращения узких мест», – подчеркивает Акюз.
Ошибка №5: Отношение к DevSecOps как к прямому источнику дохода
Если все сделано правильно, DevSecOps позволяет организациям преодолеть проблемы с безопасностью, рассматривать безопасность как часть качества программного обеспечения и двигаться в направлении повышения этого качества.
Однако он позволяет создавать более безопасное и качественное программное обеспечение быстрее с теми же ресурсами, меняя культуру работы, – отмечает Суха Акюз. «Со временем можно увидеть финансовую выгоду, поскольку экономится много времени, но прямая выгода и цель DevSecOps – это улучшенная безопасность программного обеспечения как часть лучшего качества программного обеспечения в целом».
DevSecOps под любым другим названием
Нет сомнений в том, что обеспечение безопасности приложений сейчас является обязательным требованием для любой организации, которая разрабатывает собственное программное обеспечение. В условиях стремительного роста количества утечек данных и заражений вредоносным программным обеспечением, использование уязвимого программного обеспечения может стать чрезвычайно дорогим удовольствием. DevSecOps – это один из способов встроить безопасность в конвейер веб-разработки, и какую бы аббревиатуру и процесс не выбрать, важно, чтобы он непрерывно работал в организации.
«DevSecOps – это все еще очень молодой подход, который требует времени, чтобы созреть. Ни одна компания не может сказать, что знает единственно правильный способ внедрения DevSecOps. Мы можем говорить об общих рамках, но это не значит, что все будут использовать их одинаково», – заключает Суха Акюз. «Главная цель – сделать безопасность процессом непрерывного улучшения качества программного обеспечения».
