Инструменты и методы DevSecOps повышают безопасность среды разработки

25.03.2022

На днях в Москве компания «Гротек» провела конференцию, посвященную вопросам безопасной разработки программных продуктов, а точнее – обсуждению модели DevSecOps, которая подразумевает обеспечение безопасности на всех этапах разработки. Примечательно, что мероприятие началось с интервью с заказчиками, на вопросы которых отвечали представители компаний-разработчиков.

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

Но постепенно, с развитием конкуренции, произошло сокращение длительности циклов разработки ПО до нескольких недель, а иногда и дней. В практику вошло «достраивание» функций безопасности к уже сданному в эксплуатацию продукту. Естественно, существующая стратегия разработки к настоящему моменту стала неприемлемой.

Поэтому были созданы инструменты управления процессом безопасной разработки – DevSecOps (development, security и operations), которые позволяют решать проблемы безопасности по мере их появления, когда это можно сделать с меньшими затратами времени и средств – до развертывания функций в рабочей среде. Подразумевается, что DevSecOps помогает разделить ответственность за безопасность приложений и инфраструктуры между специалистами по разработке, безопасности и эксплуатации ИТ-систем.

Однако проблемы всё же существуют. В частности, сформировалось мнение, что безопасность является серьезным препятствием на пути быстрой разработки приложений. Именно это отметили заказчики на конференции. До сих пор разработчики ИБ-специалистов не жалуют. Более того, до сих пор наблюдается их противостояние.

Напомним, существует «Манифест DevSecOps»: «Цель и смысл внедрения DevSecOps — сформировать такой образ мышления, при котором каждый участник несет ответственность за безопасность. Это обеспечивает быструю и масштабируемую передачу решений по безопасности тем, кто лучше всего владеет контекстом, без ущерба для безопасности». То есть имеется надежда, что ситуация изменится в лучшую сторону.

Вот еще несколько вопросов, которые заказчики адресовали разработчикам. В частности, компаниям не хватает информации для того, чтобы сравнить качество российских программных продуктов, не хватает примеров успешных внедрений. Заказчики сетуют на порой низкое качество ПО: нужно чтобы оно хотя бы работало и не ломалось. А если продукт сложный, необходимо знать, насколько быстро можно его изменить, исправить ошибки, закрыть бреши. Нужны понятные критерии качества разработки, чтобы определить ценность разработанного продукта.

Еще одна проблема, связана с аутсорсингом команд разработчиков. Им сейчас оплачивают сам продукт, но не его качество. Как говорят – за качество не платят. То есть – снова вопрос качества.

Между тем заказчики признают, что им трудно сформулировать требования от бизнеса, а тем более углубляться в дизайн проекта. Важнее, если имеется какая-то «кнопочка», чтобы она гарантированно работала, а справа или слева экрана она будет расположена – не столь существенно. «Не дело бизнеса сочинять ТЗ».

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

На конференции рассказали о своих продуктах, их функционале, практиках DevSecOps представители компаний «Ростелеком-Солар», AFI Distribution, CodeScoring, Fortis и другие.

Лев Толмачёв

Тема:О том, о сём