Co sprawdza analiza kodu
Klucze i hasła wpisane w kod (Stripe, AWS, GitHub, GitLab, OpenAI, Anthropic, Hugging Face, SendGrid, Slack, Telegram, Google, tokeny npm i PyPI, adresy baz danych z hasłem, klucze prywatne, pliki .env), tajny klucz aplikacji wpisany na sztywno, sekrety wystawione przeglądarce (NEXT_PUBLIC_, VITE_…), klucz service_role Supabase po stronie przeglądarki, tabele Supabase bez RLS albo z otwartymi regułami (we wszystkich migracjach projektu), reguły Firebase otwarte albo w „trybie testowym”, widoki i funkcje Supabase omijające RLS, zapytania SQL i polecenia systemowe sklejane z tekstu, zapytania, pliki i przekierowania wybierane przez użytkownika (także gdy wartość przechodzi przez zmienną kilka linii wyżej), dane zapisywane bez wyboru pól, wczytywanie danych, które może wykonać kod, hasła haszowane MD5 albo porównywane ze stałą wartością, osłabiona ochrona CSRF albo ciasteczka sesji, tokeny w localStorage albo losowane przez Math.random, włączony tryb debug, wyłączona weryfikacja TLS albo JWT, CORS otwarty z danymi logowania i HTML wstawiany bez oczyszczenia. Przykładowe wartości (your-key, xxxx), domyślne hasła lokalne, komentarze, testy i konfiguracje testowe nie są zgłaszane, z wyjątkiem sekretów.
W projekcie analiza zapisuje też, które paczki są importowane w kodzie: podatność w paczce, której kod nigdy nie importuje i której według pliku blokady nie potrzebuje żadna inna paczka, spada o jeden poziom, z powodem. Znalezione pliki zależności (package-lock.json, requirements.txt, composer.lock…) od razu dają nową wersję analizy zależności.
Kod jest czytany w pamięci i zapominany: Tamiso zatrzymuje tylko nazwę pliku, linię i krótki fragment z zamaskowanymi sekretami. Katalogi zależności i budowania (node_modules, dist…) są pomijane. Analiza regułami nie zastępuje przeglądu bezpieczeństwa.