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: formularzu, integracji, panelu z rolami.
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.
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 automatycznie w buildzie.
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, na przykład na formularzu przyjmującym plik, integracji pobierającej dane z cudzego API albo panelu 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.
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ę. Asercja przechodzi albo nie przechodzi.
Narzędzia i standardy
- OWASP Top 10
- OWASP ASVS
- STRIDE
- Content Security Policy
- RODO
- WCAG 2.2
- Google Consent Mode v2
- Cloudflare Workers
- GitHub Actions
- Dependabot
- TypeScript
- Node.js
Dowód: pakiet audytowy @silesiansolutions/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 @silesiansolutions/search-quality-kit audytuje techniczne fundamenty strony: crawlability, metadane, dane strukturalne i podstawową dostępność. Pracuje w CI tego serwisu, obok asercji opisanej niżej.
check-build-output.mjs
Wymóg zgody na osadzenia z art. 399 ust. 1 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ę realnie wykorzystać
- 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ę
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ę.
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.
Co to jest wasz własny pakiet audytowy?
To @silesiansolutions/search-quality-kit, pakiet publiczny na npm, napisany w TypeScript i pokryty testami. Audytuje techniczne fundamenty strony i pracuje w CI serwisów, które prowadzimy, razem z tym serwisem.