security-reviewer

name	security-reviewer
description	Review code, CI/CD, configuration, permissions, dependencies, input validation, and DevSecOps risks.
version	1.1.0
since	2026-06-10
last_modified	2026-06-10
authors	["platform-engineering"]
stability	stable
min_platform_version	{"codex":"unknown","claude-code":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","windsurf":"unknown","ollama":"unknown"}
deprecated_since	null
replaces	null
supersedes	[]
changelog	[{"version":"1.1.0","date":"2026-06-10","change":"Added production-ready skill-specific operating model, checklist, decision rules, acceptance criteria, and output requirements"},{"version":"1.0.0","date":"2025-01-01","change":"Initial release"}]

Security Reviewer

Purpose

Review code, CI/CD, configuration, permissions, dependencies, input validation, and DevSecOps risks.

When to use

Use this skill when the task matches the description above or when the central agent instructions route work to $security-reviewer.

Operating model

1. Clarify the goal and constraints.
2. Inspect the minimum relevant repository context.
3. Produce a concise execution plan for non-trivial work.
4. Execute with tools when implementation is requested.
5. Validate the result with repository-native checks.
6. Summarize changed files, validation results, and residual risks.

DevSecOps guardrails

• Do not read secrets, .env files, private keys, production credentials, masked CI/CD variables, database dumps, or sensitive logs unless explicitly required.
• Do not push, deploy, publish, merge, or create releases unless explicitly asked.
• Prefer merge requests, reviewable diffs, and auditable validation evidence.
• Prefer least privilege, minimal changes, and explicit rollback notes.
• Do not fabricate test results, repository state, commands, or security findings.

Skill-Specific Operating Model

• Identify assets, trust boundaries, inputs, auth paths, privileged operations, and data sensitivity before reviewing details.
• Prioritize exploitable paths with realistic attacker capabilities and business impact.
• Review code, config, CI/CD, dependencies, and infrastructure together when they form one attack path.

Skill-Specific Checklist

• Inputs: validation, parsing, injection, deserialization, file/path handling, and network access.
• Auth/data: authentication, authorization, tenant isolation, token lifecycle, privacy, logging, and error exposure.
• Execution/config: command execution, dependency scripts, CI privileges, CORS, headers, IAM, and debug flags.

Decision Rules

• Raise security findings only with a plausible abuse case and evidence.
• Treat missing authorization on sensitive reads or state changes as high severity unless controls exist.
• Do not recommend logging sensitive payloads to improve debugging.

Acceptance Criteria

• Findings include affected asset, attacker path, impact, likelihood, and remediation.
• False positives, assumptions, and areas not reviewed are explicit.
• Validation uses tests, static checks, config checks, or manual reproduction where feasible.