∞ Зачем разработчику DevSecOps?

С повышением объёмов данных растёт необходимость их защиты. Здесь как раз требуется DevSecOps, где DevOps – процесс разработки и доставки программы, а частица Sec отвечает за защиту этого приложения.

Грубо говоря, это врезка дополнительного шага в методологию разработки ПО. Шаг добавляется после внесения изменений в программу. Сама же методология направлена на более тесное сотрудничество между командами разработки и эксплуатации и добавляя к ним команду безопасности.

Каким разработчиками требуется знания DevSecOps?

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

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

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

Разница между DevOps и DevSecOps

Беспокойство о безопасности может полностью похоронить любую разработку из-за нерационально расходуемого времени.

Философия DevSecOps предлагает интегрировать тесты безопасности во все циклы DevOps: начало, дизайн, сборку, тестирование, выпуск, поддержку и обслуживание.

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

Особенности разработки

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

Важность DevSecOps

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

Методологию, кстати, можно использовать не только для разработки ПО, но и в других сферах:

• Автомобилестроение. Сокращения времени цикла при соблюдении стандартов, вроде MISRA и AUROSAR.
• Здравоохранение. Обеспечение цифровизации при сохранении конфиденциальности и безопасности данных в соответствии с HIPAA.
• Финансы и коммерция. Избавление от OWASP 10 (основные риски веб-безопасности) и обеспечение безопасности данных платёжных карт по стандартам PCI DSS для транзакций.
• Гаджеты. Предотвращение возникновения CWE 25 (самые опасные программные ошибки).

Мифы о DevSecOps

• Для применения методологии требуются крутые спецы. Не до конца правдивое утверждение. Конечно, опытные работники со своими задачами справятся лучше, но не стоит утверждать, будто только одарённые разработчики спасут безопасность. Если же стоит задача воспитать своих программистов в рамках DevSecOps, это вполне реально.
• DevSecOps может заменить Agile. В корне неверно. DevSecOps дополняет, а не заменяет Agile. Agile ориентирован на совместную работу и мгновенный фидбэк, но, в отличие от DevSecOps, никак не покрывает доставку ПО через тестирование, QA и производство. Совместное использование методологий позволяет закрыть все дыры.
• Можно купить DevSecOps. Нельзя. Приобрести можно только инструменты, а сам процесс – никак. Это скорее методология разработки или философия. Ту самую совместную работу и фокус на собственной и коллективной ответственности купить не получится, только воспитать и привить.

Хорошие практики DevSecOps

Как у каждой методологии, у DevSecOps есть собственные стандартные практики, упрощающие её использование:

• Практика безопасного кода. Пусть и очевидно, но только так можно писать хороший код, защищённый от компрометации. Да, скорее всего это создаст дополнительную задержку и расходы, но позволит избежать проблем с информационной безопасностью: утечек данных и нарушения работоспособности сервисов. Создание стандартов позволит упростить процесс разработки.
• Автоматизация. Как и в DevOps, автоматизация является ключевой характеристикой DevSecOps. Чтобы темп проверки безопасности поспевал за темпом разработки, автоматизация должна применяться изначально, особенно в крупных компаниях. Есть и обратная сторона: выбор неправильных инструментов приведёт к большой проблеме.
• Смещение (сдвиг) влево. Методология тестирования, когда проверка безопасности встраивается в разработку с самого начала, не дожидаясь цепочки поставки. Очевидная выгода – проблемы засекаются сразу и работа по их исправлению завершается намного раньше. К тому же, чем раньше замечается баг, тем дешевле его починить. Проблема в том, что «сдвиг влево» может нарушить рабочий процесс и потребуется время для привыкания.
• В DevSecOps есть три «кита»: люди, процесс, технологии.
• Люди. Если работники не заинтересованы в DevSecOps, то никак не получится добиться соблюдения всех правил. Сначала следует убедить всех, что оно того стоит. Впрочем, здесь будет несложно – в последнее время очень часто вскрывают утечки конфиденциальных данных, которые наносят огромный ущерб тем, кто их допустил. Чего стоит одна история со взломом Kaseya.
• Процесс. Важные его части: стандартизация и документация. Обычно, разные команды выполняют разные процессы, но DevSecOps призывает к созданию согласованных и совместному их исполнению для повышения безопасности при разработке.
• Технология. Технология и есть. Та же автоматизация, менеджмент версий проектов, методология Security as Code и прочие возможности ПО, которые обеспечивают выполнение задач.

Краткий список инструментов DevSecOps:

• Static application security testing (SAST). Статическое тестирование безопасности приложений. Инструменты сканируют код для выявления ошибок и конструктивных недостатков, которые приводят к появлению уязвимостей. SAST в основном используется на этапах создания кода, сборки и разработки SDLC. Coverity – один из вариантов.
• Software composition analysis (SCA). Анализ состава ПО. Сканируется исходный код и двоичные файлы для выявления известных уязвимостей в компонентах с открытыми исходниками и продуктами сторонних разработчиков. Оценивается уровень риска безопасности для приоритизации ошибок и ускорения их исправления. SCA интегрируется в CI/CD процессы для постоянного мониторинга ошибок в компонентах с открытыми исходниками.
• Interactive application security testing (IAST). Интерактивное тестирование безопасности приложений. Инструменты работают в фоне во время ручных или автоматических тестов. Анализируется поведение веб-приложений. Например, Seeker IAST наблюдает за взаимодействиями, поведением и потоком данных между запросами и ответами приложений. Находит уязвимости, воспроизводит и тестирует результаты, предоставляя информацию разработчикам. Вплоть до строки кода, где появляется ошибка.
• Dynamic application security testing (DAST). Динамическое тестирование безопасности приложений. По сути это автоматизированный чёрный ящик, имитирующий поведение хакера. Работает он через сетевое соединение и исследует исполнение приложения со стороны клиента. Таким инструментам не нужен доступ к исходникам или настройкам для сканирования: они работают с приложением и ищут уязвимости с низким уровнем ложных срабатываний.

Заключение

DevSecOps – методология разработки, в которой код, прежде чем выйти в релиз, тестируется на возможные информационные утечки. Это влияет на скорость разработки, поэтому следует заранее определить уровни ошибок: от критических до маловажных.

Если вы заинтересованы в развитии карьеры в этой сфере, стоит обратить внимание на «Факультет информационной безопасности» образовательной онлайн-платформы GeekBrains. На 70% учебная программа состоит из вебинаров с преподавателями, которым вы сможете задать все интересующие вопросы по темам и оперативно получить от них обратную связь.

Продолжительность обучения – один год. За это время вы освоите современные технологии и компетенции, которые необходимы специалистам по безопасности: Application Security Engineer, пентестеру, специалисту по информационной безопасности или DevSecOps-инженеру.