Secure_Coding

9. 1 . Жизненный цикл разработки безопасного программного обеспечения 439

Планирование и отслеживание

Команды TSP-Secure строят собственные планы. Первоначальное планирование вклю­
чает выбор языков программирования, которые будут использованы при реализации
проекта , и подготовку стандартов безопасного кодирования для этих языков. Выбирают­
ся также инструменты статического анализа и определяются первые правила статичес­
кого анализа. Определяется стратегия безопасной разработки, которая включает в себя
решения, такие как когда выполняется моделиров ание угроз, когда в процессе жизнен­
ного цикла разработки применяются инструменты статического анализа и как метрики
моделирования и анализа могут использоваться для уточнения стратегии разработки.
Следующий этап планирования проводится во время запуска проекта, в ходе которого
за три-четыре дня проходит несколько собраний, как показано на рис. 9.3. Запуском ру­
ководит квалифицированный тренер. В TSP-Secure при запуске проекта члены команды
достигают общего пони мания работы и подходов, которые они будут применять для ее
выполнения, готовят подробный план руководства работой и получают поддержку этого
плана руководством.

Начальное планирование День 1 День 2 День З

Выбор ЯЗЫКОВ � Определение Разработка П одгото вка
п рогра м м и ро ва н и я б и з нес - целе й г+ плана качества r+ к просмотру

и стандартов � руководством
безопасного
код и ро ва н и я

� ��

Определ ен ие Ра сп редел ен и е П острое н ие П росмотр
и н струмен то в ролей дета л ь н ых руководством
и правил статического персо н ал ь н ых
и определение
анализа целей команды планов

iiii

Генерация стратегии Генерация стратегии Вы п ол н ен ие Анализ
безоп асн ой разработки оценки риска в ы п ол н ен ия
разработки и процессов
отладки запуска

1�1

Разработка Квал ифицированный тренер TSP
дол госроч н ого
и краткосрочного руководит командой в процессе разработки планов
и ведет переговоры с заинтересованными лицами

планов

1
Рис. 9.3. Запуск проекта

1440 Рекомендованные практики

В конце запуска проекта TSP-Secure команда и руководство договариваются о том, как
команда будет работать над проектом. По мере завершения задач из краткосрочных пла-
нов команда проводит "перезапуск" проекта, во время которого детально планирует сле-
дующий цикл работы. После каждого цикла проводится также анализ, при котором среди
прочего оцениваются вопросы планирования, выполнения и качества, безопасность, ин­
струментарии и различные показатели, и на основе полученных результатов выполняются
необходимые корректировки. Перезапуск проекта похож на его запуск, но несколько коро­
че по продолжительности . Циклы планирования работы выполняются до полного завер­
шения проекта.

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

Управление качеством

Дефекты в окончательных версиях выпускаемого программного обеспечения представ­
ляют собой проценты от общего количества дефектов, вносимых во время жизненного
цикла разработки. Стратегия управления качеством TSP-Secure заключается в наличии
множества точек устранения дефектов в жизненном цикле разработки программного обес­
печения. Увеличение количества таких точек увеличивает вероятность обнаружения де­
фектов сразу же после внесения; оно позволяет легче исправлять обнаруженные проблемы
и более просто устанавливать и устранять их первопричины.

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

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

Разработчики программного обеспечения должны быть осведомлены об аспектах бе­
зопасности, влияющих на разрабатываемое ими программное обеспечение. Поэтому
TSP-Secure включает семинар по уведомлению, участникам которого предоставляется ог­
раниченное множество вопросов, связанных с безопасностью. Такой семинар обычно на­
чинается с обзора общей уязвимости. Также на нем должны быть представлены практики
проектирования, а также реализации и тестирования для устранения распространенных
причин уязвимостей.

9.2. Обучение 1 441

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

. .··:=.: .: .... ._ .,,,<::: , Проектирование

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

Реа л и за ц и я

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

пересмотра кода ,динамического
и статического анализа и тестирования .

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

Рис. 9.4. Фильтрация уяз8имостей

• 9.2. Обучение

Образование играет важнейшую роль в решении проблем кибербезопасности будуще­
го, в частности - участие в разработке учебных программ, которые учитывают принципы
и практику безопасного программирования [209] . Чтобы поддержать этот процесс, дирек­
ции Национального научного фонда (National Science Foundation Directorates) в области
кибернетики и информатики (Computer and Information Science and Engineering - CISE)
и в области образования и кадров ( Education and Human Resources - EHR) совместно ор­
ганизовали саммит по вопросам образования в области безопасного программного обес­
печения ( Summit оп Education in Secure Software - SESS ) , состоявшийся в Вашингтоне,
округ Колумбия, в октябре 201 О года. Целью саммита была разработка дорожной карты,
показывающей, как лучше обучать студентов и специалистов концепциям и практике на­
дежного, безопасного программирования, и определение того, какие для этого требуются
ресурсы и какие проблемы необходимо преодолеть. Саммит выработал десять конкретных
рекомендаций [ 3 1 ] , включая следующие.