Zyski:
- Umiejętność wykorzystania sztucznej inteligencji jako drugiego oka i flagowania podatności klasy OWASP (wstrzykiwanie, twardy sekret, kontrola dostępu) w kodzie poprzez podanie kontekstu
- Możliwość eliminowania fałszywych alarmów wytwarzanych przez sztuczną inteligencję z kontekstem i zapobiegania traktowaniu każdego ustalenia jako prawdziwej luki w zabezpieczeniach bez jego walidacji
- Umiejętność rozpoznania, że poprawka sugerowana przez sztuczną inteligencję może wprowadzić nowe luki/błędy i przejść każdą łatkę przez bramkę przeglądu i testów
Luki w oprogramowaniu należą do najdroższych, ponieważ są od początku wbudowane w produkt i rozpowszechniane wśród milionów użytkowników. Bezpieczny przegląd kodu to proces odczytywania kodu źródłowego wiersz po wierszu i wychwytywania luk w zabezpieczeniach — wstrzykiwania SQL, luki w zabezpieczeniach uwierzytelniania, zakodowanego na stałe hasła, nieprawidłowej autoryzacji — zanim trafią one do środowiska produkcyjnego. Wykonywane ręcznie jest powolne i męczące; W dużej bazie kodu łatwo przeoczyć lukę.
Sztuczna inteligencja jest skuteczna w przeglądaniu kodu z dwóch powodów: kod to także język, a sztuczna inteligencja jest dobra w rozpoznawaniu wzorców. Sztuczna inteligencja może szybko oznaczyć niebezpieczne wzorce w fragmencie kodu (wprowadzanie danych użytkownika bezpośrednio do zapytania, przechowywanie niezaszyfrowanych danych, brak weryfikacji danych wejściowych), wyjaśniać, dlaczego każdy z nich jest ryzykowny i sugerować rozwiązanie. Ale sztuczna inteligencja nie widzi całego kontekstu operacyjnego kodu (wejście może być czyszczone w innej warstwie), może wymyślić lukę, która nie istnieje (fałszywie pozytywny) lub przeoczyć prawdziwą lukę (fałszywie negatywną), a co najważniejsze, proponowana przez nią „poprawka” może wprowadzić nową lukę lub błąd. Sztuczna inteligencja to drugie oko i wskaźnik podczas przeglądu kodu; Programista i ekspert ds. bezpieczeństwa decydują, czy odkrycie stanowi prawdziwą lukę oraz czy poprawka jest prawidłowa i bezpieczna.
Etapy przeglądu kodu
- Podaj zakres i kontekst. W jakim języku, w jakim frameworku, gdzie ten kod pobiera dane wejściowe, gdzie generuje dane wyjściowe, w jakiej warstwie to działa? Przegląd kodu bez kontekstu daje fałszywe alarmy.
- Skanuj w poszukiwaniu niebezpiecznych wzorców. Wyszukaj znane klasy podatności na sztuczną inteligencję (takie jak OWASP Top 10): wstrzykiwanie, uwierzytelnianie, ujawnianie wrażliwych danych, kontrola dostępu.
- Uzasadnij każde ustalenie. Dla każdej flagi: która linia, jaka klasa podatności, w jaki sposób można ją wykorzystać, jakie są dowody. Nieuzasadnionego ustalenia nie traktuje się poważnie.
- Wyeliminuj fałszywe alarmy. Czy dane wejściowe są rzeczywiście czyszczone i czy ta ścieżka jest naprawdę dostępna — sprawdź w kontekście.
- Sprawdź poprawkę. Potwierdź, że łatka zalecana przez sztuczną inteligencję faktycznie zamyka lukę, nie wprowadza nowych luk/błędów i przeszła testy.
- Ludzka akceptacja. Programista + ekspert ds. bezpieczeństwa przegląda znalezisko i naprawia; W ten sposób trafia do repozytorium kodu.
Warunki: SAST (Statyczne testowanie bezpieczeństwa aplikacji — statyczne testowanie bezpieczeństwa, które analizuje kod źródłowy bez jego uruchamiania). DAST (Dynamiczny — testowanie dynamiczne, które testuje zewnętrznie uruchomioną aplikację). OWASP Top 10 to standardowa lista najpopularniejszych luk w zabezpieczeniach aplikacji internetowych. Wstrzykiwanie to luka spowodowana interpretowaniem danych wprowadzonych przez użytkownika jako polecenie/zapytanie (np. wstrzyknięcie SQL). Zapytanie parametryczne jest właściwą metodą, która zapobiega wstrzykiwaniu poprzez oddzielenie danych wejściowych od kodu.
Tabela typowych klas podatności
Klasa podatności
Objaw (w kodzie)
właściwe rozwiązanie
Pułapka AI
Wstrzyknięcie SQL
Łączenie danych wejściowych z zapytaniem
Zapytanie parametryczne
Można zignorować sanityzację
mocno zakodowany sekret
Hasło/wpisz kod
Sekretny sejf (skrypt), pow
Fałszywie dodatni (próbka/test)
Słabe uwierzytelnienie
Brak/nieprawidłowa kontrola
Wydajna, scentralizowana kontrola
pomija kontekst
Wadliwa kontrola dostępu
Brak kontroli autoryzacji
Autoryzacja po stronie serwera
Nie rozumie złożonego przepływu
Ujawnianie danych wrażliwych
Przechowywanie/rejestrowanie bez hasła
Szyfrowanie, maskowanie
Nie znam krytyczności
Niebezpieczna serializacja
Deserializuj niewiarygodne dane
Bezpieczne analizowanie
Brakuje rzadkiego wzoru
trzy mini etui
Przypadek 1 — Złapanie właściwego zastrzyku. Deweloper ma sztuczną inteligencję sprawdzającą funkcję dostępu do danych. Sztuczna inteligencja zaznacza wiersz, w którym wartość userId od użytkownika jest łączona bezpośrednio z tekstem SQL i mówi „to jest klasyczny zastrzyk SQL, zamień go w sparametryzowane zapytanie”; Zapewnia korektę próbki. Programista potwierdza, że dane wejściowe nie zostały oczyszczone gdzie indziej, weryfikuje, czy jest to rzeczywista luka, implementuje sugerowane sparametryzowane zapytanie i pisze test. Sztuczna inteligencja podkreśliła lukę; testy weryfikacyjne i korygujące pochodziły od programisty.
Przypadek 2 — Fałszywie pozytywny ustalony sekret. Sztuczna inteligencja widzi w pliku wiersz „hasło = „test1234” i mówi „krytyczne: hasło zakodowane na stałe”. Programista sprawdza kontekst: jest to plik testu jednostkowego, fikcyjne dane testowe, które nie zostały wprowadzone do produkcji i nie zostały przeniesione do prawdziwego systemu. Wynik jest fałszywie pozytywny. Deweloper dokumentuje to, ale nie podejmuje żadnych działań, ponieważ nie jest to prawdziwą tajemnicą. Lekcja: Znak „twardego sekretu” sztucznej inteligencji należy wyeliminować na podstawie kontekstu; Nie każdy ciąg znaków jest tajemnicą.
Przypadek 3 — Nowa poprawka luki. AI proponuje poprawkę dla luki XSS (cross-site scripting); ale kod, który sugeruje, usuwa dane wejściowe w niewłaściwym miejscu i pomija kodowanie wyjściowe w innym obszarze; W rezultacie luka nie zamyka się całkowicie. Ekspert ds. bezpieczeństwa przegląda poprawkę, zauważa brakujące kodowanie i poprawia je w odpowiedniej warstwie. Lekcja: łatka zalecana przez sztuczną inteligencję nie jest automatycznie bezpieczna; Każda poprawka jest sprawdzana i testowana.
Słaba zachęta/silna zachęta
Słaba zachęta:
Czy w tym kodzie jest luka, napraw ją: [kod]
Podpowiedź ta nie podaje kontekstu (języka, struktury, źródła danych wejściowych), nie prosi o uzasadnienie, nie kwestionuje fałszywie pozytywnego wyniku i jest otwarta na ślepą akceptację poprawki wprowadzonej przez sztuczną inteligencję. Sztuczna inteligencja mieszała oznaki zarówno rzeczywistej, jak i nieistniejącej podatności.
Potężny monit:
Twoja rola: asystent, który jest DRUGIM OKIEM programisty przy przeglądaniu bezpiecznego kodu. Podejmowanie decyzji; rozważ zastosowanie poprawki bezpośrednio. Kod: [określ język/framework]. Kontekst: ta funkcja [źródło wejścia: np. odbiera [zewnętrzne żądanie HTTP], zapisuje do [wyjściowego miejsca docelowego]. Twoje zadanie: (1) oznacz możliwe podatności klasą OWASP, podaj numer linii + dlaczego ryzykowne + jak wykorzystać exploit + dowody na każdą z nich, (2) napisz co najmniej 1 fałszywie pozytywny scenariusz dla każdego wyniku (np. jeśli dane wejściowe są oczyszczane w innej warstwie), (3) zaproponuj poprawkę, ale ze znakiem „[przegląd + napisz test]”; Oceń także, czy poprawka wprowadza nowe luki/błędy. Dodanie fałszywej luki.[kod]
Silna zachęta podaje kontekst, prosi o klasę OWASP i dowody, kwestionuje fałszywe pozytywne wyniki i ryzyko działań naprawczych, zmusza do przeglądu przez człowieka.
Kopiowalne szablony podpowiedzi
SZABLON SKANOWANIA PODATNOŚCI Sprawdź kod [język/framework] dla 10 najlepszych rozwiązań OWASP. Dla każdego możliwego wyniku: numer linii, klasa podatności, dlaczego jest ryzykowna, przykładowy exploit, siła dowodów (pewne/prawdopodobne/słabe). Kontekst: wejście [źródło], wyjście [cel]. Dodawanie sfabrykowanych ustaleń; Jeśli nie jesteś pewien, wpisz „[musi zostać zweryfikowany]”. Kod: [wklej]
FAŁSZYWY POZYTYWNY WZÓR ELIMINACJI W przypadku poniższego wyniku wypisz scenariusze, w których NIE występuje realna podatność: czy dane wejściowe można wyczyścić w innej warstwie, czy ta ścieżka jest dostępna, czy ta wartość jest testem/próbką, czy struktura jest automatycznie chroniona. Napisz jak potwierdzić dla każdego z nich. Znalezienie: [wklej]
SZABLON OCENY POPRAWKIZalecaj naprawę następującej luki; następnie oceń swoją własną poprawkę: (1) czy naprawdę usuwa lukę, (2) czy wprowadza nową lukę/błąd, (3) jaki test powinienem napisać (przypadek pozytywny i negatywny), (4) wpływ na wydajność/funkcjonalność. Sprawdzę i przetestuję poprawkę. Podatność + kod: [wklej]
SZABLON NAUCZANIA BEZPIECZNEGO WZORCA dla klasy podatności [np. Wstrzyknięcie SQL] przedstawiają porównawczo bezpieczny wzorzec pisania i typowe błędne wzorce w tym języku/frameworku. Ogólna zasada + podaj przykładowy kod; ale chcę, żebyś zapytał o kontekst przed zaimplementowaniem go w moim kodzie. Język/framework: [napisz]
Typowe błędy
- Recenzja bez kontekstu. Bez języka, ram i kontekstu wejścia/wyjścia sztuczna inteligencja myli zarówno rzeczywiste, jak i fałszywe ustalenia; Pamiętaj o podaniu kontekstu.
- Mylenie każdego znaku z prawdziwą słabością. Sztuczna inteligencja generuje fałszywe alarmy (dane testowe, dane wejściowe czyszczone w innej warstwie); Przesiać każde odkrycie pod kątem kontekstu.
- Ślepe stosowanie korekcji AI. Zalecana łatka może wprowadzić nowe luki/bugi; przeglądaj i pisz testy.
- Zaufanie fałszywemu negatywowi. Nawet jeśli sztuczna inteligencja powie „brak luk”, samodzielnie sprawdź ścieżki krytyczne; Skanowanie statyczne nie wykrywa każdej luki.
- Przekazanie kodu/sekretu zewnętrznemu narzędziu. Kod prywatny i prawdziwe tajemnice (klucz, hasło) stanowią własność intelektualną i są podatne na zagrożenia; anonimizować lub korzystać z korporacyjnych, izolowanych narzędzi.
Wskazówka: w przypadku posiadania kodu przeglądu AI najskuteczniejszym filtrem jest pytanie o „siłę dowodu” (pewne/prawdopodobne/słabe) dla każdego ustalenia. Większość wyników oznaczonych jako „słabe” to wyniki fałszywie pozytywne; przeznaczasz swoją energię na „pewnych”.
Uwaga: poprawka bezpieczeństwa zaproponowana przez sztuczną inteligencję nie powinna trafiać do magazynu bez przetestowania. Nieprawidłowa „poprawka” może zarówno pozostawić lukę otwartą, jak i doprowadzić do błędu funkcjonalnego w produkcji; Każda łatka przechodzi przez bramkę przeglądu i testów.
Podsumowując
Bezpieczny przegląd kodu to najtańszy sposób na wykrycie luk przed wprowadzeniem ich do środowiska produkcyjnego, a ponieważ kod jest językiem, sztuczna inteligencja staje się tutaj potężnym drugim okiem: sygnalizuje niebezpieczne wzorce, wyjaśnia ryzyko, sugeruje poprawki. Jednak sztuczna inteligencja nie widzi całego kontekstu operacyjnego, generuje fałszywe alarmy i fałszywie negatywne wyniki, a zalecana przez nią łatka może wprowadzić nowe luki. Zatem przegląd składa się z sześciu etapów (kontekst, sprawdzenie, uzasadnienie, fałszywie pozytywna eliminacja, weryfikacja poprawki, zatwierdzenie przez człowieka), a decyzja należy do programisty i eksperta ds. bezpieczeństwa. Trzy zasady: żadne znalezisko nie jest interpretowane bez kontekstu, każdy znak jest eliminowany wraz z kontekstem, żadna poprawka nie trafia do pamięci bez przetestowania. Kod/sekret nigdy nie jest przekazywany narzędziu zewnętrznemu bez anonimizacji.
Zadanie aplikacji
Pobierz przykładowy fragment kodu (usuwając wrażliwe części z własnego kodu lub przykładowy kod z lukami w zabezpieczeniach). Niech sztuczna inteligencja sprawdzi to za pomocą szablonu „Skanowanie luk”; Zastosuj szablon „fałszywie pozytywnej eliminacji” dla każdego wyniku i wyeliminuj prawdziwe. Popraw najpoważniejsze ustalenie za pomocą szablonu „Ocena środków zaradczych”, przejrzyj go samodzielnie i napisz jeden pozytywny + jeden negatywny przypadek testowy. Zwróć uwagę, ile wyników było fałszywie pozytywnych.
lista kontrolna
- [ ] Przed przejrzeniem kodu podałem język, framework i kontekst wejścia/wyjścia.
- [ ] Poprosiłem o numer linii, klasę podatności, ścieżkę exploita i dowody dla każdego ustalenia.
- [ ] Sprawdziłem każde odkrycie pod kątem wyników fałszywie pozytywnych, uwzględniając kontekst.
- [ ] Nie zastosowałem ślepo poprawki AI; Sprawdziłem i napisałem test.
- [ ] Pomimo wyniku „Brak luk” sam sprawdziłem ścieżki krytyczne.
- [ ] Zanonimizowałem kod/tajemnice lub użyłem izolowanych narzędzi korporacyjnych.
- [ ] Przekazałem odkrycie i naprawę przez programistę + zatwierdzenie zabezpieczeń.