security-engineer

Plugin security-engineer from marketplace truecast in wastedcode/truecast. Commands read from the repo's manifest — 27 days ago.

Skills (17)

• beat-the-frontier

  Use before any substantive security review, threat model or verdict, and as the last pass before handing it over — your version of the engine's "beat the frontier" loop. Name who does offensive and defensive security best today, set the bar above them, cover every known attack class for this surface

• cryptography-sanity-check

  Use when code does anything cryptographic — hashing passwords, encrypting data, signing tokens, generating randomness — catch the common crypto misuse and never let anyone roll their own.

• grade-and-remediate-risk

  Use when you have findings to report — grade each by real-world risk (P0–P3) with a specific minimal remediation, block only real exploitable harm, and name accepted risk out loud.

• handle-vuln-disclosure

  Use when a vulnerability is reported from OUTSIDE the team (a security researcher, a user, a bug bounty, an embargoed upstream CVE) — triage it without shooting the messenger, drive coordinated disclosure on a clear timeline, and stand up the intake so reports have somewhere to land.

• harden-by-default

  Use when recommending controls or evaluating whether a system is secure by construction — apply the classic security principles (least privilege, fail-safe defaults, complete mediation, economy of mechanism, no security-through-obscurity).

• hunt-vuln-classes

  Use when auditing code that takes user or network input — hunt the OWASP web vuln classes by tracing untrusted input to a dangerous sink, and substantiate every finding input → sink → file:line + the concrete attack.

• map-the-trust-boundary

  Use FIRST, before hunting any bug — write down the system's trust model (who can reach what, which callers are already trusted, what the deployment model is). It decides what is even in scope.

• respond-to-incident

  Use when a security incident is suspected or active (breach, leaked secret, active exploit, suspicious activity) — run the NIST lifecycle: contain, eradicate the root cause, recover, then a blameless postmortem.

• review-authn-authz

  Use when reviewing anything that authenticates users, checks permissions, or exposes objects by id — broken access control is the #1 web risk; verify authz is enforced server-side at every object, deny-by-default.

• review-detection-and-logging

  Use when reviewing a change, a design, or a system's readiness — ask "if this gets attacked or exploited in prod, would we even know?" Review the audit trail, the security-relevant logging, and the detection/alerting on abuse, then assume breach.

• review-external-surfaces-for-disclosure

  Use to scan everything an outsider can read — README, marketing copy, docs, public config, AND error messages, stack traces, debug pages, response headers, and logs — for leaked secrets, internal stack/architecture detail, or proprietary-pipeline disclosure.

• secrets-and-config-discipline

  Use when reviewing config, env handling, CI/CD, logging, or anything that touches credentials — secrets never in repo or logs, short-lived and least-scope, with insecure defaults caught and a leak treated as compromised.

• secure-ai-systems

  Use when reviewing an LLM feature, AI agent, RAG system, or tool/MCP integration — treat the OWASP LLM Top 10 as its own attack class: prompt injection, excessive agency, tool poisoning, system-prompt leakage.

• secure-design-review

  Use when consulted EARLY on a design or proposal (before the build) — say plainly what it would take to ship this safely while it's still cheap to change, and escalate insecure-by-construction designs to the architect.

• secure-supply-chain

  Use when a new dependency is added, a CVE is reported, or the build/CI pipeline is reviewed — assess reachability not just presence, pin and lock deps, and treat the maintainer-takeover class as a top modern risk.

• threat-model-the-change

  Use when reviewing a change, feature, or design for security — walk Shostack's four questions and STRIDE across every trust boundary of THIS stack, not a generic checklist.

• write-the-security-verdict

  Use to land your review as a durable artifact — the attack surface reviewed, findings at file:line (or "none"), the P-grade and minimal fix, and a clear GO / NO-GO — including on a clean GO.

Subagents (1)

• security-engineer

  A security engineer who tries to get in before an attacker does — threat-models this stack, traces real input to the dangerous sink, watches the blast radius of destructive/shared-credential writes, keeps internal stack and secrets out of public copy and error/log output, grades only exploitable har