Обзор аудита программного обеспечения

Аудит программного обеспечения или проверка программного обеспечения — это тип проверки программного обеспечения , при котором один или несколько аудиторов, не являющихся членами организации по разработке программного обеспечения, проводят «независимую проверку программного продукта, программного процесса или набора программных процессов для оценки соответствия спецификациям, стандартам, договорным соглашениям или другим критериям». ^[1]

«Программный продукт» в основном, но не исключительно, относится к некоторому техническому документу. Стандарт IEEE 1028 ^[2] предлагает список из 32 «примеров программных продуктов, подлежащих аудиту», включая документальные продукты, такие как различные виды планов, контрактов, спецификаций, проектов, процедур, стандартов и отчетов, а также недокументальные продукты, такие как данные, тестовые данные и поставляемые носители.

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

Термин «обзор аудита программного обеспечения» принят здесь для обозначения формы аудита программного обеспечения, описанной в стандарте IEEE 1028.

«Целью аудита программного обеспечения является предоставление независимой оценки соответствия программных продуктов и процессов применимым нормам, стандартам, руководствам, планам и процедурам». ^[3] Рекомендуются следующие роли:

• Инициатор (который может быть менеджером проверяемой организации, представителем заказчика или пользователя проверяемой организации или третьей стороной) принимает решение о необходимости проведения аудита, устанавливает его цель и объем, указывает критерии оценки, определяет персонал для проведения аудита, решает, какие последующие действия потребуются, и распространяет отчет об аудите.
• Ведущий аудитор (который должен быть «свободным от предвзятости и влияния, которые могут снизить его способность давать независимые, объективные оценки») отвечает за выполнение административных задач, таких как подготовка плана аудита, формирование и управление аудиторской группой, а также за обеспечение того, чтобы аудит соответствовал своим целям.
• Регистратор документирует аномалии, действия, решения и рекомендации, вынесенные аудиторской группой .
• Аудиторы (которые, как и ведущий аудитор, должны быть беспристрастны) проверяют продукты, определенные в плане аудита, документируют свои наблюдения и рекомендуют корректирующие действия. (Аудитор может быть только один. )
• Проверенная организация обеспечивает связь с аудиторами и предоставляет всю информацию, запрашиваемую аудиторами. После завершения аудита проверенная организация должна выполнить корректирующие действия и рекомендации.

Должны найти отражение следующие принципы аудита: ^[4]

• Своевременность: Только тогда, когда процессы и программирование постоянно проверяются на предмет их потенциальной подверженности ошибкам и слабым сторонам, а также с учетом продолжения анализа обнаруженных сильных сторон или путем сравнительного функционального анализа с аналогичными приложениями, можно продолжить обновление структуры.
• Открытость исходного кода: Требует явного указания в аудите зашифрованных программ, как следует понимать обработку открытого исходного кода. Например, программы, предлагающие приложение с открытым исходным кодом, но не рассматривающие сервер IM как открытый исходный код, должны рассматриваться как критические. Аудитор должен занять собственную позицию в парадигме необходимости открытого исходного кода в криптологических приложениях.
• Проработанность: Процессы аудита должны быть ориентированы на определенный минимальный стандарт. Недавние процессы аудита программного обеспечения для шифрования часто сильно различаются по качеству, объему и эффективности, а также опыту в приеме средств массовой информации, часто различающихся по восприятию. Из-за необходимости специальных знаний, с одной стороны, и умения читать программный код, а с другой стороны, также иметь знания о процедурах шифрования, многие пользователи доверяют даже самым кратким заявлениям формального подтверждения. Индивидуальные обязательства как аудитора, например, по качеству, масштабу и эффективности, должны, таким образом, оцениваться рефлексивно для себя и документироваться в рамках аудита.
• Финансовый контекст: необходима дополнительная прозрачность для выяснения того, было ли программное обеспечение разработано на коммерческой основе и финансировался ли аудит на коммерческой основе (платный аудит). Имеет значение, является ли это частным хобби/общественным проектом или за ним стоит коммерческая компания.
• Научная ссылка на перспективы обучения: каждый аудит должен подробно описывать результаты в контексте, а также конструктивно выделять прогресс и потребности в развитии. Аудитор не является родителем программы, но выполняет роль наставника, если аудитор рассматривается как часть круга обучения PDCA ( PDCA = Plan-Do-Check-Act). Рядом с описанием обнаруженных уязвимостей должно быть также описание инновационных возможностей и развитие потенциалов.
• Включение литературы: Читатель не должен полагаться исключительно на результаты одного обзора, но также судить по циклу системы управления (например, PDCA, см. выше), чтобы убедиться, что группа разработчиков или рецензент были и готовы провести дальнейший анализ, а также в процессе разработки и обзора открыты для обучения и рассмотрения замечаний других. Список ссылок должен прилагаться в каждом случае аудита.
• Включение руководств пользователя и документации: Далее следует проверить, имеются ли руководства пользователя и техническая документация, и расширены ли они.
• Определите ссылки на инновации: Приложения, которые позволяют как отправлять сообщения офлайн-, так и онлайн-контактам, поэтому рассматривают чат и электронную почту в одном приложении - как это также имеет место в случае с GoldBug - должны быть протестированы с высоким приоритетом (критерий присутствия чатов в дополнение к функции электронной почты). Аудитор должен также выделить ссылки на инновации и обосновать дальнейшие потребности в исследованиях и разработках.

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

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