Журнал "Information Security/ Информационная безопасность" #3, 2020

Отслеживание состояний каждого шага создания продукта "Сдвиг влево" и интеграция проверок безопасности и комплайнса в конвейер разработки ПО создает большой объем данных. Одним из вариантов их исполь- зования является создание цепочки учета событий каждого релиза. Она представ- ляет собой набор подробно зафиксиро- ванных результатов всех действий в процессе разработки, в которых содер- жится информация о том, что произошло, когда и кто это сделал. Автоматический захват данных и учет позволяют бизнесу отслеживать процесс разработки и фик- сировать результаты каждого этапа, пре- доставлять аудиторам нужную инфор- мацию и подтверждать выполнение всех проверок. Наличие такой цепочки учета событий дает возможность провести раз- бор ошибок в случае сбоя, накапливая суммарные знания компании и облегчая расследование инцидентов. Кроме того, команды получают инструмент для непре- рывного управления качеством продукта, обнаруживая все недочеты на самых ранних стадиях: невыполненные действия или действия, которые регулярно не выполняются либо выполняются с ошиб- кой, ручные процедуры, которые можно автоматизировать. Наглядное представление и оценка уязвимостей безопасности Только лишь сбора данных о соблю- дении требований безопасности и ком- плайнса и учета действий в процессе релиза недостаточно. Нужна гарантия, что каждое лицо, вовлеченное в процесс поставки ПО, может получить наглядные сведения и оценку соблюдения требо- ваний для своих целей. Корпоративная цепочка инструментов поставки ПО обычно состоит из множе- ства специализированных инструментов, каждый из которых предоставляет свои данные и свою отчетность. Но отдельные отчеты не позволяют увидеть общую картину разработки в целом. А без общей картины трудно понять, какие действия для обеспечения безопасности и комплайнса нужно предпринять. Важно автоматически извлекать необходимые данные из инструментов DevOps, подставлять их по требованию и добавлять в контекст, с помощью которого эти данные можно осознать. Например, результаты тестирования безопасности отдельного функционала не помогут специалисту по комплайнсу идентифицировать нарушение. Однако если он увидит, как этот функционал используется, взаимодействует с дру- гими функциями и разворачивается, то нарушение может стать очевидным. Фундаментальные принципы DevSecOps Джин Кин, консультант по стратегиче- ским вопросам компании XebiaLabs и автор ряда книг по DevOps, сформули- ровал ключевые принципы DevSecOps: 1. При проектировании необходимо учитывать самые худшие сценарии. Пользователи не всегда следуют опти- мальному или ожидаемому сценарию. Нужно учитывать злонамеренные поль- зовательские истории и проверять воз- можность их реализации, моделировать ландшафт угроз и проводить симуляцию разных уровней сбоев. 2. Тестирование безопасности на каж- дом этапе конвейера. Можно использовать инструменты реальной атаки типа Metas- ploit. Безопасность должна быть не в виде бумажного документа, а в виде кода, хра- нящегося в репозитории, откуда его может взять любой разработчик. В конвейер должны быть встроены SAST-, DAST-, IAST-инструменты и инструменты провер- ки компонентов Open Source. 3. Тренировок AppSec недостаточно. Нет также необходимости тренировать всех разработчиков писать безопасный код. Код пишут люди, и на 10 тыс. строк кода будет определенное число ошибок, часть из них приведет к уязви- мостям. Тренировками эту проблему не решить. Нужны подходящие инстру- менты и автоматизация. l • 51 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru Реклама Ваше мнение и вопросы присылайте по адресу is@groteck.ru