Security findings

​

Behavior to build around

• Third-party scanners: A finding from a scanner that isn’t Base44’s carries the category third_party, with source naming which one. A dependency vulnerability found by Wiz is therefore third_party rather than dependencies, because category reflects the scanner family. One package upgrade can resolve a row of each together.
• Snapshots: Findings are a latest-scan snapshot. There’s no per-finding first-seen time, and scanned_at is when the reporting scan ran. A scan section that failed or didn’t run contributes no rows, rather than an empty list that would read as clean.
• Stable IDs: An id is stable for as long as the finding’s location is. For secrets, backend_functions, and code it also covers the file’s contents, so editing an unrelated line of the same file re-keys a finding that hasn’t otherwise changed. A diff on id reads that as one finding closing and another opening. The rls and dependencies categories use natural keys and don’t move.
• Security headers: The security_headers category is sparse rather than absent. These are recommendations derived from an app’s own configuration at scan time rather than a scan section, so they carry no location and appear only for apps scanned since the platform began recording them. Don’t read absence as a clean result.
• Apps without login: On an app that doesn’t require login, every backend function is callable by anyone by design, so backend_functions lists each function once. One the scanner flags as abusable keeps high severity and the scanner’s description, as does flagged code that isn’t a function, such as a server route. The rest are low. Switching an app in or out of that mode replaces one set of rows with the other on the next scan, under new id values.