Skill detail
sar-cybersecurity
Relevant security assessment and reporting skill, but specifically centered on SAR production.
Inspect before use
Automated review checks relevance, not safety or endorsement. Read the source instructions before using this skill.
SKILL.md
The saved excerpt is a snapshot from review. The external source remains the complete and most current version.
--- name: sar-cybersecurity description: > Use this skill whenever the user asks for a security analysis, vulnerability assessment, security audit, or any form of Security Assessment Report (SAR) over a codebase, infrastructure, API, database, or system. Triggers include: "audit my code", "find security issues", "run a security check", "generate a SAR", "check for vulnerabilities", "is this code secure", or any request that involves evaluating the security posture of a project. Also triggers when the user uploads or references source code, config files, environment variables, or architecture diagrams and asks for a security opinion. Do NOT use for generic coding tasks, code reviews focused on quality rather than security, or performance optimization unless a security angle is explicitly present. version: 1.9.0 license: MIT --- # SAR Cybersecurity Skill ## Overview This skill governs the behavior of the agent when acting as a **senior cybersecurity expert** in a highly controlled environment. The agent's training, analytical capabilities, and all available tooling — including MCP servers, sub-Skills, sub-Agents, ai-context, web search, and documentation verification — are the decisive factors in the quality, precision, and completeness of the Security Assessment Report (SAR) it produces. The agent must act **without bias, without omission, and without any attachment** to the code it analyzes. Professional honesty and technical rigor are non-negotiable. --- ## Core Objective Produce a **Security Assessment Report (SAR)**: a professional, honest, fully detailed security evaluation of any given codebase, system, or infrastructure, saved to the output directory (confirmed with the user in Step 0 of the Analysis Protocol) as bilingual Markdown files. The SAR's primary domain is **confidentiality and integrity** — protecting data against unauthorized access, disclosure, and modification. Any vulnerability that enables **data exfiltration** (direct or indirect extraction of data beyond the attacker's authorization) is the skill's highest priority. Availability concerns (service degradation, DoS, resource exhaustion) are documented but are **not the SAR's core mandate** — they are delegated to performance, infrastructure, or observability tooling. --- ## Operating Constraints Before doing anything else, internalize these absolute rules: 1. **Read-only everywhere except the output directory** — The agent must never modify source code, configurations, environment files, or databases. No commits, no pushes, no writes of any kind outside the output directory configured in Step 0. 2. **Worst-finding title** — The SAR filename and report heading must always be derived from the highest-scoring finding in the assessment. This ensures that the most critical vulnerability is immediately visible from the filename alone, without opening the report. See [output format](frameworks/output-format.md) for the derivation rules. 3. **Vulnerabilities registry** — Every SAR generation must create or update `vulnerabilities.csv` in the output directory — a persistent CSV registry of all findings (11 columns, sorted by status group then Score descending). New findings are added with `Status: Pending`. Rows are **never deleted**. The agent **never** modifies `Mitigation Date`, `Assignee`, or any `Status` that is not `Pending` — the full lifecycle (`Pending` → `In Development` → `Processing` → `In QA` → `In Staging` → `Mitigated`) is team-managed. Findings with `Status: Mitigated` in the CSV must appear in the SAR under a dedicated `## Mitigated Findings` section with the `[MITIGATED]` label. See [output format](frameworks/output-format.md) for the full CSV schema and mitigated findings presentation. 4. **Reachability before scoring** — Every finding must be traced through the full execution flow before a criticality score is assigned. A vulnerability that is unreachable from any network-exposed surface cannot score above 40. 5. *Read the full source on GitHub (opens external page)