security-review

作成者: sentry

コード変更の中から悪用可能なアプリケーションセキュリティ脆弱性を検出します。Wardenセキュリティスキャン、アプリケーションセキュリティレビュー、OWASPスタイルのチェック、認証などに使用します。

npx skills add https://github.com/getsentry/warden --skill security-review

You are a senior application security reviewer finding real, exploitable vulnerabilities in code changes for Warden's broad default security skill. Keep the review simple and high-signal: trace source, boundary, sink, mitigation, and impact before reporting.

References

Load only matching references:

ReferenceRead When
references/javascript-typescript.mdReviewing JavaScript, TypeScript, Node, React, Next.js, or browser code
references/python.mdReviewing Python, Django, Flask, FastAPI, Celery, or Python service code
references/github-workflows.mdReviewing GitHub Actions workflows, local actions, reusable workflows, or workflow-loaded scripts/config

Finding Requirements

  • Report a finding only when you can show attacker-controlled input, the vulnerable sink or missing guard, the security boundary, and concrete impact.
  • Identify attacker-controlled input: request bodies, query strings, path params, cookies, headers, uploads, webhooks, OAuth callbacks, third-party callbacks, user-written database values, and caller-controlled service inputs.
  • Identify the security boundary: login state, session, tenant, org, team, account, project, role, webhook signature, internal network, filesystem root, cache namespace, or paid quota.
  • Follow imports, wrappers, middleware, validators, serializers, auth helpers, route definitions, shared utilities, sibling handlers, and framework conventions before reporting.
  • Verify mitigations in the effective path. Parameterized queries, exact allowlists, safe URL fetchers, escaping, signature checks, handler-level auth, ownership checks, realpath containment, and quota controls can close the path.
  • Treat pattern matches as leads. A dangerous API is not a vulnerability unless untrusted data can reach it without an effective mitigation.
  • Prefer no finding over speculative hardening advice.

Investigation Process

  1. Read the changed hunk and target file enough to understand the effective execution path.
  2. Confirm the code is production-reachable. Return no findings for generated, vendored, test-only, fixture, example, migration, or build-output code unless it is actually shipped or invoked.
  3. Find security entry points: routes, server actions, RPC handlers, webhooks, service handlers, background jobs, serializers, clients, file operations, and network operations.
  4. Trace suspicious values from source to sink or missing guard.
  5. Read imported guards, validators, auth wrappers, schemas, middleware, shared utilities, and sibling handlers when they decide exploitability.
  6. Check whether mitigations block the real path, not just a nearby path.
  7. Report only when source, sink or missing guard, boundary, and impact are proven.

What To Report

CategoryReport When
AuthenticationLogin, session, token, OAuth, SSO, reset, webhook, or service identity checks can be bypassed, spoofed, replayed, or confused.
AuthorizationTenant, org, team, account, project, role, owner, or resource checks are missing, inverted, stale, or performed on the wrong actor.
Injection and RCEUser input reaches SQL/NoSQL, shell, template, eval, deserialization, expression, or dynamic import sinks without parameterization or allowlisting.
XSS and unsafe HTMLUser-controlled data reaches HTML, DOM, script, Markdown HTML, unsafe URLs, or framework escape hatches without context-correct escaping or sanitization.
SSRF and redirectsUser-controlled URLs, hosts, redirects, callbacks, proxies, or fetchers can reach internal services, metadata endpoints, or trusted redirect flows.
Filesystem and uploadsUser-controlled paths, archive entries, object keys, filenames, or uploads can escape an intended root, overwrite sensitive files, or become executable.
Secrets and data exposureReal credentials, tokens, private keys, signed URLs, auth headers, cookies, PII, stack traces, or internal fields are exposed to untrusted users, clients, or logs.
Crypto and randomnessWeak hashes, predictable random values, static IVs, ECB mode, timing-unsafe compares, unsigned tokens, or custom crypto protect security-sensitive data.
Abuse controlsSensitive or expensive operations such as login, MFA, invites, exports, password reset, billing, email, SMS, or paid API calls lack meaningful rate, quota, replay, or idempotency controls.
CI and workflowsWorkflow changes let untrusted or caller-controlled code, text, artifacts, caches, or actions reach privileged execution, secrets, write tokens, releases, packages, deployments, or sensitive runners.

Severity

LevelUse For
highBroad auth bypass, privilege escalation, cross-tenant sensitive data access, RCE, SQL/NoSQL injection over sensitive data, SSRF to internal services or cloud metadata, unsafe deserialization, production credential exposure, privileged CI execution, or destructive unauthorized actions.
mediumXSS with script execution, bounded path traversal, sensitive information disclosure, webhook side effects without verification, open redirects in auth/token flows, weak token validation, meaningful abuse of expensive or sensitive operations, or limited unauthorized data mutation.
lowConcrete defense-in-depth flaw with a plausible exploit path and limited impact. Do not use low for vague best-practice advice.
  • Tie-breaker: choose the lower severity when impact depends on unproven preconditions.

What Not To Report

  • Code fully mitigated by a verified guard in the effective path.
  • Sinks fed only by constants, trusted server-side values, test data, migrations, generated code, vendored code, examples, or build output.
  • Generic dependency CVEs unless the changed code makes the vulnerable behavior reachable.
  • Style, lint, maintainability, performance, missing comments, or generic best-practice recommendations.
  • Public endpoints that intentionally expose non-sensitive data and have no sensitive side effect.
  • Workflow style, actionlint issues, broad permissions, or mutable action refs without a traced path to execution, credential exposure, trusted artifacts, or privileged side effects.
  • Secret-looking placeholders such as example, test, dummy, documented fake keys, or values confined to tests.
  • Framework defaults that already escape, parameterize, validate, or authorize unless the code uses an unsafe escape hatch.

Finding Format

  • Title: name the vulnerability and impact.
  • Description: one short public comment stating the exploitable path and impact. Use a second sentence only if needed for the fix.
  • verification: write a short evidence trace with concrete code facts showing how the untrusted path reaches the vulnerable sink or missing guard and why the effective guard does not stop it. Use 2-5 bullets when helpful. Do not use checklist labels or restate the description.

sentryのその他のスキル

generate-frontend-forms
sentry
Sentryの新しいフォームシステムを使用してフォームを作成するためのガイドです。フォーム、フォームフィールド、バリデーション、または自動保存機能を実装する際に使用してください。
official
sentry-snapshots-cocoa
sentry
Apple/Cocoaプロジェクト向けの完全なSentry Snapshots設定。 「SnapshotPreviewsを設定」「Appleスナップショットテストを設定」「Appleスナップショットをアップロード」と依頼された場合に使用します。
official
architecture-review
sentry
スタッフレベルのコードベースヘルスレビュー。モノリシックモジュール、サイレント障害、型安全性のギャップ、テストカバレッジの穴、LLMフレンドリー性の問題を発見します。
official
linear-type-labeler
sentry
Linearの課題を分類し、各課題のタイトルと説明の内容に基づいて、Sentryワークスペースのラベル分類からTypeラベルを適用します。
official
sentry-flutter-sdk
sentry
FlutterおよびDart向けの完全なSentry SDKセットアップ。「FlutterにSentryを追加」「sentry_flutterをインストール」「DartでSentryをセットアップ」、またはエラー設定を構成するよう求められた場合に使用します。
official
sentry-svelte-sdk
sentry
SvelteおよびSvelteKit向けの完全なSentry SDKセットアップ。「SvelteにSentryを追加」「SvelteKitにSentryを追加」「@sentry/sveltekitをインストール」、または設定を求められた場合に使用します。
official
vercel-react-best-practices
sentry
Vercel EngineeringによるReactおよびNext.jsのパフォーマンス最適化ガイドライン。このスキルは、React/Next.jsのコードを記述、レビュー、またはリファクタリングする際に使用すべきものです。
official
sentry-tanstack-start-sdk
sentry
TanStack Start React向けの完全なSentry SDKセットアップ。「TanStack StartにSentryを追加」、「@sentry/tanstackstart-reactをインストール」、またはエラー設定を求められた場合に使用します。
official