security-sweep

Topics in the source

• Security sweep
• 1. Map before judging
• 2. Control sweep (absence and bypass)
• 3. Sink trace
• 4. Join the dots
• 5. Confirm each candidate
• 6. Report

Most review methods walk from input to dangerous call. That finds injection and misses the bugs where nothing dangerous is called, because a check is absent, skippable or weaker on one route than another. This sweep walks the controls too. Read code, don't run it. A finding needs an actor, what they do, and what they gain that the system meant to deny. If you can't name all three, it's a note, not a finding. Report what you can show. Don't drop a finding because it's unlikely, inconvenient or merely a likely mistake in a config you can't see: mark it needsvalidation and say what fact would settle it. Read the README and any stated security model, then every entry point. Write this table for yourself before hunting, one row per route, handler, job, consumer or CLI command that takes outside input: entry | who can reach it | identity check | ownership or tenant check | input it trusts | state it changes An empty cell is a lead. Note what the system promises (tenants isolated, only admins can X, payments are final). Each promise is a thing to break. Compare peers. Line up routes that do similar work: read vs list vs export vs search vs update vs delete, v1 vs v2, UI vs API vs batch vs

This is an excerpt. Refer to the complete source and its current requirements.