Nobrainer Security

NoBrainer Security

Find exploitable security defects and missing controls in one frozen scope, then separate proven risk from checklist noise. Default to READ_ONLY. This skill does not authorize attacking a live target, retrieving secrets, weakening a control, changing credentials or implementing a fix.

Choose one mode

• THREAT_MODEL: map assets, actors, entry points, trust boundaries, abuse paths and required controls before a consequential design is frozen.
• SECURITY_REVIEW: trace an exact diff, component, endpoint or data flow and report only reachable, actionable defects.
• SUPPLY_CHAIN: inspect an exact dependency, installer, plugin, script, workflow or external skill for provenance, pinning, permissions and execution risk.
• RELEASE_GATE: verify required security controls, tests, migration safety and rollback evidence before a high-risk release.

Use nobrainer-review for a general closeout with no material security boundary. Use nobrainer-rca when the question is what caused an observed incident.

Freeze scope and authority

Record:

MODE:
SCOPE: <exact diff/files/component/endpoint/artifact>
ASSETS_AND_DATA:
TRUST_BOUNDARIES:
ATTACKER_CAPABILITIES:
ENVIRONMENT_AND_VERSION:
WRITE_AUTHORITY: READ_ONLY unless explicitly expanded
LIVE_TEST_AUTHORITY: NONE unless exact target and actions are approved
OWNER_GATES:

Resolve actual checkout, dirty state, deployed/runtime distinction, data classification and existing controls. Never place credentials, full tokens, private payloads or exploit-ready production details in prompts or reports.

Do not test a live target, scan infrastructure, create an account, send a payload, access another user's data or install/run untrusted code without exact authorization. Prefer local fixtures, static traces and isolated reproductions.

Trace the trust boundary

Follow each relevant flow from attacker-controlled or externally supplied input through validation, canonicalization, authorization, state changes and output. For every boundary, establish:

• who controls the input and what identity/account/tenant it represents;
• parsing, normalization and validation order;
• authorization decision and its ownership point;
• storage, logging, cache, queue and retry behavior;
• sensitive output, side effect and failure mode;
• current guard and evidence that it runs on the real path.

Prioritize classes that fit the actual boundary: broken access control, confused deputy, injection, SSRF, unsafe path handling, secret exposure, insecure deserialization, XSS/CSRF, request smuggling, race/idempotence, unsafe defaults, dependency or workflow substitution, and rollback bypass. Do not paste a generic vulnerability list into findings.

When a material claim depends on current standards, advisories, dependency behavior or vendor guidance, invoke nobrainer-research and prefer primary sources for the exact version. If required current evidence is inaccessible, return RESEARCH_BLOCKED; memory is not a security proof.

Mode-specific evidence

THREAT_MODEL

Produce a compact data-flow/trust-boundary map. For each plausible abuse path, state precondition, attacker action, affected asset, existing control, residual risk and one testable requirement. Rank by expected loss and reachability, not by dramatic wording.

SECURITY_REVIEW

Inspect the full changed function plus callers and consumers. Trace negative paths and concrete boundary values. Run the smallest safe test or reproduction that would distinguish a defect from a false alarm. A scanner result, model finding or dependency label is only a candidate.

SUPPLY_CHAIN

Resolve exact source, version/ref, integrity/pinning, release provenance, license, install scripts, hooks, network calls, requested permissions, credential access, write targets, update channel and rollback. Review the actual artifact before executing it. Prefer temporary isolated use over global or persistent installation.

RELEASE_GATE

Map each security acceptance item to current code/config, a focused test, runtime or migration evidence, and rollback. Static validation does not prove a deployed control. Unknown production state remains unknown.

Finding and false-positive gate

Report a defect only when all are present:

• severity with impact and realistic preconditions;
• exact location or trust boundary;
• attacker-controlled input/state/sequence;
• reachable code or runtime path;
• observable confidentiality, integrity or availability impact;
• why current controls fail;
• smallest ownership-correct fix contract;
• regression or verification proof.

Run a false-positive pass against every candidate: seek the guard, caller constraint, deployment setting, parser behavior or version fact that would make the path unreachable. Reject generic hardening, style preferences, stale advisories for another version and speculative chains missing a necessary step.

Handoff and remediation

Security review ends with evidence and a fix contract. If remediation is in scope, route each accepted finding to nobrainer-build as a bounded stage with a failing regression, allowed write scope and rollback. Then repeat the relevant security trace with fresh evidence. Consequential fixes still require an independent nobrainer-review or release gate; self-authored code is not self-approved.

Final report

MODE: THREAT_MODEL | SECURITY_REVIEW | SUPPLY_CHAIN | RELEASE_GATE
SCOPE_AND_AUTHORITY:
ASSETS_AND_TRUST_BOUNDARIES:
FINDINGS: <severity, location, path, impact, fix contract, proof>
REJECTED_CANDIDATES:
TESTS_AND_SOURCES:
UNTESTED_OR_INACCESSIBLE_SURFACE:
OWNER_GATES:
ROLLBACK_OR_CONTAINMENT:
RESULT: FINDINGS | CLEAN | PARTIAL | BLOCKED | RESEARCH_BLOCKED

Return CLEAN only for the complete frozen scope with required evidence. A partial review, inaccessible runtime or unverified external claim cannot be green.