Skaner sekretów Betterleaks: architektura i klucze
Wykrywanie sekretów w repozytoriach znacząco zmieniło się w ostatnich latach. Wcześniej wystarczyło szukać podejrzanych ciągów znaków lub kluczy o wysokiej entropii w kodzie. Dziś sytuacja jest inna: większe repozytoria, szybsze procesy CI/CD, a przede wszystkim coraz większa ilość kodu generowanego przez narzędzia automatyczne lub modele sztucznej inteligencji.
Ma to praktyczne konsekwencje: problem nie polega już tylko na znajdowaniu sekretów, ale na oddzielaniu tego, co rzeczywiście niebezpieczne, od tego, co tylko pozornie. Wiele zespołów odkrywa, że prawdziwy koszt tych skanerów nie leży w samej analizie, ale w analizie setek wyników fałszywie dodatnich.
Architektura wykrywania: co się zmienia wraz z Betterleaks
Betterleaks pojawia się właśnie w tym kontekście. Nie próbuje całkowicie zrewolucjonizować tajnego skanowania, ale podważa powszechne założenie, że wykrywanie wzorców wystarczy.
W wielu nowoczesnych repozytoriach tak nie jest.
Projekt, opracowany przez Zacha Rice'a i utrzymywany przy wsparciu Aikido, proponuje coś nieco innego. Zamiast skupiać się wyłącznie na wykrywaniu dopasowań, próbuje on zweryfikować, czy odkrycie ma sens, zanim eskaluje je jako alert.
Może się to wydawać drobiazgiem, ale znacząco zmienia dynamikę w dużych zespołach. Gdy system skanujący generuje zbyt wiele nieistotnych alertów, naturalną reakcją zespołu jest ich ignorowanie. A w dziedzinie bezpieczeństwa zignorowanie alertu może być gorsze niż brak alertu.
Aby rozwiązać ten problem, Betterleaks wprowadza dwa ciekawe rozwiązania techniczne: walidację z wykorzystaniem języka CEL (Common Expression Language) oraz metrykę zwaną „Efektywnością tokenów”, opartą na tokenizacji BPE.
Chodzi o to, że nie wszystko, co wydaje się być tajemnicą, faktycznie nią jest. Niektóre ciągi znaków o wysokiej entropii to po prostu hasze, identyfikatory lub automatycznie generowane fragmenty. Celem systemu jest redukcja tego szumu.
W dokumentacji projektu wspomniano o porównaniu, w którym tokenizacja BPE osiąga wskaźnik wykrycia na poziomie 98,6% w porównaniu z 70,4% uzyskanym przy użyciu entropii w zbiorze danych CredData. Jak w przypadku każdego benchmarku, liczby te mają charakter orientacyjny. Stanowią one dobry punkt odniesienia, ale nie zastępują testowania w rzeczywistych repozytoriach.
Źródło: GitHub
Komponenty, które robią różnicę
Analiza charakterystyki projektu ujawnia jasny kierunek: ułatwienie wdrażania w środowiskach rzeczywistych bez wprowadzania zbyt dużej złożoności technicznej.
Do najważniejszych elementów zaliczamy:
- Walidacja zdefiniowana regułą przy użyciu języka CEL (Common Expression Language)
- Skanowanie efektywności tokenów w oparciu o tokenizację BPE, a nie entropię, osiągając wskaźnik wykrycia 98,6% w porównaniu z 70,4% przy entropii w zestawie danych CredData
- Czysta implementacja Go (bez zależności od CGO lub Hyperscan)
- Automatyczne przetwarzanie podwójnie/potrójnie zakodowanych sekretów
- Rozszerzony zestaw reguł dla większej liczby dostawców
- Równoległe skanowanie Git w celu szybszej analizy repozytorium
Mimo że lista ta może wydawać się jedynie zbiorem usprawnień technicznych, ciekawe jest, jak wpływają one na codzienne użytkowanie.
Na przykład pełna implementacja Go bez natywnych zależności znacznie upraszcza integrację z procesami CI/CD. W wielu zespołach drobne szczegóły decydują o tym, czy narzędzie zostanie ostatecznie użyte, czy zapomniane w repozytorium.
Tokenizacja BPE wprowadza również inne podejście. Zamiast po prostu mierzyć losowość łańcucha, analizuje wzorce tokenów, które lepiej odzwierciedlają rzeczywistą strukturę współczesnych danych uwierzytelniających.
Co się dzieje, gdy skaner coś znajdzie?
Kiedy Betterleaks odkryje potencjalną tajemnicę, proces na tym się nie kończy.
Najpierw kontekst jest oceniany za pomocą reguł zdefiniowanych w CEL. Pozwala to na dodanie dalszych warunków: na przykład sprawdzenie, czy format jest zgodny z oczekiwanym dostawcą, lub odrzucenie wzorców często pojawiających się w przykładach lub fikcyjnych danych.
Ten krok może wydawać się błahy, ale ma istotny wpływ na praktykę. Fałszywe alarmy nie tylko marnują czas, ale także obniżają zaufanie zespołu do systemu alarmowego.
Kolejnym interesującym aspektem jest automatyczne przetwarzanie wielokrotnie zakodowanych sekretów. W niektórych repozytoriach dane uwierzytelniające są przekształcane za pomocą Base64 lub innych schematów kodowania, co utrudnia ich wykrycie.
Mimo to warto pamiętać o czymś, co czasami jest pomijane: żaden skaner nie jest w stanie całkowicie zastąpić kontroli dokonywanej przez człowieka. Wykrycie tajnego zabezpieczenia to dopiero początek; decyzja, co z nim zrobić (unieważnić, obrócić, zignorować lub zbadać), pozostaje decyzją kontekstową.
Zarządzanie i podejście skoncentrowane na człowieku/sztuczna inteligencja
Betterleaks jest publikowany na licencji MIT i zawiera wkład zewnętrznych organizacji, takich jak Royal Bank of Canada, Red Hat i Amazon.
Projekt jest także próbą dostosowania się do rzeczywistości coraz bardziej widocznej we współczesnych repozytoriach: mieszanki kodu tworzonego przez programistów i kodu generowanego przez narzędzia automatyczne.
W tym kontekście narzędzie ma dobrze funkcjonować zarówno w przepływach pracy obsługiwanych przez ludzi, jak i w zautomatyzowanych systemach, które przeglądają całe repozytoria. Jest to zgodne z rosnącym wykorzystaniem automatyzacja i narzędzia które analizują kod lub generują automatyczne recenzje.
W planie działania znalazły się również ciekawe pomysły: integracja z źródła danych poza GitemPomoc w zakresie modelu językowego do klasyfikowania ustaleń i automatycznych mechanizmów odwoływania za pośrednictwem interfejsów API dostawców.
To otwiera interesującą debatę. Automatyzacja unieważniania uprawnień może skrócić czas reakcji na incydent, ale oznacza to również konieczność polegania na dokładności systemu klasyfikacji.
Jeśli automatyczne odwołanie nie powiedzie się lub zostanie uruchomione przez pomyłkę, skutki operacyjne mogą być znaczne.
Praktyczne implikacje i ograniczenia
Z operacyjnego punktu widzenia Betterleaks jest atrakcyjnym rozwiązaniem dla zespołów, którym zależy na ograniczeniu liczby fałszywych alarmów i uproszczeniu wdrażania.
Ważne jest jednak, aby pamiętać o pewnych ograniczeniach:
- Wskaźniki wycofania zależą od użytego zestawu danych i mogą się znacznie różnić między repozytoriami.
- Automatyzacja działań, takich jak cofanie klucza, wymaga dodatkowych kontroli i rejestrów audytu.
- Tajne skanery pozostają tylko jedną warstwą obrony w ramach szerszej strategii.
W wielu przypadkach decyzja o wdrożeniu takiego narzędzia zależy nie tyle od jego dokładności teoretycznej, co od czegoś prostszego: czy dobrze integruje się z procesem pracy zespołu.
Zazwyczaj rezygnuje się z wysoce precyzyjnego skanera, który generuje zbyt duże tarcie. Zazwyczaj pozostawia się skaner o stosunkowo dużej dokładności i łatwości integracji.
W tym sensie Betterleaks stara się znaleźć równowagę. Nie obiecuje wyeliminowania wszystkich fałszywych alarmów ani zastąpienia istniejących procesów bezpieczeństwa, ale dąży do ograniczenia zakłóceń i ułatwienia integracji z nowoczesnymi systemami.
Projekt jest dostępny na GitHub i jest przedstawiane jako ewolucja podejścia stosowanego przez Gitleaks, mająca na celu dostosowanie go do repozytoriów, w których automatyzacja, agenci analizy i kod generowany przez modele językowe są regularną częścią procesu rozwoju.
