Oferta
Cyberbezpieczeństwo i zgodność
Bezpieczeństwo aplikacji i zgodność: przegląd kodu i architektury, modelowanie zagrożeń, higiena zależności, nagłówki ochronne, RODO i WCAG jako automatyczne bramki w CI/CD.
- Dla kogo
- Zespoły wydające oprogramowanie
- Zakres
- Kod, architektura i CI/CD
- Efekt
- Wymóg jako bramka w CI
- Standardy
- OWASP Top 10, WCAG, RODO itp.
Co wchodzi w zakres
Przegląd bezpieczeństwa kodu i architektury
OWASP Top 10 i ASVS jako lista kontrolna, nie jako raport ze skanera.
Modelowanie zagrożeń
Na konkretnym przepływie danych, nie na diagramie ogólnym.
Higiena zależności
Automatyczne aktualizacje z okresem karencji, alerty o podatnościach w CI.
Nagłówki ochronne i polityka treści
CSP sprawdzana asercją na zbudowanej stronie, nie w konfiguracji.
Obsługa sekretów
Część warstwy widocznej z zewnątrz, sprawdzanej asercją na zbudowanej stronie.
Bramki w CI/CD
Wymagania prawne, dostępnościowe i SEO jako asercje na wygenerowanej stronie.
Zgody i retencja danych
Zgodnie z RODO oraz Prawem komunikacji elektronicznej.
Dostępność według WCAG
Sprawdzana w buildzie, nie w arkuszu.
Od czego zaczyna się przegląd
Bezpieczeństwo aplikacji sprawdza się tam, gdzie powstaje: w kodzie, w architekturze i w CI/CD. Zaczynamy od granic systemu: kto się uwierzytelnia, kto co może zobaczyć, którędy wchodzą dane z zewnątrz. Wynikiem jest lista znalezisk uszeregowana według tego, co da się z niej realnie wykorzystać.
Modelowanie zagrożeń robimy na konkretnym przepływie, nie na diagramie ogólnym. Formularz przyjmujący plik, integracja pobierająca dane z cudzego API, panel z rolami użytkowników. Każde z tych miejsc ma własny zestaw pytań o to, co się stanie, gdy dane przyjdą w postaci, której nikt nie przewidział.
Zależności i to, co widać z zewnątrz
Zależności to dziś najczęstsza droga wejścia. Aktualizacje idą automatycznie, z okresem karencji, żeby świeżo opublikowana i przejęta wersja pakietu nie weszła do builda tego samego dnia. Alerty o podatnościach trafiają do tego samego miejsca co reszta pracy, zamiast czekać w osobnym panelu.
Nagłówki ochronne, polityka treści, obsługa sekretów i konfiguracja zgód to warstwa, którą widać z zewnątrz i którą najłatwiej zepsuć przy okazji innej zmiany. Dlatego jej stan sprawdza asercja na zbudowanej stronie, a nie pamięć osoby, która ją kiedyś ustawiała.
Dlaczego zgodność zapisujemy w CI/CD, a nie w dokumencie
Wymóg zapisany w dokumencie ktoś przeczyta raz, zapamięta na tydzień i zapomni. Wymóg zapisany w pipeline przerywa build za każdym razem, gdy przestaje być spełniony. Wymagania prawne, dostępnościowe i SEO zamieniamy w asercje sprawdzające wygenerowaną stronę, a nie intencję zapisaną w polityce. Asercja przechodzi albo nie przechodzi.
Przykładowe technologie
- TypeScript
- Node.js
- GitHub Actions
- OWASP Top 10
- WCAG
- Content Security Policy
- Dependabot
- OWASP ASVS
- search-quality-kit
Dowód: search-quality-kit
Tę metodę stosujemy najpierw na sobie. Pakiet jest publiczny na npm.
- Dystrybucja
- Publiczny pakiet npm
- Język
- TypeScript
- Gdzie pracuje
- CI każdego serwisu, który prowadzimy
Pakiet audytuje techniczne fundamenty strony: crawlability, metadane, dane strukturalne i podstawową dostępność. Jednym z serwisów, które go używają, jest CyberKatalog.pl.
check-build-output.mjs
Wymóg zgody na osadzenia z art. 399 Prawa komunikacji elektronicznej to jedna asercja: sprawdza, że strona kontaktu nie zawiera adresu osadzenia Google Maps, zanim odwiedzający wyrazi zgodę. Jeśli ktoś kiedyś przywróci mapę bez zgody, ten sam build, który dziś przechodzi, przestanie przechodzić.
Co się zmienia po wdrożeniu
- Znaleziska uszeregowane według tego, co da się wykorzystać, nie według wyniku skanera
- Wymóg raz zapisany w kodzie obowiązuje przy każdym wdrożeniu, nie tylko w dniu audytu
- Przejęty pakiet nie wchodzi do builda tego samego dnia, bo aktualizacje mają okres karencji
- Regresja zatrzymuje build, zanim trafi na produkcję, zamiast czekać, aż ktoś ją zauważy
Typowe zastosowania
- Przegląd bezpieczeństwa aplikacji webowej przed wdrożeniem u klienta końcowego
- Modelowanie zagrożeń dla panelu z rolami i integracją pobierającą dane z zewnętrznego API
- Bramka pilnująca zgody na osadzenia (mapy, wideo, piksele reklamowe), zanim odwiedzający ją wyrazi
- Bramka sprawdzająca podstawowe progi dostępności w zbudowanej wersji strony
Pytania, które padają najczęściej
Czym bramka w CI różni się od jednorazowego audytu?
Wymóg zapisany w dokumencie ktoś przeczyta raz, zapamięta na tydzień i zapomni. Bramka przerywa build za każdym razem, gdy wymóg przestaje być spełniony. Wymagania prawne, dostępnościowe i SEO zamieniamy w asercje sprawdzające wygenerowaną stronę, a nie intencję zapisaną w polityce.
Na czym opieracie przegląd bezpieczeństwa?
Na granicach systemu: kto się uwierzytelnia, kto co może zobaczyć, którędy wchodzą dane z zewnątrz. OWASP Top 10 i ASVS służą jako lista kontrolna. Wynikiem jest lista znalezisk uszeregowana według tego, co da się realnie wykorzystać.
Jak wygląda pilnowanie zależności?
Aktualizacje idą automatycznie, z okresem karencji, żeby świeżo opublikowana i przejęta wersja pakietu nie weszła do builda tego samego dnia. Alerty o podatnościach trafiają do tego samego miejsca co reszta pracy, zamiast czekać w osobnym panelu.
Co sprawdzacie w warstwie widocznej z zewnątrz?
Nagłówki ochronne, politykę treści, obsługę sekretów i konfigurację zgód. Tę warstwę najłatwiej zepsuć przy okazji innej zmiany, dlatego jej stan sprawdza asercja na zbudowanej stronie, a nie pamięć osoby, która ją kiedyś ustawiała.
Czym jest search-quality-kit?
To nasz własny pakiet, publiczny na npm, napisany w TypeScript i pokryty testami. Audytuje techniczne fundamenty strony i pracuje w CI każdego serwisu, który prowadzimy.