Запись второй встречи цикла «Вокруг РБПО за 25 вебинаров. ГОСТ Р 56939-2024». Процесс N2: Обучение сотрудников.

РБПО-038. Процесс 5 — Управление недостатками и запросами на изменение программного обеспечения (часть 1/3)
Цели пятого процесса по ГОСТ Р 56939-2024:

5.5.1.1 Обеспечение управления недостатками ПО.
5.5.1.2 Обеспечение управления запросами на изменение ПО.

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

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

Так или иначе, эти инструменты уже используются в компаниях, а если нет, то про РБПО говорить рано, надо в целом подтягивать уровень процессов :) В общем, про такой крайний случай мы не говорим. Считаем, что системы контроля изменений/недостатков и системы контроля версий уже применяются. Следующий шаг — сделать использование этих систем более управляемым и контролируемым процессом благодаря внедрению регламентов.

Требования к реализации:

5.5.2.1 Разработать регламент управления недостатками ПО.
5.5.2.2 Разработать регламент управления запросами на изменение ПО.
5.5.2.3 Контролировать реализацию изменений, связанных с недостатками ПО.
5.5.2.4 Контролировать реализацию запросов на изменение в рамках жизненного цикла ПО.
5.5.2.5 Использовать средства автоматизации для управления недостатками и запросами на изменение разрабатываемого ПО.

Примечание — В качестве средств автоматизации рекомендуется использовать системы управления изменениями, системы управления задачами, системы контроля версий и т. п. При этом рекомендуется обеспечивать взаимосвязь (перекрестные ссылки) между такими системами при исправлении недостатков.

Дополнительные ссылки:
1. Александр Мешков. Как выстроить эффективный процесс управления дефектами?
2. Wikipedia. Система управления версиями.
3. Андрей Рассамакин. Управление инцидентами и проблемами — понятия и принципы.
4. AppSec Table Top: методология безопасной разработки от Positive Technologies. См. инициативы: Система контроля версий — стр. 49, Порядок работы с дефектами — стр. 78.

РБПО-039. Процесс 5 — Управление недостатками и запросами на изменение программного обеспечения (часть 2/3)
Рассмотрим артефакты 5-го процесса ГОСТ Р 56939-2024.

5.5.3.1 Регламент управления недостатками ПО должен содержать:
- порядок идентификации недостатков ПО;
- порядок управления недостатками ПО, включающий сведения о действиях, выполняемых при выявлении, устранении, тестировании, принятии решения об окончании работы с недостатком (закрытии недостатка).

5.5.3.2 Регламент управления запросами на изменение ПО должен содержать:
- порядок идентификации запросов на изменение ПО;
- порядок управления запросами на изменение ПО, включающий сведения о действиях, выполняемых при осуществлении запроса на изменение, тестировании, принятии решения о закрытии запроса на изменение.

Даже если явно это не прописано, на практике в командах действуют устоявшиеся правила об исправлениях, обзорах кода, тестировании правок и закрытии тикетов. Если это так, то внедрение РБПО — хороший повод их формализовать и записать в регламент. Скорее всего, существующие процессы при этом мало модифицируются, и регламент не внесёт дополнительные сложности в работу команды. Случай, когда каждый делал, что хотел, я не рассматриваю :)

У нас нет именно документа-регламента, т.к. мы пока не планируем проходить сертификацию, но есть заготовленные чек-листы для различных типов задач. Если до этого дойдёт, то думаю, эти чек-листы как раз и станут основой регламента. Как я понимаю, основная идея регламента — не пропустить этап (например, тестирование) и быть уверенным, что если задача закрыта, то значит она сделана. Для этого и нужны чек-листы.

Пример одной нашей заготовки, из которой формируется задача, когда выходит новая версия IDE Qt Creator. Т.е. на основании этой заготовленного чек-листа ставится задача провести работы по проверке совместимости PVS-Studio с новой версией Qt Creator и в случае необходимости что-то доработать. Ссылки заменил на жирный шрифт.

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

Примечание. Ниже не описание задачи. Как и что делать описано отдельно во внутренней статье. Это именно чек-лист, чтобы что-то не забыть. То, что вне контекста отдельные пункты смотрятся непонятно, это нормально.

Шаблон этой задачи (чек-лист)

✅Узнать требуемую версию Qt
✅Заложить новые компоненты на наше зеркало
✅Qt (Windows, Linux, macOS)
✅Qt Creator (Windows, Linux, macOS)
✅Добавить новую версию Qt в сборочное окружение
✅Windows-контейнер
✅Linux-контейнер
✅Сборочный сервер на macOS
✅Добавить CMake пресет для новой версии
✅Фиксы по коду (Windows, Linux, macOS)
✅Оттестировать новую версию на всех платформах:
✅Windows
✅Linux
✅macOS
✅Добавить новую версию в manifest плагина (extension_manifest.json)
✅Добавить / модифицировать тесты
✅Код-ревью с ___. При его отсутствии (на усмотрение тимлида)
✅Модифицировать pipeline сборки на сервере:
✅Добавить новую версию
✅Убрать прошлую
✅Проверить и актуализировать документацию по разработке плагина
✅Добавить упоминание новой версий в документации плагина
✅Удостовериться, что новая версия плагина добавляется в дистрибутив
✅Добавить новую версию плагина на страницу beta-загрузок - задача

Завтра 16.07.2025 в 16:00 по МСК состоится третий вебинар на тему "Формирование и предъявление требований безопасности к программному обеспечению".

Приглашённый гость: Павлов Артем. Начальник отдела управления испытаниями и контроля качества департамента испытаний ООО "ЦБИ", на базе которого была создана испытательная лаборатория. Участник от организации в ТК362 ФСТЭК России по разработке отечественных стандартов.

Приглашаю зарегистрироваться: Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024.

P.S. Для тех, кто уже регистрировался на предыдущие вебинары этой серии, повторная регистрация не требуется.

РБПО-040. Процесс 5 — Управление недостатками и запросами на изменение программного обеспечения (часть 3/3)
Продолжим рассматривать артефакты 5-го процесса ГОСТ Р 56939-2024.

5.5.3.3 Артефакты реализации требований, подтверждающие реализацию управления недостатками ПО, должны содержать зафиксированные факты изменений, связанных с недостатками, включающие следующую информацию:
- уникальный идентификатор недостатка ПО;
- описание недостатка ПО;
- версию ПО (модуля ПО, компонента ПО), к которому относится недостаток ПО;
- приоритет выполнения действий с недостатком ПО;
- текущий статус обработки изменений, связанных с недостатками ПО.

5.5.3.4 Артефакты реализации требований, подтверждающие реализации управления запросами на изменение ПО, должны содержать следующую информацию:
- уникальный идентификатор запроса на изменение ПО;
- краткую характеристику запроса на изменение ПО;
- версию ПО (модуля ПО, компонента ПО), к которому относится запрос на изменение;
- приоритет выполнения действий с запросом на изменение ПО;
- текущий статус обработки запроса на изменение ПО.

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

Каждой задаче (тикету) автоматически присваивается уникальный идентификатор. Краткая характеристика запроса на изменение ПО, естественно, должна присутствовать при постановке задачи. Если кто-то напишет в названии задачи "Сделать X", а в описании "см. subj", то за такое надо ..... ........ ........ (принять административные меры) и без регламента :)

Естественно, указывается версия ПО, модуля и т.д., когда описывается баг, чтобы его можно было воспроизвести. Ну или где какая новая функциональность нужна. Здесь вроде всё тоже очевидно. Достаточно просто сформулировать всё это в виде регламента и договориться, как что называется и нумеруется (см. четвёртый процесс в ГОСТ Р 56939-2024 и ГОСТ 19.103-77 — Обозначение программ и программных документов).

"Приоритет выполнения действий с запросом на изменение ПО". Кажется, в любом багтрекере необходимо установить уровень важности задачи/бага. Единственное, это хороший момент более чётко сформулировать, кто и как решает, каков будет этот приоритет. Этот пункт ещё пересекается с 23-м процессом "Реагирование на информацию об уязвимостях", но про это мы поговорим позже.

"Текущий статус обработки запроса на изменение ПО". Здесь каждый сам формирует статусы задач, теги, принципы смены этих статусов и какие комментарии надо писать в процессе работы над задачей. Думаю, самые важные моменты:
• задача не должна теряться;
• открыв задачу, любой член команды должен по описанию и комментариям понять, в чём её суть и что сейчас происходит с задачей;
• задача должна закрываться, когда она сделана и всё, что нужно, было проверено.

Презентация для тех, кто сейчас на моём докладе, но не видит код на экране :)

У нас радостная весть!

ФСТЭК России согласовал программу повышения квалификации М-БРПО «Специалист по процессам разработки безопасного программного обеспечения»🎉

Мы долго к этому шли и вот, 25 июня 2025 года, программа была согласована!

Ключевые особенности программы:
• Соответствие требованиям ФСТЭК России и актуальным стандартам в области безопасной разработки ПО.
• Углублённое изучение процессов обеспечения безопасности на всех этапах жизненного цикла ПО.
• Практико-ориентированный подход с разбором реальных кейсов и применением современных инструментов защиты.
После успешного завершения обучения слушатели получат удостоверение о повышении квалификации, подтверждающее их компетенции в области безопасной разработки программного обеспечения.

Дата старта ближайшего потока: 04.08.2025
Запись на курс доступна по ссылке Специалист по процессам разработки безопасного программного обеспечения | Форма обучения очная 200 часов / 20 дней

Запись третьего вебинара цикла "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024": Формирование и предъявление требований безопасности к программному обеспечению.

Приглашенный эксперт — Артем Павлов, начальник отдела управления испытаниями и контроля качества департамента испытаний ООО "ЦБИ".

Сплошные плюсы. Клуб С++ разработчиков. Стань докладчиком

Команда PVS-Studio вместе с Центральным университетом 7 августа устраивает очередную встречу "Клуба С++ разработчиков". Первый доклад будет от нашей команды, а второго докладчика мы хотим привлечь со стороны. Так интереснее и разнообразнее, чем если только мы будем рассказывать :)

Мы приглашаем докладчиков на это и последующие мероприятия. Можно рассказать что-то сложное и не очень, можно рассказать что-то специализированное, можно потренироваться выступать. Напишите нам тему, которая вам не даёт покоя и хочется про неё рассказать, и мы обсудим ваше участие в одной из встреч. Контакт – Симанихина Татьяна, DevRel PVS-Studio (simanikhina@viva64.com).

Например, на встрече 26 июня были доклады по таким темам:
– Типовые ошибки C и C++ программистов и как с ними бороться;
– Основы парсинга C++ кода.

Плагин PVS-Studio для OpenIDE
Анализатор PVS-Studio совместим с российской средой разработки OpenIDE.

OpenIDE — бесплатная лицензионно чистая IDE на базе IntelliJ IDEA Community Edition с открытым исходным кодом. Вся инфраструктура для сборки и работы OpenIDE расположена в России. Для отправки статистики, поиска обновлений, подключения плагинов и т.д. среда разработки обращается только к серверам на территории РФ. В маркетплейсе OpenIDE с самого первого дня доступно более 300 плагинов.

Теперь плагин PVS-Studio можно скачивать из маркетплейса дополнений OpenIDE.

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

Все части:
1) Причины разработки и выпуска нового ГОСТ Р 56939-2024 на замену версии 2016 года
2) Содержание ГОСТ Р 56939-2024 и его структура
3) Процессы РБПО 5.1-5.10 в ГОСТ Р 56939-2024
4) Процессы РБПО 5.11-5.25 в ГОСТ Р 56939-2024
5) ГОСТ Р 56939-2024: вопросы сертификации, выводы и дополнительные ссылки

О пользе присутствия на вебинарах – возможность задавать вопросы
Цикл вебинаров про ГОСТ Р 56939-2024, это не только возможность послушать, но и задать вопросы. Поднимаются очень интересные темы. Поэтому приглашаю подключаться. Впереди ещё 22 вебинара. Что-бы заинтересовать, приведу пример.

Перед вами расшифровка фрагмента секции вопросов и ответов второго вебинара "Обучение сотрудников", где приглашённым гостем был Виталий Вареница (ЗАО "НПО "Эшелон").

Расшифровка автоматическая и в тексте будут неточности, плюс местами я вырезал для лаконичности. Однако в целом это демонстрирует, какие интересные темы обсуждаются! Подробнее смотрите в записи.

Зачитывается вопрос Антона из чата: «так, сначала за заявку в ФСТЭК с РБПО, потом лаборатория, органы по сертификации ФСТЭК. Это необходимо на первом этапе для подачи заявки…»

Виталий Пиков: Немного спутались понятия.

Виталий Вареница: — Да-да-да. У Антона классический микс. Значит, тут, смотрите, я предлагаю, сделать отдельный какой-нибудь вебинар. Знаете, про что? Сертификация СЗИ и РБПО. Потому что у вас точно этого в процессах нет. Ну, в 25 процессах этого нет. А 99% вендоров, которые к нам приходят, у них плюс-минус такие же вопросы. Это уже набитая шишка, по которой мы постоянно идем.

— Вот смотрите, для того, чтобы ответить, Антон, на ваш вопрос, мне нужно где-то минут 25−30 вам сказать о том, как процессы на самом деле устроены по сертификации средств защиты информации и по сертификации РБПО. Почему? Потому что, судя по вопросу, я вижу, что есть микс. И они, к сожалению, очень часто, когда общаемся мы на форумах различных, и даже с регуляторами иногда общаемся, регуляторы тоже имеют в виду одно у себя в презентации или на слайдах, но говорят немножко про другое. Для того, чтобы в этом разобраться, ну как бы нужно понимать, то есть пройти вот эти процессы от нуля до конца, ну желательно хотя бы не один раз. Поэтому здесь, ну как бы я попытаюсь вкратце ответить, но как бы история какая, значит, «необходим на первом этапе для подачи заявки», утверждает Антон, но история какая…

— Он необходим для подачи заявки, если вы подаетесь на сертификацию процесса безопасной разработки. Если вы поддаетесь на сертификацию средств защиты информации, он не необходим. Это некорректное утверждение. Значит, там есть требование какое при сертификации средств защиты информации? Вы, как вендор, как заявитель, должны иметь базовую лицензию на разработку средств защиты конфиденциальной информации. Почему? Потому что Антон написал, ему четвертый УД интересен.

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

— Лицензия на разработку с СЗК и есть, но ФСТЭК не перепроверяет ваших людей, их компетенции, курсы и так далее. Потому что это отдельный процесс лицензирования, который был проведен уже до того момента. До наличия лицензии вы заявку на сертификацию подать не сможете, ФСТЭК ее просто не примет у вас. Следующий момент, судя по вопросу. На первом этапе это нужно сначала подать, как так написано, во ФСТЭК.

Продолжение
— «Сначала заявка во ФСТЭК с РБПО, потом в лабораторию, органы и т.д». Нет. Нет. Это неправильно. В 55-м положении четко прописано сейчас в обновлении, что заявку во ФСТЭК подают заявители с испытательной лаборатории. Более того, в заявке стоят две подписи. Подпись разработчика заявителя и начальника испытательной лаборатории. Для чего это ФСТЭК сделал?

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

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

— Поэтому первое все равно все это изучает, анализирует, выдает какие-то рекомендации, вопросы, уточнения. Это не ФСТЭК и не органы по сертификации, а именно испытательная лаборатория. А уже потом, когда испытательная лаборатория через свои фильтры прогнала и сказала, что да, окей, теперь нам не стыдно это во ФСТЭК отправить для того, чтобы решение на сертификацию получить.

— Только после этого уже там подключаются все остальные участники, потому что у нас участников 4, минимум 4. Это заявитель, это федеральный орган ФСТЭК, это испытательные лаборатория и это назначенный орган сертификации. Вот эти четыре участника процесса, сертификации и следовательской информации, они у нас прописаны в явном виде в положении сертификации в 55-м приказе.

И для примера ещё один фрагмент обсуждений

Виталий Вареница: Да. То есть история еще раз какая, смотрите. Вообще, сертификация РБПО во ФСТЭК, по утверждению, внимание, самого ФСТЭКа, неоднократному утверждению, очень много публикаций на эту тему есть, и записанных видео презентаций начальника второго управления, заместитель начальника второго управления и так далее, ФСТЭК России, там как бы абсолютно четко по-русски сказано, что наличие сертификата на процессы безопасной разработки это классная фича для разработчиков, которые получают одну классную привилегию. Какую? Они сами могут проводить все проверки своих изменений без обращения в воспитательную лабораторию или к внешнему оценщику. Почему? Почему? Ну, потому что они у себя все эти процессы внедрили, подтвердили, сертификат от стека получили, все здорово, ФСТЭК максимально доверяет как сертифицированному вендору по РБПО и не возражает, чтобы сам данный вендор, сам свой продукт периодически все изменения перепроверял. Все. На этом все плюшки, фишки, обязательные и необязательные требования по сертификации безопасной разработки заканчиваются.
--
Подписывайтесь, участвуйте, задавайте вопросы, становитесь гостями.

РБПО-041. Процесс 6 — Разработка, уточнение и анализ архитектуры программного обеспечения
Цели шестого процесса по ГОСТ Р 56939-2024:

5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.
5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.

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

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

5.6.3.1 Требования к принципам проектирования архитектуры ПО должны содержать информацию, позволяющую на начальном этапе проектирования ПО получить представление о принятых подходах и принципах проектирования архитектуры ПО (например, инкапсуляция, уникальность, разделение задач, применение заимствованных компонентов и т. п.), в том числе с точки зрения безопасности («нулевое доверие», «протоколирование событий», «резервное копирование», «формирование перечня недопустимых событий», «приоритетное использование языков с безопасной моделью памяти» и т. п.).

Чтобы не забыть про какой-то важный элемент построения безопасной архитектуры, есть смысл предварительно обратиться к другим документам:

1. Проектируя ГИС, следует сразу ознакомиться с приказом ФСТЭК 117. Он вступит в силу 1 марта 2026 года, но прочитать его стоит уже сейчас.

2. Создавая ПО для встраиваемых систем, стоит сразу заглянуть в ГОСТ Р 51904-2002. Программное обеспечение встроенных систем. Общие требования к разработке и документированию.

3. Не забыть про какую-то из угроз поможет ГОСТ Р 58412-2019. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.

4. Описать архитектуру и другие сущности поможет ГОСТ Р 58609-2019. Состав и содержание информационных элементов жизненного цикла (документации). См. раздел 10.74 — Описание архитектуры программного продукта.

5. И так далее в зависимости от типа проекта.

РБПО-042. Процесс 7 — Моделирование угроз и разработка описания поверхности атаки (часть 1/3)
Описание термина поверхность атаки см. здесь. Цели седьмого процесса по ГОСТ Р 56939-2024:

5.7.1.1 Создание условий для снижения количества недостатков, связанных с особенностями реализации архитектуры ПО и логики его функционирования, выработка мер по нейтрализации угроз безопасности, связанных с особенностями реализации архитектуры ПО.

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

При построении этого процесса важным руководствующим документом является уже упомянутый в предыдущем посте ГОСТ Р 58412-2019: Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения.

Собственно, ГОСТ Р 56939-2024 прямо на него ссылается в примечании к п.5.7.3.1:

При составлении перечня угроз безопасности и их описания рекомендуется учитывать положения ГОСТ Р 58412, а также угрозы безопасности информации Банка данных угроз безопасности информации ФСТЭК России, других источников (например, методологии STRIDE, Open Web Application Security Project (OWASP), DREAD и пр.). В модели угроз рекомендуется указывать использованную при моделировании методологию, в том числе в случае ее собственной разработки.

Зачем определять поверхности атаки? Давайте просто всё защищать, проверять и тестировать... В том-то дело, что так не получится, так как ресурсы и время ограничены. Современные программные системы содержат огромные объёмы собственного и стороннего кода. Просто невозможно и избыточно педантично изучать и проверить весь код. Необходимо выделить функции/модули, которые взаимодействуют с внешним миром и, скорее всего, будут подвергаться атаке. На них и следует сосредоточиться в первую очередь с точки зрения противостояния угрозам и более тщательного анализа/проверки/тестирования.

Ссылки по теме:
1. Павел Довгалюк. Зачем искать поверхность атаки для своего проекта.
2. SafeCode 2024. Павел Довгалюк – Анализ поверхности атаки приложений и программных систем.
3. Сигалов Даниил. Диссертация. Методы выявления поверхности атаки веб-приложений при помощи анализа клиентского JavaScript-кода.
4. OWASP. What is Attack Surface Analysis and Why is it Important.

РБПО-043. Процесс 7 — Моделирование угроз и разработка описания поверхности атаки (часть 2/3)
Каковы основные способы определения поверхности атаки?

Привлечение эксперта. Тут, думаю, всё понятно. Эксперты изучают архитектуру проекта, код, используемые библиотеки и указывают на наиболее вероятные точки будущих атак. Эксперты не смогут внимательно просмотреть миллионы строк кода, но зато смогут подсветить высокоуровневые проблемы.

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

Инструменты поиска точек входа:
1. Attack Surface Analyzer;
2. Nikto web server scanner.

Динамический анализ кода. Основным представителем является инструмент Natch, разработанный в ИСП РАН:
1. Павел Довгалюк. Как найти поверхность атаки незнакомых приложений с помощью Natch.
2. Павел Довгалюк. Разглядываем CodeScoring с помощью Natch.
3. SafeCode. Иван Васильев – Пример практического использования Natch для анализа.

В начале не понял, а потом как понял! :)))