Bezpieczeństwo wytwarzanego oprogramowania nie jest wynikiem przypadku. Żeby otrzymać aplikację wolną od podatności trzeba wpisać bezpieczeństwo w cały cykl rozwojowy oprogramowania. Postanowiliśmy sprawdzić czy i jakie metody osiągnięcia tego celu są stosowane w firmach tworzących oprogramowanie. Prezentujemy raport z badania praktyk wytwarzania bezpiecznego oprogramowania przeprowadzonego przez nas podczas konferencji 4Developers 2014.

1. 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.

2. SecuRingBadanie“praktykiwytwarzaniabezpiecznegooprogramowania”
2
Celem badania było sprawdzenie, jakie praktyki w zakresie wytwarzania
bezpiecznegooprogramowaniasąstosowanew polskichfirmach.Badaniepolegał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:•
śledzenienabieżącoi reagowanienabłędywykrywanew 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.
Mniejniżpołowaz osób,któremiałydoczynieniaz testamibezpieczeń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.
Streszczenie

3. SecuRingBadanie“praktykiwytwarzaniabezpiecznegooprogramowania”
3
Badanie przeprowadziliśmy podczas konferencji 4Developers 6 kwietnia
2014.Danezbieranebyłyzapomocąformularzyankietowychwypełnianych
przez uczestników konferencji.
Metodyka
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,
w których uczestniczą, mogą być obiektem ataków.
56%
17%
17%
6%
4%
programista
starszy programista
stanowisko
managerskie
tester
analityk/architekt
1
http://www.opensamm.org/

4. SecuRingBadanie“praktykiwytwarzaniabezpiecznegooprogramowania”
4
Badane praktyki
W ankiecie pytaliśmy o następujące praktyki, mające na celu wytwarzanie bezpiecznego
oprogramowania:
Zarządzanie
Prewencja
Analiza
i Projektowanie
Wytwarzanie
i wdrażanie
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.
Analiza najbardziej prawdopodobnych zagrożeń i dobranie•
odpowiednich dla nich zabezpieczeń (modelowanie zagrożeń).
Opisywanie w specyfikacji wymagań dotyczących•
bezpieczeństwa – w tym wymagań niefunkcjonalnych.
Formułowanie wymagań dotyczących bezpieczeństwa na•
podstawie analizy ryzyka lub zasad dobrej praktyki i zgodności
z obowiązującymi przepisami.
Przeglądy kluczowych części kodu w zakresie bezpieczeństwa.•
Testy bezpieczeństwa przed wdrożeniem, zgodnie z przyjętymi•
wymaganiami.
Implementacja poprawek wynikających z testów•
bezpieczeństwa.
Stosowanie narzędzi automatycznych, wyszukujących defekty•
bezpieczeństwa.
Obszar Praktyki

5. SecuRingBadanie“praktykiwytwarzaniabezpiecznegooprogramowania”
5
WynikiBadania
Najczęściej stosowane praktyki
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
Prew
encja
Analiza
i
projektow
anie
W
ytw
arzanie
iw
drazanie

6. SecuRingBadanie“praktykiwytwarzaniabezpiecznegooprogramowania”
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

7. SecuRingBadanie“praktykiwytwarzaniabezpiecznegooprogramowania”
7
Wytwarzanie i wdrażanie
Tylko 42% badanych potwierdziło, że przed wdrożeniem wykonują lub zamawiają testy bezpieczeństwa,
natomiast aż 73% pytanych potwierdziło, że implementowali poprawki wynikające z testów
bezpieczeństwa. Prawdopodobnie ta różnica wynika z tego, że często testy bezpieczeństwa wykonuje
jedynie odbiorca oprogramowania.
Warto przy tym zauważyć, że tylko 43% 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 i nie
wzbudzał kontrowersji”.
Wśród ankietowanych nie znalazł się ani jeden przypadek, w którym testy bezpieczeństwa były
wykonywane, ale nie skutkowało to wprowadzeniem koniecznych poprawek.
Około połowa ankietowanych firm (46%) stosuje narzędzia automatycznie wyszukujące defekty
bezpieczeństwa. Natomiast aż 65% pytanych stwierdziło, że w ich firmach są stosowane przeglądy
kluczowych części kodu w zakresie bezpieczeństwa.
Analiza i projektowanie
44% odpowiadających na pytania potwierdziło, że w ich firmach stosuje się modelowanie zagrożeń,
tzn. są analizowane najbardziej prawdopodobne zagrożenia dotyczące ataków na aplikacje. Podobna
liczba osób (48%) stwierdziła również, że wymagania dotyczące bezpieczeństwa są formułowane
na podstawie analizy ryzyka lub zasad dobrej praktyki i zgodności z obowiązującymi przepisami.
Natomiast tylko 31% ankietowanych potwierdziło, że wymagania dotyczące bezpieczeństwa są opisane
w specyfikacji. Można z tego wyciągnąć wniosek, że w znacznej części projektów bezpieczeństwo
jest uwzględniane, ale wymagania w tym zakresie nie są spisywane, co powoduje, że nie mogą być
w sposób uporządkowany weryfikowane podczas wytwarzania i wdrażania.
44%
31%
48%
73%
65%
42%
46%
Analiza najbardziej prawdopodobnych zagrożeń i dobranie odpowiednich
dla nich zabezpieczeń (modelowanie zagrożeń).
Przeglądy kluczowych części kodu w zakresie bezpieczeństwa.
Opisywanie w specyfikacji wymagań dotyczących bezpieczeństwa – w tym
wymagań niefunkcjonalnych.
Formułowanie wymagań dotyczących bezpieczeństwa na podstawie
analizy ryzyka lub zasad dobrej praktyki i zgodności z obowiązującymi
przepisami.
Testy bezpieczeństwa przed wdrożeniem, zgodnie z przyjętymi
wymaganiami.
Implementacja poprawek wynikających z testów
bezpieczeństwa.
Stosowanie narzędzi automatycznych, wyszukujących defekty
bezpieczeństwa.

8. SecuRingBadanie“praktykiwytwarzaniabezpiecznegooprogramowania”
8
SecuRing to zespół ekspertów zajmujących się bezpieczeństwem aplikacji
i systemów informatycznych. Naszą misją jest zapewnienie wsparcia dla
naszych partnerów na każdym etapie procesu, jakim jest zarządzanie
bezpieczeństwem aplikacji.OSecuRing
Oferujemy między innymi:
testy bezpieczeństwa aplikacji webowych, mobilnych, WebService,•
grubego klienta, embeded systems, SaaS i innych,
analizę ryzyka, modelowanie zagrożeń – przed przystąpieniem•
do implementacji,
wsparcie w definiowaniu założeń dotyczących bezpieczeństwa,•
ocenę projektu systemu pod względem bezpieczeństwa,•
pomoc we wpisaniu bezpieczeństwa w cały cykl rozwoju i utrzymania•
systemów.
Nasza firma działa od 2003 roku i w tym okresie z naszych usług
skorzystały czołowe banki, instytucje ubezpieczeniowe, operatorzy
telekomunikacyjni, firmy tworzące oprogramowanie, a także instytucje
administracji centralnej zarówno w Polsce jak i za granicą. Staramy się
dostarczać usług o wysokiej jakości, opartych na wiedzy naszych pracowników
i doświadczeniu firmy.
Przejrzyj nasze prezentacje i raporty: http://www.slideshare.net/wojdwo.
Nasza strona www: http://www.securing.pl
Koszt usuwania defektów bezpieczeństwa wykrytych przez odbiorcę
aplikacji jest wielokrotnie wyższy, niż koszt wykrycia i usunięcia
potencjalnego defektu po stronie firmy wykonującej aplikację. Nasz
zespół zdobywał swoje doświadczenie pracując przez wiele lat przy
testach bezpieczeństwa dla klientów końcowych. Jeśli chcesz mieć
pewność, że aplikacje i systemy dostarczane przez Twoją firmę są właściwie
zabezpieczone i pragniesz, by klienci Twojej firmy postrzegali ją jako partnera,
do którego produktów można mieć zaufanie – skorzystaj z naszych
usług.
Jeśli chcesz uzyskać więcej informacji, skontaktuj się z nami pod telefonem
+48 12 4252575 lub email-em info@securing.pl.
www.securing.pl
info@securing.pl
+48 12 4252575