Дарья Орешкина

Дарья Орешкина,

директор по развитию бизнеса компании Web Control

Р

а н ь ш е к т о г р о м ч е к р и ч а л , т о т и п р о д в и г а л с в о и з а п р ос ы в р о а д м а п , а п о т о м п о я в и л с я V S M .

2020 год выдался нелегким для бизнеса. Клиенты компаний – разработчиков ПО в условиях сокращения бюджетов требуют снижения стоимости поставки программных продуктов. Разработчикам как никогда необходимо оптимизировать процессы, развивать сотрудников, одновременно повышая качество и скорость реакции на запросы клиентов, при этом увеличивая прибыль. Системы управления потоком создания ценности конечного продукта (Value Stream Management, VSM) для разработки программного обеспечения помогают принимать взвешенные, соответствующие бизнес-целям решения, а также управлять качеством и вовремя осуществлять выпуски.

В течение последних нескольких лет, и особенно ярко в 2020 г., мы наблюдаем переход от индустриальной экономики, основанной на производстве, к цифровой экономике – экономике знаний на базе ИТ. В новых реалиях главная роль отводится производству цифровых продуктов. Разработке ПО как самостоятельной отрасли приходится непрерывно изыскивать способы оптимизации процессов поставки ПО, чтобы удержаться на высококонкурентном рынке. В поисках таких способов она обращается к методологическим наработкам промышленности –зрелой отрасли, для которой выработаны системные подходы к оптимизации производства, например такие, как конвейер Форда, менеджмент качества Деминга, бережливое производство и концепция just in time. Однако эти системные подходы не могут быть использованы в разработке в чистом виде, что связано с существенными отличительными особенностями этой отрасли.

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

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

Простое и быстрое изменение требований к функционалу разрабатываемого продукта стало возможным благодаря практикам Agile, ориентированным на результат, а не на процессы, которые стали логическим развитием методик бережливого производства и Канбана. Непрерывная доставка с автоматизированными сборками и развертываниями стала возможной благодаря методологии DevOps, которая позволяет повысить скорость создания программных продуктов в тысячи раз. Затем ожидаемо возник вопрос о повышении эффективности процесса создания ценности (то есть разработки программного обеспечения), чтобы на высококонкурентном рынке можно было снизить стоимость разработки, предоставляя при этом функционал, наиболее полно отвечающий требованиям заказчика. Так начал формироваться и относительно недавно увидел свет новый класс решений – Value Stream Management, управление потоком создания ценности.

Под потоком создания ценности понимается совокупность всех действий, которые требуется совершить, чтобы определенный товар или услуга прошли стадии от разработки концепции до готового продукта. Решения этого класса объединяют Agile-планирование и DevOps в единый поток и делают его видимым, "материальным". VSM-инструменты отслеживают прогресс, статус и изменение состояния эпиков, пользовательских историй, задач разработки, артефактов, перемещающихся в потоке создания ценности, а также визуализируют процессы, генерируют отчеты, предоставляют практические рекомендации на основе аналитики и алгоритмов AI и ML. Все это позволяет связывать разные события в процессе и получать своевременную обратную связь для управления процессами планирования и разработки.

Давайте рассмотрим, что дает VSM для DevOps на примере функциональных групп возможностей решения Digital.ai Agility, уже проявившего себя как эффективного помощника в создании успешных программных продуктов.

Планирование продукта

Наверное, все помнят картинку-мем про разработку качелей, которая показывает, насколько порой расходится

VSM – это не только Agile, но и оркестрация релизов, автоматизация развертывания, защита приложений изнутри, аналитика на основе искусственного интеллекта и многое другое

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

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

Программный менеджмент

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

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

Agile-управление проектами и командами

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

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

Agile-метрики и аналитика

Как оценить эффективность разработки без точных показателей и всесторонней аналитики? Часто такая оценка сводится к субъективному мнению.

VSM помогает принимать решения, обеспечивая визуализацию различных слоев производства и сводных показателей по проектам и командам, предоставляя отчеты и аналитику по стадиям производства программного обеспечения (см. рис.).

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

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

VSM – это не только Agile, но и оркестрация релизов, автоматизация развертывания, защита приложений изнутри, аналитика на основе искусственного интеллекта и многое другое, о чем я расскажу в следующих статьях.

Управление потоком создания ценности продукта – это не просто стратегия сокращения затрат, а основа развития. l

Ваше мнение и вопросы присылайте по адресу is@groteck.ru

Как перейти на безопасную разработку: история одного проекта

Алексей Жуков,

эксперт отдела систем защиты приложений, Positive Technologies

В

среднем на одно приложение приходятся1

22 уязвимости, при этом 82% уязвимостей содержится в исходном коде, а устранить их можно было бы еще на самых ранних этапах создания приложения. Такой подход называется безопасной разработкой (SSDL, SDL, SDLC2). Почему анализ безопасности кода необходим бизнесу и как организовать SSDL-процесс на предприятии, разберем на примере проекта ИТ-компании, которая занимается заказной разработкой ПО.

Анализ3

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

Согласно исследованию Applied Software Measurement, Capers Jones, исправление ошибок на этапе написания кода обойдется компании до $10, а вот за их устранение на этапе эксплуатации ПО компания заплатит уже свыше $10 000. Эти цифры с каждым годом будут только расти. Приходится соглашаться с тем, что в качественном соотношении представленная картина и в будущем сохранит свою актуальность (см. рис. 1).

По данным GBKSoft4, в среднем разработка одного приложения занимает 4,5 месяца, такие темпы не позволяют выделить время на выявление всех уязвимостей вручную. Для обеспечения высокого уровня защищенности приложений компаниям необходимо построить процесс безопасной разработки, который включает применение не только технологий, но и ряда организационных мер.

Разберем, как перейти на SSDL на примере работы одной ИT-компании.

Кто созрел для SSDL

Мы построили процесс безопасной разработки с нуля, последовательно внедрив его ключевые компоненты, в том числе периодическое проведение как ручного, так и инструментального анализа защищенности приложения, встраивание автоматизированного поиска уязвимостей в конвейеры сборки, разработку документации, проведение обучения разработчиков, консультирование по выявленным проблемам. Наш клиент – крупная ИT-компания, занимающаяся разработкой ПО по заказам более 20 лет. В команду входят свыше 1 тыс. сотрудников. Помимо внешних, заказных проектов, организация развивает и свои внутренние решения –обучающие программы для персонала, HR-инструменты, корпоративный портал.

Рис. 1. Стоимость устранения уязвимостей в коде в зависимости от этапа разработки

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

Первый помощник в SSDL –анализатор кода

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

Внедрение анализатора кода стало для нас задачей первой важности. Поскольку в проектах клиента уже использовались практики CI/CD5, необходимо было интегрировать его в действующие процессы. Мы провели тщательную подготовку и начали строить решение на базе нашего анализатора кода PT Application Inspector.

Командная работа и security champions

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

https://www.ptsecurity.com/ru-ru/research/analytics/web-vulnerabilities-2020/

Процесс, обеспечивающий возможность поддержки необходимого уровня безопасности создаваемой системы как на этапе разработки, так и в ходе эксплуатации. Ключевыми аспектами этого подхода является обеспечение безопасности приложения, идентификация рисков и управление ими. https://www.ptsecurity.com/ru-ru/research/analytics/web-vulnerabilities-2020/ https://gbksoft.com/blog/how-long-does-it-take-to-develop-a-web-app

Continuous Integration & Continuous Delivery, CI/CD – комбинация непрерывной интеграции и непрерывной доставки или непрерывного развертывания.

Человек в команде разработки, являющийся “точкой входа" в команду разработки в вопросах, относящихся к безопасности продукта, и напрямую заинтересованный в ней. При этом он не только пользователь технических средств обеспечения безопасности кода, он должен способствовать повышению общего уровня экспертизы команды в соответствующих вопросах, проводить тренинги, CTF и консультации.

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

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

Как настроить доступ к коду

Один раз проанализировать код несложно. Достаточно просто скачать его или скопировать на USB-накопитель и доставить до компьютера, на котором установлен анализатор. Однако если вы хотите автоматизировать этот процесс и проверять код регулярно, то помимо технических вопросов возникают и организационные, например, как дать анализатору кода доступ к набору репозиториев исходного кода. Предоставить доступ сразу ко всем проектам небезопасно, а открывать его к каждому проекту по отдельности – значит перегрузить ИT-отдел заявками.

У этой проблемы есть простое и эффективное решение: интегрировать анализатор кода в систему CI, для которой проблема контролируемого доступа к коду уже решена.

Что делать со сторонним кодом

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

В нашем случае нужно было найти эффективное решение, которое позволило бы работать с такими зависимостями. Типовой выход – автоматизированная загрузка используемых компонентов на основе данных, определенных в специализированных файлах (pom.xml, composer.json и т.д.). Но это потребовало бы предоставления доступа в Интернет к открытым репозиториям артефактов (например, MVN Repository) с хостов, на которых выполняется анализ кода.

Мы нашли другое решение – интеграцию с системами CI/CD, которая позволила избежать такого шага.

Как обрабатывать результаты

Анализ для нас не являлся самоцелью. Это лишь часть подхода, который помогает решить основную задачу – сделать разрабатываемое приложение безопасным. Мы хотели, чтобы данный процесс был удобным для пользователя. PT Application Inspector идеально подошел для этой цели, поскольку обеспечил инкрементальный7

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

Как обучить сборщика

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

Для каждого пилотного проекта мы разработали уникальные наборы правил для интеграции анализа кода в CI/CD. В большинстве случаев, если в ходе важной сборки (например, релиз-кандидата) обнаруживалась критическая ошибка, сборка останавливалась. Это позволило снизить трудозатраты разработчиков: теперь не было необходимости смотреть в каждый отчет анализатора и вручную принимать решение о дальнейшей судьбе сборки, все было автоматизировано.

Первое внедрение

ИT-компания выбрала около 20 проектов, над которыми работали 10 команд разработчиков. Наша задача состояла в том, чтобы проверить жизнеспособность и надежность системы в ее текущей реализации. На этом этапе мы выполнили следующие задачи: 1. Подключили пилотные проекты к развернутому решению и проверили его работоспособность. 2. Написали руководства по самостоятельному развертыванию системы для сотрудников компании. 3. Помогли разработчикам добавить решение в другие проекты.

После этого процесс SSDL заработал в полную мощь! Оставалось только передать нашу экспертизу по анализу результатов.

Итоговое обучение

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

Затем мы провели встречи с каждой группой, уделив больше внимания тем аспектам, которые были наиболее критичны для их продуктов. Подробно поговорили об уязвимостях, анализаторах кода, а также разобрали конкретные кейсы приложений. Как и ожидалось, это помогло специалистам ИT-компании улучшить навыки работы с продуктом и повысить осведомленность в теме безопасной разработки.

Результаты

Переход на безопасную разработку на базе PT Application Inspector позволил ИT-компании обеспечить раннее выявление уязвимостей в коде, снизить трудозатраты команд разработки на их устранение, повысить осведомленность и заинтересованность в безопасности кода.

Эти рекомендации будут полезны для любого жизненного цикла разработки приложений, но лучше всего они работают в проектах CI/CD. l

Убедитесь в том, что руководство понимает важность внедрения SSDL, заручитесь его поддержкой и зафиксируйте цели внедрения. l

Каждая команда разработчиков должна выбрать своего security champion –лидера по вопросам безопасности. Этот человек будет основным драйвером в процессе внедрения практик безопасной разработки. l

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

l

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

Настройте анализатор кода. Проверьте результаты его работы и отрегулируйте настройки сканирования, чтобы добиться приемлемого числа ложных срабатываний. l

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

Протестируйте решение на небольшом количестве проектов. Это даст вам обратную связь, которая позволит провести тонкую настройку решения. l

Напишите точные и краткие инструкции для команд, которые начнут работать с SSDL после завершения пилотной стадии проекта. l

Проведите обучение по безопасности для сотрудников и затем проверьте их понимание принципов SSDL и знание технических деталей. l

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

Ваше мнение и вопросы присылайте по адресу is@groteck.ru

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