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

A аудит программного обеспечения или аудит программного обеспечения - это тип обзора программного обеспечения, в котором один или несколько аудиторов, не являющихся членами организации разработка программного обеспечения, проводят «независимую экспертизу программного продукта, программного процесса или набора программных процессов для оценки соответствия спецификациям, стандартам, договорным соглашениям и т. д. критерии ".

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

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

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

• 1 Цели и участники
• 2 Принципы аудита программного обеспечения
• 3 Инструменты
• 4 Ссылки

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

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

Следующие принципы аудита должны найти отражение:

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

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

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

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