security-mindset-master — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited security-mindset-master (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Security is a design constraint. Not a checklist. Not a phase. Not someone else's job.
Core principle: Think like an attacker during implementation. Reasoning about threats after the code is written is too late — you've already chosen the unsafe path.
Violating the letter of this rule is violating the spirit of this rule.
NO ENDPOINT, DATA ACCESS PATTERN, OR USER INPUT HANDLER SHIPS WITHOUT A SECURITY ANALYSIS FIRSTThe insecure path must never be the path of least resistance.
Always — before writing code that touches:
Not for:
Thinking "this is a small change, security analysis is overkill"? That's rationalization. Small changes to auth logic have caused the largest breaches.
Complete before writing any code.
Answer these questions explicitly — not in your head, in the response:
Minimum acceptable output: at least one named threat and its mitigation documented. "No threats identified" is not an acceptable output for any code path touching user data.
Read references/secure-defaults.md. Each gate must be verified present — not assumed.
These are non-negotiable. There are no exceptions, only tradeoffs that must be explicitly documented:
Read references/attacker-patterns.md. Before writing any code, reason through each attack class for this specific feature:
| Attack | Question to answer |
|---|---|
| IDOR | Can a user modify an ID parameter to access another user's object? Is there a per-object ownership check? |
| Privilege escalation | Can a lower-privilege user reach this through a different code path? Is the role check on the resource, not just the route? |
| Replay attack | Is a valid request replayable? Are tokens/nonces single-use? |
| Timing attack | Does a timing difference between success and failure leak information (e.g., valid vs invalid username)? |
| Mass assignment | Does this endpoint bind request parameters to a model? Are bindable fields explicitly allowlisted? |
| Insecure deserialization | Does this code deserialize user-supplied data? Is the deserialization format safe? |
| Error leakage | Do error responses reveal stack traces, internal paths, DB structure, or version strings? |
Not every attack applies to every feature. Document which you considered, which apply, and how each applicable one is mitigated.
After writing code, before marking done.
For every security control implemented, ask:
"If every future developer who touches this code ignores all comments, all docs, and all institutional memory — does this control still hold?"
Structural — the unsafe action is syntactically or architecturally impossible: parameterized queries, framework-level CSRF middleware, DB constraints, type system enforcement. Prefer these.
Behavioral — the control works only if developers remember to use it: a function that must be called manually, a comment saying "always check auth here." These accrue debt.
If a control is behavioral: either redesign it to be structural, or document the explicit risk acceptance with the reason redesign isn't feasible.
These patterns require an immediate stop. Do not work around them. Fix them or escalate.
| Pattern | Stop Reason |
|---|---|
| String concatenation in any query | SQL / LDAP / command injection. Parameterize it. |
password, secret, token, or key in a log statement | Credentials in logs. Remove unconditionally. |
| Endpoint handler with no visible auth/session check | Unauthenticated access. Add the check before continuing. |
CORS: * or equivalent wildcard on an authenticated endpoint | Cross-origin credential theft. Specify allowed origins explicitly. |
| User-supplied data in a file path or shell command | Path traversal or command injection. Restrict and sanitize. |
| Error response includes stack trace or internal state | Information leakage. Return generic errors; log detail server-side. |
| "I'll add auth after the feature works" | This is how auth never gets added. Add it now. |
| Rationalization | Reality |
|---|---|
| "It's an internal endpoint" | Internal endpoints get compromised. Supply chain attacks, SSRF, and misconfigured VPCs hit internal services routinely. Defense in depth means internal = untrusted. |
| "The client validates it" | Clients can be bypassed. Any attacker posts directly to the API. Server-side validation is non-negotiable regardless of frontend logic. |
| "We're behind a VPN / firewall" | Perimeter security fails. Assume breach. Zero-trust is the baseline, not the advanced model. |
| "It's just test data" | Test environments get used with real credentials. They share code paths with production. Treat them identically. |
| "I'll harden it before launch" | Security bolted on after is weaker, slower to ship, and requires revisiting every data access path. The debt compounds. |
| "Automated scanners would catch it" | IDOR, business logic flaws, and timing attacks are routinely missed by scanners. They find known patterns. You are writing the unknown pattern. |
| "UUIDs prevent IDOR" | Non-guessable IDs are defense-in-depth, not access control. If an ID leaks through any related endpoint, the vulnerability is exploitable. Per-object ownership checks are required regardless. |
Run after code is written, before marking the task complete. See also superpowers:verification-before-completion.
<!-- Built with Agent Engineer Master — get your own production-ready skill: www.agentengineermaster.com/skill-engineer -->
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.