Audyt bezpieczeństwa kodu źródłowego
Test penetracyjny pokazuje, co da się zrobić z aplikacją z zewnątrz w czasie przeznaczonym na projekt. Audyt kodu pokazuje, dlaczego to w ogóle było możliwe, i wychwytuje błędy, które są trudniejsze do wykrycia lub niemożliwe do wykrycia z zewnątrz: błędy w bibliotekach, martwe ścieżki uruchamiane tylko w rzadkich warunkach, funkcje debugowe pozostawione w produkcji, czy celowo umieszczony kod obniżający bezpieczeństwo.
Pracujemy trzema trybami: analiza automatyczna (SAST), ręczny przegląd kodu i podejście mieszane, w którym automat obejmuje całość, a pentester analizuje fragmenty odpowiadające za uwierzytelnianie, autoryzację, kryptografię i dostęp do danych. W zależności od zakresu projektu wykorzystujemy wsparcie modeli AI, żeby zoptymalizować analizę i wyciągnąć z niej jeszcze więcej.
Doświadczenie: pracowaliśmy m.in. dla banków, domów maklerskich, firm leasingowych, energetycznych, telekomunikacyjnych, produkcyjnych i e-commerce.
Dowiedz się więcejCo obejmuje audyt bezpieczeństwa kodu
Uwierzytelnianie i autoryzacja
Miejsca, gdzie sprawdzane są uprawnienia, i miejsca, gdzie powinny być sprawdzane, a nie są. Spójność kontroli między interfejsem, warstwą usług i dostępem do danych. Obsługa sesji, tokenów i ról.
Przetwarzanie danych wejściowych
Śledzimy drogę danych od punktu wejścia do miejsca użycia. Tam, gdzie dane od użytkownika trafiają do zapytania, polecenia systemowego, szablonu lub odpowiedzi, sprawdzamy, czy po drodze przeszły walidację i kodowanie.
Kryptografia i przechowywanie danych wrażliwych
Dobór algorytmów, zarządzanie kluczami, sposób przechowywania haseł i kluczy, szyfrowanie danych w spoczynku i w tranzycie, generowanie wartości losowych.
Zależności i łańcuch dostaw
Biblioteki zewnętrzne, ich wersje i znane podatności trudne do weryfikacji bez dostępu do kodu, zależności przechodnie, źródła pobierania pakietów. To obszar, który OWASP w edycji 2025 wydzielił jako osobną kategorię Software Supply Chain Failures, i ten sam obszar, którego dotyczy wymóg SBOM w rozporządzeniu Cyber Resilience Act (CRA).
Obsługa błędów i sytuacji wyjątkowych
Co się dzieje, gdy operacja się nie powiedzie: czy transakcja zostaje wycofana, czy system przechodzi w stan bezpieczny, czy komunikat błędu nie ujawnia szczegółów środowiska.
Logowanie zdarzeń
Czy zapisujecie zdarzenia pozwalające odtworzyć przebieg incydentu i czy przy okazji nie trafiają do logów dane, które nie powinny tam być zapisane: hasła, tokeny, pełne numery kart, dane osobowe.
Praktyki bezpiecznego programowania
Zgodność z CWE Top 25, OWASP ASVS w zakresie, który jest nieosiągalny do osiągnięcia bez dostępu do kodu źródłowego i standardami bezpiecznego kodowania właściwymi dla używanego języka. Ta część daje zespołowi materiał do poprawy na przyszłość, nie tylko listę błędów do zamknięcia.
Zakres dopasowujemy do profilu aplikacji: dla aplikacji webowej opieramy go o OWASP TOP 10 i ASVS, dla mobilnej o OWASP MASVS i MAS, a przy przetwarzaniu danych kartowych uwzględniamy wymogi PCI DSS. Ryzyko każdej podatności wyceniamy według CVSS lub OWASP Risk Rating Methodology.
Skontaktuj się z nami
Trzy warianty audytu kodu źródłowego
Analiza automatyczna (SAST). Narzędzia przechodzą przez całą bazę kodu i wychwytują wzorce typowych błędów. Szybka i tania, pokrywa całość, ale generuje wyniki wymagające weryfikacji i nie rozumie kontekstu biznesowego. Sensowna jako cykliczny przegląd i element pipeline’u.
Ręczny przegląd kodu. Pentester czyta kod i śledzi przepływ danych. Najwyższa jakość wyników, wychwytuje błędy logiczne i celowo umieszczone furtki. Kosztowna przy dużych repozytoriach, dlatego rzadko stosuje się ją do całości.
Podejście mieszane. Wariant, który w praktyce wybiera większość klientów: automat obejmuje całą bazę kodu, a ręczna analiza skupia się na modułach o najwyższym ryzyku, czyli uwierzytelnianiu, autoryzacji, płatnościach, kryptografii i integracjach zewnętrznych. Wyniki z automatu weryfikujemy ręcznie, więc do raportu trafiają tylko potwierdzone podatności.
W zależności od zakresu projektu wykorzystujemy wsparcie modeli AI, żeby zoptymalizować analizę i wyciągnąć z niej jeszcze więcej. Audyt kodu najlepiej działa w połączeniu z testami. Jeżeli chcesz sprawdzić aplikację również od strony działającego systemu, zobacz testy penetracyjne aplikacji webowych, pentest aplikacji mobilnych lub testy bezpieczeństwa API.
Dlaczego warto wykonać audyt kodu źródłowego?
Czego nie pokaże test penetracyjny – dlaczego warto wybrać audyt kodu?
Pentest i audyt kodu odpowiadają na inne pytania i dlatego się uzupełniają, a nie zastępują. Cztery kategorie błędów, które w praktyce są zwykle wykrywane dopiero przy analizie kodu:
- Podatności w rzadko osiąganych ścieżkach. Obsługa nietypowego stanu zamówienia, tryb serwisowy, ścieżka uruchamiana raz w miesiącu przez zadanie wsadowe. Tester black-box ich nie wykryje, bo nie ma jak do nich dotrzeć w czasie projektu.
- Błędy w implementacji kryptografii. Programiści mogą szyfrować dane. Przy teście penetracyjnym nie widać na przykład, że klucz jest stały dla wszystkich instalacji, że wektor inicjujący nie jest losowy albo że hasła trafiają do bazy po jednym przebiegu funkcji skrótu bez soli, co istotnie osłabia bezpieczeństwo danych.
- Pozostałości po pracy deweloperskiej. Zaszyte poświadczenia, konta testowe, endpointy do analizy działania aplikacji, zaślepki, warunki obchodzące uwierzytelnianie dla wybranego identyfikatora.
- Kod umieszczony celowo. Furtki pozostawione przez nieuczciwego programistę lub podwykonawcę. To najtrudniejsza kategoria, bo taki kod wygląda poprawnie, dopóki nie prześledzi się dokładnie, kto i kiedy może wywołać daną funkcję.
Kiedy zlecić audyt kodu
- Przed odbiorem systemu od zewnętrznego dostawcy, zanim podpiszesz protokół i zapłacisz ostatnią transzę.
- Przy przejęciu spółki lub produktu, jako element due diligence technicznego.
- Po zmianie zespołu deweloperskiego albo zakończeniu współpracy z podwykonawcą.
- Gdy test penetracyjny wykazał podatność, której przyczyny nie udało się ustalić od strony działającej aplikacji.
- Przed certyfikacją lub audytem wymagającym wykazania bezpiecznego procesu wytwarzania.
- Przy kodzie generowanym z pomocą narzędzi AI, gdzie tempo powstawania kodu wyprzedza możliwości przeglądu przez ludzi, a wzorce bezpieczeństwa bywają odtwarzane niepoprawnie.
Audyt kodu a Cyber Resilience Act
Od 11 września 2026 r. producentów produktów z elementami cyfrowymi obowiązuje wynikający z rozporządzenia CRA obowiązek zgłaszania aktywnie wykorzystywanych podatności oraz poważnych incydentów, w krótkich terminach liczonych w godzinach. Pełne stosowanie rozporządzenia, wraz z wymogami zasadniczymi i dokumentacją zgodności, nastąpi 11 grudnia 2027 r. Sankcje sięgają 15 mln euro lub 2,5% światowego obrotu.
Żeby zgłosić podatność w produkcie, trzeba najpierw wiedzieć, z czego ten produkt się składa. Stąd wymóg SBOM, czyli zestawienia komponentów oprogramowania w formacie odczytywalnym maszynowo. Audyt kodu z przeglądem zależności daje podstawę do jego zbudowania i jednocześnie odpowiada na pytanie, które komponenty niosą realne ryzyko.
Dla podmiotów objętych NIS2 i ustawą o KSC obowiązuje odrębny harmonogram: nowelizacja weszła w życie 3 kwietnia 2026 r., okres dostosowawczy mija 3 kwietnia 2027 r., a podmioty kluczowe muszą przeprowadzić pierwszy audyt bezpieczeństwa do 3 kwietnia 2028 r. Jeżeli chcesz uporządkować warstwę formalną, zobacz audyt zgodności z NIS2 i UoKSC.
Korzyści
Przyczyna, nie tylko objaw
Raport wskazuje konkretny plik i linię kodu, więc poprawka trafia w źródło problemu, a nie w jego przejaw w interfejsie.
Wzrost kompetencji zespołu
Audyt kodu jest jednym z najskuteczniejszych narzędzi budowania świadomości bezpieczeństwa wśród programistów, bo omawiacie własny kod, a nie abstrakcyjne przykłady ze szkolenia.
Podatności, do których pentest nie dotrze
Rzadkie ścieżki, błędy kryptograficzne, pozostałości deweloperskie i celowo umieszczony kod.
Wejście do rozmowy o procesie
Jeżeli te same klasy błędów powtarzają się w różnych modułach, problem leży w procesie wytwarzania. Opracowujemy i wdrażamy Secure SDLC oraz włączamy automatyczne testy bezpieczeństwa do pipeline'u CI/CD.
Materiał wejściowy do SBOM i zarządzania ryzykiem
Przegląd zależności daje obraz tego, z czego faktycznie składa się Wasz produkt.
Argument przy odbiorze od dostawcy
Niezależna ocena kodu bywa jedynym sposobem, żeby rozmawiać z wykonawcą o jakości na podstawie faktów, a nie deklaracji.
Nie wiesz, czy audytować całość, czy wybrane moduły?
Skorzystaj z BEZPŁATNEJ KONSULTACJI
Przejrzymy architekturę i stos technologiczny, wskażemy moduły o najwyższym ryzyku i zaproponujemy wariant audytu dopasowany do budżetu. Bez zobowiązań.
Raport
Raport z audytu bezpieczeństwa kodu
Raport pisany jest dla dwóch odbiorców i tak też jest podzielony.
Część raportu dla Zarządu i osób decyzyjnych
- cel i zakres wykonanych prac,
- zastosowane podejście,
- podsumowanie wyników językiem biznesowym, bez terminologii technicznej,
- ogólna ocena poziomu bezpieczeństwa kodu.
Część techniczna raportu, dla każdej podatności – zależna od zakresu
- tytuł i szczegółowy opis,
- lokalizacja w kodzie: plik, fragment, kontekst wywołania,
- proof of concept tam, gdzie podatność da się wykazać na działającej aplikacji,
- opis możliwych skutków wykorzystania,
- poziom ryzyka według CVSS lub OWASP RRM w skali: krytyczny, wysoki, średni, niski, informacyjny,
- odniesienie do publicznych baz podatności i identyfikatorów CWE,
- rekomendacja naprawcza z opisem sposobu wdrożenia, dopasowana do Waszej technologii.
Raport zawiera też zakres i datę audytu, listę zastosowanych metodyk i technik, wykorzystane narzędzia oraz zestawienie zidentyfikowanych podatności.
Dlaczego warto powierzyć nam audyt bezpieczeństwa kodu?
Audytorzy, którzy sami atakują aplikacje. Kod czytają pentesterzy realizujący testy penetracyjne, nie audytorzy jakości. Różnica jest widoczna w tym, na co zwracają uwagę: nie na czytelność i styl, tylko na to, co wpływa na bezpieczeństwo Twojej aplikacji.
Zespół. Ponad 20 inżynierów bezpieczeństwa z certyfikatami OSCP, OSCE, OSWE, OSEE, CEH, CISSP i CISA, z doświadczeniem w programowaniu i administracji systemami.
Metodyka na uznanych standardach. OWASP Code Review Guide, OWASP ASVS, OWASP Developer Guide, OWASP Top 10, CWE Top 25, CERT Secure Coding Standards, NIST SP 800-218 (SSDF), NIST SP 800-53, Microsoft SDL oraz wytyczne bezpiecznego kodowania dla poszczególnych języków.
Dwie osoby kontaktowe. Pentester Wiodący odpowiada na pytania techniczne, Project Manager pilnuje terminów i ustaleń.
Jakość i niezależny przegląd. Dostajesz raport, a nie wynika pracy narzędzi. Raport jest wynikiem pracy przynajmniej dwóch niezależnych pentesterów lub zespołów – jeden wykonuje prace, drugi niezależnie weryfikuje ich wyniki i raport.
Ochrona kodu i raportów. Zgodnie z ISO 27001: kontrola dostępu do zasobów, na których składowany jest kod, szyfrowanie dysków, szyfrowanie plików i załączników PGP, ciągłe monitorowanie dostępu. Dla wielu klientów to warunek, bez którego rozmowa o audycie kodu w ogóle się nie zaczyna.
Wyjście poza jednorazowy audyt. Opracowujemy, optymalizujemy i wdrażamy Secure SDLC oraz włączamy automatyczne testy bezpieczeństwa do pipeline’u CI/CD.
Skontaktuj się z nami
Najczęściej zadawane pytania
Wycena zależy przede wszystkim od wielkości bazy kodu, wybranego wariantu i liczby technologii w projekcie. Podajemy ją po wstępnej rozmowie i przejrzeniu struktury repozytorium, zawsze jako konkretną pracochłonność.
Od 2 do 8 tygodni, zależnie od wielkości kodu i wariantu. Termin ustalamy przed startem.
Nie. Zakres można ograniczyć do wybranych modułów, zwykle tych odpowiadających za uwierzytelnianie, autoryzację, płatności i przetwarzanie danych wrażliwych. Do sensownej analizy potrzebujemy natomiast kontekstu, czyli informacji, jak audytowany fragment łączy się z resztą systemu.
Zgodnie z ISO 27001: kontrola dostępu do serwerowni i zasobów sieciowych, szyfrowanie dysków, szyfrowanie plików i załączników PGP, szyfrowanie treści wiadomości, ciągłe monitorowanie dostępu. Warunki przekazania i przechowywania kodu ustalamy przed rozpoczęciem prac i zapisujemy w umowie.
Nie, odpowiadają na inne pytania. Audyt kodu pokazuje przyczynę i sięga do miejsc, do których atakujący z zewnątrz pentester może w ograniczonym czasie testów nie dotrzeć. Test penetracyjny pokazuje, co faktycznie da się zrobić z działającym systemem. Najlepsze pokrycie daje połączenie obu.
SAST przechodzi przez całą bazę kodu i wychwytuje wzorce typowych błędów, ale nie rozumie kontekstu biznesowego i zwraca wyniki wymagające weryfikacji. Ręczny przegląd wychwytuje błędy logiczne i celowo umieszczony kod, ale jest kosztowny przy dużych repozytoriach. Dlatego zwykle rekomendujemy wariant mieszany.
Do analizy statycznej m.in. Semgrep, SonarQube i Fortify, uzupełnione o narzędzia właściwe dla danej technologii oraz autorskie rozwiązania pisane pod konkretne przypadki. W zależności od zakresu możemy wspierać pracę modelami AI. Narzędzia traktujemy jako wsparcie ręcznej analizy, nie jako jej zamiennik.
Zakres ustalamy indywidualnie, bo dobór audytora zależy od stosu technologicznego. Przy nietypowych lub starszych technologiach potwierdzamy dostępność odpowiedniej osoby przed złożeniem oferty.
Tak. Wspieramy zespół przy naprawie, prowadzimy szkolenia z usuwania podatności i weryfikujemy wprowadzone poprawki.
Tak. Wdrażamy automatyczne testy bezpieczeństwa w pipeline CI/CD oraz opracowujemy i optymalizujemy Secure SDLC.
Zależnie od wrażliwości danych, poziomu ryzyka i liczby zmian w systemie. Zwykle rekomendujemy cykl od 3 do 24 miesięcy, przy czym analiza automatyczna może działać ciągle w pipeline, a pełny audyt manualny obejmować moduły zmienione od poprzedniego przeglądu.
Tak, przy współpracy długoterminowej warunki są korzystniejsze niż przy pojedynczym projekcie.