Oprogramowanie dedykowane · Security by design
Security by design oznacza, że bezpieczeństwo projektujemy razem z systemem, a nie dokładamy po audycie. W naszym cyklu wytwórczym każda faza ma kontrole bezpieczeństwa - od modelu zagrożeń i wymagań OWASP ASVS, przez przegląd kodu i testy w potoku CI/CD, po test penetracyjny naszego zespołu przed każdym większym wydaniem i zarządzanie podatnościami w utrzymaniu.
git push origin main[ci] build · test · security · deployOKunit + integration tests: passedOKSAST: 0 high, 0 criticalOKdependency audit: 0 known CVE!!DAST (staging): 1 medium - CSP report-onlyOKcontainer scan: base image up to datedeploy: staging (UE) · retest przed produkcją01Definicja
Security by design (bezpieczeństwo w fazie projektowania) to podejście, w którym wymagania i kontrole bezpieczeństwa są częścią każdego etapu wytwarzania oprogramowania - analizy, architektury, programowania, testów, wdrożenia i utrzymania - zamiast jednorazowego audytu przed startem. W praktyce nazywa się je też secure SDLC, a jego zautomatyzowaną część w potoku CI/CD - DevSecOps.
Różnica jest przede wszystkim ekonomiczna. Błąd w wymaganiach, poprawiony na etapie analizy, kosztuje zmianę w dokumencie. Ten sam błąd odkryty w teście penetracyjnym przed startem może wymagać zmiany architektury, a odkryty po incydencie - kosztuje dane klientów i zaufanie.
Dla nas to naturalne, bo mamy w zespole pentesterów, którzy na co dzień atakują systemy innych firm. Wiedzą, które błędy powtarzają się najczęściej - i to ta wiedza trafia do wymagań, przeglądów kodu i reguł w potoku CI/CD.
To samo podejście stosujemy we wszystkich projektach: aplikacjach webowych, mobilnych i integracjach systemów. Nie jest płatnym dodatkiem, tylko standardem pracy.
02Cykl wytwórczy
Wymagania bezpieczeństwa i regulacyjne (RODO, NIS2/KSC, DORA) zapisujemy razem z funkcjonalnymi - jako mierzalne kryteria akceptacji.
Zanim powstanie kod, modelujemy zagrożenia dla przepływów danych i granic zaufania oraz decydujemy, gdzie dane będą przechowywane.
Każda zmiana przechodzi przegląd kodu, a potok CI/CD uruchamia testy, analizę statyczną (SAST) i analizę zależności (SCA).
Nasi pentesterzy testują system przed wydaniem na produkcję, a poprawki sprawdzają w reteście.
Wdrażamy w centrach danych w UE - w chmurze prywatnej, w chmurze klienta albo w jego infrastrukturze (on-premise).
Monitorujemy zależności i podatności, a poprawki bezpieczeństwa wydajemy w ramach umowy SLA.
| Faza | Praktyka | Co powstaje |
|---|---|---|
| Analiza | Wymagania bezpieczeństwa według OWASP ASVS 5.0 (poziom L1, L2 lub L3 dobrany do ryzyka) i wymagania regulacyjne | Wymagania z kryteriami akceptacji |
| Architektura | Model zagrożeń: przepływy danych, granice zaufania, scenariusze nadużyć i decyzje o zabezpieczeniach | Model zagrożeń i dokument architektury |
| Implementacja | Przegląd każdej zmiany przez drugą osobę, analiza statyczna (SAST) i analiza zależności (SCA) w potoku CI/CD | Historia przeglądów, wyniki skanów |
| Testy | Testy automatyczne uprawnień, skan aplikacji na środowisku testowym, test penetracyjny przed wydaniem i retest | Raport z testu penetracyjnego |
| Wdrożenie | Konfiguracja środowiska w UE, sekrety w sejfie, minimalne uprawnienia, logowanie zdarzeń bezpieczeństwa | Opis środowiska i konfiguracji |
| Utrzymanie | Monitoring zależności i nowych podatności, poprawki według ryzyka w ramach SLA | Rejestr podatności i poprawek |
Praktyki układamy według sprawdzonych ram: wymagania według OWASP ASVS 5.0, a cały proces odpowiada obszarom NIST SSDF (SP 800-218, wersja 1.1) - przygotowaniu organizacji, ochronie oprogramowania, wytwarzaniu dobrze zabezpieczonego kodu i reagowaniu na podatności. Ramy wymieniamy tekstem - to opis naszego procesu, a nie certyfikat.
03DevSecOps
Narzędzia w potoku sprawdzają każdą zmianę, ale nie zastępują ludzi. Skaner nie wie, kto powinien mieć dostęp do jakich danych - dlatego testy uprawnień piszemy razem z funkcjami, a przegląd kodu robi zawsze druga osoba.
Progi blokujące ustalamy z zespołem: podatność krytyczna w zależności albo w kodzie zatrzymuje wydanie, a ustalenia niższego ryzyka trafiają do rejestru z terminem naprawy.
Przed wydaniem na produkcję system testują nasi pentesterzy - tak samo jak w usłudze testów penetracyjnych aplikacji webowych, z kontami każdej roli. Najważniejsze moduły mogą przejść dodatkowo ręczny przegląd bezpieczeństwa kodu, jak w audycie kodu źródłowego.
Przykładowy przebieg takiego potoku pokazuje terminal na górze strony - to ilustracja z danymi demonstracyjnymi.
04Utrzymanie
Nowe podatności w bibliotekach i komponentach są publikowane codziennie - system bezpieczny w dniu wdrożenia nie jest bezpieczny na zawsze. W utrzymaniu:
Terminy naprawy według poziomu ryzyka ustalamy w umowie SLA. Punktem wyjścia są terminy, które rekomendujemy klientom w raportach z testów penetracyjnych:
Dla systemów krytycznych i podatności aktywnie wykorzystywanych w atakach terminy bywają krótsze - ustalamy je z Twoim zespołem bezpieczeństwa.
05Zgodność
Regulacje coraz częściej wymagają nie tylko bezpiecznych systemów, ale też dowodów, że dostawca oprogramowania pracuje bezpiecznie.
NIS2 / KSC
Podmioty kluczowe i ważne muszą zapewnić m.in.: bezpieczeństwo i ciągłość dostaw produktów, usług i procesów ICT, z oceną podatności i jakości dostawców (art. 8 ust. 1 pkt 2 lit. e, ust. 2) oraz bezpieczeństwo przy nabywaniu, rozwoju, utrzymaniu i eksploatacji systemu, w tym testowanie systemu informacyjnego (art. 8 ust. 1 pkt 2 lit. b).
DORA
Procedura rozwoju systemów obejmuje przeglądy kodu źródłowego z testami statycznymi i dynamicznymi, w tym testy bezpieczeństwa aplikacji internetowych (art. 16 ust. 3 rozporządzenia delegowanego (UE) 2024/1774).
RODO
Administrator wdraża odpowiednie środki techniczne i organizacyjne, np. pseudonimizację i minimalizację danych, zarówno przy określaniu sposobów przetwarzania, jak i w czasie samego przetwarzania (art. 25 ust. 1 RODO). Wśród środków bezpieczeństwa rozporządzenie wymienia regularne testowanie, mierzenie i ocenianie skuteczności środków technicznych i organizacyjnych (art. 32 ust. 1 lit. d RODO).
CRA
Obowiązek zgłaszania aktywnie wykorzystywanych podatności i poważnych incydentów stosuje się od 11 września 2026 r., także do produktów wprowadzonych do obrotu wcześniej (art. 71 ust. 2 i art. 69 ust. 3 CRA). Producent przeprowadza skuteczne i regularne testy i przeglądy bezpieczeństwa produktu (załącznik I część II pkt 3 CRA).
Akt o cyberodporności (CRA) dotyczy oprogramowania i urządzeń wprowadzanych na rynek - na przykład aplikacji instalowanych u klientów. Oprogramowanie na zamówienie nie jest wyłączone z CRA; przy produkcie dostosowanym do potrzeb użytkownika biznesowego strony mogą umownie odstąpić tylko od bezpiecznej konfiguracji domyślnej i bezpłatności aktualizacji zabezpieczeń (motyw 64 i załącznik I CRA). Z kolei samodzielne usługi SaaS i aplikacje dostępne wyłącznie przez przeglądarkę co do zasady nie są produktami z elementami cyfrowymi; CRA obejmuje je tylko jako zdalne przetwarzanie danych produktu (motywy 11 i 12 CRA, wytyczne Komisji C(2026) 5252). To, czy i kto jest producentem w rozumieniu CRA, oceniamy razem z Twoim działem prawnym na etapie analizy - a praktyki z tej strony (testy i przeglądy bezpieczeństwa, zarządzanie podatnościami, lista komponentów) są fundamentem wymagań CRA.
Test na końcu znajduje błędy, gdy ich naprawa jest najdroższa - czasem wymaga zmiany architektury tuż przed startem. W podejściu security by design większość problemów nie powstaje, bo wymagania i model zagrożeń są znane od początku, a przegląd kodu i narzędzia w potoku CI/CD wyłapują błędy w dniu, w którym powstały. Test penetracyjny przed wydaniem nadal robimy, ale staje się potwierdzeniem, a nie pierwszym badaniem bezpieczeństwa.
Na początku projektu dodaje trochę pracy, ale w praktyce przyspiesza wydania - automatyczne kontrole w potoku zastępują ręczne sprawdzanie, a błędy bezpieczeństwa nie wracają tuż przed terminem. Najbardziej spowalnia odkrycie poważnej podatności tydzień przed startem, a temu właśnie zapobiegamy.
Wymagania bezpieczeństwa z kryteriami akceptacji, model zagrożeń, raport z testu penetracyjnego z retestem, wyniki analizy zależności oraz opis procesu zarządzania podatnościami. To materiały, które przydają się przy ocenie dostawcy w ramach NIS2/KSC i DORA - zobacz audyt NIS2 / KSC.
Biblioteki dobieramy świadomie - sprawdzamy, czy są utrzymywane, jaką mają licencję i historię podatności. W potoku CI/CD analiza zależności (SCA) porównuje je z bazami znanych podatności przy każdej zmianie, a w utrzymaniu monitorujemy nowe zgłoszenia i aktualizujemy zależności według ryzyka.
Tak. Wykonujemy audyty kodu źródłowego i testy penetracyjne systemów, których nie budowaliśmy - ten sam zespół, te same standardy. Zobacz audyt kodu źródłowego (white box) i testy penetracyjne aplikacji webowych.
Testy penetracyjne · White box
Audyt kodu źródłowego i testy white box - logika autoryzacji, sekrety, kryptografia i zależności z CVE. Ręczny przegląd, SAST i SCA, gotowe poprawki w raporcie.
Testy penetracyjne · Aplikacje webowe
Testy penetracyjne aplikacji webowych według OWASP WSTG v4.2 - uwierzytelnianie, uprawnienia, logika biznesowa i API. Raport z dowodami, CVSS i retest.
Zgodność · NIS2 / KSC
Audyt NIS2 i KSC: kogo obejmuje nowelizacja, terminy 3.04.2027 i 3.04.2028, obowiązki, audyt z art. 15 i kary. Audyt zerowy, wdrożenie, pentesty.
Opisz krótko, czego potrzebujesz - wrócimy z propozycją kolejnych kroków.
lub zadzwoń pod numer +48 575 621 877