I would like to view this page in
DevSecOps — методология разработки ПО, где на каждом этапе работы учитываются требования безопасности. В результате уязвимости устраняются в самом начале и не замедляют CI/CD-пайплайн.
Методология DevSecOps подчеркивает, что важно внедрять тестирование безопасности и методы ее обеспечения на каждом этапе разработки ПО. Раннее внедрение безопасности (сдвиг влево) позволяет гарантировать, что быстрая доставка не ведет к появлению уязвимостей в коде.
DevSecOps — подход к разработке ПО на основе методологии DevOps. DevOps объединяет разработку (development) и эксплуатацию (operations), а DevSecOps добавляет к этому безопасность (security). Тем самым подчеркивается, что важно учитывать требования безопасности на каждом этапе разработки ПО.
Задача DevSecOps — дать командам возможность быстрее и эффективнее доставлять пользователям ПО, одновременно не допуская появления уязвимостей в кодовой базе. Такая стратегия защищает от кибератак и вашу организацию, и ваших пользователей.
Методология DevOps нацелена на ускорение доставки ПО при одновременном повышении качества и сокращении числа багов. В основе DevOps лежат принципы Agile-разработки. Методология была создана для решения проблем, возникающих при традиционном каскадном подходе к разработке и доставке ПО.
Вместо линейного процесса проектирования, разработки, интеграции, тестирования и выпуска ПО, который может занять несколько лет, DevOps предлагает командам перейти на частые и короткие циклы работы. Для этого DevOps предлагает использовать устойчивые автоматизированные CI/CD-процессы, которые ускоряют доставку и обеспечивают быструю обратную связь, создавая эффективный цикл непрерывных улучшений.
В чем разница между DevSecOps и DevOps? Методология DevOps вовсе не исключает вопросы безопасности. Однако на деле получалось, что DevOps объединяет именно команды разработчиков и операционистов, а команды информационной безопасности в основном оставались в стороне. Чтобы решить эту проблему, придумали DevSecOps, а также несколько его вариаций, таких как SecDevOps, DevOpsSec и Rugged DevOps.
Термин «DevSecOps» напоминает всем участникам, что вопросы безопасности должны постоянно учитываться в процесс разработки и развертывания ПО. Сюда входят:
Точно так же, как «сдвиг влево» позволяет быстрее и проще находить устранять ошибки, методы обеспечения безопасности проще внедрить и эффективнее использовать на ранних этапах процесса разработки.
Уязвимости представляют серьезную угрозу для ПО.
Уязвимости ПО — причина финансового и репутационного ущерба, а также утечек огромного количества конфиденциальной информации: от внутренних документов до персональных данных клиентов. В зависимости от применимой юрисдикции, за утечку пользовательских данных могут накладываться серьезные денежные штрафы и юридическая ответственность.
Несмотря на все это, при традиционном подходе к разработке безопасность воспринимается не как возможный актив, а как некое обременение. Аудиты безопасности, составление отчетов — все это замедляет процесс и препятствует доставке новых возможностей прямиком в руки пользователей. Однако, игнорируя важность безопасности в жизненном цикле разработки ПО, вы рискуете попасть в заголовки новостей о новой масштабной кибератаке.
В свое время эти уязвимости попали в новостные заголовки. А ведь их причины оказались довольно прозаичными. Код пишут люди, а люди делают ошибки — так и появляются уязвимости. Бывают всем известные ошибки — их проще обнаружить (правда, надо знать, где искать). Но порой ошибки бывают и новыми, возникающими в результате новой комбинации факторов.
Ситуация дополнительно усложняется тем, что практически любое ПО (и с открытым исходным кодом, и проприетарное) включает зависимости, и вы не можете быть уверенными, что сторонний код не содержит уязвимостей. Поэтому безопасность цепочки поставок не менее важна, чем безопасность вашего собственного исходного кода.
Как же включить аспекты безопасности в цикл разработки ПО? DevSecOps-подход использует те же принципы, что и для организации более быстрых и стабильных релизов: сдвиг безопасности влево, то есть решение этих вопросов на более ранних этапах и более регулярно.
На первый взгляд, сдвиг безопасности влево требует просто добавить лишний этап в CI/CD-пайплайн, чтобы подготовить ПО для тестирования и анализа в команде информационной безопасности.
Ручному тестированию безопасности, безусловно, есть место в процессе, и мы обсудим это подробнее ниже. Однако, отводя требованиям по безопасности лишь некий шаг в конце пайплайна, вы лишаетесь преимуществ быстрой и регулярной обратной связи:
Как работает метод сдвига безопасности влево на практике? Универсального решения нет, однако есть набор инструментов и техник, которые помогают включить вопросы безопасности в цикл разработки ПО.
Культура общей ответственности очень важна. Однако недостаточно просто сказать разработчикам, что теперь они все отвечают за безопасность ПО. Отслеживание новых векторов атак и разработок вредоносного ПО — это работа, на которую нужен отдельный сотрудник. Вы не можете ожидать от всех того же уровня экспертизы.
Введя в многопрофильную команду эксперта по безопасности, который поделится своими знаниями лучшими практиками, вы поможете вашим сотрудникам осознать и поддержать культуру сотрудничества с профессионалами в области безопасности.
В идеале требования безопасности необходимо учесть еще до того, как код будет написан. Безопасность должна быть отражена в пользовательских историях. Она должна обсуждаться при рассмотрении бэклога и планировании спринтов. Продумывая новую функциональность, уделите время рассмотрению тех рисков, которые она может нести, и того, как их можно снизить.
Стратегия моделирования угроз STRIDE и инструменты вроде шпаргалки OWASP помогут вам придерживаться правильного курса. Продумывая безопасность на стадии проектирования, вы не сможете учесть всего, но это уже заложит хорошее начало и будет продвигать культуру DevSecOps.
Автоматизация — центральный принцип DevOps. Она ускоряет выполнение задач и обеспечивает консистентность, а также разгружает людей, освобождая время для более творческой работы. Если вы хотите доставлять продукт пользователям регулярно и часто, важно, чтобы в вашем пайплайне были автоматизированные тесты на безопасность.
При написании юнит-тестов, а также автоматизированных интеграционных и сквозных тестов, обеспечение безопасности должно рассматриваться наравне с любой другой функциональностью. Если на этапе проектирования ваша команда включала требования по безопасности в пользовательские истории и модели угроз, добавить тесты, покрывающие эти функции, — вполне естественно.
Помимо написанных лично вами тестов есть различные инструменты тестирования, которые помогут вам быть увереннее в качестве вашего кода. Традиционные инструменты сканирования безопасности не очень хорошо подходят для автоматизированного CI/CD-пайплайна, но сейчас появились инструменты, разработанные специально для него. Они встраиваются в пайплайн и передают результаты на панель мониторинга или напрямую в баг-трекеры. Как и с любыми автоматизированными тестами, имеет смысл ввести структуру, чтобы оперативно получать результаты по разным категориям.
Инструменты статического тестирования безопасности приложений (Static Application Security Testing, SAST) выполняют статический анализ кода, проверяя его на известные уязвимости (переполнение буфера, внедрение SQL-кода и т. д.). Поскольку статический анализ кода выполняется для исходного кода, его можно запускать на ранних стадиях CI/CD-пайплайна — сразу после коммита изменений.
Инструменты SAST привязаны к языку. Некоторые из них интегрируются с IDE, обеспечивая таким образом непрерывный цикл обратной связи (прямо в ходе написания кода) и возможность в любой момент запустить тесты. Инструменты SAST указывают разработчикам на строки кода, содержащие уязвимости, — это позволяет им быстро вносить исправления. Однако бывают и ложноположительные уведомления. Чтобы результаты SAST не стали бесполезным фоновым шумом, важно уметь отключать некоторые уведомления.
Динамическое тестирование безопасности приложений (Dynamic Application Security Testing, DAST) появилось вслед за SAST. Они рассматривают приложение как черный ящик и проверяют его на предмет известных уязвимостей, таких как межсайтовый скриптинг, внедрение команд и SQL-кода небезопасная конфигурация сервера. Инструменты DAST работают с уже собранным и развернутым приложением, поэтому обычно они используются на более поздних стадиях CI/CD-пайплайна.
У киберпреступников много возможностей для атаки. Злоумышленники часто находят уязвимости в широко распространенном ПО. Такие атаки служат постоянным напоминанием о том, насколько важно обеспечить безопасность вашей цепочки поставок ПО.
Под «цепочкой поставок ПО» мы, попросту говоря, понимаем все, что связано с разработкой и доставкой вашего продукта. Для разработки ПО необходимо другое ПО — от повторно используемых компонентов и библиотек до IDE, фреймворков и инструментов сборки. Чтобы обеспечить безопасность цепочки поставок ПО, необходимо оценить безопасность того ПО, которое вы используете в процессе разработки.
Для такой оценки можно использовать инструменты анализа состава/компонентов ПО (Software Composition/Component Analysis, SCA). Инструменты SCA исследуют не только присутствующие зависимости, но и зависимости каждой зависимости (рекурсивно). Это прекрасный пример задачи, которую эффективнее выполнять при помощи компьютера, особенно если учесть, насколько часто в проект добавляются зависимости.
Инструменты SCA можно автоматически запускать в рамках CI/CD-пайплайнов. Некоторые из них также доступны в виде плагинов для IDE, обеспечивающих обратную связь буквально на лету. SCA-тестирование (так же, как статическое и динамическое) анализирует ПО лишь на предмет известных уязвимостей. Поэтому нужно следить, чтобы используемые вами инструменты регулярно пополнялись новыми уязвимостями и покрывали те области, которые имеют отношение к вашему продукту и организации.
Понятие красной команды пришло из игр про войну, где вы просили ваших соратников симулировать атаку врага, чтобы определить слабые места вашей защиты и стратегии. Тот же подход широко используется при разработке ПО, например, в виде тестирования на проникновение или этичного хакинга для обнаружения новых и неожиданных уязвимостей.
Чтобы красная команда срабатывала эффективно, она не должна участвовать в разработке тестируемой системы. Как и те, кто занимается исследовательским тестированием, тестировщики красной команды должны уметь мыслить нестандартно и использовать программное обеспечение не по назначению.
Красная команда может работать в тестовом окружении (максимально близком к продакшну) или непосредственно с системой в продакшне. Последнее предполагает, что вы можете с уверенностью положиться на поведение вашей системы в случае ошибки либо у вас очень толерантные пользователи (и руководители).
Подход DevSecOps предполагает, что ответственность за безопасность продукта несет вся команда. Поэтому не стоит разделять уязвимости и «обычные» ошибки. Любые уязвимости, которые вы обнаружили, должны попадать в тот же бэклог, что и другие проблемы, и приоритизироваться наравне с ними.
За устранение уязвимостей отвечает вся команда, не только специалист по безопасности. Это поможет всем сотрудникам лучше разбираться в вопросах безопасности и применять полученные знания и навыки при работе как с текущей кодовой базой, так и на будущих проектах.
Несмотря на все меры, которые вы ввели на предыдущих этапах цикла разработки, риск того, что хакер все же найдет слабое место в вашей системе, все равно остается. Чтобы защитить вашу организацию и пользователей, имеет смысл подключить брандмауэры и инструменты мониторинга. Инструменты самозащиты приложения во время выполнения (Runtime Application Self Protection, RASP) также обеспечат дополнительную защиту и позволят автоматически выявлять и блокировать подозрительное поведение.
Знакомим вас с дополнительными мерами, которые обеспечат более надежную защиту ваших пайплайнов сборки.
Управление релизами — это возможность координировать выполнение автоматизированных задач в нескольких системах с целью обеспечить доставку обновлений ПО пользователям.
Предварительное тестирование коммитов в TeamCity позволяет удаленно проверять новый код ДО его отправки в VCS.