Kontrole bezpieczeństwa, które należą do CI

Ten wpis jest częścią serii Podstawy testowania bezpieczeństwa. Jeśli pominąłeś poprzedni, przeczytaj Część 4 — Sesje, ciasteczka i CSRF.

Wprowadzenie — checklista nie uruchomi się sama

Części 1 do 4 to przejścia, które może zrobić człowiek. W piątkowe wydanie zostaną pominięte, chyba że te mechaniczne mieszkają w pipeline. Błędem jest wrzucić je wszystkie do pipeline i blokować build każdą linijką, którą narzędzie wypisze.

Trzy kontrole, trzy joby

Sekrety. Klucz, token albo certyfikat prywatny w commicie powinien blokować pull request. To prawie nigdy nie jest fałszywy alarm, który chcecie wydać. Wystarczy gitleaks albo skaner sekretów samej platformy.

Zależności. Znana podatność w bibliotece, którą wysyłacie, to pozycja do przeglądu. Blokowanie każdego pull requestu niskim ostrzeżeniem w narzędziu deweloperskim uczy ludzi ignorować job. Blokuj progi, przy których naprawdę zatrzymalibyście wydanie. Resztę przeglądaj według harmonogramu.

Baseline ZAP na efemerycznym albo stagingowym URL. Część 2 była metodą triage. Pipeline jest uczciwy tylko wtedy, gdy tej metody używa. Blokuj alerty, których nie zapisaliście jako zaakceptowane. Nie blokuj całego domyślnego zestawu reguł.

- name: Secret scan
  run: gitleaks detect --source . --redact --exit-code 1

- name: ZAP baseline
  if: github.ref == 'refs/heads/main'
  run: docker run --rm -v "$PWD:/zap/wrk:rw" -t ghcr.io/zaproxy/zaproxy:stable
    zap-baseline.py -t ${{ vars.STAGING_URL }} -r zap.html -c zap-rules.conf

Plik reguł to triage wrzucony do repozytorium. Identyfikator alertu w tym pliku to zaakceptowane ryzyko z powodem w commicie. Nowy alert blokuje, dopóki ktoś nie doda go świadomie.

Co zostaje ręczne

Przejście kontroli dostępu z części 3 potrzebuje dwóch użytkowników i obiektu. Jedno żądanie z podmienionym identyfikatorem da się zautomatyzować jako test API i warto. Nie da się zastąpić przejścia wtyczką skanera i skasować testu.

Wrogi formularz CSRF z części 4 jest niewygodny w CI i łatwy ręcznie według harmonogramu. Nie blokuj merge niestabilnym odtworzeniem polityki przeglądarki.

Wylogowanie, które unieważnia sesję, jest zwykłym testem API. Ten należy do suite, którą już odpalacie.

Nie budź QA każdym CVE

Przegląd zależności to kolejka. Nazwij właściciela. Rola QA przy wydaniu, które rusza logowanie albo płatności, to zapytać, czy w kolejce jest otwarta pozycja progu, który umówiliście się blokować. QA nie jest osobą, która w sobotę łata framework, chyba że to naprawdę jego praca.

Podsumowanie

Automatyzuj kontrole z jasną porażką: sekret w diffie, podatność powyżej ustalonej linii, nowy alert ZAP, którego nie zaakceptowaliście. Przejścia na dwóch użytkownikach i z obcej strony zostaw jako testy i jako pracę w harmonogramie. Taka jest seria: sposób myślenia, skaner, który umiecie przesiać, przypadki, które skaner pomija, sesja i część, która mieści się w CI.

Zadanie na ten tydzień: Dodaj skan sekretów do workflow pull requestu. Potem weź jeden zaakceptowany alert ZAP z części 2 i wpisz jego identyfikator do pliku reguł, żeby baseline mógł paść na wszystkim innym.

To kończy serię Podstawy testowania bezpieczeństwa.