Настоящая безопасность “сдвиг влево и продление вправо” требует уполномоченных разработчиков

DevOps принципиально о сотрудничестве и гибкости. К сожалению, когда мы добавляем к изображению ь и соответствие, сообщение искажается.

Термин «DevSecOps» вошел в моду в последние несколько лет с намерением беспрепятственно интегрировать без и соответствие требованиям в структуру DevOps. Однако реальность далека от идеала: инструменты безопасности были прикреплены к существующему процессу DevOps вместе с новыми уровнями автоматизации, и все называют это «DevSecOps». Это ошибочный подход, который не учитывает принципы сотрудничества и гибкости.

Интеграция безопасности в DevOps для выполнения требований DevSecOps изменила мышление, процессы и технологии. Руководители служб безопасности и управления рисками должны придерживаться гибкого и коллективного характера DevOps, чтобы тестирование безопасности было беспроблемным в процессе разработки, что сделало бы «Sec» в DevSecOps прозрачным. – Нил Макдональд, Gartner

В идеальном мире все разработчики должны быть обучены и иметь опыт безопасного кодирования от внешнего интерфейса до внутреннего и иметь навыки предотвращения всего, от внедрения SQL до эксплойтов среды авторизации. Разработчики также будут иметь всю информацию, необходимую им для принятия решений, связанных с безопасностью, на ранней стадии проектирования.

Если разработчик работает над типом контроля безопасности, над которым он раньше не работал, организация должна провести соответствующее обучение, прежде чем возникнет проблема с безопасностью.

И снова реальность не соответствует идеалу. Хотя автоматизация CI / CD предоставила разработчикам право собственности на развертывание своего кода, этим разработчикам по-прежнему мешает отсутствие прозрачности соответствующей информации, которая могла бы помочь им принимать более обоснованные решения, прежде чем они даже сядут писать код.



Вся концепция обнаружения и устранения уязвимостей на ранних этапах процесса разработки уже в некотором смысле устарела. Лучшим подходом является предоставление разработчикам информации и обучения, которые им необходимы, чтобы предотвратить превращение потенциальных рисков в уязвимости.

Рассмотрим разработчика, которому поручено добавлять поля PII в API с выходом в Интернет. Элементы управления авторизацией в шлюзе облачного API критически важны для безопасности новой функции. «Сдвиг влево и продвижение вправо» не означает, что средство сканирования или архитектор безопасности должны обнаруживать угрозу безопасности на более раннем этапе процесса – это означает, что разработчик должен иметь весь контекст для предотвращения уязвимости еще до того, как она произойдет. Постоянная обратная связь является ключом к повышению уровня знаний разработчиков в области безопасности на несколько порядков.