Softline и Microsoft открывают новую серию технических вебкастов темой безопасности "Возлюби безопасника своего как самого себя: Построение DevSecOps как гармоничный путь развития", который пройдёт 28 января. 

Как это было раньше?

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

Разработчик: Я писал с применением популярных легальных open source библиотек.

Безопасник: В вашем коде целый кусок не соответствует требованиям безопасности и дыряв как швейцарский сыр.

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

А как сейчас.

Появилась методология DevSecOps. Она позволяет интегрировать процессы обеспечения безопасности внутри разработки. На всех этапах ответственный за соблюдение норм безопасности работает плечом к плечу с командой разработки.

У такого подхода несколько плюсов:

Приложение выводится в продакшн быстрее.
В приложении меньше дефектов и уязвимостей.
Уменьшается время, необходимое для обеспечения безопасности приложения.
Конфликты «безопасник/разработчик» снижаются и решаются на самых ранних этапах.
Снижаются риски использования некачественных или юридически рискованных open source компонентов, которые можно выявить, например, при проверке через Black Duck или WhiteSource