SecuRing Badanie praktyki wytwarzania bezpiecznego oprogramowania Raport Na wstępie pragniemy serdecznie podziękować ponad 50 specjalistom z firm zajmujących się wytwarzaniem oprogramowania, którzy zechcieli poświęcić swój czas i wziąć udział w naszym badaniu.
8
Embed
Raport z badania - Praktyki wytwarzania bezpiecznego oprogramowania
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Na wstępie pragniemy serdecznie podziękować ponad 50 specjalistom z firm zajmujących się wytwarzaniem oprogramowania, którzy zechcieli poświęcić swój czas i wziąć udział w naszym badaniu.
Secu
Rin
g Ba
dan
ie “
prak
tyki
wyt
war
zan
ia b
ezpi
eczn
ego
opro
gram
owan
ia”
2
Celem badania było sprawdzenie, jakie praktyki w zakresie wytwarzania
bezpiecznego oprogramowania są stosowane w polskich firmach. Badanie polegało
na przeprowadzeniu ankiety wśród specjalistów uczestniczących w konferencji
4Developers 2014.
Kluczowe wnioski wynikające z opracowania wyników ankiet.
Najczęściej stosowane praktyki:•
śledzenie na bieżąco i reagowanie na błędy wykrywane w stosowanych »
komponentach, frameworkach i bibliotekach,
testy bezpieczeństwa i implementacja poprawek wynikających z tych »
testów,
przeglądy kluczowych części kodu w zakresie bezpieczeństwa. »
Praktyki te stosowane są w ponad połowie badanych firm.
Szkolenia z zakresu bezpiecznego programowania (nawet na poziomie •
podstawowym) w dalszym ciągu nie są powszechnie stosowane, mimo iż
jest to skuteczny i łatwy do wprowadzenia środek prewencyjny.
W znacznej części projektów bezpieczeństwo jest na pewnym poziomie •
uwzględniane, ale wymagania w tym zakresie nie są spisywane, tak więc
również nie mogą być w sposób uporządkowany weryfikowane podczas
wytwarzania i wdrażania.
W większości projektów • (73%) są wprowadzane poprawki wynikające
z testów bezpieczeństwa i nie znalazł się ani jeden przypadek, w którym
po wykonaniu testów bezpieczeństwa nie trzeba byłoby takich poprawek
wprowadzać.
Testy bezpieczeństwa często są wykonywane • jedynie przez odbiorcę
oprogramowania.
Mniej niż połowa z osób, które miały do czynienia z testami bezpieczeństwa, •
uznało, że dostarczony przez wykonawcę testów bezpieczeństwa raport
był zrozumiały. Tak więc istnieje widoczna konieczność poprawy jakości
usług testowania bezpieczeństwa.
Stre
szcz
enie
Secu
Rin
g Ba
dan
ie “
prak
tyki
wyt
war
zan
ia b
ezpi
eczn
ego
opro
gram
owan
ia”
3
Badanie przeprowadziliśmy podczas konferencji 4Developers 6 kwietnia
2014. Dane zbierane były za pomocą formularzy ankietowych wypełnianych
przez uczestników konferencji. M
etod
yka
Pytania zostały skonstruowane na podstawie standardu OWASP OpenSAMM
“Security Assurance Maturity Model”1 w zakresie pierwszej fazy wdrożenia
zasad dobrej praktyki dla firm produkujących oprogramowanie.
Uczestnicy badania
W badaniu wzięło udział 52 pracowników z 42 firm. Większość
ankietowanych to programiści (56%) lub starsi programiści (17%). 17% osób
pracowało na stanowiskach managerskich.
Większość z odpowiadających na pytania stwierdziło, że z tematami
dotyczącymi bezpieczeństwa aplikacji ma do czynienia na co dzień (31%) lub
czasami (48%). Natomiast zdaniem 73% biorących udział w badaniu projekty,
Najczęściej stosowane dobre praktyki według wypełniających naszą ankietę
to:
śledzenie na bieżąco i reagowanie na błędy wykrywane w stosowanych •
komponentach, frameworkach i bibliotekach (77% odpowiedzi). Wynik
ten jest zgodny z rezultatami innych badań, np. monitoringu repozytoriów
komponentów (szczegóły poniżej w rozdziale „Prewencja” ),
testy bezpieczeństwa i implementacja poprawek wynikających z tych •
testów (73%). Należy jednak zauważyć, że znaczna część tych testów
to prawdopodobnie testy wykonywane przez odbiorcę oprogramowania
(szczegóły w rozdziale „Wytwarzanie i wdrażanie” ),
przeglądy kluczowych części kodu w zakresie bezpieczeństwa (65%).•
38% 38% 38%
77%
44%48%
31%
73%
65%
42%46%
Zarządzanie
Prewencja
Analiza i
projekto
wanie
Wytw
arzanie i w
drazanie
Secu
Rin
g Ba
dan
ie “
prak
tyki
wyt
war
zan
ia b
ezpi
eczn
ego
opro
gram
owan
ia”
6
Zarządzanie
W ankiecie pytaliśmy czy w firmach, w ramach kluczowych projektów, jest stosowany wystandaryzowany
program zapewnienia bezpieczeństwa wytwarzanego oprogramowania oraz czy jest wyznaczona
osoba odpowiedzialna za bezpieczeństwo aplikacji. W obydwu przypadkach ilość odpowiedzi
twierdzących była taka sama – około 38%. Zastanawiająca jest jednak korelacja między tymi
odpowiedziami. Tylko co czwarty ankietowany, który twierdził, że w firmie istnieje spójny program
zapewnienia bezpieczeństwa, odpowiedział twierdząco na pytanie dotyczące osoby odpowiedzialnej
za bezpieczeństwo aplikacji. Wyznaczenie takiej osoby jest kluczowym elementem każdego programu
zapewnienia jakości.
Prewencja
Pytaliśmy o dwie praktyki prewencyjne – o szkolenia oraz monitorowanie błędów ujawnianych
w stosowanych komponentach. Większość (77%) odpowiadających stwierdziła, że śledzą błędy
wykrywane we frameworkach i bibliotekach oraz reagują na te informacje. Uzyskane dane w pewnym
stopniu pokrywają się z niezależnymi badaniami Sonatype i Aspect Security2, z których wynikło,
że w 26% przypadków stosowane są „dziurawe” wersje bibliotek i frameworków.
Na pytanie czy architekci, programiści i testerzy przeszli podstawowe przeszkolenie z zakresu
bezpiecznego programowania 38% badanych odpowiedziało twierdząco. To niewiele, jeśli weźmiemy
pod uwagę, że jest to podstawowy, bardzo skuteczny i łatwy do wprowadzenia środek zmierzający
do podniesienia jakości oprogramowania w zakresie bezpieczeństwa.
38%
38%
38%
77%
Wdrożenie uporządkowanego planu zapewnienia bezpieczeństwa wytwarzanego lub zamawianego oprogramowania.
Wyznaczenie osoby odpowiedzialnej za bezpieczeństwo aplikacji.
Szkolenia z zakresu bezpieczeństwa oprogramowania.
Śledzenie i reagowanie na błędy wykrywane w stosowanych
komponentach, frameworkach i bibliotekach.
2 The Unfortunate Reality of Insecure Libraries: https://www.aspectsecurity.com/uploads/downloads/2012/03/Aspect-Security-The-Unfortunate-Reality-of-Insecure-Libraries.pdf