Все кейсы

Оценка зрелости процесса разработки ПО для компании из отрасли машиностроения

Клиент Крупный российский производитель транспортного оборудования.
Экспертиза
DevSecOps
Задача

Наш клиент производит оборудование, которым ежедневно пользуются миллионы человек. При производстве подобных устройств вопросы безопасности зачастую решаются только на аппаратном уровне: например, все критические датчики собираются в одну электрическую цепь, которая размыкается, если что-то идет не по плану. Так конвейер должен остановиться, если на ленту попал посторонний предмет, а в метро или ТЦ эскалатор не может разогнаться выше определенной скорости — для таких случаев предусмотрены блокировки.

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

Чтобы определить стартовую точку для развития процессов безопасной разработки ПО (DevSecOps), компания обратилась к нам. 

Решение

Мы провели для компании оценку зрелости DevSecOps и предложили дорожную карту развития на три года. При оценке опирались на модель Crosstech Appsec Framework (CAF), разработанную в нашей компании, и дополнили ее требованиями заказчика. Такой подход позволил охватить все этапы жизненного цикла ПО и учесть отраслевую специфику.

Проект реализовали за 3 месяца. Работали поэтапно:

  1. Аудит ИТ-систем и процессов. Мы оценили готовность ИТ-инфраструктуры к внедрению DevSecOps: провели инвентаризацию систем, изучили, где и как хранится и запускается код, какие инструменты автоматизации установлены. Затем изучили существующие процессы: смотрели, как ведутся ветки на GitHub, как проходит проверка кода, как выявляются дефекты.
    При оценке мы искали баланс между лучшими практиками и специфическими техническими регламентами и ГОСТами, существующими для конкретного вида оборудования, которое производит наш клиент.
  2. Аудит безопасности среды интеграции и доставки кода (CI/CD). Мы проверили, как предоставляется доступ к среде, как работает система контроля версий, как разграничиваются права, проводится тестирование, хранятся артефакты и секреты.
  3. Оценка зрелости процесса разработки и приложений. Мы получили от клиента реальные ТЗ, с которыми работает команда разработки, и проверили, насколько код приложений соответствует ТЗ с точки зрения функциональных, архитектурных и логических требований. Затем оценили безопасность готовых приложений: провели статический и композиционный анализ кода, просканировали его на уязвимости.
  4. Подготовка отчета и дорожной карты развития DevSecOps в компании. В отчете мы собрали выявленные уязвимости и слабые места процессов, и предложили, как их скорректировать. Все проблемы приоритизировали по критичности для безопасности кода, добавили рекомендации по внедрению инструментов (SAST, DAST) и организационных мер, а также обучению для команды. В итоге получили дорожную карту, которая позволит клиенту достичь целевого уровня зрелости DevSecOps за 3 года.
Результат

Компания получила представление об уровне развития разработки с точки зрения безопасности и дорожную карту развития DevSecOps. Эти инструменты помогут ИБ-подразделению синхронизировать свои цели с одной из ключевых целей бизнеса — обеспечивать клиентам высочайший уровень безопасности продукции. 

«DevSecOps на промышленном предприятии — это не про инструменты, а про договорённости между людьми» Аудит показал, что именно с договоренностей стоит начинать: сканер разворачивается за пару недель, а вот согласование того, кто исправляет найденное, в какие сроки и на каких условиях, занимает месяцы.

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

Хорошая новость в том, что оба шага делаются один раз и сделать их можно ещё до первой закупки. Именно ради этого и проводится аудит: он показывает реальную картину разработки и превращает абстрактное «нам нужен DevSecOps» в понятный перечень шагов с приоритетами. Дальше остаётся идти по нему. Так что промышленным предприятиям, которые только начинают, я желаю не откладывать: путь абсолютно проходимый, и начинается он не с инструментов, а с честного взгляда на то, как у вас устроена разработка сегодня.
Антон Редько Руководитель группы по безопасной разработке, Кросстех

У вас похожая
задача?

Мы свяжемся с вами и предложим решение Давайте обсудим