Bezpieczeństwo
Sprawdzamy bezpieczeństwo aplikacji webowych i mobilnych, API oraz kodu źródłowego. Łączymy testy penetracyjne z przeglądem kodu i konfiguracji, opierając zakres m.in. na OWASP Top 10, ASVS i WSTG. Otrzymujesz raport z podatnościami uporządkowanymi według realnego ryzyka i priorytetu naprawy. Jeśli chcesz, możemy również wdrożyć poprawki i wykonać retest.
Firmy które nam zaufały
Podstawy
Co daje audyt bezpieczeństwa i czym różni się od testu penetracyjnego
Audyt bezpieczeństwa aplikacji webowej to sprawdzenie, czy aplikację da się wykorzystać niezgodnie z przeznaczeniem: obejść logowanie, zobaczyć cudze dane, wykonać operację bez uprawnień, wyciągnąć dane z bazy. Punktem odniesienia jest OWASP — powszechnie przyjęta lista najczęstszych klas podatności. Test penetracyjny i audyt bywają mylone. Pentest to próba włamania w ograniczonym czasie: pokazuje, co da się wykorzystać teraz. Audyt jest szerszy — obejmuje także konfigurację, uprawnienia i zależności, i odpowiada na pytanie, gdzie w tym systemie tkwi ryzyko. W praktyce dobrze zrobiony audyt zawiera elementy jednego i drugiego.
Audyt jest potrzebny, gdy aplikacja przetwarza dane osobowe lub płatności, gdy wymaga tego klient albo regulacja, gdy zmieniał się wykonawca i nikt nie wie, co jest w środku, albo po prostu przed wypuszczeniem produktu do szerszego grona. Nie zastępuje stałej higieny: aktualizacji zależności, przeglądów kodu i kopii zapasowych, które są tańsze niż jakikolwiek audyt.
Zobacz wybrane projekty dla naszych klientów
„Zespół Boring Owl był bardzo pomocny, chętny do współpracy i błyskawicznie odpowiadał na nasze pytania. Cały projekt został zrealizowany w wyznaczonym terminie.”
Michał Rugiełło — E-Commerce Director, Kwant Hurtowanie Elektryczne sp. z o. o.
Opinia z Clutch (tłum. z angielskiego)
Przebieg
Jak przebiega audyt bezpieczeństwa aplikacji?
Zaczynamy od ustalenia zakresu: które elementy aplikacji testujemy, jakie role użytkowników obejmujemy, z jakiego środowiska korzystamy i które obszary są poza testem. Testy zwykle prowadzimy na środowisku testowym. Jeśli konieczne jest sprawdzenie produkcji, wcześniej ustalamy zasady działania, okno testowe i osobę kontaktową. Wynikiem jest raport z listą znalezisk uszeregowaną według realnego ryzyka, z opisem, jak każde odtworzyć, i z rekomendacją naprawy. Możemy również wdrożyć poprawki i sprawdzić je podczas retestu.
Po Twojej stronie potrzebujemy dostępów, zgody właściciela systemu na testy oraz osoby, która w razie czego szybko odpowie. Formalności — umowa i NDA — załatwiamy przed rekonesansem, nie w trakcie.
Na czas wpływa wielkość aplikacji, liczba ról użytkowników i to, czy mamy dostęp do kodu, czy testujemy wyłącznie od zewnątrz. Audyt z dostępem do kodu jest dokładniejszy i zwykle szybszy niż testowanie na ślepo.
Decyzje
Decyzje, które trzeba podjąć przed audytem i po nim
Z dostępem do kodu czy bez. Testowanie bez wiedzy o systemie odwzorowuje sytuację napastnika z zewnątrz. Testowanie z dostępem do kodu znajduje więcej i szybciej. Jeśli celem jest bezpieczeństwo, a nie odtworzenie realnego ataku, drugie podejście daje więcej za te same pieniądze.
Co zrobić z listą znalezisk. Raport bez wdrożonych poprawek nie zmienia poziomu ryzyka — zmienia tylko stan wiedzy. Zaplanuj budżet na naprawy razem z audytem, a nie w następnym kwartale.
Jak często. Jednorazowy audyt opisuje stan na dany dzień. Aplikacja rozwijana co tydzień odchodzi od tego stanu natychmiast. Taniej jest wpleść przeglądy w proces wytwarzania niż powtarzać pełny audyt.
Czego nie robić. Nie testuj na produkcji bez ustalonego okna i planu wycofania. Nie publikuj szczegółów znalezisk przed naprawą. I nie traktuj zgodności z listą wymagań jako dowodu bezpieczeństwa — to dwie różne rzeczy.
Zakres
Audyty według OWASP, poprawki własnymi rękami
Większość firm audytorskich kończy pracę na dokumencie. My możemy pójść dalej: poprawki wdrażamy sami, bo na co dzień programujemy w tych samych stackach, które audytujemy - od Next.js i Node.js po headless CMS-y i aplikacje w Dockerze. Nie trzeba tłumaczyć raportu kolejnemu zespołowi ani czekać, aż znajdzie na niego miejsce w swoim backlogu.
Audytujemy również systemy, których nie budowaliśmy. To zresztą najczęstszy przypadek: kod pisał ktoś inny, dokumentacji nie ma. Zaczynamy wtedy od inwentaryzacji, nie od testów.
Metodyka
Jak wygląda audyt: od rekonesansu po retest
1. Ustalenie zakresu — określamy najważniejsze elementy aplikacji, role użytkowników, środowisko i obszary wyłączone z testów.
2. Rekonesans — poznajemy strukturę aplikacji, API, integracje, uprawnienia i miejsca przetwarzania danych.
3. Testy bezpieczeństwa — prowadzimy testy manualne wspierane odpowiednimi narzędziami, wykorzystując m.in. OWASP Top 10, OWASP ASVS i WSTG. Krytyczne podatności zgłaszamy na bieżąco.
4. Raport — opisujemy każdą podatność, jej ryzyko, sposób odtworzenia i rekomendowaną poprawkę.
5. Poprawki — może wdrożyć je Twój zespół albo możemy zrobić to sami.
6. Retest — ponownie sprawdzamy znalezione podatności i potwierdzamy, czy zostały skutecznie usunięte.
Zasady współpracy
NDA, dostępy i bezpieczeństwo testów
NDA możemy podpisać jeszcze przed przekazaniem szczegółów technicznych. Dostępy otrzymujemy wyłącznie na czas audytu, a informacje o znalezionych podatnościach trafiają tylko do wskazanych przez Ciebie osób. Testy prowadzimy przede wszystkim na środowisku testowym. Jeśli zakres obejmuje produkcję, wcześniej ustalamy sposób działania i wyłączamy testy, które mogłyby wpłynąć na dostępność lub dane.
Przez cały audyt masz kontakt z osobą prowadzącą testy. W razie potrzeby możemy je natychmiast przerwać.
Rezultat
Co dostajesz po audycie
- Raport techniczny. Każda potwierdzona podatność zawiera opis problemu, ocenę ryzyka, sposób odtworzenia oraz rekomendację naprawy. Raport przygotowujemy tak, aby zespół developerski mógł od razu zacząć pracę.
- Priorytety napraw. Nie wszystkie problemy wymagają natychmiastowego działania. Pomagamy określić, które podatności należy usunąć w pierwszej kolejności, a które można zaplanować później.
- Podsumowanie biznesowe. Najważniejsze wnioski przedstawiamy również w formie zrozumiałej dla osób nietechnicznych.
- Retest. Po wdrożeniu zmian sprawdzamy ponownie znalezione podatności. Jeśli chcesz, możemy wcześniej zająć się również samymi poprawkami.
FAQ
Pytania, które słyszymy przed audytem
- Pentest koncentruje się na praktycznym wykorzystaniu podatności i symuluje działania atakującego. Audyt może mieć szerszy zakres i obejmować również kod, konfigurację, zależności czy architekturę. W praktyce często łączymy oba podejścia.
- Zależy to od wielkości aplikacji, liczby funkcji i ról użytkowników, zakresu API oraz dostępu do kodu. Po krótkim poznaniu systemu jesteśmy w stanie określić zakres i harmonogram testów.
- Cena zależy przede wszystkim od zakresu aplikacji, liczby testowanych obszarów i wybranego modelu testów. Przed rozpoczęciem ustalamy zakres, dzięki czemu wiadomo, co dokładnie obejmuje wycena.
- Nie zawsze. Możemy przeprowadzić testy bez dostępu do kodu, ale jego udostępnienie pozwala dokładniej przeanalizować aplikację i zwykle szybciej znaleźć źródło problemu.
- Standardowo pracujemy na środowisku testowym. Jeśli testujemy produkcję, wcześniej ustalamy zakres, okno testowe oraz zasady bezpieczeństwa, aby ograniczyć ryzyko wpływu na użytkowników i dane.
- Tak. Jesteśmy zespołem developerskim, dlatego możemy nie tylko wskazać problem, ale również poprawić kod i następnie zweryfikować rozwiązanie podczas retestu.
- Pełny audyt warto powtarzać po większych zmianach w aplikacji, zmianach architektury lub przed istotnym wdrożeniem. Przy intensywnie rozwijanych systemach lepiej dodatkowo włączyć regularne przeglądy bezpieczeństwa do procesu developmentu.
Zbudujmy wspólnie produkty cyfrowe dla Twojej firmy
Powiązane artykuły
Interesuje cię audyt bezpieczeństwa aplikacji?
Pentesty według OWASP Top 10, przegląd kodu i audyt RODO — raport z podatnościami uszeregowanymi według realnego ryzyka, nie lista strachów.
Napisz do nasPozostałe usługi
Web development
Projektujemy i tworzymy dedykowane aplikacje webowe - od MVP, które pozwala szybko zweryfikować pomysł, po rozbudowane platformy i systemy rozwijane przez lata. Budujemy zarówno warstwę frontendową, jak i backend, API, bazy danych, panele administracyjne oraz integracje z zewnętrznymi systemami. Pracujemy m.in. z Next.js, React, Node.js, NestJS, Pythonem, PostgreSQL i MongoDB. Tworzymy rozwiązania dopasowane do konkretnego procesu biznesowego: aplikacje SaaS, systemy wewnętrzne, platformy sprzedażowe, serwisy internetowe, marketplace’y i systemy CMS.
Dowiedz się więcejUX/UI Design
Projektujemy UX/UI aplikacji webowych, mobilnych i systemów B2B - od analizy potrzeb użytkowników i pierwszych makiet po gotowy interfejs oraz design system w Figmie. Nie projektujemy ekranów w oderwaniu od produktu. Sprawdzamy ścieżki użytkowników, dane z analityki i ograniczenia technologiczne, żeby stworzyć rozwiązanie, które jest wygodne w użyciu i możliwe do sprawnego wdrożenia. Po uruchomieniu produktu możemy wrócić do heatmap, nagrań sesji, analityki i rozmów z użytkownikami. Dzięki temu kolejne zmiany wynikają z danych, a nie z przypuszczeń.
Dowiedz się więcejE-commerce
Projektujemy i wdrażamy sklepy internetowe oraz platformy e-commerce dopasowane do modelu sprzedaży i procesów firmy. Pracujemy zarówno z gotowymi rozwiązaniami, jak i z architekturą headless oraz dedykowanymi systemami sprzedażowymi. Budujemy e-commerce dla sprzedaży B2C i B2B, rozbudowanych katalogów produktów, wielu rynków oraz marketplace’ów. Integrujemy sklepy z ERP, WMS, CRM, PIM, płatnościami i logistyką, projektujemy konfiguratory produktów i niestandardowe procesy zakupowe. Dbamy również o wydajność, SEO techniczne i przygotowanie platformy na sezonowe wzrosty ruchu.
Dowiedz się więcej