VulCode

Audyt kodu źródłowego i bezpieczeństwa aplikacji

Audyt kodu to przegląd repozytorium przez programistów, którzy na co dzień robią code review u siebie i w cudzych projektach open source. Dostajesz raport z listą ryzyk uszeregowaną od najpilniejszych, z miejscem w kodzie i propozycją poprawki, oraz rozmowę o wynikach.

Katalog usług
Raport z audytu kodu w przeglądarce: streszczenie dla zarządu i pierwsze znalezisko

Audyt kodu, test penetracyjny i skaner

Trzy różne rzeczy, często mylone. Audyt często poprzedza pentest, bo usuwa oczywiste błędy taniej.

  • Audyt kodu

    Czyta kod źródłowy od środka i przy każdym znalezisku wskazuje plik, linię i poprawkę.

    • Patrzy na kod źródłowyTak
    • Atakuje działającą aplikację z zewnątrzNie
    • Znajduje błędy w logice uprawnieńTak
    • Wskazuje plik i poprawkęTak
    • Odsiewa fałszywe alarmyTak

  • Test penetracyjny

    Atakuje działającą aplikację z zewnątrz, tak jak zrobiłby to napastnik, bez wglądu w kod.

    • Patrzy na kod źródłowyNie
    • Atakuje działającą aplikację z zewnątrzTak
    • Znajduje błędy w logice uprawnieńCzęściowo
    • Wskazuje plik i poprawkęNie
    • Odsiewa fałszywe alarmyTak

  • Sam skaner

    Narzędzie oznacza podejrzane miejsca w kodzie, ale nikt nie sprawdza, które z nich są prawdziwym problemem.

    • Patrzy na kod źródłowyTak
    • Atakuje działającą aplikację z zewnątrzNie
    • Znajduje błędy w logice uprawnieńNie
    • Wskazuje plik i poprawkęCzęściowo
    • Odsiewa fałszywe alarmyNie

Kiedy warto

Dla każdego, kto podejmuje decyzję na podstawie kodu, którego sam nie czyta.

  • Przed zakupem albo inwestycją

    Sprawdzasz, co naprawdę kryje się w kupowanym produkcie: czy kod jest bezpieczny, czy da się go rozwijać i ile będzie kosztować doprowadzenie go do porządku. Raport pomaga ustalić cenę i warunki umowy.

  • Przed odbiorem projektu

    Druga opinia, zanim zapłacisz ostatnią ratę wykonawcy. Wiesz, co poprawić w ramach gwarancji, a co jest już Twoim kosztem, i masz to na piśmie przy rozmowie o odbiorze.

Raport z audytu

To niezależny przegląd aplikacji, który mówi, co w kodzie jest ryzykiem, zanim to ryzyko stanie się awarią albo wyciekiem.

14 znalezisk od najpilniejszych.

  • Gdy wszystko zwalnia

    Każda zmiana trwa coraz dłużej i psuje coś innego. Pokazujemy, które miejsca w kodzie spowalniają pracę zespołu i od czego zacząć, żeby nowe funkcje znowu wchodziły szybko.

  • Przed przejęciem projektu

    Chcesz wiedzieć, czy kod da się rozwijać, czy trzeba zacząć od nowa. Dostajesz listę ryzyk i szacunek pracy dla obu dróg. Zobacz też przejęcie projektu.

Co sprawdzamy

Audyt to niezależny przegląd aplikacji, który mówi, co w kodzie jest ryzykiem, zanim to ryzyko stanie się awarią albo wyciekiem. Sprawdzamy cztery obszary, w których błąd kosztuje najwięcej.

Gdzie leżą znaleziska przykładowego raportu
14 znalezisk z raportu na tej stronie, każde z numerem z raportu i w kolorze swojego priorytetu.
  • 1347

    Bezpieczeństwo

    Uwierzytelnianie i uprawnienia, dane wejściowe i zapytania do bazy, sekrety w repozytorium.

    Najczęściej tu leżą znaleziska o najwyższym priorytecie.

  • 69101213

    Jakość kodu

    Struktura i powtórzenia, obsługa błędów, czy kod da się bezpiecznie zmieniać.

    Dług techniczny to skróty w kodzie, które przyspieszyły start, a teraz spowalniają każdą zmianę.

  • 211

    Zależności

    Przestarzałe biblioteki, znane podatności, plan aktualizacji.

    Znana podatność to błąd bezpieczeństwa biblioteki, opisany publicznie, z wersją, która go naprawia.

  • 5814

    Wdrożenie i infrastruktura

    Jak kod trafia na serwer, kopie zapasowe, czy środowisko da się odtworzyć.

    Wdrożenie i kopie zapasowe są częścią audytu, bo tam też tracą się dane.

W czym piszemy na co dzień

Audytujemy to, w czym piszemy na co dzień, między innymi TypeScript i JavaScript, React, Node.js, PHP, Python, Go, Rust i C#. O innych technologiach mówimy przed wyceną, a nie w trakcie audytu.

Jak wygląda jedno znalezisko

Część sprawdzamy narzędziami, ale najważniejsze błędy znajduje człowiek, który czyta logikę. Tak wygląda jedno znalezisko w raporcie: co jest nie tak, co grozi i jak to poprawić, bez czytania kodu. Obok ta sama poprawka w pull requeście, potwierdzona przez audytora.

Każdy może pobrać cudze zamówienia
Priorytet
Krytyczny
Gdzie
Panel klienta, lista zamówień
Sprawdzone
Ręcznie, na wersji testowej
Poprawka
Około 2 godzin pracy
  1. Co jest nie takLista zamówień nie sprawdza, kto pyta, a zapytanie do bazy powstaje z adresu e-mail wpisanego w adresie strony.Każde znalezisko zaczyna się od opisu bez żargonu.
  2. Co groziKażdy, kto zna adres panelu, pobierze dane i zamówienia wszystkich klientów sklepu.Priorytet wynika ze skutku dla firmy, nie z rodzaju błędu.
  3. Jak poprawićLista tylko dla zalogowanego klienta i tylko z jego zamówieniami, zapytanie z parametrem zamiast sklejania tekstu.Opis wystarcza Twojemu zespołowi albo nam, żeby wprowadzić poprawkę.
  4. Jak sprawdzić poprawkęTest loguje się jako klient A, prosi o zamówienia klienta B i dostaje odmowę.Każde znalezisko ma test, który potwierdza, że problem zniknął.

W prawdziwym raporcie znalezisko ma też ścieżkę pliku i numer linii z Twojego repozytorium.

Pull request z poprawką znaleziska 1 i komentarzami audytora

Raport, który pomaga podjąć decyzję

Raport ma pomóc podjąć decyzję, a nie tylko wyliczyć błędy. Każde znalezisko dostaje priorytet z tej samej skali, a z priorytetu wynika, kiedy je naprawić.

Pierwsza strona
Streszczenie dla zarządu
Jedna strona bez żargonu
Stan aplikacji

Panel działa i da się go rozwijać, ale dwa błędy trzeba usunąć przed kolejnym wdrożeniem.

Co grozi

Wyciek danych klientów przez listę zamówień i włamanie przez starą bibliotekę.

Co zrobić najpierw
  1. Zamknąć dostęp do cudzych zamówień
  2. Zaktualizować bibliotekę z podatnością
  3. Włączyć kopię bazy poza serwerem
Wniosek
Rozwijać po poprawkach z części 1
Priorytet od skutku
Błąd w płatnościach waży więcej niż literówka w komentarzu, więc kolejność zależy od skutku dla biznesu. Przy każdym znalezisku piszemy też, dlaczego dostało taki priorytet.

  1. Krytyczny

    Przed kolejnym wdrożeniem

    Wyciek danych, przejęcie kont albo pieniędzy.

    Przykład z raportu
    2Dostęp do cudzych zamówień

  2. Wysoki

    W najbliższym etapie prac

    Awaria albo podatność, którą łatwo wykorzystać.

    Przykład z raportu
    3Biblioteka z publiczną podatnością

  3. Średni

    W planie na najbliższe tygodnie

    Ryzyko zależne od warunków.

    Przykład z raportu
    4Brak kopii zapasowej bazy poza serwerem

  4. Niski

    Przy okazji zmian w tym miejscu

    Dług techniczny i czytelność.

    Przykład z raportu
    5Powtórzona logika cen w trzech miejscach

    Dług techniczny nie miesza się z ryzykiem bezpieczeństwa, żeby było jasne, co jest pilne.

Jak pilnujemy jakości raportu

Cztery zasady, które stosujemy w każdym audycie, żeby raport dało się wykorzystać do decyzji.

  • Za kurtyną4

Za kurtyną

  • Kontekst biznesowy

    Priorytet zależy od skutku, nie od liczby linii. Zanim zaczniemy, pytamy, które części aplikacji zarabiają i gdzie są dane klientów.

  • Bez fałszywych alarmów

    Wyniki narzędzi sprawdzamy ręcznie. Do raportu trafia tylko to, co da się odtworzyć i co jest prawdziwym problemem.

  • Poufność

    Kod czytamy na podstawie umowy o poufności i nie kopiujemy go poza ustalone środowisko. Zakres dostępu ustalamy z Tobą przed startem.

  • Język zrozumiały dla zarządu

    Raport ma streszczenie bez żargonu dla osób, które nie czytają kodu. Każde znalezisko ma też część techniczną dla Twojego zespołu.

Jak przebiega audyt

Od dostępu do repozytorium do omówienia raportu.

  1. Zakres

    Ustalamy, które moduły i środowiska audytujemy, jaki jest cel audytu i co jest dla Ciebie najważniejsze. Kod czytamy na podstawie umowy o poufności i nie kopiujemy go poza ustalone środowisko.

    Moduł płatności
    dopisany do zakresu po omówieniu
    dostajesz: wycena i termin raportu
  2. Przegląd automatyczny

    Narzędzia sprawdzają podatne biblioteki, sekrety w repozytorium i jakość kodu w analizie statycznej. Analiza statyczna to sprawdzanie kodu narzędziem bez jego uruchamiania.

    dostajesz: lista kandydatów do sprawdzenia
  3. Przegląd ręczny

    Czytamy logikę: uwierzytelnianie i uprawnienia, dane wejściowe i zapytania, architekturę i testy. Wyniki narzędzi weryfikujemy i do raportu trafia tylko to, co jest prawdziwym problemem.

    dostajesz: potwierdzone znaleziska
  4. Raport

    Znaleziska uszeregowane od najpilniejszych, każde z plikiem, linią, skutkiem i propozycją poprawki.

    Biblioteka z podatnością
    wskazana przez narzędzie, potwierdzona ręcznie
    Dostęp do cudzych zamówień
    znaleziony przy czytaniu uprawnień
    dostajesz: raport ze streszczeniem
  5. Omówienie i poprawki

    Omawiamy raport z Tobą albo z Twoim zespołem i odpowiadamy na pytania. Poprawki to osobne zlecenie.

    nowy obszar wraca do: Zakres
    dostajesz: decyzja, co dalej
Sam raport
Raport ze streszczeniem i omówienie z Twoim zespołem.
  • Masz własny zespół, który wprowadzi poprawki.
  • Potrzebujesz oceny przed decyzją o zakupie albo odbiorze.
Raport i poprawki
Poprawki jako osobne zlecenie wycenione z raportu, a potem ponowny przegląd.
  • Nie masz zespołu albo jest zajęty.
  • Chcesz potwierdzenia, że znaleziska zostały zamknięte.
Termin raportu podajemy w wycenie, po tym jak zobaczymy repozytorium i ustalimy, które części sprawdzamy. Cennik i wycena

Code review robimy na co dzień

Robimy je przy własnych projektach i w cudzych projektach open source, gdzie nasze zmiany przechodzą przegląd opiekunów. Poniżej kilka błędów, które znaleźliśmy i poprawiliśmy w cudzym kodzie, i to, czego nas nauczyły.

125zmian przyjętych przez opiekunów, każda to jeden kwadrat
60+cudzych projektów open source z naszymi przyjętymi zmianami
540 000+gwiazdek na GitHubie mają te projekty
Jak wygląda przegląd u opiekunów
  • Opiekun projektu czyta każdą zmianę, uruchamia testy i prosi o poprawki, zanim ją przyjmie. Do kodu trafia dopiero wersja, którą zaakceptował.
  • Uczy nas to tego samego, czego szukamy w audycie: jak ktoś spoza zespołu czyta kod, który dla autora był oczywisty.
  • W audycie pracujemy tak samo: każde znalezisko opisujemy tak, żeby dało się je sprawdzić i poprawić bez nas.
Sześć błędów z cudzego kodu i czego nas nauczyły
  • Proxmox VEPerl i JavaScriptSprawdzanie danych wejściowychW dużym projekcie infrastrukturalnym interfejs musi sprawdzać dane tak samo jak API, bo inaczej użytkownik dowiaduje się o błędzie dopiero po wysłaniu formularza.
  • MonologPHPSekrety w logachUkrywanie sekretów w logach musi schodzić w głąb struktur danych.
  • WhoopsPHPUcieczka znakówUcieczka znaków w stronie błędu też jest kwestią bezpieczeństwa: klikalne powinny być tylko linki http i https.
  • PHPMailerPHPStan połączenia i błędyProtokół SMTP ma stany, a polecenie wysłane w złym stanie staje się treścią wiadomości.
  • SonicRustKopie zapasoweKopia zapasowa robiona w trakcie pracy musi brać spójny stan, a nie blokować magazyn albo czytać go w połowie zapisu.
  • Pelican PanelPHPAktualizacjeAktualizacja, która w połowie drogi pada, nie może zostawić systemu w gorszym stanie niż przed nią.

Najczęstsze pytania o audyt kodu

Odpowiedzi o zakresie, poufności i wycenie audytu.

Czytaj dalej

Co zwykle dzieje się po audycie i jak chronimy kod, który nam powierzasz.

Chcesz wiedzieć, co kryje Twój kod?

Napisz, czego dotyczy aplikacja i w czym jest napisana. Odpowiemy w godzinę z pytaniami i wyceną audytu.