{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Strach i nienawi\u015b\u0107 DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mieli\u015bmy 2 analizatory kodu, 4 narz\u0119dzia do testowania dynamicznego, w\u0142asne wynalazki i 250 skrypt\u00f3w. Nie to, \u017ceby to wszystko by\u0142o potrzebne w obecnym procesie, ale skoro zacz\u0105\u0142em wdra\u017ca\u0107 DevSecOps, to trzeba to zrobi\u0107 do ko\u0144ca.<\/p>\n

\"Strach
\n
\n\u0179r\u00f3d\u0142o<\/a><\/noindex>. Autorzy postaci: Justin Roiland i Dan Harmon.<\/i><\/p>\n

Czym jest SecDevOps? A DevSecOps? Jakie s\u0105 r\u00f3\u017cnice? Bezpiecze\u0144stwo aplikacji - o czym to? Dlaczego klasyczne podej\u015bcie ju\u017c nie dzia\u0142a? Na wszystkie te pytania zna odpowied\u017a Jurij Szabalin<\/b> z\u00a0Swordfish Security. <\/b>Jurij szczeg\u00f3\u0142owo na wszystko odpowie i om\u00f3wi problemy zwi\u0105zane z przej\u015bciem od klasycznego modelu bezpiecze\u0144stwa aplikacji do procesu DevSecOps: jak prawid\u0142owo podej\u015b\u0107 do integracji procesu bezpiecznego rozwoju w proces DevOps i niczego przy tym nie zepsu\u0107, jak przej\u015b\u0107 przez g\u0142\u00f3wne etapy testowania na bezpiecze\u0144stwo, jakie narz\u0119dzia mo\u017cna stosowa\u0107, czym si\u0119 r\u00f3\u017cni\u0105 i jak je prawid\u0142owo skonfigurowa\u0107, aby unikn\u0105\u0107 pu\u0142apek.
\n<\/a><\/noindex>
\n

\r\n \"Odtwarzaj\r\n
<\/div>\r\n <\/div><\/center>
\nO prelegencie:<\/b> Jurij Szabalin - <\/b>G\u0142\u00f3wny architekt bezpiecze\u0144stwa w firmie Swordfish Security<\/b>. Odpowiada za wdro\u017cenie SSDL, za og\u00f3ln\u0105 integracj\u0119 narz\u0119dzi analizy aplikacji w jedn\u0105 ekosystem\u0119 rozwoju i testowania. 7 lat do\u015bwiadczenia w bezpiecze\u0144stwie informacji. Pracowa\u0142 w Alfa-Bank, Sberbank i w Positive Technologies, kt\u00f3ra rozwija oprogramowanie i dostarcza us\u0142ugi. Prelegent mi\u0119dzynarodowych konferencji ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Bezpiecze\u0144stwo aplikacji: o czym to?<\/h2>\n

\nBezpiecze\u0144stwo aplikacji<\/b>\u00a0to dzia\u0142 bezpiecze\u0144stwa, kt\u00f3ry odpowiada za bezpiecze\u0144stwo aplikacji. To nie odnosi si\u0119 do infrastruktury ani do bezpiecze\u0144stwa sieci, a konkretnie do tego, co piszemy i nad czym pracuj\u0105 programi\u015bci - to niedoci\u0105gni\u0119cia i luki samej aplikacji.<\/p>\n

Kierunek SDL lub SDLC<\/a><\/noindex>\u00a0\u2014 Cykl \u017cycia rozwoju bezpiecze\u0144stwa<\/b>\u00a0zosta\u0142 opracowany przez firm\u0119 Microsoft. Na schemacie - kanoniczny model SDLC, kt\u00f3rego g\u0142\u00f3wnym celem jest uczestnictwo bezpiecze\u0144stwa na ka\u017cdym etapie rozwoju, od wymaga\u0144 po wydanie i wyj\u015bcie na produkcj\u0119. W Microsoft uznano, \u017ce w produkcie jest zbyt wiele b\u0142\u0119d\u00f3w, ich liczba ro\u015bnie i trzeba co\u015b z tym zrobi\u0107, i zaproponowano to podej\u015bcie, kt\u00f3re sta\u0142o si\u0119 kanoniczne.<\/p>\n

\"Strach
\n
\nBezpiecze\u0144stwo aplikacji i SSDL nie maj\u0105 na celu wykrywania luk, jak si\u0119 powszechnie s\u0105dzi, ale zapobieganie ich powstawaniu. Z biegiem czasu kanoniczne podej\u015bcie Microsoftu zosta\u0142o ulepszone, rozwini\u0119te, wprowadzono w nim g\u0142\u0119bsze, bardziej szczeg\u00f3\u0142owe zanurzenie.<\/p>\n

\"Strach
\n
\nKanoniczny SDLC jest szczeg\u00f3\u0142owo opisany w r\u00f3\u017cnych metodologiach - OpenSAMM, BSIMM, OWASP. Metodologie r\u00f3\u017cni\u0105 si\u0119, ale w zasadzie s\u0105 podobne.<\/p>\n

Model Dojrzewania Bezpiecze\u0144stwa<\/h3>\n

\nNajbardziej przemawia do mnie BSIMM<\/b>\u00a0\u2014 Model Dojrzewania Bezpiecze\u0144stwa<\/a><\/noindex>. Podstaw\u0105 metodologii jest podzia\u0142 procesu bezpiecze\u0144stwa aplikacji na 4 domeny: Governance, Intelligence, SSDL Touchpoints oraz Deployment. W ka\u017cdej domenie znajduje si\u0119 12 praktyk, kt\u00f3re s\u0105 przedstawione w formie 112 aktywno\u015bci.<\/p>\n

\"Strach
\n
\nKa\u017cda z 112 aktywno\u015bci ma 3 poziomy dojrza\u0142o\u015bci<\/b>: podstawowy, \u015brodkowy i zaawansowany. Wszystkie 12 praktyk mo\u017cna studiowa\u0107 w sekcjach, wybieraj\u0105c wa\u017cne dla siebie elementy, zrozumie\u0107, jak je wdra\u017ca\u0107 i stopniowo dodawa\u0107 elementy, takie jak statyczna i dynamiczna analiza kodu lub przegl\u0105d kodu. Tworzy si\u0119 plan i spokojnie pracuje w ramach wdra\u017cania wybranych aktywno\u015bci.<\/p>\n

Dlaczego DevSecOps<\/h2>\n

<\/p>\n

DevOps to og\u00f3lny, du\u017cy proces, w kt\u00f3rym nale\u017cy dba\u0107 o bezpiecze\u0144stwo.<\/p><\/blockquote>\n

\nPocz\u0105tkowo DevOps<\/b><\/a><\/noindex> zak\u0142ada\u0142 sprawdzanie bezpiecze\u0144stwa. W praktyce liczba zespo\u0142\u00f3w odpowiedzialnych za bezpiecze\u0144stwo by\u0142a znacznie mniejsza ni\u017c obecnie, a one uczestniczy\u0142y nie jako uczestnicy procesu, lecz jako organ kontrolny i nadzorczy, kt\u00f3ry stawia wymagania i sprawdza jako\u015b\u0107 produktu na ko\u0144cu wydania. To klasyczne podej\u015bcie, w kt\u00f3rym zespo\u0142y bezpiecze\u0144stwa by\u0142y oddzielone od rozwoju i nie bra\u0142y udzia\u0142u w procesie.<\/p>\n

\"Strach
\n
\nG\u0142\u00f3wnym problemem jest to, \u017ce IIB s\u0105 oddzielone od rozwoju. Zwykle to jaki\u015b kontur IIB i w nim 2-3 du\u017cych i kosztownych narz\u0119dzi. Co p\u00f3\u0142 roku przybywa kod \u017ar\u00f3d\u0142owy lub aplikacja, kt\u00f3ra musi by\u0107 sprawdzona, a raz w roku przeprowadzane s\u0105 pentestowanie<\/a><\/noindex>. To wszystko prowadzi do wyd\u0142u\u017cenia termin\u00f3w wprowadzenia na rynek, a dla dewelopera pojawia si\u0119 ogromna ilo\u015b\u0107 podatno\u015bci z automatycznych narz\u0119dzi. Wszystko to jest niemo\u017cliwe do roz\u0142o\u017cenia i naprawienia, poniewa\u017c jeszcze przez ostatnie p\u00f3\u0142 roku nie przeanalizowano wynik\u00f3w, a tutaj nadchodzi nowa partia.<\/p>\n

W trakcie pracy naszej firmy widzimy, \u017ce bezpiecze\u0144stwo w r\u00f3\u017cnych obszarach i bran\u017cach rozumie, \u017ce nadszed\u0142 czas, aby nad\u0105\u017cy\u0107 i wsp\u00f3\u0142pracowa\u0107 z rozwojem w jednej p\u0142aszczy\u017anie - w\u00a0Agile<\/b><\/a><\/noindex>. Paradigma DevSecOps doskonale wpisuje si\u0119 w metodologi\u0119 zwinnego podej\u015bcia, wprowadzania, wsparcia oraz udzia\u0142u w ka\u017cdym wydaniu i iteracji.<\/p>\n

\"Strach
\n<\/p>\n

Przej\u015bcie do DevSecOps<\/h2>\n

\nNajwa\u017cniejsze s\u0142owo w cyklu \u017cycia bezpiecze\u0144stwa aplikacji to \"proces\"<\/b>Musisz to zrozumie\u0107, zanim pomy\u015blisz o zakupie narz\u0119dzi.<\/p>\n

Samo w\u0142\u0105czenie narz\u0119dzi w proces DevOps nie wystarczy \u2013 wa\u017cna jest interakcja i zrozumienie pomi\u0119dzy uczestnikami procesu.<\/p><\/blockquote>\n

<\/p>\n

Bardziej licz\u0105 si\u0119 ludzie, a nie narz\u0119dzia.<\/h3>\n

\nCz\u0119sto planowanie procesu bezpiecznego rozwoju zaczyna si\u0119 od wyboru i zakupu narz\u0119dzia, a ko\u0144czy pr\u00f3bami zintegrowania narz\u0119dzia w obecnym procesie, kt\u00f3re pozostaj\u0105 jedynie pr\u00f3bami. To prowadzi do smutnych konsekwencji, poniewa\u017c ka\u017cde narz\u0119dzie ma swoje cechy i ograniczenia.<\/p>\n

Cz\u0119sto zdarza si\u0119, \u017ce dzia\u0142 bezpiecze\u0144stwa wybiera dobre, drogie narz\u0119dzie z szerokimi mo\u017cliwo\u015bciami i przychodzi do programist\u00f3w, aby wkomponowa\u0107 je w proces. Ale nie da si\u0119 \u2013 proces jest zbudowany w ten spos\u00f3b, \u017ce ograniczenia ju\u017c zakupionego narz\u0119dzia nie pasuj\u0105 do obecnej paradygmy.<\/p>\n

Najpierw opisz, jaki wynik chcesz osi\u0105gn\u0105\u0107 i jak ma wygl\u0105da\u0107 proces. To pomo\u017ce zrozumie\u0107 role narz\u0119dzia i bezpiecze\u0144stwa w procesie.<\/p><\/blockquote>\n

<\/p>\n

Zacznij od tego, co ju\u017c jest u\u017cywane.<\/h3>\n

\nZanim kupisz drogie narz\u0119dzia, sprawd\u017a, co ju\u017c masz. W ka\u017cdej firmie istniej\u0105 wymagania dotycz\u0105ce bezpiecze\u0144stwa, kt\u00f3re s\u0105 stawiane przed rozwojem, s\u0105 kontrole, testy penetracyjne \u2013 dlaczego nie przekszta\u0142ci\u0107 tego wszystkiego w zrozumia\u0142y i wygodny dla wszystkich format?<\/p>\n

Zwykle wymagania to papierowy dokument, kt\u00f3ry le\u017cy na p\u00f3\u0142ce. By\u0142 przypadek, kiedy przyje\u017cd\u017cali\u015bmy do firmy, aby obejrze\u0107 procesy i prosili\u015bmy o pokazanie wymaga\u0144 dotycz\u0105cych bezpiecze\u0144stwa oprogramowania. Specjalista, kt\u00f3ry si\u0119 tym zajmowa\u0142, d\u0142ugo szuka\u0142:<\/p>\n

\u2013 Gdzie\u015b teraz w notatkach by\u0142 \u015blad, gdzie le\u017cy ten dokument.<\/i><\/p>\n

W rezultacie otrzymali\u015bmy dokument po tygodniu.<\/p>\n

Dla wymaga\u0144, kontroli i innych utw\u00f3rz stron\u0119, na przyk\u0142ad na\u00a0Confluence<\/b>\u00a0\u2013 to wygodne dla wszystkich.<\/p>\n

Pro\u015bciej jest przekszta\u0142ci\u0107 to, co ju\u017c istnieje, i wykorzysta\u0107 jako punkt wyj\u015bcia.<\/p><\/blockquote>\n

<\/p>\n

U\u017cywaj Security Champions. <\/h3>\n

\nZwykle w \u015bredniej firmie na 100-200 programist\u00f3w pracuje jeden specjalista ds. bezpiecze\u0144stwa, kt\u00f3ry pe\u0142ni kilka funkcji i fizycznie nie jest w stanie wszystkiego sprawdzi\u0107. Nawet je\u017celi stara si\u0119 z ca\u0142ych si\u0142 \u2013 nie jest w stanie samodzielnie sprawdzi\u0107 ca\u0142ego kodu, kt\u00f3ry generuje rozw\u00f3j. Dla takich przypadk\u00f3w opracowano koncepcj\u0119 \u2013 Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions to osoba w zespole deweloperskim, kt\u00f3ra jest zainteresowana bezpiecze\u0144stwem twojego produktu.<\/p><\/blockquote>\n

\"Strach
\n
\nSecurity Champion to punkt kontaktowy w zespole deweloperskim oraz ewangelista bezpiecze\u0144stwa w jednej osobie.<\/p>\n

Zwykle, gdy do zespo\u0142u deweloperskiego przychodzi specjalista ds. bezpiecze\u0144stwa i wskazuje na b\u0142\u0105d w kodzie, otrzymuje zdziwion\u0105 odpowied\u017a:<\/p>\n

\u2014 A kim ty jeste\u015b? Widz\u0119 ci\u0119 po raz pierwszy. U mnie wszystko dobrze \u2013 m\u00f3j starszy kolega podczas przegl\u0105du kodu da\u0142 mi \u00abapply\u00bb, idziemy dalej!<\/i><\/p>\n

To typowa sytuacja, poniewa\u017c do starszych lub po prostu koleg\u00f3w z zespo\u0142u, z kt\u00f3rymi deweloper cz\u0119sto wsp\u00f3\u0142pracuje i przeprowadza przegl\u0105dy kodu, jest znacznie wi\u0119ksze zaufanie. Je\u015bli zamiast specjalisty ds. bezpiecze\u0144stwa na b\u0142\u0105d i konsekwencje wska\u017ce Security Champion, jego s\u0142owo b\u0119dzie mia\u0142o wi\u0119ksz\u0105 moc.<\/p>\n

Deweloperzy lepiej znaj\u0105 sw\u00f3j kod ni\u017c jakikolwiek specjalista ds. bezpiecze\u0144stwa. Osobie, kt\u00f3ra ma w narz\u0119dziu analizy statycznej co najmniej 5 projekt\u00f3w, zazwyczaj trudno jest zapami\u0119ta\u0107 wszystkie szczeg\u00f3\u0142y. Security Champions znaj\u0105 sw\u00f3j produkt: co z czym wsp\u00f3\u0142dzia\u0142a i na co zwraca\u0107 uwag\u0119 w pierwszej kolejno\u015bci \u2013 s\u0105 efektywniejsi.<\/p>\n

Zastan\u00f3w si\u0119 nad wprowadzeniem Security Champions i zwi\u0119kszeniem wp\u0142ywu zespo\u0142u bezpiecze\u0144stwa. Dla samego mistrza jest to r\u00f3wnie\u017c korzystne: rozw\u00f3j zawodowy w nowym obszarze, poszerzenie horyzont\u00f3w technicznych, rozw\u00f3j umiej\u0119tno\u015bci technicznych, zarz\u0105dzaj\u0105cych i przyw\u00f3dczych, zwi\u0119kszenie warto\u015bci rynkowej. To pewien element in\u017cynierii spo\u0142ecznej, twoje \u00aboczy\u00bb w zespole deweloperskim.<\/p>\n

Etapy testowania<\/h2>\n

\nParadigma 20 na 80<\/a><\/noindex>\u00a0m\u00f3wi, \u017ce 20% wysi\u0142k\u00f3w daje 80% rezultatu. Te 20% to praktyki analizy aplikacji, kt\u00f3re mo\u017cna i nale\u017cy automatyzowa\u0107. Przyk\u0142ady takich aktywno\u015bci to analiza statyczna \u2013 SAST<\/b>, analiza dynamiczna \u2013 DAST,<\/b> i\u00a0kontrola Open Source<\/b>. Opowiem wi\u0119cej o aktywno\u015bciach, a tak\u017ce o narz\u0119dziach, z jakimi cechami zwykle si\u0119 spotykamy przy ich wdra\u017caniu w proces oraz jak robi\u0107 to poprawnie.<\/p>\n

\"Strach
\n<\/p>\n

G\u0142\u00f3wne problemy narz\u0119dzi<\/h3>\n

\nWska\u017a\u0119 istotne problemy, kt\u00f3re dotycz\u0105 wszystkich narz\u0119dzi i wymagaj\u0105 uwagi. Zajm\u0119 si\u0119 nimi szczeg\u00f3\u0142owo, aby nie powtarza\u0107 si\u0119 dalej.<\/p>\n

D\u0142ugi czas analizy. <\/b>Je\u015bli od commit do wydania na produkcj\u0119 zajmuje 30 minut na wszystkie testy i budow\u0119, to kontrole z zakresu bezpiecze\u0144stwa informacji zajm\u0105 ca\u0142\u0105 dob\u0119. Nikt nie b\u0119dzie spowalnia\u0142 procesu. We\u017acie pod uwag\u0119 t\u0119 cech\u0119 i wyci\u0105gnijcie wnioski.<\/p>\n

Wysoki poziom False Negative lub False Positive. <\/b>Wszystkie produkty s\u0105 r\u00f3\u017cne, wszystkie wykorzystuj\u0105 r\u00f3\u017cne frameworki i maj\u0105 sw\u00f3j w\u0142asny styl pisania kodu. Na r\u00f3\u017cnych bazach kodu i technologiach narz\u0119dzia mog\u0105 pokazywa\u0107 r\u00f3\u017cny poziom False Negative i False Positive. Dlatego zwr\u00f3\u0107cie uwag\u0119 na to, co dok\u0142adnie w\u00a0waszej<\/b> firmie i dla waszych<\/b> aplikacji b\u0119dzie pokazywa\u0107 dobry i wiarygodny wynik.<\/p>\n

Brak integracji z istniej\u0105cymi narz\u0119dziami<\/b>. Patrzcie na narz\u0119dzia z punktu widzenia integracji, z tym, co ju\u017c u\u017cywacie. Na przyk\u0142ad, je\u015bli macie Jenkins lub TeamCity - sprawd\u017acie integracj\u0119 narz\u0119dzi z tym oprogramowaniem, a nie z GitLab CI, kt\u00f3rego nie u\u017cywacie.<\/p>\n

Brak lub nadmierna z\u0142o\u017cono\u015b\u0107 dostosowywania. <\/b>Je\u015bli narz\u0119dzie nie ma API, to po co jest potrzebne? Wszystko, co mo\u017cna zrobi\u0107 w interfejsie, powinno by\u0107 dost\u0119pne przez API. W idealnym przypadku narz\u0119dzie powinno mie\u0107 mo\u017cliwo\u015b\u0107 dostosowywania kontroli.<\/p>\n

Brak mapy rozwoju produktu. <\/b>Rozw\u00f3j nie stoi w miejscu, zawsze korzystamy z nowych framework\u00f3w i funkcji, przepisujemy stary kod na nowe j\u0119zyki. Chcemy by\u0107 pewni, \u017ce narz\u0119dzie, kt\u00f3re kupimy, b\u0119dzie wspiera\u0107 nowe frameworki i technologie. Dlatego wa\u017cne jest, aby wiedzie\u0107, \u017ce produkt ma realn\u0105 i odpowiedni\u0105 map\u0119<\/a><\/noindex> rozwoju.<\/p>\n

Cechy procesu<\/h3>\n

\nOpr\u00f3cz cech narz\u0119dzi, bierzcie pod uwag\u0119 r\u00f3wnie\u017c cechy procesu tworzenia. Na przyk\u0142ad, przeszkadzanie w tworzeniu to typowy b\u0142\u0105d. Zobaczmy, jakie jeszcze cechy nale\u017cy uwzgl\u0119dni\u0107 i na co zwr\u00f3ci\u0107 uwag\u0119 zespo\u0142owi bezpiecze\u0144stwa.<\/p>\n

Aby nie op\u00f3\u017ania\u0107 termin\u00f3w tworzenia i wydania, stw\u00f3rzcie r\u00f3\u017cne zasady<\/b> i r\u00f3\u017cne show stoppers\u00a0<\/b>\u2014 kryteria wstrzymania procesu budowy w przypadku wyst\u0105pienia luk \u2014 dla r\u00f3\u017cnych \u015brodowisk.<\/b>Na przyk\u0142ad rozumiemy, \u017ce obecna ga\u0142\u0105\u017a idzie na \u015brodowisko deweloperskie lub UAT, wi\u0119c nie zatrzymujemy si\u0119 i nie m\u00f3wimy:<\/p>\n

\u2014 Macie tutaj luki, nie przejdziecie dalej!<\/i><\/p>\n

Na tym etapie wa\u017cne jest, aby powiedzie\u0107 deweloperom, \u017ce s\u0105 problemy bezpiecze\u0144stwa, na kt\u00f3re warto zwr\u00f3ci\u0107 uwag\u0119.<\/p>\n

Obecno\u015b\u0107 luk w zabezpieczeniach nie jest przeszkod\u0105 dla dalszego testowania<\/b>: r\u0119cznego, integracyjnego lub manualnego. Z drugiej strony, musimy jako\u015b podnie\u015b\u0107 bezpiecze\u0144stwo produktu, wi\u0119c aby programi\u015bci nie zbagatelizowali tego, co znajduje bezpiecze\u0144stwo. Dlatego czasami robimy tak: na stoisku, kiedy produkt trafia na \u015brodowisko deweloperskie, po prostu informujemy zesp\u00f3\u0142 deweloperski:<\/p>\n

\u2014 Ch\u0142opaki, macie problemy, prosz\u0119 zwr\u00f3\u0107cie na nie uwag\u0119.<\/i><\/p>\n

Na etapie UAT znowu pokazujemy ostrze\u017cenia o lukach, a na etapie wydania do produkcji m\u00f3wimy:<\/p>\n

\u2014 Ch\u0142opaki, kilka razy was ostrzegali\u015bmy, nie zrobili\u015bcie nic \u2014 z tym nie wypu\u015bcimy was.<\/i><\/p>\n

Je\u015bli m\u00f3wimy o kodzie i dynamice, nale\u017cy pokazywa\u0107 i ostrzega\u0107 o lukach tylko w tych funkcjach i kodzie, kt\u00f3ry zosta\u0142 napisany dopiero w tej funkcji. \u0415\u0441\u043b\u0438 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u043f\u0435\u0440\u0435\u0434\u0432\u0438\u043d\u0443\u043b \u043a\u043d\u043e\u043f\u043e\u0447\u043a\u0443 \u043d\u0430 3 \u043f\u0438\u043a\u0441\u0435\u043b\u044f i m\u00f3wimy mu, \u017ce ma tam SQL-iniekcj\u0119 i \u017ce musi to szybko poprawi\u0107 \u2014 to jest nieprawid\u0142owe. Patrzcie tylko na to, co zosta\u0142o napisane teraz, i na to, co si\u0119 zmienia w aplikacji.<\/p>\n

Powiedzmy, \u017ce mamy jak\u0105\u015b funkcjonaln\u0105 usterk\u0119 \u2014 to, jak aplikacja nie powinna dzia\u0142a\u0107: pieni\u0105dze nie s\u0105 przekazywane, klikaj\u0105c przycisk nie przechodzi na nast\u0119pna stron\u0119 lub towar si\u0119 nie \u0142aduje. Usterki bezpiecze\u0144stwa<\/b>\u00a0\u2014 to takie same usterki, ale nie w kontek\u015bcie dzia\u0142ania aplikacji, a bezpiecze\u0144stwa. <\/p>\n

Nie wszystkie problemy jako\u015bci oprogramowania to problemy bezpiecze\u0144stwa. Ale wszystkie problemy bezpiecze\u0144stwa s\u0105 powi\u0105zane z jako\u015bci\u0105 oprogramowania. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nPoniewa\u017c wszystkie luki s\u0105 takimi samymi usterkami, powinny by\u0107 traktowane tam samo, gdzie wszystkie usterki rozwojowe. Zapomnijcie o raportach i strasznych PDF-ach, kt\u00f3rych nikt nie czyta.<\/p>\n

\"Strach
\n
\nKiedy pracowa\u0142em w firmie zajmuj\u0105cej si\u0119 rozwojem, przyszed\u0142 do mnie raport z narz\u0119dzi statycznej analizy. Otworzy\u0142em go, przestraszy\u0142em si\u0119, zrobi\u0142em kaw\u0119, przeszed\u0142em przez 350 stron, zamkn\u0105\u0142em i wr\u00f3ci\u0142em do pracy. Du\u017ce raporty to martwe raporty<\/b>. Zwykle nigdzie nie trafiaj\u0105, e-maile s\u0105 usuwane, zapominane, gubione lub biznes m\u00f3wi, \u017ce akceptuje ryzyko.<\/p>\n

Co robi\u0107? Potwierdzone defekty, kt\u00f3re znale\u017ali\u015bmy, po prostu przekszta\u0142camy w wygodniejszy do opracowania format, na przyk\u0142ad umieszczamy w backlogu w Jira. Priorytetyzujemy defekty i usuwamy je w kolejno\u015bci priorytetu, na r\u00f3wni z defektami funkcjonalnymi i defektami test\u00f3w.<\/p>\n

Analiza statyczna \u2014 SAST<\/h2>\n

\nTo analiza kodu pod k\u0105tem luk w zabezpieczeniach<\/b>, ale to nie to samo, co SonarQube. Sprawdzamy nie tylko na podstawie wzorc\u00f3w lub stylu. W analizie stosowane s\u0105 r\u00f3\u017cne podej\u015bcia: wed\u0142ug drzewa luk w zabezpieczeniach, wed\u0142ug\u00a0DataFlow<\/a><\/noindex>, wed\u0142ug analizy plik\u00f3w konfiguracyjnych. To wszystko, co dotyczy bezpo\u015brednio kodu.<\/p>\n

Zalety podej\u015bcia<\/b>: wykrywanie luk w zabezpieczeniach w kodzie na wczesnym etapie rozwoju<\/b>, kiedy jeszcze nie ma \u015brodowiska testowego ani gotowego narz\u0119dzia, i\u00a0mo\u017cliwo\u015b\u0107 inkrementacyjnego skanowania<\/b>: skanowanie zmienionej cz\u0119\u015bci kodu oraz tylko tej funkcjonalno\u015bci, kt\u00f3r\u0105 aktualnie przygotowujemy, co skraca czas skanowania.<\/p>\n

Minusy<\/b>\u00a0\u2014 to brak wsparcia dla potrzebnych j\u0119zyk\u00f3w.<\/p>\n

Potrzebne integracje, <\/b>kt\u00f3re powinny by\u0107 w narz\u0119dziach, moim subiektywnym zdaniem:<\/p>\n