Что такое проверки жизненного цикла разработки безопасного по sdl

10/02/2020
Чтение занимает 2 мин

В этой статье

Включает рекомендованные проверки жизненного цикла разработки безопасности (SDL).Enables recommended Security Development Lifecycle (SDL) checks. Эти проверки изменяют связанные с безопасностью предупреждения в ошибки и устанавливают дополнительные функции создания безопасного кода.These checks change security-relevant warnings into errors, and set additional secure code-generation features.

СинтаксисSyntax

/sdl[–]/sdl[–]

/SDL включает надмножество базовых проверок безопасности, предоставляемых /GS и переопределений /GS- ./sdl enables a superset of the baseline security checks provided by /GS and overrides /GS-. По умолчанию параметр /sdl имеет значение OFF.By default, /sdl is off. /sdl- отключает дополнительные проверки безопасности./sdl- disables the additional security checks.

Проверки времени компиляцииCompile-time Checks

/sdl включает эти предупреждения как ошибки:/sdl enables these warnings as errors:

Включаемые/sdl предупрежденияWarning enabled by /sdl	Эквивалентный параметр командной строкиEquivalent command-line switch	ОписаниеDescription
C4146C4146	/we4146/we4146	Унарный оператор “минус” был применен к беззнаковому типу, что приведет к получению результата без знака.A unary minus operator was applied to an unsigned type, resulting in an unsigned result.
C4308C4308	/we4308/we4308	Отрицательная целая константа преобразуется в беззнаковый тип, что, вероятно, приведет к получению бессмысленного результата.A negative integral constant converted to unsigned type, resulting in a possibly meaningless result.
C4532C4532	/we4532/we4532	Использование continue break ключевых слов,, или goto в __finally / finally блоке имеет неопределенное поведение во время аварийного завершения.Use of continue, break, or goto keywords in a __finally/finally block has undefined behavior during abnormal termination.
C4533C4533	/we4533/we4533	Код инициализации переменной не выполняется.Code initializing a variable will not be executed.
C4700C4700	/we4700/we4700	Используется неинициализированная локальная переменная.Use of an uninitialized local variable.
C4703C4703	/we4703/we4703	Используется потенциально неинициализированная локальная переменная-указатель.Use of a potentially uninitialized local pointer variable.
C4789C4789	/we4789/we4789	Переполнение буфера при использовании определенных функций среды выполнения C (CRT).Buffer overrun when specific C run-time (CRT) functions are used.
C4995C4995	/we4995/we4995	Использование функции, помеченной директивой pragma deprecated .Use of a function marked with pragma deprecated.
C4996C4996	/we4996/we4996	Использование функции, помеченной как deprecated .Use of a function marked as deprecated.

Проверки во время выполненияRuntime checks

Если /sdl включен, компилятор создает код, выполняющий эти проверки во время выполнения:When /sdl is enabled, the compiler generates code that does these checks at run time:

Включает режим /GS обнаружения переполнения буфера во время выполнения, эквивалентный компиляции с #pragma strict_gs_check(push, on) .Enables the strict mode of /GS run-time buffer overrun detection, equivalent to compiling with #pragma strict_gs_check(push, on).
Ограничена очистка указателя.Does limited pointer sanitization. В выражениях, не затрагивающих разыменование и в типах, не имеющих пользовательских деструкторов, ссылки на указатели устанавливаются в недопустимый адрес после вызова delete .In expressions that don’t involve dereferences and in types that have no user-defined destructor, pointer references are set to a non-valid address after a call to delete. Такая очистка помогает предотвратить повторное использование устаревших ссылок на указатели.This sanitization helps to prevent the reuse of stale pointer references.
Инициализирует указатели членов класса.Initializes class member pointers. Автоматически инициализирует члены класса типа указателя до nullptr создания экземпляра объекта (перед запуском конструктора).Automatically initializes class members of pointer type to nullptr on object instantiation (before the constructor runs). Это помогает предотвратить использование неинициализированных указателей, которые конструктор не инициализирует явным образом.It helps prevent the use of uninitialized pointers that the constructor doesn’t explicitly initialize. Инициализация указателя члена, созданного компилятором, вызывается при условии, что:The compiler-generated member pointer initialization is called as long as:
- Объект не выделяется с помощью пользовательского (определенного пользователем) operator newThe object isn’t allocated using a custom (user defined) operator new
- Объект не выделяется как часть массива (например, new A[x] )The object isn’t allocated as part of an array (for example new A[x])
- Класс не управляется или не импортируетсяThe class isn’t managed or imported
- Класс имеет определенный пользователем конструктор по умолчанию.The class has a user-defined default constructor.
Для инициализации с помощью созданной компилятором функции инициализации класса элемент должен быть указателем, а не свойством или константой.To be initialized by the compiler-generated class initialization function, a member must be a pointer, and not a property or constant.

Дополнительные сведения см. в статьях предупреждения,/SDL и улучшение обнаружения неинициализированных переменных.For more information, see Warnings, /sdl, and improving uninitialized variable detection.

Установка данного параметра компилятора в среде разработки Visual StudioTo set this compiler option in the Visual Studio development environment

Откройте диалоговое окно Страницы свойств проекта.Open the project’s Property Pages dialog box. Подробнее см. в статье Настройка компилятора C++ и свойства сборки в Visual Studio.For details, see Set C++ compiler and build properties in Visual Studio.
Перейдите на страницу свойств Свойства конфигурации > C/C++ > Общие.Select the Configuration Properties > C/C++ > General property page.
Задайте свойство проверки SDL с помощью раскрывающегося списка свойств.Set the SDL checks property by using the property drop-down control. Нажмите кнопку ОК или Применить , чтобы сохранить изменения.Choose OK or Apply to save your changes.

См. также разделSee also

Параметры компилятора MSVCMSVC Compiler Options
Синтаксис командной строки компилятора КОМПИЛЯТОРОМ MSVCMSVC Compiler Command-Line Syntax

Источник

Цитируя автора книги Managing Information Technology Projects Джеймса Тейлора, «жизненный цикл проекта охватывает всю деятельность проекта». Задачей же разработки ПО является выполнение требований продукта. Если вы хотите научиться создавать и выпускать высококачественное ПО, вам придется следовать плану. Со слов Тейлора, вашей целью должен стать всесторонний анализ деятельности проекта и контроля каждого этапа его разработки. Вот только с чего именно начать?

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

Принципы работы SDLC и почему им пользуются

На диаграмме ниже можно ознакомиться с шестью основными этапами SDLC.

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

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

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

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

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

Этапы 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 – инструментом и помощником.

Источник

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

Что такое Security Development Lifecycle

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

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

Перед тем как внедрить SDL: Обучение

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

Безопасный дизайн

Снижение областей атаки
Глубокая защита
Принцип наименьших привилегий
Безопасность по умолчанию

Моделирование угроз, включая следующие темы:

Обзор моделей угроз
Влияние модели угроз на дизайн
Ограничения для стиля кодирования, базирующиеся на модели угроз

Безопасное кодирование, включая следующие темы:

Переполнение буфера (для приложений на C и C++)
Ошибки целочисленной арифметики (для приложений на C и C++)
Кросс-сайтовый скриптинг (для Веб-приложений)
SQL-инъекции (для приложений взаимодействующих с БД)
Слабая криптография

Тестирование безопасности, включая следующие темы:

Различия между тестированием безопасности и функциональным тестированием
Аудит рисков
Методы тестирования безопасности

Обеспечение приватности, включая следующие темы:

Типы приватной информации
Приватность: лучшие практики дизайна
Аудит рисков
Приватность: лучшие практики разработки
Приватность: лучшие практики тестирования

Конечно, при изучении этих тем необходимо учитывать роль (тестер, разработчик, менеджер, аналитик), тем не менее, очень важно чтобы все члены команды прошли этот тренинг.

Анализ требований: Что следует учитывать в контексте безопасности

Уже на уровне анализа требований к системе нужно учитывать важные аспекты, связанные с безопасностью. При этом важно разделять между собой «безопасные требования» и «требования безопасности». В SDL есть некоторый набор практик, и несколько таких из таких практик – «Анализ безопасности и приватности требований» может быть применена на этапе анализа требований. Эта практика предназначена для идентификации функциональных требований, у которых есть необходимость углубленного изучения вопросов связанных с безопасностью. Такой аудит может включать в себя следующую информацию:

Какая часть ПО требует анализа угроз перед релизом?
Какая часть ПО требует анализа дизайна в контексте безопасности?
Какая часть ПО требует дополнительного анализа угрозы проникновения независимой группой?
Есть ли дополнительные вопросы безопасности и риски, которые могут быть снижены?
Границы нечеткого тестирования в контексте безопасности.
Каков уровень угрозы разглашения приватных данных?

Дизайн с учетом безпасности

При дизайне приложений так же можно применить ряд практик, которые помогут повысить безопасность приложения. В первую очередь это снижение площади поверхности возможных атак (Attack Surface Reduction) и моделирование угроз. Несмотря на близкую взаимосвязь этих двух понятий, первый механизм подразумевает активное снижение возможностей злоумышленника на эксплуатацию неизвестных брешей в безопасности. Для снижения площади возможных атак можно применять механизмы послойной защиты и принципы наименьших привилегий. Моделирование угроз в свою очередь позволяет предположить, какие компоненты системы могут быть рассмотрены в качестве векторов атак. Удобным инструментом для моделирования угроз является Microsoft Thread Modeling Tool базирующийся на классификации STRIDE.

Реализация с учетом безопасности

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

Фаза верификации (тестирования) с учетом безопасности

На этой фазе возможно использование таких практик как динамический анализ кода (во время выполнения) который позволяет быстро выявить аномальное поведение функций, порчу памяти, использование привилегированных функций и другие критические проблемы. Одним из инструментов который может пригодится для решения этой задачи является AppVerifier. В дополнение к стандартным функциональным тестам так же следует добавить плавающее тестирование которое предназначено для проверки приложения в режиме ввода неверных данных, неправильно сформированных параметров и других условий которые могут привести к аномальному поведению но при этом все равно система должна быть в безопасном состоянии. Так же на этом этапе важным является проверка смоделированных векторов атак на предыдущих фазах для того чтобы убедиться в корректности сформированных моделей.

Фаза Выпуска с учетом безопасности

На этой фазе важно создание плана по реакции инцидентов связанных с безопасностью, в которых будет задекларирован порядок взаимодействия и реакции на выявленные угрозы или проникновение. Финальные релизы (RTM,RTW) должны соответствовать всем заранее обговоренным на стадии дизайна условиям безопасности перед развертыванием. Если это не так, даже при соблюдении всех функциональных требований, необходим повтор стандартного цикла разработки для фиксации проблем связанных с безопасностью.

Что дальше

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

Если вы хотите узнать более подробно о SDL, посмотрите завтра прямую трансляцию докладов конференции «Microsoft Secure Software Development Conference». В том числе там будут доклады Алекса Лукаса «Эволюция цикла безопасной разработки SDL», Гленна Питавея «Внедрение SDL».

Источник