Jednym z projektów OWASP jest projekt Application Security Verification Standards. Warto przyglądnąć się udostępnionym dokumentom (choć znajdują się wciąż w fazie beta)
Do zapisania w umowie: Application Security Verification Standards
Pisałem kilka razy o tym, że częstym problemem lub raczej błędem popełnianym przez klientów zamawiających aplikacje internetowe jest brak wyspecyfikowania w umowie warunków akceptacji aplikacji. Temat ten pojawił się również na spotkaniu SPIN podczas dyskusji (bo do slajdów dotyczących tego tematu nie doszedłem, patrz: materiały ze spotkania SPIN). Sam kilka razy stosowałem wymagania związane z OWASP Top10, co było rozwiązaniem niedoskonałym, ale lepszym niż nic. Obecnie pewnym wsparciem dla klientów może być ASVS. Definiuje on cztery poziomy weryfikacji:
- Level 1 – Automated Verification
- Level 1A – Dynamic Scan (Partial Automated Verification)
- Level 1B – Source Code Scan (Partial Automated Verification)
- Level 2 – Manual Verification
- Level 2A – Penetration Test (Partial Manual Verification)
- Level 2B – Code Review (Partial Manual Verification)
- Level 3 – Design Verification
- Level 4 – Internal Verification
W rozdziale Detailed Verification Requirements dostępne są szczegółowe punkty kontrolne, które aplikacja musi spełniać, by zaliczyć określony poziom. Jak widać lista jest dość rozbudowana, ale ogólna, tak więc może istnieć konieczność dopisania dodatkowych punków w przypadku specyficznych aplikacji. Listy te, nawet w postaci "domyślnej", są według mnie doskonałym kandydatem do wpisania w umowie jako warunków odbioru aplikacji (pod względem bezpieczeństwa). Tylko jedna uwaga - by wymagania miały sens, muszą być możliwe do zweryfikowania. Zwracam uwagę na fakt, że poziomy 2B, 3 i 4 są naprawdę wymagające, jeśli chodzi o sam proces weryfikacji. Moim zdaniem tworzenie zapisów w umowie, których później nie można egzekwować/wykonać, mija się z celem. W większości przypadków w zupełności wystarcza 2A ewentualnie uzupełnione przez elementy przeglądu kodu z 2B (i 2009 CWE/SANS Top 25 Most Dangerous Programming Errors).
UWAGA: na upartego weryfikację aplikacji pod kątem zgodności z takimi wymaganiami można określić mianem audytu. Osobiście jednak chyba optowałbym za użyciem pojęcia weryfikacja zgodności.
