What the code analysis checks
Keys and passwords written in the code (Stripe, AWS, GitHub, GitLab, OpenAI, Anthropic, Hugging Face, SendGrid, Slack, Telegram, Google, npm and PyPI tokens, database addresses with a password, private keys, .env files), the application secret key hard-coded, secrets exposed to the browser (NEXT_PUBLIC_, VITE_…), the Supabase service_role key in the browser, Supabase tables without RLS or with open policies (across all the project's migrations), Firebase rules that are open or in “test mode”, Supabase views and functions that bypass RLS, SQL queries and system commands built from text, requests, files and redirects chosen by the user (also when the value goes through a variable a few lines earlier), data saved without choosing the fields, data loading that can run code, passwords hashed with MD5 or compared to a fixed value, weakened CSRF protection or session cookies, tokens in localStorage or drawn with Math.random, debug mode on, TLS or JWT verification turned off, CORS open with credentials and HTML inserted without sanitising. Example values (your-key, xxxx), default local passwords, comments, tests and test configurations are not reported, except for secrets.
In a project, the analysis also notes which packages are imported in the code: a vulnerability in a package that the code never imports, and that no other package needs according to the lockfile, goes down one level, with the reason. Dependency files found (package-lock.json, requirements.txt, composer.lock…) directly give a new version of the dependency analysis.
The code is read in memory and then forgotten: Tamiso keeps only the file name, the line and a short excerpt with secrets masked. Dependency and build folders (node_modules, dist…) are skipped. A rule-based analysis does not replace a security review.