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

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

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

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

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

Цели и участники

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

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

Принципы аудита программного обеспечения

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

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

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

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

Инструменты

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

Рекомендации