shift left security что это
СОДЕРЖАНИЕ
Вред из-за позднего тестирования
Тестирование со сдвигом влево важно, поскольку оно помогает предотвратить следующие виды вреда из-за позднего тестирования:
Типы проверки сдвига влево
Есть четыре основных способа сдвинуть тестирование на более ранний этап жизненного цикла (то есть влево по классической V-модели ). Их можно назвать традиционным тестированием сдвига влево, пошаговым тестированием сдвига влево, тестированием сдвига влево Agile / DevOps и тестированием сдвига влево на основе моделей.
Традиционное тестирование сдвига влево
Как показано на следующем рисунке, традиционный shift-left смещает акцент тестирования ниже (и, следовательно, немного влево) с правой стороны классической модели V. Вместо того чтобы делать упор на приемку и тестирование на уровне системы (например, тестирование графического интерфейса пользователя с инструментами записи и воспроизведения), традиционный сдвиг влево концентрируется на модульном тестировании и тестировании интеграции (например, с использованием тестирования API и современных инструментов тестирования). Переход к традиционному тестированию с переключением влево в основном завершен.
Традиционное тестирование сдвига влево
Инкрементальный сдвиг влево
Как показано на следующем рисунке, многие проекты, разрабатывающие большие и сложные программно-зависимые системы, разбивают разработку на небольшое количество приращений (Vs), имеющих соответственно меньшую продолжительность. Сдвиг влево, показанный пунктирными красными стрелками, происходит из-за того, что части типов тестирования одиночной большой V-модели с водопадом (показаны серым) смещены влево, чтобы стать приращениями соответствующих типов тестирования в меньших инкрементных V-моделях. Когда каждое приращение также является доставкой заказчику и операциям, то при постепенном сдвиге влево тестирование сдвигает влево как тестирование разработки, так и эксплуатационное тестирование. Постепенное тестирование с левым переключением популярно при разработке больших сложных систем, особенно тех, которые включают значительное количество оборудования. Как и в случае с традиционным сдвигом влево, переход к постепенному сдвигу влево также в основном завершен.
Инкрементальный сдвиг влево
Тестирование влево / вправо Agile / DevOps
Как показано на следующем рисунке, проекты Agile и DevOps имеют множество кратковременных V (спринтов) вместо одного или небольшого количества V, как в двух предыдущих примерах тестирования сдвига влево. Эти маленькие буквы V также могут быть изменены, если один или несколько ранних спринтов используются для блокировки основных требований и архитектуры или если выполняется разработка, ориентированная на тестирование и управляемая тестированием (TDD). Сдвиг влево происходит потому, что типы тестирования с правой стороны самого раннего из этих крошечных V находятся слева от соответствующих типов тестирования с правой стороны от большей V, которую они заменяют. Хотя следующий рисунок выглядит удивительно одинаковым для Agile и DevOps, Agile-тестирование обычно ограничивается тестированием разработки и не включает в себя эксплуатационное тестирование, которое происходит после ввода системы в эксплуатацию. Переход к Agile / DevOps-тестированию с левым переключением в настоящее время популярен и продолжается.
Тестирование влево / вправо Agile / DevOps
Тестирование сдвига влево на основе модели
Все предыдущие формы были сосредоточены на тестировании на ранних этапах цикла разработки. Однако все они проводят тестирование после того, как программное обеспечение существует, и стремятся выявить только дефекты реализации.
Тестирование на основе моделей перемещает тестирование в левую часть V, проверяя требования, архитектуру и модели проектирования. При таком переходе тестирование начинается практически сразу, вместо того, чтобы ждать долгое время (традиционное тестирование), среднее время (инкрементное тестирование) или короткое время (Agile / DevOps), чтобы программное обеспечение стало доступным справа от Vs. Эта тенденция только начинается.
10 шагов для начала успешной работы с тестированием в режиме Shift Left
“Ошибки обходятся дешевле, пока они “молоды”.”
Это слова популярного эксперта – Лари Смита, в отношении к концепту Shift Left тестирования’.
Если вы работаете в сфере тестирования программного обеспечения, вы, должно быть, довольно часто слышали о терминах «shift left». С ростом популярности Agile, BDD и DevOps QA компании быстро продвигаются к тестированию Shift Left для повышения своей производительности.
Так что же такое Shift Left тестирование?
Так как же начать работать с Shift Left тестированием?
Ниже перечислены 10 шагов, которые объясняют, как начать работу с Shift Left тестированием легко и эффективно, чтобы получить все преимущества:
1. Определение и планирование жизненного цикла тестирования
Для компаний важно определить и спланировать весь жизненный цикл тестирования до начала фактического процесса разработки. Это поможет разработчикам и тестировщикам понять задачи и ожидаемые результаты проекта. Один из способов сделать это – определить требования к тестированию прямо из этапа планирования проектов и требований.
2. Интеграция процесса разработки и управления проектами с тестированием
Еще одним важным шагом для начала работы с Shift Left тестированием является интеграция всех процессов разработки, управления проектами и операций с тестированием. Это поможет понять, где и на каких этапах должно пройти тестирование. Это также поможет определить приблизительное время необходимое для завершения цикла тестирования и избежать дублирование задач в процессе реализации теста.
3. Определение стандартов качества и контроля для всех этапов SDLC
Также рекомендуется определять ожидаемые стандарты качества и осуществлять контроль качества на разных этапах SDLC. Это поможет определить, совпадает ли процесс разработки с процессом тестирования и выявить любые отклонения от ожидаемого результата. Это, в свою очередь, поможет в принятии корректирующих действий на соответствующем этапе, что в конечном итоге будет определять общее состояние проекта.
4. Планирование релизов
Также рекомендуется планировать релизы до того, как вы приступите к Shift Left тестированию. Это поможет определить возможные задержки, а также управлять ресурсами, требуемыми в каждом спринте, для достижения заранее определенных целей. Планирование релизов также поможет команде сфокусироваться и эффективно управлять циклами релиза.
5. Развертывание процесса, основанное на тест-кейсах и фреймворке
Чтобы плавно перейти к тестированию Shift Left, эксперты также предлагают создавать тест-кейсы и фреймворки, которые в целом покрывают функциональные процессы, а также рабочие шаблоны. Это делается для того, чтобы избежать ошибок во время развертывания приложений со стадии разработки. Разработка тест-кейсов и фреймворков, которые уже проверены в соответствии с функциональным и операционным процессом, помогает сократить количество тест-кейсов, которые будут созданы в будущем, а также ускорит работу SDLC.
6. Внедрение автоматизации тестирования
Чтобы получить максимальную выгоду от тестирования в режиме Shift Left, для компаний рекомендуется использовать автоматизацию тестирования. Благодаря автоматизации тестирования разработчики и тестировщики могут автоматизировать всю сборку для тестирования на всех этапах SDLC (разработка, производство, тестирование, развертывание и т. д.), которые будут способствовать лучшей интеграции между процессами, непрерывной доставке и повышению уверенности в каждом релизе.
7. Стимулирование разработчиков программировать, тестируя свой код в уме
Важно также побудить всех разработчиков приступить к работе таким образом, что каждый разработчик должен быть ответственным за обеспечение качества созданного кода. Это обеспечит надежность, а также позволит преодолеть “разрыв” между разработчиками и тестировщиками для ускорения завершения цикла тестирования.
8. Определение механизма непрерывной обратной связи
Также целесообразно определить механизм непрерывной обратной связи, чтобы тестировщики могли непрерывно предоставлять обратную связь разработчикам во время и после этапа разработки. Сообщать о дефектах и достигать желаемого качества будет намного проще, поскольку при непрерывном мониторинге и обратной связи шансы на ошибки, как правило, снижаются.
9. Поощрение тестировщиков в программировании
Также тсетировщикам рекомендуется улучшать свои знания в области программирования, так как, когда дело доходит до тестирования в спринте, знание программирования может помочь в проведении более глубокого анализа багов. Кроме того, знание программирования может оказаться полезным, если тестировщик захотят внести небольшие изменения в код, не будучи в зависимости от разработчиков.
10. Контроль качества время от времени
Регулярный контроль качества и общая проверка время от времени важны для успеха любого проекта Shift Left тестирования, поскольку она помогает в раннем обнаружении ошибок и уменьшает вероятность возникновения серьезных дефектов на этапе производства и развертывания. Более того, периодический контроль качества экономит много времени для тестировщиков, таким образом они могут сосредоточиться на качестве, а не на выявлении недостатков.
Наконец, чтобы успешно начать работу с Shift Left тестированием, всем членам команды рекомендуется хорошо выполнять именно свою задачу, так как каждый несет ответственность за высокое качество программного обеспечения.
Завершение
Тестирование в режиме Shift Left обеспечивает эффективные средства для проведения тестирования параллельно с процессами разработки, позволяя получать приложения быстрее, лучше и качественнее, улучшая взаимодействие между разработчиками и командой тестировщиков. Если процесс тестирования будет реализован должным образом, он может снизить издержки и риски сбоя приложения, обнаружив баги на раннем этапе SDLC, а также уменьшит вероятность исправления ошибок, что позволит компаниям быть более конкурентоспособными и продуктивными в 10 раз.
Наши курсы Тестирования ПО в Минске тщательно разбирают этот вопрос, поэтому рекомендуем записаться к нам прямо сейчас!
Shift left security что это
Сейчас уже многие говорят о переносе процесса тестирования на ранние стадии разработки. Как же так? Ведь всего лишь несколько недель назад тестирование двигалось вправо, ближе к концу жизненного цикла. Где вы сейчас? Не стоит размышлять о переносе тестирования на ранние либо поздние этапы, без осознания его текущей позиции.
Впрочем, вначале давайте рассмотрим преимущества раннего и позднего тестирования, с учетом того, какие потребности будут покрыты или, что будет улучшено за счет такого смещения.
Чтоб последующая информация воспринималась легче, давайте-ка добавим немного визуализации. Поскольку мы уже упоминали автомобильную коробку переключения передач, представьте ее в виде набора из пяти шестерен с разным количеством зубьев на каждой.
Классика жанра: третья передача
Увы, но это текущее положение вещей в большинстве компаний. На этапе разработки проводятся только основные и технические проверки. Есть специальная система тестирования, в которой и выполняется проверки качества продукта. Все как обычно: разработчики пишут код, а тестировщики проверяют функциональность продукта, в том числе в связке с другим софтом.
Тестируемые приложения «упакованы» таким образом, что общаются друг с другом только посредством специально разработанного функционала, как правило, с ограниченными возможностями. Несмотря на то, что подобная конфигурация довольно-таки статична, для ее поддержки и обслуживания требуется «тонна» усилий, глубокое понимание принципов работы каждого отдельного продукта, знание применяемых технологий и общих принципов рабочего процесса. Поскольку каждое приложение связано с определенной командой разработчиков (иногда даже находящихся в разных компаниях), то в случае появления «багов» вы сильно зависите от того парня, который непосредственно написал проблемный код. А что если сейчас он недоступен? Тогда у вас проблема! Выход продукта на рынок снова откладывается, поскольку нужная вам информация пока недоступна.
Однажды мы сотрудничали с банком, который использовал специальную систему, сконфигурированную таким образом, чтобы тестирование выполнялось на каждом этапе разработки. Тестовые случаи включали ситуации с воссозданными проблемами, раннее выявленными в процессе работы приложения.
Проблемные кейсы включали несогласованность тестовых данных в системах, различия между рабочими средами систем или этапов, а также некоторые ошибки, появляющиеся только при определенных конфигурациях. Большая часть времени, отведенного для тестирования, приходилось на настройку систем и выстраивания их в нужной последовательности, которая, как предполагалось, отвечала бы реальной ситуации.
Базу тестовых данных можно было просто импортировать. Она была полезной еще и потому, что позволяла легко создавать пользователей и учетные записи, подставляя «на лету» любые даты, иначе тестирование заняло бы годы. Есть ли способ получше?
Сдвиг влево: Первая передача
Почему мы привыкли к тому, что в жизненном цикле разработки тестирование проходит на поздних этапах? Ведь это же очевидный факт – чем раньше найдена ошибка, тем проще и дешевле обходится ее исправление. Давайте-ка сдвинем этап тестирование влево по временной оси жизненного цикла разработки программного обеспечения, и переместим его в среду разработки.
Благо, что из-за существенных изменений в конфигурациях, провернуть это дельце сейчас уже не так хлопотно, как раньше. Системы мигрировали в облачные сервисы, а тестировщики перешли к использованию API. Работая в среде, контролируемой на уровне API, каждое приложение может вызвать функцию (универсальную или выделенную) в обход службы, чтобы выполнить более раннее тестирование. После окончания проверки данные передаются через запрос для формирования ответа. Если требуемая система недоступна, этот вопрос решает служба виртуализации (service virtualization).
Служба виртуализации — это простой, но действенный способ для проведения всесторонних испытаний любой подключенной системы, позволяющий тестировщикам «играть» с ней по своим правилам. Виртуализация также помогает создавать сложное окружение, чтобы обучение проходило в обстановке, «приближенной к боевой», а полученная практика уменьшала риски возникновения непредвиденных ситуаций. Тем более, что для последующего воспроизведения требуемых ситуаций, все потоки данных записываются. Вызовы служб выполняются на уровне API и служба виртуализации ведет себя так же, как вел бы себя готовый продукт (система).
Модульный подход к тестированию также вносит свои изменения в правила игры. Разработчики создают модули, которые после используются тестировщиками. Просто представьте перспективы тестируемой системы, в которой разработчик видит только ее часть, а тестировщики видят картину системного «ландшафта» целиком и со всеми возможными конфигурациями. Повторное использование некоторых артефактов создаст новые цепочки процессов либо добавит новые возможности в процесс моделирования. Разработчики могут определить обязательные параметры подключения, такие как логины, пароли, конечные точки и минимально необходимые меры безопасности, а тестировщики просто берут все это и используют в тестовой среде (да-да, именно среде, а не выделенной области тестирования, в которой системы реально взаимодействуют друг с другом без виртуализации.)
Тестовые данные и варианты всех тестов могут быть доступны и для dev- и для test-команд поэтому в зависимости от важности конкретного теста, он может быть запущен уже на этапе разработки, с последующей записью входящих/исходящих данных. Вызов службы можно осуществить типичным способом, но это зависит от данных, которыми оперирует команда. Поиск ошибок на ранних стадиях жизненного цикла приводит к уменьшению ресурсов, выделяемых для последующего тестирования, и ускоряет время выхода продукта на рынок.
Однажды мы участвовали в переносе тестирования на ранние стадии в компании, занимающейся обслуживанием кредитных карт. Хотя в то время им уже удалось избавиться от статической конфигурации тестов и перейти к API, но, несмотря на всю специфичность софта и функционала, на ранней стадии тестирования было выявлено очень много ошибок. Компания располагала отдельной командой тестировщиков, которая просто фокусировалась на уровне API и проверяла связь между ним и приложениями. Тестировщики вместе с разработчиками создавали модули, предоставляющие запросы и ответы. Одни и те же модули использовались повторно при тестировании системы с разными параметрами соединений. Это экономило огромное количество времени, так как команда разработчиков знала, что будет нужно тестировщикам в случае внесения определенных изменений в параметры соединений. Критичные ошибки и нестыковки данных были выявлены еще на этапе разработки и были решены поэтапно, во время развернутого тестирования.
Когда они еще только начали «истязать» приложение с помощью служб виртуализации, разработчики уже успели рассказать нам, как далеко смогут зайти их проверки, чем существенно сэкономили время дальнейшего тестирования и обслуживания.
Сдвиг вправо: пятая передача
Этот особенный метод, потому что мы попытаемся получить лучшее из обоих техник, рассмотренных выше. На этом этапе существенно увеличивается количество тестировщиков, но время выхода на рынок должно сократиться, потому что тестирование происходит в продакшене.
Одним из лучших примеров смещения тестирования вправо (shifting right) является Amazon, так как его заказчики и потребители также выступают в качестве тестировщиков. Все операции глубоко интегрированы. Оптимальный результат достигается в том случае, когда стадия раннего тестирования уже пройдена и на выходе у вас остается только финальный продукт, который проходит автоматическую сборку.
Для того чтобы провести надлежащее тестирование в продакшене, придется потратить больше усилий, чем на предыдущих этапах, потому что все процессы должны быть настроены идеально, а работа – автоматизирована в пользу уровня API. Все, что вы забыли проверить, будет присутствовать в производстве, поэтому функциональность, которая не была покрыта тестами, может привести к реальным проблемам. Ваш продукт должен уже быть сверхстабильным и, возможно, работать с ограниченным числом подключений. По крайней мере, позаботьтесь о том, чтобы все было протестировано с не менее чем 90 % покрытием рисков, иначе некоторые операции не смогут развернуться.
Каждый модуль должен обрабатываться независимо. Полное развертывание в рабочей среде должно состоять из множества фрагментов, так как это обеспечит лучшее покрытие тестами. Большинство фич могут вызвать побочные эффекты. Их может быть даже больше ожидаемого, поэтому их нужно включить в ваши тесты как можно раньше. Конечно, финальное тестирование выполнят непосредственно пользователи, а их отзывы приведут вас к оставшимся ошибкам.
Несмотря на вышесказанное, необходимо не забыть о готовом рабочем конвейере непрерывной интеграции QA, который будет запускаться во время сборки. Большинство тестов запускаются автоматически, во время работы, выбранной CI-тулзы, поэтому сборка выполнится только в случае их успешного прохождения. Тестировщикам нужно позаботиться только о создании тестов, их поддержке и проверке результатов. Идеально, если тестировщики еще и умеют распознавать ложные срабатывания, а также оценивать необходимость вовлечения в процессы тестирования или разработки.
Если вам удалось пройти через все «передачи» воображаемой коробки передач, то вы должны использовать преимущества первой. Здесь модули API могут использоваться повторно, а обслуживание на техническом уровне выполняется только один раз. Качество конечного продукта будет оценено клиентами на основании их отзывов (речь идет о сообщениях-разочарованиях).
Этот способ подходит для увеличения лояльности пользователей и для создания функционала, отвечающего их требованиям, но, чтобы воспользоваться им, нужно, чтобы ваш продукт уже находился на определенном уровне. Если новые «фишки» не слишком сильно повлияют на ваш бизнес, в том смысле, что частота их использования, как и возможный ущерб, несущественны, можно смело экспериментировать в этом направлении. В противном случае постарайтесь убедиться, что тесты покрывают как можно больше функциональности, а все побочные эффекты обнаружены. Чем выше плотность тестового покрытия, тем выше доверие к продукту.
Ранее мы настраивали этот процесс для одного из крупных ритейлеров. Их продукт был уже почти готов и как раз проходил стадию наполнения фичами. Каждое приложение, созданное сторонней командой, виртуализировать и подключалось через API. Каждая сборка проходила через конвейер CI и проверялась на стороне разработчика с помощью автоматизированных API-тестов и JUnit.
Если все «Ok», сборка автоматически перемещалась в специальное тестовое окружение. Там с помощью CI-тулзы в сборку включались тестовая среда и инструменты тестирования, после чего она пересобиралась. Потом запускались автоматизированные функциональные тесты, во время которых использовались UI, API и реальные устройства. Если результаты прохождения тестов «зеленые», сборка передавалась в продакшен и собиралась автоматически. С одной стороны, вы сильно сэкономите время и деньги, с другой — должны быть уверены в используемых системах и приложениях.
В случае необходимости внесения изменений в тесты вам нужно будет работать всего лишь с одним продуктом, что также сильно снимает «головную боль». Благодаря заранее встроенным модулям, не придется создавать одни и те же тесты для разных окружающих сред, но главная проблема – это «ровная» работа виртуализации на различных этапах. При создании тестового набора мы даже ввели принцип “четырех глаз”, чтобы убедиться в том, что все проверено и покрыто тестами.
Не бойтесь использовать передачи
Каждое тестовое окружение зависит от многих факторов, включающих команду, само приложение и конфигурацию инфраструктуры. На разных этапах могут использоваться различные тестовые стратегии и подходы. Если в процессе тестирования вы думаете, что переход вправо либо влево мог бы быть полезнее, либо сам ход процесса «толкает» вас в определенном направлении — сделайте это.
Каждый сдвиг — это целый процесс, а не одно мгновение. Не бойтесь переносить тестирование на разные стадии жизненного цикла программного обеспечения, если считаете, что это принесет больше пользы для общего дела. И, да, мысли о создании совершенно нового плана тестирования всегда будут останавливать вас. Не позволяйте им делать это. Возможность повторного использования теста очень высока, поэтому однажды применив что-то на «третьей передаче», вы можете сэкономить много времени и денег на пятой.
Пусть ваши тестовые циклы сами наталкивают вас на верный путь, подобно тому, как звук мотора автомобиля, с механической коробкой, наталкивает водителя на мысль о необходимости переключить передачу.
What is Shift Left Security?
Shift left refers to moving security sooner in the development process. Graphing the process of application development, with time as the X axis, the process begins with recognition of a need that a technology or service will fulfill, whether it’s an application being developed for sale to paying customers or for internal use. As the solution moved through the stages of conception, design, develop, build, and test, security was often a final step, prior to deployment. Security was merely wrapped around the outside of the application prior to release to end users. And this step, necessarily, added time.
Additionally, a tighter integration of security throughout the process leads to better security outcomes, versus tacking it on at the end.
Shift left is the way to remedy these problems.
The Dangers of Keeping Security Right
With the immediate publication of software comes the immediate publication of any risks.
The Six Pillars of DevSecOps: Automation, published by the Cloud Security Alliance (CSA), states, “Security can be achieved only when it has been designed in. Applying security measures as an afterthought is a recipe for disaster.
Security protections must follow the same automated paths. Tight integration of security throughout the duration of the development lifecycle can not only speed up the time to release, but result in improved security.
Cooperate Rather Than Clash
The traditional process of implementing security after development was completed, but prior to release, resulted in frequent clashes between security and development teams. As development teams completed their portion of the task, they sought to place applications into the end users’ hands, to deliver the outcome of their efforts, begin gathering feedback, and meet deadlines. For security to put the brakes on releases resulted in adversarial relationships between the two.
A survey of more than 165 developers, application security, and DevOps professionals conducted by ShiftLeft finds 89% of respondents said the current disconnect between developers and cybersecurity teams is the biggest inhibitor of productivity.
By shifting security left, teams can cooperate instead, and integrate the processes necessary to prepare apps for release on time, securely.
Embed Responsibility for Security Earlier
Shifting left involves making changes in when, where and how to apply security best practices. Security must build trust with developers and DevOps. It’s helpful to understand the DevOps automation culture and the speed with which they deploy code.
As part of shifting left, you should provide developers with the tools to do their job securely without adding work. This includes automating security such as conducting vulnerability scanning at the point of deployment and generating permissions for Lambda functions.
Remove Friction
While security must be proactive, it’s challenging to achieve while maintaining that speed. You need to get control, governance, and observability. Security professionals must enable, rather than restrict, the business.
It’s important for developers to understand secure coding methods. This can enable developers, rather than security analysts, to check for and eliminate vulnerabilities early.
As Marco Rottigni, chief technical security officer tells Computer Business Review, “Developers should be empowered with plug-ins that trigger security and compliance controls at every step of the DevOps process, exposing the results right within the tools they commonly use to enable rapid remediation of the vulnerable code.”
While there has been progress shifting left, it’s often not enough. Over 42% of respondents to GitLab’s Mapping the DevSecOps Landscape 2020 Survey said testing happens too late in the lifecycle.
Without security automation, DevOps teams are often hindered by the need to wait for human approval.
Tools to Equip Shift Left Security
Granting Time for Shifting Left
As Paul Holland, wrote in Computer Weekly, “CISOs need to realise that developers should be granted time to develop securely and not judge their performance solely by the time to build.”
It’s unreasonable to assign additional duties for application security to developers, while expecting them to maintain a furious pace. While shifting security left results in a more efficient process and can speed time to market, time must still be allocated for tasks those security tasks, such as code reviews.
Automate to Shift Left
“Security controls can’t be successfully integrated without automated security capabilities that allow for timely and meaningful feedback. By adopting even modest automated security capabilities entire classes of risk can potentially be eliminated,” said Sean Heide, Research Analyst Cloud Security Alliance.
Automate remediation. Don’t create tickets to solve things that could be resolved in an automated way. Offer developers self-serve to assess security of a stack they’re about to deploy.
Nigel Kersten, Puppet’s field chief technology officer, stressed the importance of deploying automation at scale in DevSecOps practices. “Without [scaled automation], organisations will end up with the same manual processes and the same conflicting incentives. Then, instead of DevSecOps, these businesses are left with just Dev, Sec and Ops.”
Automate Security Across the Cloud
Disparate solutions fall short. In particular, app security was not designed to adapt automatically to app changes. The large scale of most cloud infrastructures along with dynamic environments makes security particularly challenging.
Today’s security professionals need to deploy multi-layer security across all cloud environments – with a consistent security approach and policy language across everything you do. Check Point provides an automated security approach that protects at cloud scale and speed. Keep track of your configurations with posture management, high fidelity visibility around assets. Maintain protection according to best practices as well as to your own policies. Continuously monitor and take actions across the entire cloud infrastructure.