| name | security-review |
| description | On-demand security review for code, containers, and Kubernetes configuration. Use when changes involve authentication/authorization logic, input parsing, file handling, secrets, logging, dependency upgrades, Dockerfiles, Docker Compose, Helm charts, CI/CD workflows, or privilege elevation. Covers secure code review (input validation, injection, dynamic execution, dependency hygiene), AI-generated code guardrails, container artifact hardening (Dockerfile, Compose), and Helm/Kubernetes security defaults. Produces classified findings (Fix in artifact vs. Deployment-time responsibility) with severity and confidence levels. Do NOT use for: runtime, host, cluster, or organizational security controls; general code quality or style reviews unrelated to security; enforcing network policies, node hardening, or cloud IAM configuration. |
Security Review
Purpose
This document defines on-demand security review guidance for code and configuration changes.
It complements the always-on secure-by-default rules defined in .github/copilot-instructions.md.
This skill applies only at development and authoring time.
Runtime, host, cluster, or organizational security controls are explicitly out of scope.
Security Review Trigger Points
Load this security review skill when changes involve:
- Authentication, session, or token logic
- Authorization or resource ownership checks
- Input parsing, validation, normalization, or canonicalization
- File handling, deserialization, template rendering, or process execution
- Logging, telemetry, secrets handling, or sensitive data paths
- Dependency upgrades, lockfile changes, or CVE-related updates
- Dockerfile or container base image changes
- Docker Compose, Helm charts, or Kubernetes-related configuration
- CI/CD workflow changes affecting build, test, release, or scanning
- Privilege elevation, root execution, host mounts, or new Linux capabilities
AI-Generated Code Guardrails
When reviewing AI-generated changes:
- Treat AI output as untrusted draft code until reviewed and tested
- Verify package names, APIs, images, and tools exist and originate from trusted sources
- Reject suggestions that bypass or disable security controls for convenience
- Require pinned versions and lockfiles for generated dependencies; prefer integrity-verified installs when supported
- Never accept generated code or configs that inject secrets via source files, Dockerfile
ARG/ENV, or committed templates
- Reject generated install scripts that use unchecked remote execution patterns (e.g.,
curl | sh) without checksum or signature verification
- Reject generated build commands that disable TLS, certificate verification, or security checks to make builds pass
- Apply RCI pattern: ask the AI to review its own output for security issues, then improve; repeat 1-2 iterations
Secure Code Review (OSS Context)
Apply when reviewing application logic, services, APIs, or libraries.
Input handling
- Validate input at trust boundaries (format, type, range, length)
- Avoid unsafe deserialization
- Do not propagate unvalidated input across trust boundaries
- Avoid command, query, or expression construction via string concatenation
- Use parameterized queries for all database access
Authorization
- Keep authorization checks server-side and close to protected actions or resources
- Do not rely on client-side enforcement for access control
Error handling
- Errors must not expose sensitive internal details
- Avoid ignored return values or silent failures
Memory & resource safety (where applicable)
- Avoid unchecked allocations and unbounded resource use
- Ensure files, sockets, and handles are closed deterministically
Logging & telemetry
- Do not log credentials, tokens, secrets, or PII
- Logs should be actionable without exposing sensitive data
Dynamic execution
- Avoid unsafe dynamic execution patterns (
eval, exec, reflection, or untrusted code execution).
Dependency usage
- Avoid shelling out when native APIs or libraries exist
- Flag outdated, unmaintained, or suspicious dependencies
- Prefer latest stable versions; specify exact or range-locked versions
OSS-specific review checks
- Is externally observable security-relevant behavior documented?
- Are assumptions and limitations stated explicitly for users?
If uncertainty exists, flag it clearly rather than guessing or assuming safety.
Container Artifact Review (Development-Time)
Apply when generating or reviewing:
- Dockerfiles / Containerfiles
- docker-compose.yml
- Helm charts (templates and values)
Dockerfile
- Avoid
latest or floating tags; pin versions or digests
- Prefer minimal base images
- Ensure containers do not run as root
- Avoid setuid or setgid binaries
- Use multi-stage builds and remove build tools, package caches, and temp files from final image
- Prefer
COPY over ADD
- Never embed secrets in
ARG, ENV, or filesystem layers
Docker Compose
- Avoid
privileged: true and host networking unless explicitly justified
- Do not mount the Docker socket
- Restrict host filesystem mounts
- Limit exposed ports and networks; prefer internal networks
Concerns that depend on deployment or runtime policy should be flagged as:
"Deployment-time responsibility."
Helm / Kubernetes Review (Development-Time)
- Default to
runAsNonRoot: true
- Set
allowPrivilegeEscalation: false
- Prefer read-only root filesystem where feasible
- Drop unnecessary Linux capabilities
- Do not template secrets directly into charts
- Document required runtime security assumptions
Do not enforce cluster-wide, node-level, or runtime security controls.
Review Output Expectations
- Identify which section applies (Code / Container / Helm)
- Classify findings as:
- Fix in artifact
- Deployment/runtime responsibility
- Explicitly state assumptions or uncertainty
- Use severity levels: Critical / High / Medium / Low with confidence: High / Medium / Low
- Include specific file/function references and recommended fixes
Security review is advisory; final decisions belong to maintainers.
