security-review

Audits codebases for vulnerabilities, access-control flaws, and trust-boundary risks with evidence-based findings.

22|Updated Sep 10, 2026
One-click install
npx skills add https://github.com/Lynricsy/HyperSkills --skill security-review-lynricsy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: security-review
Source: https://github.com/Lynricsy/HyperSkills/tree/main/skills/security-review
Command: npx skills add https://github.com/Lynricsy/HyperSkills --skill security-review-lynricsy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Security audits often drown readers in false positives, unverified scanner output, and severity ratings with no demonstrated impact. This Skill structures a whole-codebase or feature-level security audit into four passes — context, attack surface, hunt, verify — so every finding names a reachable path, the control that should have stopped it, and a severity capped at demonstrated impact. ## Core Features & Use Cases - Four-pass audit workflow: Build context, enumerate the attack surface (including deployment config), hunt along reachable paths, then verify every candidate through explicit dismissal tests before reporting. - Threat modelling and triage: Model trust boundaries as concrete edges with STRIDE per edge, triage scanner output with falsifiable dismissal tests, and separate likelihood from impact when assigning severity. - Specialized workflows: Handle leaked credentials with a revoke-first response order, and turn repeated findings into tested semgrep rules with annotated test files. - Use Case: Before opening a reporting feature to customers, audit its Express routes, Python service, and deployment config to find an unauthenticated pickle deserialization sink, an IDOR on order routes, and a client-controlled role header — each reported with a file:line path and a fix. ## Quick Start Ask the agent to audit this repository or a named feature for security vulnerabilities and produce a severity-ranked report with confirmed, needs-validation, and rejected findings.

Frequently Asked Questions about security-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit a codebase for security vulnerabilities?

Run four passes in order: build context on what the system protects, enumerate the attack surface including routes and deployment config, hunt for bug classes along reachable paths, then verify each candidate before reporting. Establish reachability from a named attacker before assigning any severity.

How do I write a semgrep rule to enforce a security invariant?

Write the annotated test file first with ruleid and ok comments, then choose taint mode when the bug depends on data flow rather than the call itself. Run semgrep --test and require all tests passing, since a green exit code alone can hide unmatched test files.

What should I do first when credentials are committed to a repository?

Revoke every leaked credential at the provider first, then rotate, and deal with git history last. Rewriting history invalidates nothing because forks, mirrors, and clones keep working copies until revocation, and each credential needs its own blast-radius assessment.

How do I reduce false positives in security scan results?

Triage scanner output as candidates, not findings: check whether the input is actually attacker-controlled, whether a framework control mitigates it on that route, and whether the code is reachable in real usage. Record every dismissal with its reason and never carry a scanner's severity into your report.

Does this cover CI pipeline and GitHub Actions security?

No, hardening GitHub Actions — permissions blocks, action pinning, workflow expression injection, pull_request_target — belongs to the github skill. This skill covers whole-codebase auditing, threat modelling, secrets response, dependency risk, and semgrep rule writing.

Which OWASP Top 10 version does the audit use?

It uses the OWASP Top 10 2025 edition, where A01 is Broken Access Control, A03 is Software Supply Chain Failures, and A05 is Injection. SSRF is no longer standalone because CWE-918 sits inside A01:2025, and ASVS citations use 5.0 chapter numbers.