software development lifecycle что это
Как создавать безопасные системы. Краткое введение в SDL
При разработке любой программной системы, будь это простой вебсайт, десктоп-приложение или сложный трехзвенный комплекс, рано или поздно возникают вопросы безопасности. Нельзя исключить, что та система, которую вы разрабатываете, будет каким-то образом атакована. Причем, в зависимости от типа системы, ее сложности, применяемых технологических решений, векторы атак и их последствия могут иметь самый разный характер. Возможно, время от времени кто-то в команде проводит анализ безопасности разрабатываемой системы, проводится моделирование. Куда хуже если эти вопросы оставляются на потом. Результаты могут быть весьма плачевными, если вашу систему взламывают в режиме коммерческой эксплуатации и вам приходится впопыхах создавать исправления для обнаруженной бреши. Очевидно, что вопросы, связанные с безопасностью лучше решать, начиная с самых ранних этапов создания системы, таких как анализ требований и архитектурного моделирования. Но лучше всего это делать на всем жизненном цикле системы, интегрировав в процесс разработки специальные шаги, предназначенные для решения этих вопросов. Одним из таких процессов является Security Development Lifecycle – набор практик направленных на повышение безопасности разрабатываемых систем.
Что такое Security Development Lifecycle
SDL это процесс который позволяет убедиться в необходимом уровне безопасности разрабатываемой системы. SDL базируется на основе практик направленных на обучение команды, подготовку отчетности и непосредственные действия связанные с анализом безопасности разрабатываемой системы и имплементацией механизмов направленных на улучшение безопасности. Эти практики в виде конкретных шагов легко ложатся на привычный спиральный цикл разработки программного обеспечения.
Некоторые из этих практик сами по себе могут улучшить безопасность разрабатываемой системы. Но как показывает опыт, их применение в рамках процесса разработки позволяет значительно улучшить результат и снизить затраты.
Перед тем как внедрить SDL: Обучение
Все члены команды, перед тем как непосредственно начать разработку, должны пройти тренинг по безопасности и изучить важные моменты, связанные с текущими трендами в этой области. Базовый уровень этого тренинга должен включать в себя:
Анализ требований: Что следует учитывать в контексте безопасности
Уже на уровне анализа требований к системе нужно учитывать важные аспекты, связанные с безопасностью. При этом важно разделять между собой «безопасные требования» и «требования безопасности». В SDL есть некоторый набор практик, и несколько таких из таких практик – «Анализ безопасности и приватности требований» может быть применена на этапе анализа требований. Эта практика предназначена для идентификации функциональных требований, у которых есть необходимость углубленного изучения вопросов связанных с безопасностью. Такой аудит может включать в себя следующую информацию:
Дизайн с учетом безпасности
При дизайне приложений так же можно применить ряд практик, которые помогут повысить безопасность приложения. В первую очередь это снижение площади поверхности возможных атак (Attack Surface Reduction) и моделирование угроз. Несмотря на близкую взаимосвязь этих двух понятий, первый механизм подразумевает активное снижение возможностей злоумышленника на эксплуатацию неизвестных брешей в безопасности. Для снижения площади возможных атак можно применять механизмы послойной защиты и принципы наименьших привилегий. Моделирование угроз в свою очередь позволяет предположить, какие компоненты системы могут быть рассмотрены в качестве векторов атак. Удобным инструментом для моделирования угроз является Microsoft Thread Modeling Tool базирующийся на классификации STRIDE.
Реализация с учетом безопасности
Этап реализации, как правило, наиболее трудоемкая часть проекта. Чтобы облегчить эту задачу используется множество средств, технологий и готовых компонент. В контексте безопасности важно чтобы перечень этого инструментария был заранее зафиксирован. Рекомендованным подходом является формирование перечня разрешенных при имплементации инструментов. Везде где только можно следует исключать или специально обозначать использование небезопасных или вышедших из употребления функций и компонент. В дополнение, важно использование автоматизированных средств, таких как статический анализ кода.
Фаза верификации (тестирования) с учетом безопасности
На этой фазе возможно использование таких практик как динамический анализ кода (во время выполнения) который позволяет быстро выявить аномальное поведение функций, порчу памяти, использование привилегированных функций и другие критические проблемы. Одним из инструментов который может пригодится для решения этой задачи является AppVerifier. В дополнение к стандартным функциональным тестам так же следует добавить плавающее тестирование которое предназначено для проверки приложения в режиме ввода неверных данных, неправильно сформированных параметров и других условий которые могут привести к аномальному поведению но при этом все равно система должна быть в безопасном состоянии. Так же на этом этапе важным является проверка смоделированных векторов атак на предыдущих фазах для того чтобы убедиться в корректности сформированных моделей.
Фаза Выпуска с учетом безопасности
На этой фазе важно создание плана по реакции инцидентов связанных с безопасностью, в которых будет задекларирован порядок взаимодействия и реакции на выявленные угрозы или проникновение. Финальные релизы (RTM,RTW) должны соответствовать всем заранее обговоренным на стадии дизайна условиям безопасности перед развертыванием. Если это не так, даже при соблюдении всех функциональных требований, необходим повтор стандартного цикла разработки для фиксации проблем связанных с безопасностью.
Что дальше
Конечно, эта заметка раскрывает только самые основные аспекты SDL и для успешного применения требуется дополнительное изучение. Помочь в этом может центр безопасности MSDN.
Если вы хотите узнать более подробно о SDL, посмотрите завтра прямую трансляцию докладов конференции «Microsoft Secure Software Development Conference». В том числе там будут доклады Алекса Лукаса «Эволюция цикла безопасной разработки SDL», Гленна Питавея «Внедрение SDL».
Что такое SDLC? Этапы, методология и процессы жизненного цикла программного обеспечения
Цитируя автора книги Managing Information Technology Projects Джеймса Тейлора, «жизненный цикл проекта охватывает всю деятельность проекта». Задачей же разработки ПО является выполнение требований продукта. Если вы хотите научиться создавать и выпускать высококачественное ПО, вам придется следовать плану. Со слов Тейлора, вашей целью должен стать всесторонний анализ деятельности проекта и контроля каждого этапа его разработки. Вот только с чего именно начать?
Ответить можно так: направить ваш рабочий процесс в верном направлении поможет подходящий фреймворк. В наши дни довольно сильным и популярным фреймворком является SDLC – жизненный цикл программного обеспечения.
Принципы работы SDLC и почему им пользуются
На диаграмме ниже можно ознакомиться с шестью основными этапами SDLC.
В целом, SDLC это такой замкнутый цикл, в котором каждый этап влияет на действия в последующих и дает перспективные указания на будущее. Для получения ответов на конкретные вопросы и обеспечения согласованности вашего процесса разработки все шесть этапов стараются эффективно и последовательно друг на друга влиять.
Я постараюсь абстрагироваться от тонкостей и предоставить общие примеры, подходящие для студентов и разработчиков ПО. Например, если вы по аналогии с Zoomshift пробуете создать приложение, рассчитанное на работников с почасовой оплатой, или приложение для учета времени, начать вам нужно будет с этапа анализа требований.
На этом самом основном уровне вы сможете понять каковы должны быть требования к работникам в вопросах учета времени и труда, для чего полезно будет опросить как самих работников, так и их руководящих менеджеров. Так же для большего понимания проблем текущих приложений в области вы можете протестировать ваши решения на рынке, а создание диаграмм, графиков и в целом ведение записей поможет вам более глубоко понимать количественную и качественную обратную связь. Только после осознания этих критических особенностей вы будете готовы перейти к следующему этапу SDLC – планированию.
Фаза анализа требований может оказаться очень утомительной, но проходя через эти шаги, вы добиваетесь множества результатов: снижаете время выхода продукта на рынок, обеспечиваете большую его производительность, экономите бюджет и повышаете вероятность вхождения продукта на рынок.
Мыслите за пределами обычного приложения по отслеживанию времени — думайте о том, что вы хотите создать, чем вы хотите заниматься, а затем определите требования для решения связанных с этим проблем. Это и будет вашим началом.
Этапы SDLC и лучшие практики и методологии
В ходе разработки перед переходом от текущего этапа к следующему необходимо выполнить каждый его шаг, для чего их следует лучше понимать. В этом отношении первые три этапа стараются дать ответы на проверочные вопросы, а последние три оптимизированы для достижения фактических результатов.
Давайте детальнее рассмотрим каждый этап и разберем проверочные вопросы и результаты, некоторые из которых вы можете захотеть оптимизировать под вашу конкретную ситуацию.
Этап #1: Анализ требований
На этом этапе SDLC вам необходимо получить обратную связь и поддержку от соответствующих внутренних и внешних заинтересованных сторон. Вспомните мой недавний пример с разработкой приложения по учету времени: вам нужно будет широко задуматься о том, кто станут вашими потенциальными пользователями. Некоторые идеи будут включать ваших клиентов, дизайнеров, вашего начальника или других технических специалистов команды. В целом вы хотите ответить на следующий вопрос: «Какие проблемы требуют решений?» Быть внимательным и делать заметки будет очень полезно на этом этапе.
Когда полученные ответы вас удовлетворят, вы сможете перейти к следующей фазе.
Этап #2: Планирование
На этом этапе вы ищете ответ на следующий вопрос: «Что вы хотите сделать?» Этот вопрос может вдохновить вас на понимание юнит-экономики вашего плана (затраты и выгоды), факторов снижения рисков и ожидаемых стоимостей. По аналогии с планированием отпуска, вам нужно будет разложить ваши вещи и подумать о том, что следует взять с собой.
Я много читал об истории Инстаграма, чей этап планирования занял невероятно много времени. Это совпало с бурным ростом социальных сетей, поэтому взаимодействие пользователей с продуктом во многом все еще было неизвестно. Разработчики знали, что сильный первичный опыт (съемка, редактирование и обмен фотографиями) обеспечит рост, успех и высокую конверсию, а корректное планирование упростит проектирование, поэтому планировали соответствующе и тратили на дизайн много времени. Они всегда смотрели на шаг вперед и думали о будущем социальных сетей и электронной коммерции.
Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода к третьему этапу.
Этап #3: Проектирование и дизайн
К этому этапу вы уже должны знать требования вашего продукта и в целом понимать чего вы вообще хотите, и прежде чем приступить к написанию кода, этого понимания должно быть достаточно для ответа на следующий вопрос: «Как мы добьемся наших целей?» Иначе говоря, вам необходимо понять, что именно вы оптимизируете и проектировать соответствующе.
Допустим, вы хотите создать безопасное, высокопроизводительное, эффективное и выдерживающее нагрузки приложение. Какой из этих четырех принципов наиболее для вас наиболее важен? Почему? Согласны ли с этим заинтересованные стороны из первого этапа? Важно обеспечить одобрение всех участников.
После фазы дизайна вы наконец-то сможете засесть за клавиатуры, и внесение изменений в отношении времени и потраченных ресурсов будет неуклонно расти, а также буду постепенно накапливаться всевозможные малые факторы. В этой фазе для принятия окончательных решений по вопросам дизайна я рекомендую учитывать несколько основных его элементов: операционное превосходство, безопасность, надежность, эффективность производительности, и оптимизация затрат.
Этап #4: Разработка ПО
На этапе разработки вы стремитесь не столько отвечать на вопросы, сколько произвести результаты, или, говоря точнее, вам необходимо склоняться к действиям и создать прототип или систему, испытать которую смогут другие. На этом этапе ваша задача – заручиться доверием заинтересованных сторон через воплощение образа мышления разработчика. Для соответствия результата ожиданиям критично при начале разработки следовать первым трем этапам.
Доставайте ваш компьютер, убедитесь, что окружение способствует рабочей атмосфере, хватайте ваш горячий кофе – и приступайте к делу.
Этап #5: Тестирование
Сотрудники в футболках с надписями вида «Разрабатывать круто, тестировать не очень» были для меня привычным зрелищем, но вы должны понимать, что не получится создать финальную версию продукта, пока вы на нем собаку не съедите. По завершению этого этапа вы должны будете в состоянии обеспечить рабочее состояние продукта. Отслеживайте ошибки и неточности, выслушивайте чужие точки зрения, и глубоко погружайтесь в вопрос с целью поиска тормозящих выход финального продукта ошибок. Вам просто необходимо обеспечить прочную основу.
Этап #6: Развертывание
Возьмите ваш продукт и пользуйтесь им. Предложите заинтересованным сторонам из первого этапа пользоваться вашим продуктом в естественных условиях, начните отслеживать вовлеченность в продажи. Снова и снова прислушивайтесь к пользователям, ведь благодаря обратной связи через опросы и рекомендации вы сможете вернуться к первой фазе и начать собирать новые требования. И не забудьте отпраздновать релиз.
Объединяя все вместе: подход SDLC
Фреймворк SDLC существует для помощи в сокращении времени вывода продукта на рынок, обеспечении более качественной производительности, экономии бюджета и повышения потенциальной пользы вашего продукта для заинтересованных сторон, о которых вы заботитесь. Особенно хорошо SDLC помогает при разработке ПО, поскольку он заставляет вас трудиться в строгих рамках. Другими словами, для обеспечения корректных действий в корректное время и по корректным причинам SDLC заставит вас следовать каждому необходимому шагу. Думайте о SDLC как о плане по достижению успеха: слепое ему следование ничего вам не гарантирует, но повышает вероятность что вы останетесь довольны результатами.
Разработка ПО, как все мы с вами знаем, это тема обширная, и она может затрагивать вопросы от инструментов веб-дизайна и онлайн форм до более надежного машинного обучения или систем бэкенда. Пишете ли вы код в браузере или занимаетесь более надежной разработкой, план действий вам необходим.
Разработка ПО может быть трудным, и в то же время полезным занятием.
SDLC это план по ведению технических работ, но если смотреть шире, то можно воспринимать его как руководство по жизни. Применять SDLC можно к множеству тем, например, создание контента в SaaS модели ведется по циклу SDLC. Перед написанием контента автор сначала определяет требования, планирует, что именно он будет писать, и лишь затем фактически прикладывает перо к бумаге. Также SDLC отлично подходит для технологических предпринимателей.
Мой друг хотел основать лучшее рекламное агентство для Facebook и обратился ко мне и другим специалистам за помощью. Несмотря на его большие амбиции, я посоветовал ему воспользоваться фреймворком SDLC чтобы сначала провести анализ требований. Я спросил его: «Какие проблемы ты хочешь решать? Чего хотят твои пользователи? И самое главное, как эта платформа поможет тебе достичь твоих целей?»
Сформулировав эти вопросы вокруг SDLC, он смог лучше отточить свой финальный продукт и предоставить нужные инструменты правильным пользователям. Он сузил свой кругозор до более строгого определения его проблемной области и смог выделить ресурсы на планирование еще до того как он начал делать что-либо еще.
Затем он перешел к созданию самого лучшего сервиса по росту на Instagram, но его интересы постоянно развиваются, и сейчас уже есть программы-планировщики деятельности в социальных сетях в любом масштабе. И в итоге ему придется вернуться к основам: анализу требований.
Принятие пользователями его технологий доказывает, что при правильном применении SDLC можно достичь основательных технологических и финансовых результатов. Однако, как и при развитии бизнеса, разработка ПО никогда не заканчивается.
Следовательно, цикл продолжается.
Вне зависимости от того что вы создаете, компанию ли, инструмент, сложную программу либо полностью новый продукт, чтобы обеспечить качество и сосредоточиться на пользователях, хорошим решением будет взять на вооружение SDLC.
Фраза «Создавать круто» должна стать вашей путеводной звездой, а SDLC – инструментом и помощником.
(S)SDLC, или Как сделать разработку безопаснее. Часть 1
С каждым годом культура разработки растет, появляются новые инструменты для обеспечения качества кода и новые идеи, как эти инструменты использовать. Мы уже писали про устройство статического анализа, про то, на какие аспекты анализаторов нужно обращать внимание, и, наконец, про то, как с организационной точки зрения можно построить процесс на основе статического анализа.
Отталкиваясь от вопросов, с которыми мы часто сталкиваемся, мы описали весь процесс внедрения сканера кода в процесс безопасной разработки. Сегодня речь пойдет о том, как выбрать подходящий вам анализатор.
Все разработчики так или иначе сталкиваются со статическим анализом (анализом кода без выполнения). Например, когда компилятор по результатам сборки выдает какие-то ошибки или предупреждения — это результаты статического анализа. Мы часто используем линтеры — это тоже статический анализ, хоть зачастую и очень простой. Есть и более интересные примеры — spotbugs (ранее — findbugs), который позволяет находить довольно интересные уязвимости в байткоде Java, или хорошо известный SonarQube — платформа для контроля качества кода.
Однако с полноценными SAST-инструментами пока мы сталкиваемся редко. В первую очередь мы говорим про тулы, которые могут находить сложные уязвимости. Как оказывается на практике, открытые известные инструменты не справляются с этой задачей, как минимум потому, что фокусируются на другой области (баги и простые уязвимости). Хороший SAST-тул реализует межпроцедурный анализ потока данных. Анализ должен проходить не на тексте программы, а на внутреннем представлении — CFG, AST и т.п. Про это подробнее лучше почитать в предыдущей статье.
Здесь приведем пример — всем известную SQL-инъекцию. В этом примере данные от пользователя попадают в функцию completed из запроса, передаются в функцию injectableQuery и уже там попадают в SQL-запрос, делая приложение уязвимым к SQL-инъекции.
Для того чтобы найти такую уязвимость, нужно понимать, откуда могут приходить “плохие” данные, как такие данные могут валидироваться, где их нельзя использовать. И самое важное — нужно отслеживать передачу данных по всему приложению, это и есть dataflow-анализ. Пример очень простой, в реальном же приложении данные могут пройти через множество функций и модулей, присваиваний и синонимов.
Понятно, что текстовый поиск не найдет такую уязвимость. Внутрипроцедурный анализ также не найдет, а в некоторых открытых инструментах только он и реализован. Чтобы находить такие уязвимости (а это обычно и есть самые критические уязвимости, то есть главная цель работы SAST-тула), нужны хорошо проработанные алгоритмы межпроцедурного анализа потока данных с большими базами правил.
Именно исходя из алгоритмической сложности возникает ряд технических вопросов, которые отличают внедрение SAST-инструмента от других статических анализаторов, например, SonarQube. Эти вопросы мы и обсудим в серии статей. Спойлер: потребление ресурсов, продолжительность анализа, ложные срабатывания.
Надо упомянуть, что помимо алгоритмов хороший инструмент оборачивает всю математику в удобную интерфейсную оболочку, позволяя использовать SAST без серьезной подготовки. Такие инструменты также встраиваются в CI/CD с помощью плагинов и API, таким образом автоматизируя поиск уязвимостей и позволяя строить процессы безопасной разработки.
В первой статье мы попытались классифицировать основные вопросы, которые возникают при изучении SAST, а также и после решения внедрить инструмент. О каких-то вопросах поговорим здесь, какие-то уйдут в следующие статьи.
Начнём
Зачем SAST, если уже есть бесплатные статические анализаторы?
Этот вопрос мы частично затронули в предыдущей части. Мы, конечно, ни в коем случае не умаляем заслуги открытых инструментов. Все знают SonarQube — прекрасный инструмент для автоматизации оценки качества кода, с большим количество поддерживаемых языков, интеграций и плагинов. SonarQube хорош для встраивания в процесс разработки, но предназначен больше для подсчета различных метрик кода и поиска достаточно простых ошибок или уязвимостей. В нем не реализован межпроцедурный анализ потока данных, соответственно, его нельзя использовать для поиска сложных уязвимостей. Обычно мы рекомендуем использовать как SonarQube, так и хороший SAST-тул (тут может быть полезно, если SAST-тул умеет интегрироваться с SonarQube).
Есть и другие хорошие открытые статические анализаторы. Можно назвать spotbugs (findbugs) для байткода JVM с плагином find-sec-bugs, в котором реализован внутрипроцедурный анализ потока данных с небольшим набором правил. Для Python есть известный анализатор bandit. Нельзя не упомянуть встроенный в clang статический анализатор, который обладает и хорошим движком анализа, и неплохой базой правил.
Проблемы таких инструментов в том, что обычно они довольно узко специализированы (например, подходят для одного языка), реализуют простые алгоритмы (то есть не позволяют находить сложные уязвимости), обладают сильно меньшими базами правил, чем коммерческие инструменты. Помимо этого они обладают меньшим набором функциональности, как интерфейсной, так и интеграционной. Ну и можно упомянуть отсутствие поддержки.
С другой стороны хорошие коммерческие SAST-тулы (а есть и нехорошие) реализуют сложные специфические алгоритмы и обладают обширными базами правил, которые могут насчитывать тысячи записей. Обычно они поддерживают много языков программирования, обладают богатыми возможностями интерфейса и интеграции (плагины, API). Ниже привожу пример, о каких интеграциях может идти речь.
А еще ниже посмотрите на пример схемы интеграции, которую можно построить на основе SAST-инструмента. В целом схема не отличается от внедрения других средств контроля качества кода. Разработчики пишут код и могут сразу запускать проверку SAST. Код попадает в репозиторий и оттуда по различным триггерам с помощью CI/CD попадает в SAST. Результаты сканирования можно либо смотреть в интерфейсе SAST, либо они могут попадать в средства, обеспечивающие процесс разработки (багтрекер, почту и т.п.).
Какой SAST-тул выбрать?
Немного остановлюсь на этапе выбора инструмента. SAST-тулов довольно много, на рынке обычно представлено несколько штук (3-4). Возникает вопрос, как выбрать нужный инструмент, на что обращать внимание? Тут не буду удивлять, остановлюсь на трех пунктах: функциональное сравнение, сравнение по качеству и лицензирование. Важно взять инструмент на тестирование (пилот) в свой локальный контур и проверять на своем коде в своей инфраструктуре.
Хорошо бы попробовать все фичи интерфейса, понять, насколько они применимы к вашему кейсу и насколько ими удобно пользоваться. Отсылаю к одной из предыдущих статей. Приведу несколько полезных фич:
Для проверки качества нужно просканировать ваш код. Хорошо выбрать несколько разных примеров на разных языках, чтобы выборка была репрезентативна. С точки зрения качества нужно смотреть на ложные срабатывания (там, где явно нет уязвимости, а тул показывает) и на пропуски (в идеале нужно знать, где есть уязвимости, ну или сравнивать найденные уязвимости в разных тулах). Я бы чуть меньше внимания обращал на ложные срабатывания, так как обычно достаточно один раз пройтись по результатам сканирования, пометить ложные, и дальше они не будут беспокоить вас.
Остановлюсь на двух важных моментах. Во-первых, очень важно смотреть на все это в применении именно к вашей ситуации. Проверять именно ваш код (SAST может по-разному работать на разных типах приложений). Искать те фичи, которые нужны вам для встраивания тула в процесс разработки. Проверять интеграции с системами, которые у вас есть.
Во-вторых, очень важно во время пилота общаться с вендором. SAST — не самая простая штука, и часто достаточно получить обычную консультацию от вендора, чтобы оценить в полную силу мощь инструмента.
В какой момент запускать сканирования?
При таком подходе мы еще и получаем бонус: разработчики, когда видят результаты SAST “каждый день”, продвигаются в знаниях безопасного программирования, таким образом в целом повышается культура безопасной разработки и код становится лучше.
Само собой, при внедрении SAST в процесс разработки необходимо внедрение в CI/CD, построение DevSecOps. Тренд переноса SAST с контрольных проверок перед релизом в процесс разработки виден давно, и в последние 2-3 года он догнал наш рынок. Сейчас ни один пилот не проходит без тестирований возможностей интеграции.
При этом я бы оставлял контрольные проверки перед релизом, в идеале, — по бинарным сборкам (такое тоже возможно). Так можно удостовериться, что никаких новых уязвимостей не было добавлено в процессе сборки и переноса приложения в продуктив.
Технические вопросы
А дальше приведу сразу 4 вопроса.
Организационные вопросы
Я бы не стал забывать и про организационные вопросы. В больших компаниях их возникает немало, от самого процесса внедрения, выделения ресурсов до создания регламентов и тиражирования процессов.
Организационные вопросы порождаются теми же техническими особенностями, которые мы обсуждали в предыдущем пункте. Ну а помимо этого пока никуда не девается исторически сложившееся разделение и противостояние разработки и безопасности. Также отсылаю к предыдущей нашей статье.