Lista kontrolna technical due diligence dla projektów oprogramowania

Oceniasz projekt informatyczny przed transakcją? Poznaj nasz audyt kodu i technical due diligence.

Przeczytaj także: DevSecOps w 2026: jak zintegrować bezpieczeństwo z pipeline’em

Technical due diligence oddziela opinie od faktów. Niezależnie od tego, czy przejmujesz firmę, inwestujesz w startup, wybierasz dostawcę, czy audytujesz wewnętrzny projekt, ta lista kontrolna daje systematyczne ramy oceny fundamentów technicznych. Każda sekcja zawiera konkretne punkty do sprawdzenia oraz wskazówki punktacji, które pozwalają ująć ryzyko w liczbach.

Obszar 1: Jakość kodu

Jakość kodu to najbardziej bezpośredni wskaźnik dyscypliny inżynierskiej. Czysty, dobrze ustrukturyzowany kod łatwiej utrzymać, rozwijać i debugować. Słaba jakość kodu zdradza nagromadzone skróty, których koszt będzie z czasem narastał.

Analiza automatyczna

• Uruchom narzędzia analizy statycznej (SonarQube, ESLint, Pylint) — jaka jest ogólna ocena jakości?
• Zmierz pokrycie kodu testami — jaki odsetek kodu obejmują testy automatyczne? (Punkt odniesienia: 60–80% to dobry wynik, poniżej 40% to czerwona flaga)
• Sprawdź złożoność cyklomatyczną — wysoka złożoność oznacza kod trudny do zrozumienia i przetestowania
• Wyszukaj duplikację kodu — powyżej 10% duplikacji sugeruje programowanie metodą „kopiuj-wklej”
• Przeskanuj zależności pod kątem podatności — ile znanych CVE (publicznie zgłoszonych luk bezpieczeństwa) występuje w drzewie zależności?

Ręczny przegląd kodu

• Oceń konwencje nazewnictwa — czy zmienne, funkcje i klasy mają jasne i spójne nazwy?
• Oceń separację odpowiedzialności — czy logika biznesowa jest oddzielona od infrastruktury, warstwy prezentacji i dostępu do danych?
• Sprawdź obsługę błędów — czy błędy są przechwytywane, logowane i obsługiwane w kontrolowany sposób, czy propagują się po cichu?
• Oceń standardy kodowania — czy styl jest spójny, czy każdy plik wygląda, jakby napisał go ktoś inny?
• Przejrzyj ostatnie commity — czy opisy commitów są sensowne? Czy pull requesty przechodzą review? Czy historia w gicie jest uporządkowana, czy chaotyczna?

Ocena długu technicznego

• Zidentyfikuj komentarze TODO/FIXME/HACK — policz je i pogrupuj
• Oceń backlog długu technologicznego — czy istnieje udokumentowana lista znanych problemów? Rośnie czy maleje?
• Oceń rozkład wieku kodu — jaki odsetek kodu nie był modyfikowany od 2 lat lub dłużej?
• Wyszukaj martwy kod — nieużywane funkcje, nieosiągalne gałęzie, zakomentowane bloki

Kod generowany przez AI

• Ustal pochodzenie kodu — które części bazy kodu wygenerowali asystenci AI i czy takie użycie jest udokumentowane oraz objęte polityką?
• Sprawdź pokrycie testami modułów wygenerowanych przez AI — czy są przetestowane co najmniej tak dobrze jak kod pisany ręcznie, czy trafiły do repozytorium bez testów?
• Przejrzyj wygenerowany kod pod kątem „przecieku” licencji — czy może powielać fragmenty projektów open source o niezgodnych licencjach?
• Przeskanuj wygenerowany kod pod kątem ujawnionych sekretów i niebezpiecznych wzorców — zaszytych na stałe danych logowania, kluczy API, wyłączonej walidacji (zobacz, dlaczego kod z AI tak często zawiera luki bezpieczeństwa)

Wskazówki punktacji:

• Zielony (niskie ryzyko): pokrycie > 70%, brak krytycznych podatności, spójny styl, dług techniczny pod kontrolą
• Żółty (umiarkowane ryzyko): pokrycie 40–70%, pojedyncze podatności, niespójny styl, rosnący dług techniczny
• Czerwony (wysokie ryzyko): pokrycie < 40%, krytyczne podatności, brak standardów, przytłaczający dług techniczny

Obszar 2: Architektura

Architektura decyduje o tym, jak dobrze system może ewoluować, skalować się i integrować z otoczeniem. Dobra architektura sprawia, że zmiany są tanie. Słaba sprawia, że każda zmiana jest kosztowna i ryzykowna.

Projekt systemu

• Udokumentuj architekturę wysokiego poziomu — czy zespół potrafi ją jasno wyjaśnić? Czy istnieje diagram?
• Zidentyfikuj wzorzec architektoniczny — monolit, mikroserwisy, modularny monolit, architektura sterowana zdarzeniami? Czy wybór pasuje do złożoności systemu?
• Oceń sprzężenie (coupling) — jak ściśle powiązane są komponenty? Czy da się zmienić jeden bez wpływu na pozostałe?
• Oceń spójność (cohesion) — czy każdy komponent ma jedną, jasno określoną odpowiedzialność?
• Sprawdź dryf architektoniczny — czy faktyczny kod odpowiada udokumentowanej architekturze?

Architektura danych

• Udokumentuj model danych — czy jest znormalizowany, opisany i spójny?
• Oceń wybór bazy danych — czy pasuje do charakteru danych (relacyjna, NoSQL, szeregi czasowe)?
• Sprawdź strategię migracji danych — czy istnieje proces migracji schematu? Czy migracje są wersjonowane?
• Oceń integralność danych — czy ograniczenia referencyjne są egzekwowane? Czy dane są walidowane na poziomie aplikacji?
• Oceń kopie zapasowe i odtwarzanie — czy backupy są zautomatyzowane, testowane i możliwe do odtworzenia w zdefiniowanym RTO?

Architektura integracji

• Zmapuj integracje zewnętrzne — API, usługi firm trzecich, kolejki komunikatów, transfery plików
• Oceń odporność integracji — co się dzieje, gdy usługa zewnętrzna działa wolno lub jest niedostępna? (Circuit breakery, ponowienia, mechanizmy awaryjne)
• Sprawdź wersjonowanie API — jak zarządza się zmianami łamiącymi zgodność wobec konsumentów?
• Oceń przetwarzanie komunikatów — czy komunikaty są przetwarzane dokładnie raz, czy co najmniej raz? Czy zaimplementowano idempotentność?

Wskazówki punktacji:

• Zielony: czytelna architektura, adekwatne wzorce, niskie sprzężenie, udokumentowany model danych
• Żółty: częściowa dokumentacja, miejscami silne sprzężenie, niespójności w modelu danych
• Czerwony: brak dokumentacji architektury, silnie sprzężony monolit, nieudokumentowany model danych

Obszar 3: Bezpieczeństwo

Ocena bezpieczeństwa wskazuje podatności, które mogą doprowadzić do wycieku danych, naruszenia przepisów lub zakłóceń w działaniu.

Bezpieczeństwo aplikacji

• Przeprowadź skan SAST — ile jest podatności krytycznych i wysokich?
• Przeprowadź skan DAST — czy w działającej aplikacji są podatności możliwe do wykorzystania?
• Sprawdź pokrycie OWASP Top 10 — wstrzykiwanie kodu, błędy uwierzytelniania, ujawnianie danych wrażliwych, XXE, błędy kontroli dostępu
• Oceń implementację uwierzytelniania — algorytm haszowania haseł, zarządzanie sesjami, obsługa MFA
• Przejrzyj model autoryzacji — czy kontrola dostępu opiera się na rolach czy na atrybutach? Czy uprawnienia są egzekwowane konsekwentnie?
• Zweryfikuj zobowiązania wynikające z licencji open source — czy w oprogramowaniu dystrybuowanym lub dostarczanym jako SaaS jest kod na licencjach copyleft (GPL, AGPL), które wymuszają udostępnienie kodu źródłowego? Czy zobowiązania licencyjne są śledzone w SBOM (wykazie składników oprogramowania)?

Bezpieczeństwo infrastruktury

• Przejrzyj architekturę sieci — czy systemy produkcyjne działają w prywatnych podsieciach? Czy ruch przychodzący i wychodzący jest kontrolowany?
• Sprawdź szyfrowanie danych — czy dane są szyfrowane w spoczynku i w transmisji? Jakie algorytmy i jakie zarządzanie kluczami?
• Oceń zarządzanie sekretami — czy dane uwierzytelniające są przechowywane w kodzie, w zmiennych środowiskowych, czy w menedżerze sekretów?
• Przejrzyj kontrolę dostępu — kto ma dostęp do produkcji? Czy dostęp jest logowany? Czy MFA jest wymuszone?
• Sprawdź monitoring bezpieczeństwa — wykrywanie włamań, analiza logów, alerty o podejrzanej aktywności

Zgodność z regulacjami

• Zidentyfikuj obowiązujące regulacje (RODO, SOC 2, HIPAA, PCI-DSS)
• Oceń praktyki prywatności danych — przetwarzanie danych osobowych, zarządzanie zgodami, polityki retencji danych
• Sprawdź ścieżkę audytu — czy krytyczne działania są logowane z tożsamością użytkownika, znacznikiem czasu i szczegółami operacji?
• Przejrzyj plan reagowania na incydenty — czy istnieje? Czy był testowany?

Wskazówki punktacji:

• Zielony: brak krytycznych podatności, silne uwierzytelnianie, szyfrowanie wszędzie, gotowość do audytu zgodności
• Żółty: pojedyncze podatności (bez krytycznych), częściowe szyfrowanie, luki w zgodności
• Czerwony: krytyczne podatności, słabe uwierzytelnianie, sekrety otwartym tekstem, brak ram zgodności

Obszar 4: Skalowalność i wydajność

Skalowalność przesądza o tym, czy system udźwignie wzrost bez proporcjonalnego wzrostu kosztów lub przepisywania architektury.

Bieżąca wydajność

• Przejrzyj metryki wydajności — czasy odpowiedzi (p50, p95, p99), przepustowość, odsetek błędów
• Sprawdź wykorzystanie zasobów — CPU, pamięć, dysk i sieć przy obecnym obciążeniu
• Zidentyfikuj wąskie gardła — zapytania do bazy danych, wywołania zewnętrznych API, operacje intensywne obliczeniowo
• Oceń strategię cache’owania — co, gdzie i jak jest buforowane oraz jak rozwiązano unieważnianie cache’u?

Architektura skalowalności

• Oceń poziomą skalowalność — czy aplikację da się skalować przez dodawanie instancji, czy wymaga skalowania pionowego?
• Sprawdź skalowalność bazy danych — repliki do odczytu, pule połączeń, optymalizacja zapytań, gotowość do shardingu
• Oceń bezstanowość — czy dowolna instancja może obsłużyć dowolne żądanie, czy wymagane jest przypisanie sesji do instancji?
• Przejrzyj konfigurację autoskalowania — czy system skaluje się automatycznie w zależności od obciążenia?

Testy obciążeniowe i przeciążeniowe

• Czy przeprowadzono testy obciążeniowe? Jakie były wyniki?
• Jaka jest maksymalna przetestowana przepustowość? Jak ma się do prognozowanego szczytowego obciążenia?
• Jak system zachowuje się przy przeciążeniu — degraduje się w kontrolowany sposób czy ulega awarii kaskadowej?
• Ile trwa powrót do normalnego działania po przeciążeniu?

Wskazówki punktacji:

• Zielony: skalowanie poziome, przeprowadzone testy obciążeniowe, skonfigurowane autoskalowanie, 3-krotny zapas ponad obecny szczyt
• Żółty: wyłącznie skalowanie pionowe, ograniczone testy obciążeniowe, ręczne skalowanie, 1,5-krotny zapas
• Czerwony: brak możliwości skalowania bez przebudowy architektury, brak testów obciążeniowych, system na granicy wydajności

Obszar 5: Zespół i procesy

Technologia jest tak dobra, jak zespół, który ją buduje i utrzymuje. Ocena zespołu pokazuje, czy organizacja jest w stanie utrzymać i rozwijać system.

Skład zespołu

• Zmapuj zespół — role, poziomy doświadczenia, staż, obszary odpowiedzialności
• Zidentyfikuj zależność od kluczowych osób — czy krytyczna wiedza jest skupiona w jednej lub dwóch osobach?
• Policz bus factor dla krytycznych modułów — ile osób musiałoby odejść, żeby nikt nie rozumiał danej części systemu?
• Oceń stabilność zespołu — rotacja w ciągu ostatnich 12 miesięcy
• Oceń proces rekrutacji — ile czasu zajmuje obsadzenie wolnego stanowiska?

Proces wytwórczy

• Oceń dojrzałość CI/CD — zautomatyzowany pipeline budowania, testowania i wdrażania
• Przejrzyj strategię gałęzi — czy obowiązuje spójny workflow (GitFlow, trunk-based)?
• Sprawdź praktyki przeglądu kodu — czy każda zmiana jest przeglądana przed scaleniem? Jaka jest jakość tych przeglądów?
• Oceń proces wydań — jak często trafiają wdrożenia na produkcję? Ile czasu mija od commita do produkcji?

Zarządzanie wiedzą

• Oceń dokumentację projektową — dokumentacja architektury i API, przewodnik wdrożeniowy dla nowych osób, runbooki
• Sprawdź dokumentację w kodzie — czy złożone funkcje są opisane? Czy istnieje dokumentacja referencyjna API?
• Oceń onboarding — ile czasu potrzebuje nowy programista, żeby wnieść pierwszy istotny wkład?
• Przejrzyj praktyki dzielenia się wiedzą — prezentacje techniczne, kultura dokumentowania, programowanie w parach

Wskazówki punktacji:

• Zielony: pełny zespół, brak pojedynczych punktów awarii, dojrzałe CI/CD, kompletna dokumentacja
• Żółty: częściowa zależność od kluczowych osób, podstawowe CI/CD, częściowa dokumentacja
• Czerwony: silna zależność od kluczowych osób, procesy ręczne, szczątkowa dokumentacja

Szablon podsumowania ocen

Obszar	Waga	Ocena (1–5)	Wynik ważony	Kluczowe ustalenia
Jakość kodu	20%	_	_
Architektura	25%	_	_
Bezpieczeństwo	20%	_	_
Skalowalność	15%	_	_
Zespół i procesy	20%	_	_
Razem	100%		_ / 5,0

Interpretacja:

• 4,0–5,0: niskie ryzyko — system jest dobrze zbudowany i łatwy w utrzymaniu
• 3,0–3,9: umiarkowane ryzyko — wybrane obszary wymagają inwestycji, ale nie ma blokerów
• 2,0–2,9: wysokie ryzyko — znaczący dług techniczny, którego spłata będzie wymagała dużego budżetu
• Poniżej 2,0: ryzyko krytyczne — fundamentalne problemy, które mogą wymagać przebudowy architektury lub napisania systemu od nowa

Kiedy zlecić audyt zewnętrzny

Część tej listy możesz przejść samodzielnie, ale w kilku sytuacjach niezależna ocena się opłaca:

• Przed przejęciem lub inwestycją — gdy od wyników zależy decyzja, ocena musi być obiektywna, a oceniający nie mogą mieć interesu w jej wyniku.
• Gdy zespół miałby oceniać własny kod — wewnętrzne przeglądy rzadko dostrzegają własne słabe punkty, a ich wnioski mają mniejszą wagę dla inwestorów i zarządu.
• Przed przejęciem systemu od dostawcy — zanim zaakceptujesz przekazanie, musisz znać rzeczywisty stan kodu, bezpieczeństwa i dokumentacji.
• Gdy w firmie brakuje kompetencji w zakresie architektury, bezpieczeństwa lub DevOps, by przeprowadzić te kontrole z pełnym przekonaniem.

Nasz pakiet Technical Due Diligence obejmuje pełny audyt kodu, a dodatkowo zespół i procesy, skalowalność, licencje open source oraz ryzyka istotne dla inwestora. Trwa 2–3 tygodnie, a jego cena zaczyna się od 35 000 PLN. Jeśli potrzebujesz wyłącznie oceny na poziomie kodu — jakości, bezpieczeństwa i długu technicznego — Audyt kondycji kodu trwa 1–2 tygodnie i kosztuje od 18 000 PLN.

Jak ARDURA Consulting wspiera technical due diligence

Technical due diligence wymaga doświadczonych inżynierów, którzy szybko i obiektywnie ocenią kod, architekturę i praktyki zespołu — a takie kompetencje trudno pozyskać na krótkie zlecenie.

• Ponad 500 seniorów z obszarów architektury oprogramowania, inżynierii bezpieczeństwa, DevOps i zapewniania jakości — dostępnych w ciągu 2 tygodni
• Stawki o około 35-55% niższe niż średnia stawka freelancera IT w Niemczech, z elastycznością od jednorazowych ocen po stałe doradztwo techniczne
• 99% klientów zostaje z nami — inżynierowie dostarczają szczere, praktyczne oceny zamiast ogólników
• Ponad 211 zrealizowanych projektów — oceniający, którzy widzieli dobre i złe rozwiązania w dziesiątkach stosów technologicznych i branż

Niezależnie od tego, czy potrzebujesz oceny o stałym zakresie w harmonogramie transakcji M&A, czy stałego doradztwa technicznego dla spółek portfelowych, ARDURA Consulting zapewnia inżynierską głębię, która zamienia ustalenia due diligence w świadome decyzje.