security-review-spec

Name: security-review-spec
Author: warpdotdev

288stars37forks

How to install security-review-spec?

warpdotdev/oz-for-oss/security-review-spec

$npx -y skills add warpdotdev/oz-for-oss --skill security-review-spec

Installs into the current project.

Summary

Audit a product or tech spec pull request diff for high-level security concerns (threat surface, authentication and authorization model, trust boundaries, sensitive data handling, secrets and key management, dependency posture, and abuse or misuse cases) and fold findings into th

Files · 1

View on GitHub

SKILL.md

1	# Security Review Spec Skill
2
3	Audit the current spec pull request for security concerns at the design-doc level and fold any findings into the same `review.json` produced by the base `review-spec` skill.
4
5	## Goal
6
7	Provide a focused security pass on top of the general spec review. This is a supplement to `review-spec`, not a separate output. Findings must be merged into the single combined `review.json` so reviewers receive one cohesive review.
8
9	The focus here is high-level design concerns that a security-minded reader would raise on a product or tech spec, not line-by-line code issues. Flag gaps, ambiguities, or design choices that would plausibly lead to an insecure implementation if built as described.
10
11	## Inputs
12
13	- The working directory is the PR branch checkout.
14	- The workflow usually provides an annotated diff in `pr_diff.txt`.
15	- The workflow usually provides the PR description in `pr_description.md`.
16	- Spec PRs typically only modify files under `specs/`.
17	- Focus on the spec files and sections changed by this PR.
18	- Default behavior: do not post comments or reviews to GitHub directly.
19
20	## When to apply this skill
21
22	- Apply on spec PRs whenever `review-spec` is applied.
23	- Do not apply on code PRs handled by `review-pr`; those use `security-review-pr` instead.
24	- Skip the skill entirely when the changed spec content has no plausible security surface (e.g. purely editorial wording changes, typo fixes, or doc structure cleanup). It is better to stay silent than to manufacture findings.
25	- Do not duplicate findings the base `review-spec` pass will already raise. If the base review would naturally catch an issue, leave it there rather than re-reporting it from the security pass.
26
27	## Security concerns to audit
28
29	Evaluate the changed spec content against the following concerns. Treat the list as a checklist, not a ceiling — flag other clearly security-relevant design issues when they appear. Stay at the design-doc level: worry about what the spec does or does not commit to, not how it will be coded.
30
31	### Threat surface and trust boundaries
32	- New external inputs, endpoints, webhooks, CLI surfaces, or file formats that are introduced without describing who can reach them and under what trust assumptions.
33	- Trust boundaries that are implied but not explicitly stated (e.g. "the agent receives data from GitHub" without saying which fields are attacker-controlled).
34	- User-supplied or third-party content (issues, comments, spec bodies, uploaded files, remote URLs) that will flow into automation, prompts, commands, or storage without a clear validation or sanitization plan.
35	- Features that expand what an unauthenticated or low-privilege actor can cause the system to do.
36
37	### Authentication and authorization model
38	- New actors, roles, or automation identities introduced without a clear description of how they authenticate and what they are allowed to do.
39	- Authorization rules that are described informally ("only maintainers can trigger this") without specifying how that is enforced.
40	- Privilege escalation risks: features where a less-privileged user can cause a more-privileged actor (bot, workflow, agent) to act on their behalf without explicit gating.
41	- Missing discussion of how permission or ownership changes propagate (e.g. revoking access, rotating tokens, removing a collaborator).
42
43	### Sensitive data handling and privacy
44	- New data the system will collect, store, log, or transmit without stating sensitivity, retention, or access controls.
45	- Personally identifiable information, auth tokens, session identifiers, private repository contents, or customer data routed through logs, analytics, prompts, or third-party services without a redaction plan.
46	- Specs that assume data is "internal" without describing the boundary that keeps it internal.
47	- Missing discussion of how the feature behaves for private repositories, restricted orgs, or data subject to deletion requests.
48
49	### Secrets and key management
50	- New credentials, API keys, signing keys, or tokens introduced without describing where they live, who can read them, and how they are rotated.
51	- Specs that describe passing secrets through environment variables, command-line arguments, or log-visible paths without acknowledging the exposure.
52	- Shared secrets across environments (dev, staging, prod) where the spec does not call out isolation.
53	- Missing discussion of what happens when a secret is leaked or revoked.
54
55	### Abuse, misuse, and denial of service
56	- Features that can be triggered by external events (webhooks, comments, s

People who liked this also viewed

6 picks

Type

security-review-spec

288stars37forks

View on GitHub

How to install security-review-spec?

warpdotdev/oz-for-oss/security-review-spec

$npx -y skills add warpdotdev/oz-for-oss --skill security-review-spec

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Security Review Spec Skill
2
3	Audit the current spec pull request for security concerns at the design-doc level and fold any findings into the same `review.json` produced by the base `review-spec` skill.
4
5	## Goal
6
7	Provide a focused security pass on top of the general spec review. This is a supplement to `review-spec`, not a separate output. Findings must be merged into the single combined `review.json` so reviewers receive one cohesive review.
8
9	The focus here is high-level design concerns that a security-minded reader would raise on a product or tech spec, not line-by-line code issues. Flag gaps, ambiguities, or design choices that would plausibly lead to an insecure implementation if built as described.
10
11	## Inputs
12
13	- The working directory is the PR branch checkout.
14	- The workflow usually provides an annotated diff in `pr_diff.txt`.
15	- The workflow usually provides the PR description in `pr_description.md`.
16	- Spec PRs typically only modify files under `specs/`.
17	- Focus on the spec files and sections changed by this PR.
18	- Default behavior: do not post comments or reviews to GitHub directly.
19
20	## When to apply this skill
21
22	- Apply on spec PRs whenever `review-spec` is applied.
23	- Do not apply on code PRs handled by `review-pr`; those use `security-review-pr` instead.
24	- Skip the skill entirely when the changed spec content has no plausible security surface (e.g. purely editorial wording changes, typo fixes, or doc structure cleanup). It is better to stay silent than to manufacture findings.
25	- Do not duplicate findings the base `review-spec` pass will already raise. If the base review would naturally catch an issue, leave it there rather than re-reporting it from the security pass.
26
27	## Security concerns to audit
28
29	Evaluate the changed spec content against the following concerns. Treat the list as a checklist, not a ceiling — flag other clearly security-relevant design issues when they appear. Stay at the design-doc level: worry about what the spec does or does not commit to, not how it will be coded.
30
31	### Threat surface and trust boundaries
32	- New external inputs, endpoints, webhooks, CLI surfaces, or file formats that are introduced without describing who can reach them and under what trust assumptions.
33	- Trust boundaries that are implied but not explicitly stated (e.g. "the agent receives data from GitHub" without saying which fields are attacker-controlled).
34	- User-supplied or third-party content (issues, comments, spec bodies, uploaded files, remote URLs) that will flow into automation, prompts, commands, or storage without a clear validation or sanitization plan.
35	- Features that expand what an unauthenticated or low-privilege actor can cause the system to do.
36
37	### Authentication and authorization model
38	- New actors, roles, or automation identities introduced without a clear description of how they authenticate and what they are allowed to do.
39	- Authorization rules that are described informally ("only maintainers can trigger this") without specifying how that is enforced.
40	- Privilege escalation risks: features where a less-privileged user can cause a more-privileged actor (bot, workflow, agent) to act on their behalf without explicit gating.
41	- Missing discussion of how permission or ownership changes propagate (e.g. revoking access, rotating tokens, removing a collaborator).
42
43	### Sensitive data handling and privacy
44	- New data the system will collect, store, log, or transmit without stating sensitivity, retention, or access controls.
45	- Personally identifiable information, auth tokens, session identifiers, private repository contents, or customer data routed through logs, analytics, prompts, or third-party services without a redaction plan.
46	- Specs that assume data is "internal" without describing the boundary that keeps it internal.
47	- Missing discussion of how the feature behaves for private repositories, restricted orgs, or data subject to deletion requests.
48
49	### Secrets and key management
50	- New credentials, API keys, signing keys, or tokens introduced without describing where they live, who can read them, and how they are rotated.
51	- Specs that describe passing secrets through environment variables, command-line arguments, or log-visible paths without acknowledging the exposure.
52	- Shared secrets across environments (dev, staging, prod) where the spec does not call out isolation.
53	- Missing discussion of what happens when a secret is leaked or revoked.
54
55	### Abuse, misuse, and denial of service
56	- Features that can be triggered by external events (webhooks, comments, s

People who liked this also viewed

6 picks

Type