Войти в систему
Войти с помощью соц. сетей:
Как мы помним из первой главы, чем раньше в жизненном цикле разработки системы мы обнаружим ошибку или недостаток в системе безопасности, тем дешевле, проще и быстрее будет ее исправить. Начало обеспечения безопасности на более ранних стадиях называется сдвигом влево. Если разработчики пользуются инструментами по обеспечению безопасности, они найдут и устранят некоторые проблемы еще на этапе кодирования, то есть до этапа тестирования (когда нас, скорее всего, пригласят для выполнения действий по обеспечению безопасности). Это большая победа!
Еще одна причина, по которой следует предоставить разработчикам инструменты безопасности, – это цифры. На каждого специалиста по обеспечению безопасности приходится (в среднем) 100 или более разработчиков. То есть у разработчиков больше времени, но, как правило, меньше навыков (связанных с обеспечением безопасности). Обучение всех разработчиков в команде пользованию даже одним инструментом может дать потрясающие результаты при минимальной загрузке людей.
Поддерживая интерес разработчиков к безопасности, мы можем превратить их в чемпионов безопасности, которые возьмут на себя еще больше ответственности в данной области. Дополнительное обучение чемпионов безопасности, чтобы они могли выполнять обзор безопасности кода, писать негативные модульные тесты, выполнять более продвинутое тестирование и многое другое, – вот пример эффективного использования времени и ресурсов.
Разработчики программного обеспечения – это строители, и большинство из них гордятся своей работой: они хотят создавать безопасные приложения. Предоставление им инструментов, обучение тому, как ими пользоваться, и безопасная среда могут поспособствовать созданию высококачественного программного обеспечения, к которому они стремятся.
СОВЕТ. Поиск уязвимостей можно превратить в увлекательное занятие, создав систему поощрений и баллов для разработчиков, которые найдут и устранят больше недостатков, чем другие. Одобрение и награда – хороший стимул. Работа, которая не является очередной задачей в списке, может быть приятной, познавательной и продуктивной.
Необходимо формализовать (предписать или создать политику для поддержки) деятельность по обеспечению безопасности, которую вы хотите видеть частью жизненного цикла разработки системы. Если необходимо, чтобы каждый новый проект включал установленные требования безопасности, напишите политику для поддержки этого условия работы. При этом в расписании проектов также должно быть выделено время для этих действий, связанных с обеспечением безопасности, иначе их не удастся выполнить.
Ниже приведены примеры действий, которые можно осуществить на каждом из этапов жизненного цикла разработки системы (независимо от используемой методологии). Выбор любого из них на каждом этапе цикла повысит безопасность конечного продукта.
• Требования: требования безопасности в соответствии со второй главой, пользовательские истории безопасности, оценка безопасности и утверждение предлагаемого стека технологий.
• Проектирование: моделирование угроз, создание досок с планом поиска недостатков в архитектуре, оценка безопасности структуры приложения (в соответствии с третьей главой).
• Кодирование: линтеры, написание модульных тестов безопасности, сканирование инструментами SAST или SCA, написание безопасного кода (согласно четвертой главе), использование плагинов IDE или вебхуков для исправления небезопасных частей написанного кода, использование известных безопасных паттернов и/или библиотек.
• Тестирование: сканирование инструментами DAST, SAST и SCA, проведение оценки безопасности или теста на проникновение, проверка безопасности кода (также инструментом SAST), сканирование на наличие секретов плюс что-нибудь из шестой главы.
• Развертывание, релиз и поддержка: DAST, RASP или WAF, мониторинг, ведение журналов, оповещения безопасности, обученная и готовая к работе команда реагирования на инциденты и установленный процесс развертывания.
Этот список не является исчерпывающим, его можно расширять практически бесконечно. Основной момент здесь заключается в том, что мероприятия выбираются самостоятельно, и одним из главных условий является их регулярное проведение.
СОВЕТ. По возможности поддерживайте вашу политику паттернами, примерами кода, документацией и всем, что только можно придумать, чтобы помочь другим командам соблюдать установленные требования.
Выбор, приобретение и внедрение инструментов обеспечения безопасности требуют времени, энергии и опыта. Не нужно взваливать это на разработчика. Не все инструменты одинаково полезны, ведь каждый из них имеет свои плюсы и минусы. В этой книге не будут предлагаться конкретные продукты или бренды. Лучший способ сделать выбор – провести проверку концепции (англ. Proof of concept, POC) того или иного инструмента и протестировать его самостоятельно. Желательно подключить к данному процессу разработчиков, чтобы они сами посмотрели, подходит ли им предлагаемый вариант. В конце концов, именно для них это делается.
По возможности автоматизируйте рабочий процесс выбранных вами инструментов (часто в этом может помочь CI/CD). Ручная работа предполагает ошибки, бесполезную потерю времени и скуку. Если инструмент будет использоваться десятки, сотни или тысячи раз, не следует запускать его вручную.
СОВЕТ. Создайте базу знаний по теме обеспечения безопасности, чтобы разработчики могли централизованно перенимать чужой опыт и делиться своим. Данная деятельность приобретает все большую ценность, и через несколько лет нельзя будет представить жизни без нее!
Войти с помощью соц. сетей: