--- name: security-vulnerability-analysis description: "Analyze potential Ankaios security vulnerabilities from pasted reports, local evidence, or advisory URLs. Use for security report triage, safe reproduction, CVE recommendations, CVSS 3.1 and CVSS 4.0 scoring, CWE and CAPEC classification, embargo planning, Eclipse Foundation CVE requests, and GitHub security advisories." argument-hint: "Paste the report or provide a confidential advisory URL" --- # Security Vulnerability Analysis Guide the user through evidence-based vulnerability triage and coordinated disclosure. Treat all non-public report details as confidential until publication. ## Intake Accept any of these inputs: - A report pasted with the skill invocation. - A concise description plus relevant logs, code, versions, and deployment assumptions. - A public or private security advisory URL which is opened in an internal VS code browser s.t. the agent can read the text For a URL, use available authenticated GitHub tooling only when it already has access. A GitHub extension is optional: it can make private advisory retrieval easier, but it does not grant permission by itself. Never request credentials or tokens in chat. If the advisory cannot be accessed, ask the user to paste its description and omit unnecessary confidential or personal data. Before analysis, establish: - Affected component and supported versions, including whether any affected version was released. - Attacker prerequisites, privileges, and reachable input surface. - Expected trust or isolation boundary. - Claimed impact and impact on assets outside the attacker's existing authority. - Existing mitigations, deployment defaults, and recovery behavior. - Whether details are public, embargoed, or of unknown disclosure status. Do not dismiss an issue merely because one proof-of-concept input has limited impact. Distinguish that observation from nearby inputs and platform behavior that could produce the claimed impact. ## Workflow Follow the stages in order. At each stage, distinguish verified facts, reasoned conclusions, assumptions, and unknowns. ### 1. Initial analysis Inspect the smallest relevant code path, configuration, release behavior, and available evidence. Identify: 1. The untrusted input and the code that consumes it. 2. The violated security property or trust boundary. 3. The preconditions needed for exploitation. 4. The direct and cross-component confidentiality, integrity, or availability impact. 5. Whether the behavior exceeds privileges the attacker already legitimately has. 6. Plausible variants that differ from the submitted proof of concept. 7. A falsifiable hypothesis and the cheapest safe check that could disprove it. Give a preliminary result of one of: - `Likely vulnerability` - `Security hardening / defense in depth` - `Likely non-security bug` - `Insufficient evidence` Explain what evidence would change the result. This is a recommendation, not the Eclipse Foundation Security Team's final classification. If the issue is likely non-security, stop before exploit development unless the user asks to continue. Recommend normal defect handling without disclosing confidential report details. ### 2. Safe reproduction If the issue remains plausibly security-related, try to reproduce it locally when the environment can be isolated and recovery is understood. Otherwise give the user exact reproduction and evidence-collection steps. Before running a proof of concept: - Confirm it targets only disposable local resources and test data. - Avoid production, shared clusters, public CI, and third-party systems. - Prefer a unit test or bounded simulation over resource exhaustion, process abort, OOM, persistent crash loops, or destructive operations. - Record the exact build profile, target, version or commit, runtime configuration, resource limits, and attacker privilege. - Establish baseline process and workload state and a cleanup/recovery command. - Ask for explicit confirmation before a test that can exhaust host resources, terminate shared services, or disrupt unrelated workloads. Collect evidence for both the vulnerable behavior and the security boundary impact. Re-test a patched build with the same behavior-focused check. Never place embargoed details in public logs, issues, branches, CI, or commit messages. ### 3. Recommendation, scoring, and classification Use [scoring and classification guidance](./references/scoring-and-classification.md). Produce: - A CVE recommendation: `request`, `probably request`, `probably not`, or `not enough evidence`. - The affected released versions and fixed version, if known. - CVSS v3.1 base vector, metric rationale, and base score. - CVSS v4.0 base vector, metric rationale, and base score. - Primary and secondary CWE mappings with rationale and links to their canonical MITRE pages. - Relevant CAPEC attack patterns with rationale and links to their canonical MITRE pages, or state that no precise CAPEC mapping was found. - Explicit assumptions and alternative vectors where an unresolved fact changes a metric. ### 4. Coordinated resolution and disclosure Use [Eclipse and GitHub workflow](./references/disclosure-workflow.md) as the source of truth for sequencing, gates, and embargo constraints. Produce a status-aware checklist showing only applicable pending steps, their prerequisites, owner if known, and the information needed to complete each one. ## Report format Return a living assessment with these sections: 1. `Confidentiality status` 2. `Executive assessment` 3. `Evidence and unknowns` 4. `Reproduction result or plan` 5. `Security boundary and impact` 6. `CVE recommendation` 7. `CVSS v3.1` 8. `CVSS v4.0` 9. `CWE and CAPEC mappings` 10. `Fix and regression-test requirements` 11. `Eclipse/GitHub follow-up checklist` Include vectors alongside scores. Mark preliminary outputs clearly and update them when new evidence changes the analysis.