micronaut-security-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Micronaut Security Review

Use this skill whenever work changes executable code, dependencies, build logic, CI/CD, release automation, secrets handling, security-sensitive configuration, or security-sensitive docs in a Micronaut repository.

## Session Start

Before you review:

1. Open the Paperclip issue, current execution stage, latest linked GitHub context, and any prior QA or Architect artifact.
2. Continue only if the issue is assigned to you in `TODO` for pre-triage, you are the current stage participant for final security review, the issue returned `changes_requested` to final security review, or the monthly-security-deep-scan routine invoked you.
3. If another stage participant or a human approval is active, stop and leave routing unchanged.
4. Read `executionState.returnAssignee` before you decide whether a finding should return to the executor as `changes_requested`.
5. Decide whether you are in issue-review mode or monthly-security-deep-scan mode before you inspect anything.

## Review Scope

- Java, Groovy, or Kotlin code paths that process untrusted input
- HTTP, serialization, deserialization, reflection, dynamic loading, filesystem, process, and outbound-network surfaces
- authentication, authorization, token or session, and secret handling
- Gradle wrapper, version catalogs, plugins, build scripts, generated code, annotation processors, and publishing or release workflows
- GitHub Actions or other CI/CD automation, especially permissions, secret exposure, and supply-chain pinning
- docs or examples that could encourage insecure defaults

## Threat Questions

- Can untrusted input reach a dangerous sink without validation, escaping, or authorization?
- Could the change leak secrets, tokens, sensitive config, or user data through logs, errors, metrics, or docs?
- Does it introduce unsafe defaults or widen exposure that users will inherit silently?
- Does the dependency, build, or CI change increase supply-chain risk or grant more privilege than necessary?
- Is there a smaller hardening change that preserves compatibility while reducing risk?

## Possible Outcomes

- `approved`: pre-triage hands the issue `TODO` exactly to the next entry in the authoritative ordered `qa-intake.stageSequence` with a next-action comment; final Security review approves the execution-policy stage and advances to Code Reviewer. The stage artifact explains why the work is safe enough to proceed.
- `changes_requested`: the stage artifact identifies a concrete vulnerability, insecure default, leaked secret, excessive permission, or other plausible exploit path that must be fixed before the work can advance. Pre-triage returns `TODO` to QA naming the gap; final review uses `status: in_progress` so the host routes to `executionState.returnAssignee`.

## Role Boundary

- QA owns acceptance against the plan or reproducer.
- Security Engineer owns two distinct conditional gates: pre-triage before implementation and final review after QA. Pre-triage never skips Architect, implementation, QA verification, or final Security review.
- Code Reviewer owns maintainability, performance, developer experience, and PR quality only after final Security sign-off when Security is required.

## Finish Verification

Before you stop:

1. Re-open the issue and confirm the current execution state matches your chosen outcome.
2. After pre-triage, confirm the issue is `TODO`, assigned to the next `stageSequence` entry, with no execution policy.
3. If you approved the final review stage, confirm the current stage participant is no longer you, the issue is still in `in_review`, and the next `currentParticipant` is Code Reviewer.
4. If you requested changes, confirm the issue execution state shows `changes_requested` and your artifact names the exact remediation or compensating control.
5. Confirm routing is correct; do not attempt a cross-agent heartbeat invocation.
6. Inspect relevant GitHub review threads, but do not mutate them. Record any required reply or resolution for `followThroughOwner`, then confirm that owner performs the thread mutation before you approve.

## Monthly Security Deep Scan Mode

When invoked by the `monthly-security-deep-scan` routine:

- inspect recent code changes, open PRs, default branches, dependency movement, Gradle wrapper or plugin changes, build logic, CI/CD permissions, release automation, and security-sensitive docs
- deduplicate every finding against existing synced GitHub issues or PRs with `paperclip-github-plugin:search_repository_items`
- record what was inspected, what is already tracked, and what still needs follow-up
- if a new vulnerability does not already have a synced GitHub issue or PR, prepare a maintainer-ready Paperclip escalation instead of improvising unsupported GitHub issue creation

From alvarosanchez/micronaut-agent-company, MIT.

More from alvarosanchez/micronaut-agent-company