Przegląd audytu oprogramowania

Przegląd audytu oprogramowania lub audyt oprogramowania to rodzaj przeglądu oprogramowania , w którym jeden lub więcej audytorów niebędących członkami organizacji zajmującej się rozwojem oprogramowania przeprowadza „Niezależne badanie produktu oprogramowania, procesu oprogramowania lub zestawu procesów oprogramowania w celu oceny zgodność ze specyfikacjami, normami, umowami lub innymi kryteriami”.

„Oprogramowanie” odnosi się głównie, ale nie wyłącznie, do pewnego rodzaju dokumentu technicznego. standard IEEE 1028 zawiera listę 32 „przykładów oprogramowania podlegających audytowi”, w tym produkty dokumentalne, takie jak różnego rodzaju plany, umowy, specyfikacje, projekty, procedury, standardy i raporty, ale także produkty niebędące dokumentami, takie jak dane, testy danych i dostarczanych nośników.

Audyty oprogramowania różnią się od przeglądów oprogramowania i przeglądów zarządzania oprogramowaniem tym, że są przeprowadzane przez personel zewnętrzny i niezależny od organizacji opracowującej oprogramowanie i dotyczą zgodności produktów lub procesów, a nie ich zawartości technicznej, jakości technicznej lub implikacje menedżerskie.

Termin „przegląd audytu oprogramowania” został tu przyjęty na określenie formy audytu oprogramowania opisanej w IEEE Std. 1028.

Cele i uczestnicy

„Celem audytu oprogramowania jest zapewnienie niezależnej oceny zgodności produktów i procesów oprogramowania z obowiązującymi przepisami, standardami, wytycznymi, planami i procedurami”. Zalecane są następujące role:

• Inicjator (którym może być kierownik w audytowanej organizacji, klient lub przedstawiciel użytkowników audytowanej organizacji lub osoba trzecia) decyduje o potrzebie przeprowadzenia audytu, ustala jego cel i zakres, określa kryteria oceny, identyfikuje personelu audytowego, decyduje, jakie działania następcze będą wymagane, i przekazuje raport z audytu.
• Audytor wiodący (który musi być osobą „wolną od uprzedzeń i wpływów, które mogłyby ograniczyć jego zdolność do dokonywania niezależnych, obiektywnych ocen”) jest odpowiedzialny za zadania administracyjne, takie jak przygotowanie planu audytu oraz zebranie zespołu audytowego i zarządzanie nim, a także za zapewnienie, że audyt spełnia swoje cele.
• Rejestrator dokumentuje anomalie, działania , decyzje i zalecenia zespołu audytowego.
• Audytorzy (którzy muszą być, podobnie jak Audytor Wiodący, wolni od stronniczości) badają produkty określone w planie audytu, dokumentują swoje spostrzeżenia i rekomendują działania korygujące . (Może być tylko jeden audytor.)
• Audytowana organizacja zapewnia łączność z audytorami i dostarcza wszelkich informacji wymaganych przez audytorów. Po zakończeniu audytu audytowana organizacja powinna wdrożyć działania naprawcze i zalecenia.

Zasady audytu oprogramowania

Poniższe zasady audytu powinny znaleźć odzwierciedlenie:

• Terminowość: Tylko wtedy, gdy procesy i programowanie są poddawane ciągłej kontroli pod kątem ich potencjalnej podatności na błędy i słabości, ale także pod kątem kontynuacji analizy znalezionych mocnych stron lub poprzez porównawczą analizę funkcjonalną z podobnymi aplikacjami, można zaktualizować ramę bedzie kontynuowane.
• Otwartość źródła: wymaga wyraźnego odniesienia w audycie zaszyfrowanych programów, jak należy rozumieć obsługę otwartego oprogramowania. Np. programy, które oferują aplikację open source, ale nie traktują serwera komunikatorów jako open source, należy uznać za krytyczne. Audytor powinien zająć własne stanowisko wobec paradygmatu potrzeby natury open source w aplikacjach kryptologicznych.
• Dopracowanie: Procesy audytu powinny być zorientowane na pewien minimalny standard. Niedawne procesy audytu oprogramowania szyfrującego często różnią się znacznie pod względem jakości, zakresu i skuteczności, a także doświadczenia w odbiorze mediów, często odmiennych percepcji. Ze względu na potrzebę posiadania z jednej strony specjalistycznej wiedzy, az drugiej umiejętności czytania kodu programowania, az drugiej znajomości procedur szyfrowania, wielu użytkowników ufa nawet najkrótszym stwierdzeniom formalnym. Indywidualne zaangażowanie jako audytora, np. w zakresie jakości, skali i skuteczności, należy zatem ocenić samodzielnie i udokumentować w ramach audytu.

• Kontekst finansowy: Konieczna jest większa przejrzystość, aby wyjaśnić, czy oprogramowanie zostało opracowane komercyjnie i czy audyt był finansowany komercyjnie (audyt płatny). Ma znaczenie, czy jest to prywatne hobby / projekt społecznościowy, czy też stoi za nim firma komercyjna.
• Naukowe odniesienia do perspektyw uczenia się: Każda kontrola powinna szczegółowo opisywać ustalenia w kontekście, a także konstruktywnie podkreślać postępy i potrzeby rozwojowe. Audytor nie jest rodzicem programu, ale pełni rolę mentora, jeśli audytor jest uważany za część koła szkoleniowego PDCA ( PDCA = Plan-Do-Check-Act). Obok opisu wykrytych podatności powinien znajdować się również opis możliwości innowacyjnych i rozwoju potencjałów.
• Włączenie literatury: Czytelnik nie powinien polegać wyłącznie na wynikach jednej recenzji, ale także oceniać zgodnie z pętlą systemu zarządzania (np. PDCA, patrz wyżej), aby upewnić się, że zespół programistów lub recenzent był i jest przygotowany w celu przeprowadzenia dalszej analizy, a także w procesie opracowywania i przeglądu jest otwarty na naukę i rozważenie uwag innych. Do każdego audytu należy dołączyć wykaz referencji.
• Włączenie instrukcji obsługi i dokumentacji: Ponadto należy sprawdzić, czy istnieją instrukcje i dokumentacje techniczne oraz czy są one rozszerzone.
• Zidentyfikuj odniesienia do innowacji: Aplikacje, które umożliwiają zarówno przesyłanie wiadomości do kontaktów offline, jak i online, dlatego rozważanie czatu i poczty e-mail w jednej aplikacji – jak ma to miejsce również w przypadku GoldBug – powinny być testowane z wysokim priorytetem (kryterium obecności czatów dodatkowo do funkcji e-mail). Audytor powinien również podkreślić odniesienia do innowacji i uzasadnić dalsze potrzeby w zakresie badań i rozwoju.

Ta lista zasad audytu aplikacji kryptograficznych opisuje - poza metodami analizy technicznej - w szczególności podstawowe wartości, które należy wziąć pod uwagę

Narzędzia

Części audytu oprogramowania można przeprowadzić za pomocą narzędzi do analizy statycznej, które analizują kod aplikacji i oceniają jego zgodność ze standardami, wytycznymi, najlepszymi praktykami. Z listy narzędzi do statycznej analizy kodu niektóre obejmują bardzo szerokie spektrum, od kodu po przegląd architektury i mogą być wykorzystane do testów porównawczych.