Dojrzałość w zakresie bezpieczeństwa aplikacji · DevSecOps i bezpieczne kodowanie
Państwa łańcuch wytwarzania oprogramowania oceniony od kodu po wdrożenie i przełożony na mapę drogową.
10 obszarów tematycznych, undefined pytań, skala 5 poziomów. I działanie, które pozwala przejść z jednego poziomu na kolejny.
10 obszarów tematycznych modelu referencyjnego, już opracowanych od N1 do N5. Jedna firma, jedna jednostka biznesowa, albo 300 naraz.
Dojrzałość w zakresie bezpieczeństwa aplikacji · DevSecOps i bezpieczne kodowanie
10 obszarów tematycznych, undefined pytań, skala 5 poziomów.
Nordhavn Industries
53 / 100
Oni mierzą swoją dojrzałość z Datamensio
Przykład
Ta sytuacja mogłaby być Państwa sytuacją.
Weźmy przykład firmy: trzy oddziały, trzy arkusze kalkulacyjne, żadnej wspólnej odpowiedzi.
Nikt nie potrafi tego skonsolidować.
Nordhavn Industries, 2400 osób w Hamburgu, Lyonie i Porto. Zamawiający pyta, na jakim etapie jest grupa. Każdy oddział odpowiada we własnym arkuszu, z własnymi skalami.
Trzy tygodnie, jedna wspólna baza.
Diagnoza Model dojrzałości DevSecOps i bezpieczeństwa aplikacyjnego (inspirowany OWASP SAMM i BSIMM) uruchomiona jednocześnie na trzech oddziałach, na podstawie notatek ze spotkań z osobami odpowiedzialnymi. Model referencyjny był już gotowy, podobnie jak 10 obszarów tematycznych i poziomy od N1 do N5.
Dwa wydatki uniknięte, zanim zostały poniesione.
Wynik 53 na 100, luka skoncentrowana na trzech obszarach tematycznych. Asystent IA wykrył, że dwa działania planu pokrywają się z działaniami z innego audytu. Prezentacja wyników dla komitetu powstała w jedno zdanie.
Czego dzięki temu uniknięto
- 3oddziały zmierzone na tej samej podstawie, zamiast trzech kwestionariuszy do przetworzenia
- 2zdublowane działania wykryte przed poniesieniem wydatku
- 1prezentacja wyników dla komitetu, bez ręcznego opracowania
Te liczby pochodzą z przykładu. Mogłyby być Państwa liczbami.
Norma narzuca procesy. Datamensio mówi, na jakim etapie Państwo są.
01
Model referencyjny jest już gotowy
Obszary tematyczne, pytania i poziomy od N1 do N5 opracowane. Nie zaczynają Państwo od pustego arkusza.
02
Wynik jest gotowy tego samego dnia
Online, przez link do samooceny albo podczas spotkania. Obszar po obszarze, porównywalny w czasie.
03
Luka staje się wycenionym planem
Każde przejście na kolejny poziom niesie ze sobą działanie. IA priorytetyzuje według oczekiwanego efektu, nie według kolejności z normy.
04
Postęp da się wykazać
Kampania po kampanii, względem Państwa celu i względem Państwa przeszłości. Tego właśnie oczekuje Państwa zarząd.
Skala dojrzałości
Jeden poziom, kolejny i działanie, które je łączy.
To właśnie ten mechanizm (poziom, poziom wyższy oraz działanie łączące oba) przekształca stwierdzenie stanu w trajektorię.
Czy podatności wykryte przez zautomatyzowane analizy są naprawiane w określonych terminach?
- N1
Wyniki analiz nie są wykorzystywane. Nie określono żadnych terminów naprawy i nikt nie jest wyznaczony do obsługi wykrytych podatności.
- N2
Niektóre zespoły zajmują się krytycznymi podatnościami, gdy je zauważą. Terminy zależą od dostępności i bieżącego obciążenia.
- N3
Terminy naprawy według poziomu krytyczności są określone i znane. Podatności są przypisywane do właściciela i monitorowane aż do zamknięcia.
- N4
Terminy są dotrzymywane i mierzone dla każdego zespołu. Przekroczenia podlegają udokumentowanemu i zatwierdzonemu odstępstwu, a dług bezpieczeństwa jest monitorowany jako zaplanowane obciążenie.
- N5
Progi i terminy są okresowo weryfikowane w zależności od incydentów i rozwoju portfela aplikacji, z udokumentowanym śledzeniem rewizji i ich skutków.
Działanie umożliwiające przejście z poziomu 2 na poziom 3
Opublikowanie siatki terminów naprawy według poziomu krytyczności, automatyczne tworzenie zgłoszenia przypisanego do zespołu będącego właścicielem repozytorium przy każdym wykryciu oraz przegląd otwartych zgłoszeń podczas przeglądu sprintu.
« Dzięki Datamensio realizujemy nasze cele ze znacznie większą skutecznością. Służby inspekcyjne EFRR oraz naszego ministerstwa nadzorującego szczególnie doceniły to podejście, które dostarcza im wiarygodnych danych. »
Dyrektorka CCI 94CCI Île-de-France
« Uważamy, że to rozwiązanie najlepiej odpowiada potrzebie skalowania naszego projektu transformacji i mierzenia jego wpływu zgodnie z naszymi wymaganiami. »
Maja SucekChief Operating Officer, Interreg Danube
Rzadko sam
Model referencyjny da się łączyć z innymi. Niech Państwo połączą kilka, by objąć całą działalność, albo pozwolą IA napisać własny.
Wykonajcie swój pierwszy pomiarna DEV SECOPS.
O czym jest ten model referencyjny
Bezpieczeństwo aplikacji obejmuje całość praktyk ograniczających liczbę możliwych do wykorzystania wad w oprogramowaniu, od projektowania aż po eksploatację. DevSecOps jest tego organizacyjnym przełożeniem: wbudowanie kontroli bezpieczeństwa w łańcuch ciągłego dostarczania, zamiast umieszczania ich na końcu cyklu. Zakłada to zasady bezpiecznego kodowania, zautomatyzowaną analizę statyczną i dynamiczną, zarządzanie zależnościami i sekretami, modelowanie zagrożeń na wczesnym etapie oraz przeszkolone zespoły programistyczne. Nie chodzi o produkt do zainstalowania, lecz o zestaw praktyk, które trzeba zakorzenić w codziennej pracy zespołów.
W praktyce jest to temat trudny do prowadzenia, ponieważ jest rozproszony. Bezpieczeństwo aplikacyjne należy jednocześnie do zespołów produktowych, zespołów platformowych i pionu bezpieczeństwa, bez jednego podmiotu posiadającego pełny obraz sytuacji. Konkretne pytania wracają zawsze te same: czy analizy kodu uruchamiane są na wszystkich repozytoriach, czy tylko na tych, które skonfigurował zmotywowany zespół? Czy wykryte podatności są naprawiane, czy spiętrzają się na pulpicie, którego nikt już nie otwiera? Czy przegląd bezpieczeństwa jest rzeczywistym punktem kontrolnym, czy jedynie zaznaczonym polem przed wdrożeniem produkcyjnym?
Warto rozwiać częste nieporozumienie: posiadanie narzędzi to nie to samo, co opanowanie tematu. Wiele organizacji dysponuje skanerem komponentów zewnętrznych, analizatorem statycznym i magazynem sekretów, bez powiązania tych elementów z polityką naprawczą, progami blokującymi czy wyznaczonym właścicielem. Rozwój wspomagania kodowania przez generatywną sztuczną inteligencję pogłębia ten problem: rośnie ilość wytwarzanego kodu, a przegląd i znajomość zależności muszą za tym nadążać. Pytanie nie dotyczy już zakupu narzędzi, lecz tego, co łańcuch wytwarzania faktycznie robi z ich wynikami.
Audyt sprawdza obecność danego mechanizmu i kończy się wskazaniem luki. Diagnostyka dojrzałości stawia inne pytanie: na jakim poziomie znajdują się Państwa praktyki, zespół po zespole, i jakie konkretne działanie pozwala przejść na poziom wyższy. W temacie tak nierównomiernym między poszczególnymi produktami ta szczegółowość zmienia sposób zarządzania. Wynik dla każdego obszaru pozwala porównywać jednostki biznesowe między sobą i mierzyć postęp z cyklu na cykl, zamiast stwierdzać stan globalny bez wyznaczonej trajektorii.
Model referencyjny jest dostępny i od razu gotowy do użycia w Datamensio. Mogą Państwo dostosować go do swojej organizacji: sztuczna inteligencja dostosowuje obszary tematyczne, przeformułowuje pytania i precyzuje poziomy zgodnie z metodą CMMI, lub tworzy wersję opartą na Państwa własnych politykach wytwarzania oprogramowania i wewnętrznych standardach.
Norma referencyjna: Model dojrzałości DevSecOps i bezpieczeństwa aplikacyjnego (inspirowany OWASP SAMM i BSIMM)
Oceniane obszary tematyczne
Ład bezpieczeństwa aplikacyjnego
Polityka bezpiecznego wytwarzania oprogramowania, role i referenci bezpieczeństwa w zespołach produktowych, podejmowanie decyzji w sprawie wyjątków, wskaźniki monitorowane przez kierownictwo.
Wymagania i projektowanie
Wymagania bezpieczeństwa sformalizowane w specyfikacjach, modelowanie zagrożeń, przeglądy architektury, wybór komponentów i wzorców projektowych.
Bezpieczne kodowanie i przegląd kodu
Standardy kodowania, przegląd kodu przez współpracowników z elementem bezpieczeństwa, zasady walidacji danych wejściowych, zarządzanie błędami i rejestrowaniem zdarzeń.
Zarządzanie zależnościami i łańcuchem dostaw oprogramowania
Inwentaryzacja komponentów zewnętrznych, spis składników oprogramowania (SBOM), monitorowanie publikowanych podatności, polityka aktualizacji, podpisywanie artefaktów.
Zautomatyzowane testy bezpieczeństwa
Analiza statyczna, analiza dynamiczna, testy kompozycji oprogramowania, pokrycie repozytoriów, progi blokujące w łańcuchach integracji.
Bezpieczeństwo łańcucha CI/CD
Kontrola dostępu do repozytoriów i runnerów, zarządzanie sekretami, integralność potoków, rozdzielenie środowisk, identyfikowalność wdrożeń.
Zarządzanie podatnościami i naprawa
Kwalifikacja i priorytetyzacja wykrytych podatności, terminy naprawy według poziomu krytyczności, monitorowanie aż do zamknięcia, zarządzanie długiem bezpieczeństwa.
Testy penetracyjne i walidacja zewnętrzna
Zakres i częstotliwość testów, program ujawniania podatności lub nagród za ich znalezienie, wprowadzanie wniosków do standardów wytwarzania oprogramowania.
Kompetencje i kultura
Szkolenia z bezpiecznego kodowania, rozwój kompetencji referentów, uświadamianie w zakresie wykorzystania wspomagania kodowania przez sztuczną inteligencję, dzielenie się wnioskami z incydentów.
Eksploatacja i ciągłe doskonalenie
Bezpieczeństwo konfiguracji produkcyjnych, nadzór aplikacyjny, wnioski po incydentach, okresowy przegląd standardów i progów.
Krótsza wersja modelu referencyjnego, licząca undefined pytań, jest dostępna do samooceny online. Pełna wersja obejmuje 10 obszarów tematycznych i undefined pytań.
Najczęściej zadawane pytania
Czy ta ocena prowadzi do certyfikacji?
Nie. Bezpieczeństwo aplikacyjne nie ma własnej jednostki certyfikującej. Datamensio mierzy dojrzałość Państwa praktyk i tworzy powiązany plan działania. Wyniki mogą jednak zasilić dokumentację dla klientów lub szerszy system zarządzania bezpieczeństwem.
Jaka jest różnica w stosunku do audytu kodu lub testu penetracyjnego?
Audyt kodu lub test penetracyjny poszukuje wad w danej aplikacji, w danym momencie. Ocena bada zdolność Państwa organizacji do unikania tych wad i ich powtarzalnej naprawy. Oba podejścia się uzupełniają: wnioski techniczne zasilają ocenę praktyk.
Ile czasu zajmuje ocena?
Wersja skrócona wypełniana jest w 20 do 30 minut przez osobę odpowiedzialną, znającą łańcuch wytwarzania oprogramowania. Wersja pełna, w trybie współpracy z zespołami produktowymi i platformowymi, trwa zwykle od tygodnia do dwóch, przy czym większość czasu zajmuje zbieranie danych.
Czy można dostosować model referencyjny do naszej organizacji?
Tak. Obszary tematyczne, pytania i poziomy można modyfikować. Sztuczna inteligencja może przeformułować całość na podstawie Państwa polityk wytwarzania oprogramowania, standardów kodowania lub rzeczywistego oprzyrządowania, albo stworzyć wersję właściwą dla danej linii produktowej.
Jak porównać kilka zespołów programistycznych?
Ten sam model referencyjny jest udostępniany każdemu zespołowi lub jednostce biznesowej. Wyniki dla poszczególnych obszarów można porównywać między jednostkami i w czasie. Przekrojowa mapa drogowa konsoliduje następnie plany działania, aby uniknąć dziesięciokrotnego finansowania tego samego projektu wdrożenia narzędzi.
Czy trzeba być programistą, aby odpowiadać na pytania?
Pytania dotyczą praktyk i mechanizmów, a nie konkretnych konfiguracji. Odpowiada na nie kierownik inżynierii lub referent bezpieczeństwa. Tryb współpracy pozwala przypisać pytania dotyczące narzędzi zespołowi platformowemu, a pytania dotyczące projektowania architektom.
Czy uwzględniane jest wykorzystanie generatywnej sztucznej inteligencji do pisania kodu?
Tak. Model referencyjny ocenia nadzór nad tymi praktykami: zasady wykorzystania, przegląd wytworzonego kodu, kontrolę wprowadzanych zależności oraz szkolenia programistów. Elementy te można dostosować, jeśli Państwa wewnętrzna polityka jest bardziej szczegółowa.
Gdzie przechowywane są dane?
We Francji, u dostawcy OVH, z kopią zapasową u Scaleway. Żaden transfer poza Unię Europejską nie ma miejsca. Wykorzystywane modele sztucznej inteligencji można wybierać, w tym spośród rozwiązań europejskich.