Bezpieczeństwo aplikacji: minimum, którego wymagać od wykonawcy

Bezpieczeństwo aplikacji zamawianej u software house’u trzeba zapisać w umowie jako konkretne wymagania, a nie zakładać, że wykonawca zadba o nie sam. Minimum to wspólny punkt odniesienia (OWASP Top 10 i standard ASVS), aktualizacje zależności, hasła i klucze poza kodem, kopie zapasowe ze sprawdzonym odtworzeniem, testy bezpieczeństwa przed startem oraz jasna odpowiedzialność po wdrożeniu. Poniżej rozpisuję tę listę i pokazuję, jak sprawdzić wykonawcę, nie będąc programistą.

Dlaczego bezpieczeństwo aplikacji trzeba zapisać w umowie

Bezpieczeństwa nie widać przy odbiorze. Aplikacja z poważną luką wygląda i działa tak samo jak aplikacja zabezpieczona, więc bez zapisanych wymagań zamawiający nie ma jak go sprawdzić ani wyegzekwować.

Do tego dochodzi presja kosztów. Jeśli budżet jest napięty, a wymagań bezpieczeństwa nie ma w specyfikacji, najłatwiej oszczędzić właśnie na nich, bo nikt tego od razu nie zauważy. Firma, która przetwarza dane osobowe, ma przy tym własny obowiązek: art. 32 RODO wymaga od administratora i podmiotu przetwarzającego odpowiednich środków technicznych i organizacyjnych, w tym regularnego testowania ich skuteczności. Wykonawca pomaga je wdrożyć, ale odpowiedzialność wobec klientów i urzędu zostaje po stronie firmy.

OWASP Top 10 i ASVS: wspólny język z wykonawcą

Zamiast wymyślać własną listę wymagań, warto odwołać się do dwóch otwartych dokumentów fundacji OWASP. Pierwszy mówi, czego się bać, drugi, co konkretnie sprawdzić.

Lista OWASP Top 10:2025, czyli wydanie z 2025 roku, to zestawienie najpoważniejszych zagrożeń dla aplikacji internetowych. Na pierwszych miejscach są błędy kontroli dostępu, błędy konfiguracji oraz problemy w łańcuchu dostaw oprogramowania, czyli w bibliotekach i narzędziach, z których korzysta projekt. To dobra lista do rozmowy z zarządem i do pytań zadawanych wykonawcy.

ASVS to standard weryfikacji bezpieczeństwa aplikacji z wymaganiami, które da się sprawdzić jedno po drugim. Ma trzy poziomy, a jego autorzy piszą, że do poziomu drugiego powinna dążyć większość aplikacji, natomiast poziom pierwszy to minimum na start, jak opisuje rozdział o poziomach w ASVS 5.0. W umowie wystarczy zapis, który poziom obowiązuje i jak wykonawca wykaże jego spełnienie.

Minimum, którego wymagać od wykonawcy

Niezależnie od poziomu ASVS są wymagania, bez których nie przyjmowałbym żadnej aplikacji biznesowej. Każde z nich da się sprawdzić pytaniem albo dokumentem, bez czytania kodu.

1. Kontrola dostępu po stronie serwera. Każda operacja sprawdza, czy zalogowany użytkownik ma do niej prawo, a nie tylko ukrywa przycisk w interfejsie.
2. Bezpieczne logowanie. Hasła przechowywane w postaci skrótu, ograniczenie liczby prób, logowanie dwuskładnikowe co najmniej dla kont administracyjnych.
3. Hasła i klucze poza kodem. Dane dostępowe do baz i usług zewnętrznych trzymane w menedżerze sekretów lub konfiguracji serwera, nigdy w repozytorium.
4. Kontrola zależności. Lista używanych bibliotek, automatyczne wykrywanie znanych podatności i ustalony czas na wdrożenie poprawek.
5. Bezpieczna konfiguracja. Wyłączony tryb diagnostyczny na produkcji, brak domyślnych haseł, szyfrowane połączenia, oddzielne środowisko testowe.
6. Kopie zapasowe. Automatyczne, przechowywane poza głównym serwerem, z odtworzeniem sprawdzanym w ustalonym rytmie.
7. Logi i alerty. Zapis logowań, zmian uprawnień i błędów, bez haseł i pełnych danych osobowych w logach, z powiadomieniem o nietypowych zdarzeniach.
8. Obsługa błędów. Użytkownik widzi zrozumiały komunikat, a szczegóły techniczne trafiają tylko do logów.
9. Przegląd kodu. Każda zmiana przechodzi przez drugą osobę, zanim trafi na produkcję.
10. Ograniczony dostęp do produkcji. Imienna lista osób z dostępem i odbieranie go od razu po zmianie składu zespołu.

Weźmy jako przykład panel klienta, w którym zamówienie otwiera się pod adresem z numerem. Jeśli serwer nie sprawdza, czy zamówienie należy do zalogowanego klienta, wystarczy zmienić numer w pasku przeglądarki, żeby zobaczyć cudze dane. Ten błąd nie wymaga żadnej wiedzy hakerskiej i dlatego kontrola dostępu jest na pierwszym miejscu listy.

Testy bezpieczeństwa przed startem i po zmianach

Testy bezpieczeństwa powinny być częścią odbioru, a nie dodatkiem po uruchomieniu systemu. Minimum to automatyczne testy uprawnień, skan zależności przy każdym wdrożeniu i test penetracyjny przed startem aplikacji.

Test penetracyjny najlepiej zlecić komuś spoza zespołu, który budował aplikację. Własny zespół zna system zbyt dobrze i nieświadomie omija te same miejsca, które przeoczył przy pisaniu kodu. Raport z testu powinien mieć opis każdej znalezionej luki, ocenę jej wagi i potwierdzenie naprawy po ponownym teście. Kolejny test planuje się po dużych zmianach, na przykład po dodaniu płatności albo nowego rodzaju kont użytkowników.

Bezpieczeństwo aplikacji po wdrożeniu

Większość pracy nad bezpieczeństwem zaczyna się po starcie. Nowe podatności w bibliotekach i serwerach są publikowane stale, więc aplikacja bezpieczna w dniu odbioru po roku bez aktualizacji już taka nie jest.

Dlatego wymagania bezpieczeństwa muszą trafić też do umowy utrzymania: czas na wdrożenie poprawki krytycznej, regularne aktualizacje zależności, przegląd kont i uprawnień, test odtworzenia kopii. Szczegóły takiej umowy opisuję w tekście o tym, co powinna zawierać umowa SLA na utrzymanie systemu. Aktualizacje odkładane latami zamieniają się w dług, który potem trzeba spłacić naraz, o czym piszę przy temacie długu technologicznego w systemach firmowych.

Kod pisany z pomocą AI a bezpieczeństwo aplikacji

Kod pisany z pomocą asystentów AI podlega tym samym wymaganiom co każdy inny. Bezpieczeństwo aplikacji nie zależy od tego, kto napisał linijkę, tylko od tego, czy ktoś ją sprawdził i przetestował.

Zespoły programistów coraz częściej korzystają z modeli językowych przy pisaniu kodu, co przyspiesza pracę, ale dokłada kilka ryzyk. Asystent potrafi zaproponować bibliotekę przestarzałą albo taką, która w ogóle nie istnieje, a ktoś może opublikować paczkę o tej nazwie. Potrafi też wygenerować kod, który działa, ale pomija sprawdzenie uprawnień. Do tego dochodzi pytanie, czy programiści nie wklejają do narzędzi AI kluczy i fragmentów danych klienta. Zapytaj wykonawcę, jakie ma zasady korzystania z AI i kto przegląda wygenerowany kod. Szerzej piszę o tym w tekście o tym, co dla klienta oznacza AI w zespole programistów.

Jak sprawdzić wykonawcę, nie będąc programistą

Wykonawcę najlepiej sprawdzić pytaniami o konkretne praktyki i prośbą o dokumenty, a nie pytaniem, czy dba o bezpieczeństwo. Na to drugie każdy odpowie twierdząco.

• Gdzie przechowujecie hasła i klucze do produkcji i kto ma do nich dostęp?
• Jak odbieracie dostępy osobie, która odchodzi z projektu?
• Skąd wiecie o podatności w bibliotece i ile trwa wdrożenie poprawki?
• Czy możemy zobaczyć raport ze skanera zależności dla jednego z waszych projektów, bez danych klienta?
• Jak testujecie, że użytkownik nie zobaczy cudzych danych?
• Kiedy ostatnio odtwarzaliście system z kopii zapasowej i ile to trwało?

Konkretne, spokojne odpowiedzi z przykładami są dobrym sygnałem. Ogólniki i odsyłanie do certyfikatów dostawcy chmury już nie, bo zabezpieczenia serwerowni nie chronią przed błędem w kodzie aplikacji. Jeśli system już działa i przejmujesz go od kogoś innego, zacznij od audytu, który opisuję w tekście o tym, jak przeprowadzić przejęcie projektu IT z audytem.

Odpowiedzialność za bezpieczeństwo w umowie

Umowa powinna mówić, jakie wymagania bezpieczeństwa obowiązują, jak wykonawca wykaże ich spełnienie i co się dzieje, gdy wykryjecie lukę albo incydent. Same ogólne zapisy o należytej staranności nie wystarczą.

• Wymagania w specyfikacji: poziom ASVS albo lista wymagań z tego tekstu jako część zakresu.
• Kryteria odbioru: raport z testu penetracyjnego i potwierdzenie naprawy ważnych luk przed startem.
• Incydenty: obowiązek niezwłocznego informowania o podejrzeniu naruszenia i współpracy przy jego wyjaśnieniu.
• Czas na poprawki: w umowie utrzymania osobno dla luk krytycznych i pozostałych.
• Dane osobowe: umowa powierzenia, jeśli wykonawca ma dostęp do danych produkcyjnych.
• Własność kont: repozytorium, serwery i klucze na firmę, wykonawca z dostępem nadanym imiennie.

Wykonawcy zwykle ograniczają w umowie swoją odpowiedzialność, na przykład do wartości zlecenia. To normalne, ale warto negocjować wyjątki dla naruszenia poufności i rażącego niedbalstwa, a sam limit dopasować do skutków, jakie wyciek miałby dla firmy. Kara umowna nie przywróci zaufania klientów, więc ważniejsze od jej wysokości są wymagania, które zmniejszają ryzyko incydentu.

Następny krok: przed kolejnym zamówieniem dopisz do specyfikacji poziom ASVS i dziesięć wymagań z listy minimum, a obecnego wykonawcy zadaj sześć pytań z tego tekstu. Odpowiedzi szybko pokażą, jak wygląda bezpieczeństwo aplikacji, z których dziś korzysta firma. Jeśli chcesz przejrzeć je razem, napisz do mnie bezpośrednio.