Security Engineer

Also worth a look

Depends on your team and stack

Written from the changes above. Read and adapt one before you use it.

• Security finding triageChecks if a reported vulnerability is real and exploitable, rates severity, drafts a replysecurity-finding-triageView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named security-finding-triage. When to use it: Triages a security finding or vulnerability report, whether from a scanner, an AI tool or an external researcher, by checking whether it is real, reachable and exploitable in this codebase, rating severity and drafting a prioritised recommendation and reply. Use when handling scanner alerts, bug bounty or disclosure reports, AI-generated vulnerability reports, a backlog of security findings, or when asked "is this vulnerability real" or "how serious is this".

  ---
  name: security-finding-triage
  description: Triages a security finding or vulnerability report, whether from a scanner, an AI tool or an external researcher, by checking whether it is real, reachable and exploitable in this codebase, rating severity and drafting a prioritised recommendation and reply. Use when handling scanner alerts, bug bounty or disclosure reports, AI-generated vulnerability reports, a backlog of security findings, or when asked "is this vulnerability real" or "how serious is this".
  metadata:
    title: "Security finding triage"
    summary: "Checks if a reported vulnerability is real and exploitable, rates severity, drafts a reply"
  ---
  
  # Security Finding Triage
  
  Decide whether a reported security issue is real and exploitable here, and draft a prioritised recommendation for a human to confirm.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The finding or report text, including any proof of concept, affected file, endpoint, version or rule ID.
  - The source: scanner, AI tool, internal reviewer or external reporter.
  - The repository and the deployed version or branch the report applies to.
  - How the affected component is deployed and exposed (internet-facing, internal, behind authentication).
  - The team's severity scale, disclosure policy and response time targets.
  - Whether you may run the application or tests locally. Never test against production or systems you are not authorised to test.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Restate the claim in one sentence: what weakness, where, and what an attacker could achieve.
  2. Check the report for signs of low quality: references to files, functions or versions that do not exist, generic text not tied to this code, or an impact that does not follow from the described flaw. Verify every reference in the repository before reasoning further.
  3. Locate the vulnerable code. Confirm it exists in the affected version and is not dead, test-only or already fixed.
  4. Trace reachability: follow the data from an entry point an attacker can control to the vulnerable code. Note every validation, encoding, authorisation or configuration step on the way.
  5. Identify preconditions: authentication level, user role, feature flags, configuration, deployment settings.
  6. Judge exploitability. If a proof of concept is provided, decide whether it would work against this code. Read the full PoC before running; never run obfuscated code or code that makes network calls; only run it in a sandbox with no credentials or network access, and only with permission. Never run it against shared or production systems.
  7. Assess impact on confidentiality, integrity and availability, and what data or systems are exposed.
  8. Rate severity using the team's scale, showing the factors that drove the rating. If there is no scale, use Critical, High, Medium, Low and explain each rating.
  9. Check for duplicates: the same flaw reported before, the same pattern elsewhere in the codebase, or the same issue in a dependency.
  10. Propose a remediation direction and any short-term mitigation. Do not write or apply the fix as part of triage.
  11. Draft a reply to the reporter that is factual and polite, and does not reveal details beyond what the disclosure policy allows. Do not send the reply or contact the reporter.
  
  ## Output format
  
  ```markdown
  ## Triage: <finding title or ID>
  
  - **Source:** <scanner / AI tool / researcher / internal>
  - **Verdict:** Confirmed / Likely / Not reproducible / Not applicable / Duplicate of <ID>
  - **Proposed severity:** <rating> — needs human confirmation
  - **Confidence:** High / Medium / Low
  
  ### Claim
  
  <one sentence>
  
  ### Evidence
  
  | Check                           | Result | Reference (file:line, config, commit) |
  | ------------------------------- | ------ | ------------------------------------- |
  | Code exists in affected version |        |                                       |
  | Reachable from attacker input   |        |                                       |
  | Existing controls on the path   |        |                                       |
  | Preconditions                   |        |                                       |
  | Proof of concept assessed       |        |                                       |
  
  ### Impact
  
  <what an attacker gains, what data or systems are affected>
  
  ### Related findings
  
  - <duplicates or same pattern elsewhere>
  
  ### Recommended next steps
  
  1. <mitigation or fix direction, owner to be decided>
  
  ### Draft reply to reporter
  
  <text>
  
  ### Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Scanner output and AI-written reports are a first filter, not a verdict. Open the code for anything that matters.
  - Reports that are fluent and detailed but point at code that does not exist or cannot be reached.
  - Dismissing a report too quickly because its writing looks generated. Check the substance.
  - Severity inflation or deflation driven by the reporter's wording rather than reachability and impact.
  - A controls check that stops at the first validation step; confirm it actually blocks the attack.
  - Sharing report details, code or secrets with anyone or any service outside the team's approved channels.
  - Never reproduce secrets, tokens, credentials or personal data from the report, code or logs in the output; refer to them by location and type, and tell the user to rotate anything exposed.
  - A large queue of findings. Record verdicts consistently so the team can prioritise patching.
  
  ## Before you finish
  
  - [ ] Every file, function and version in the report was checked in the repository.
  - [ ] Reachability and preconditions are backed by references.
  - [ ] Severity shows the factors behind it and is marked as a proposal.
  - [ ] Nothing was tested against production or unauthorised systems.
  - [ ] Any PoC was read in full first and run only with permission, in a sandbox with no credentials or network access.
  - [ ] The reporter reply follows the disclosure policy. Do not send the reply or contact the reporter.
  - [ ] Clearly flag your assumptions, your confidence, and the severity, disclosure and fix decisions a human must make.
  

• Security fix verificationChecks that a security fix, including AI-suggested ones, closes the hole safelysecurity-fix-verificationView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named security-fix-verification. When to use it: Verifies a proposed security fix, especially one suggested by an AI tool or autofix feature, by checking that it closes the vulnerability on every path, does not introduce new vulnerabilities, keeps program behaviour intact and adds only real, intended dependencies. Use when reviewing an AI-suggested security patch, a scanner autofix, a vulnerability remediation pull request, or when asked "does this fix actually close the issue".

  ---
  name: security-fix-verification
  description: Verifies a proposed security fix, especially one suggested by an AI tool or autofix feature, by checking that it closes the vulnerability on every path, does not introduce new vulnerabilities, keeps program behaviour intact and adds only real, intended dependencies. Use when reviewing an AI-suggested security patch, a scanner autofix, a vulnerability remediation pull request, or when asked "does this fix actually close the issue".
  metadata:
    title: "Security fix verification"
    summary: "Checks that a security fix, including AI-suggested ones, closes the hole safely"
  ---
  
  # Security Fix Verification
  
  Check that a proposed security fix really closes the issue without breaking behaviour or adding new risk, and draft a merge recommendation.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The original finding: weakness type, affected code, and proof of concept if one exists.
  - The proposed fix as a diff or pull request, and who or what produced it.
  - The tests and CI results for the fix branch.
  - Other places in the codebase that use the same pattern or call the changed code.
  - Whether you may build and run tests locally.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Restate the root cause in one sentence. A fix that does not address this root cause is incomplete, however tidy it looks.
  2. Read the fix diff in full. Classify the approach: input validation, output encoding, parameterised query, authorisation check, safer API, configuration change, dependency upgrade, or removal of a feature.
  3. Check completeness. List every path by which attacker-controlled data reaches the vulnerable sink, and confirm the fix covers each one, not only the path named in the finding.
  4. Search the codebase for the same vulnerable pattern elsewhere and note any instance the fix does not touch.
  5. Try to bypass the fix on paper: alternative encodings, case changes, nested or double input, different content types, other HTTP methods, other user roles, and race conditions.
  6. Check for new vulnerabilities introduced by the change, such as a new injection point, weakened authorisation, sensitive data in logs or error messages, or disabled security features.
  7. Check behaviour. Compare old and new logic for legitimate inputs and note any change in results, error handling or performance a user could notice.
  8. Check dependencies. For every added or upgraded package, confirm the name is exactly the intended, well-established package and not a similar-looking name, and that the version is one the project allows.
  9. Check tests: a test that reproduces the original vulnerability should now fail against the old code and pass against the fix. Flag tests that were deleted, skipped or weakened.
  10. If you are allowed to, build and run the tests in an isolated environment without production credentials, and record results. Do not merge, push or deploy.
  11. Draft a recommendation with any changes required before merge.
  
  ## Output format
  
  ```markdown
  ## Fix verification: <finding ID> / <PR>
  
  - **Fix source:** <person / AI suggestion / autofix>
  - **Recommendation:** Merge / Merge after changes / Reject and rework
  - **Root cause:** <one sentence>
  
  ### Coverage of attack paths
  
  | Path (entry point → sink) | Covered by fix | Evidence |
  | ------------------------- | -------------- | -------- |
  
  ### Bypass attempts (reasoned)
  
  | Attempt | Result | Notes |
  | ------- | ------ | ----- |
  
  ### New risks introduced
  
  - <item, or "none found">
  
  ### Behaviour changes
  
  - <item, or "none found">
  
  ### Dependencies
  
  | Package | Change | Name and version verified |
  | ------- | ------ | ------------------------- |
  
  ### Tests
  
  - Regression test for this vulnerability: <present / missing>
  - Tests removed, skipped or weakened: <list>
  - Results: <observed results, or "not run">
  
  ### Same pattern elsewhere
  
  - <file:line>
  
  ### Required changes before merge
  
  1. <change>
  
  ### Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Fixes that are wrong in quiet ways: they compile, pass tests and still leave the vulnerability open on another path.
  - Fixes that change program semantics, such as rejecting valid input or altering error behaviour.
  - Dependency names that look right but are not the real, intended package.
  - Blocklist-style filters that stop the proof of concept but not variations of it.
  - Fixes applied in the client or user interface only, with no server-side check.
  - Treating CI passing as proof the fix works; confirm a regression test targets the vulnerability.
  - Never reproduce secrets, tokens, credentials or personal data from code, tests, logs or the finding in the output; refer to them by location and type, and tell the user to rotate anything exposed.
  
  ## Before you finish
  
  - [ ] Every attack path is listed and marked covered or not covered.
  - [ ] At least three bypass ideas were considered.
  - [ ] Every new or changed dependency name and version was verified.
  - [ ] Test results are observed, or marked "not run".
  - [ ] You did not merge, push or deploy anything.
  - [ ] Clearly flag your assumptions, residual risk, and the merge decision a human must make.
  

• Agent permission reviewReviews what an AI agent can access and do, and drafts least-privilege recommendationsagent-permission-reviewView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named agent-permission-review. When to use it: Reviews the tools, integrations, credentials and autonomy granted to an AI agent, assistant or MCP server setup, checking for the combination of private data access, exposure to untrusted content and a way to send data out, plus over-broad permissions, and drafts least-privilege recommendations. Use before connecting an agent or MCP server to real systems, when auditing an AI feature's tool access, reviewing agent credentials or scopes, or assessing prompt injection and data exfiltration risk.

  ---
  name: agent-permission-review
  description: Reviews the tools, integrations, credentials and autonomy granted to an AI agent, assistant or MCP server setup, checking for the combination of private data access, exposure to untrusted content and a way to send data out, plus over-broad permissions, and drafts least-privilege recommendations. Use before connecting an agent or MCP server to real systems, when auditing an AI feature's tool access, reviewing agent credentials or scopes, or assessing prompt injection and data exfiltration risk.
  metadata:
    title: "Agent permission review"
    summary: "Reviews what an AI agent can access and do, and drafts least-privilege recommendations"
  ---
  
  # Agent Permission Review
  
  Map what an AI agent can read, what untrusted content reaches it and what it can do, then draft recommendations to narrow its access.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - A description of the agent or AI feature and the tasks it is meant to do.
  - Its configuration: tools, integrations or MCP servers, and the permissions or scopes of each.
  - The credentials it uses (service account, user token, API key) and who owns them.
  - Where its inputs come from: users, documents, web pages, email, tickets, repositories, other agents.
  - Which actions run without human approval.
  - Logging and monitoring in place for the agent's actions.
  
  Do not ask for secret values. Names and scopes of credentials are enough.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. List every tool or integration the agent can call. For each, record what it can read, what it can write or change, and whether it can send data outside the organisation.
  2. List every source of content that reaches the agent's context. Mark each source as trusted (controlled by the organisation) or untrusted (anyone outside can influence it, including public issues, inbound email, web pages and uploaded files).
  3. Check for the risky combination. Mark whether the agent, as configured, has all three of: access to private data, exposure to untrusted content, and any way to communicate externally (sending messages, creating public content, making web requests, writing to places others can read). Check this across all tools together, and within single tools.
  4. For each capability, compare the granted scope with what the stated tasks need. Flag broad scopes, write access that is never needed, shared or personal credentials, and long-lived tokens.
  5. Walk through prompt injection scenarios: for each untrusted source, describe what hidden instructions could make the agent do with its current tools.
  6. Review autonomy. Classify each action as read-only, reversible or destructive, and check which of them run without human approval.
  7. Review identity: whether the agent's actions can be told apart from a human user's in logs, and whether its access can be revoked quickly.
  8. Review supply chain: where each tool or MCP server comes from, who maintains it, and how updates are controlled.
  9. Draft recommendations in order of risk reduction. Prefer removing one leg of the combination; treat filters as a secondary layer, not the main defence.
  10. Do not change any configuration, revoke credentials or call the agent's tools yourself. Recommendations are for humans to apply.
  
  ## Output format
  
  ```markdown
  ## Agent permission review: <agent or feature name>
  
  - **Purpose:** <one sentence>
  - **Risky combination present:** Yes / No / Unclear
  - **Overall risk (proposed):** High / Medium / Low
  
  ### Capabilities
  
  | Tool or integration | Reads | Writes or acts | Can send data out | Credential and scope | Needed for tasks? |
  | ------------------- | ----- | -------------- | ----------------- | -------------------- | ----------------- |
  
  ### Content sources
  
  | Source | Trusted / Untrusted | How it reaches the agent |
  | ------ | ------------------- | ------------------------ |
  
  ### Risky combination check
  
  - Private data access: <tools>
  - Untrusted content exposure: <sources>
  - External communication: <tools>
  
  ### Injection scenarios
  
  | Untrusted source | Hidden instruction example | Possible outcome with current tools |
  | ---------------- | -------------------------- | ----------------------------------- |
  
  ### Autonomy
  
  | Action | Read-only / Reversible / Destructive | Human approval required? |
  | ------ | ------------------------------------ | ------------------------ |
  
  ### Recommendations
  
  | #   | Recommendation | Risk reduced | Effort | Owner to decide |
  | --- | -------------- | ------------ | ------ | --------------- |
  
  ### Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Single tools that combine all three risky capabilities, such as one integration that reads private repositories, reads public issues and creates pull requests.
  - Hidden channels for sending data out: rendered images or links, web fetches, comments, commit messages, tickets visible to outsiders.
  - Relying on guardrail or detection filters as the main defence.
  - Agents running with a person's full credentials instead of a scoped identity.
  - Memory or retrieved context that can be poisoned by earlier untrusted input.
  - Configuration described in documents that differs from what is actually deployed. Say which one you reviewed.
  - Never reproduce secrets, tokens, credentials or personal data from configs, logs or documents in the output; refer to them by location and type, and tell the user to rotate anything exposed.
  
  ## Before you finish
  
  - [ ] Every tool, content source and credential is listed with its scope.
  - [ ] The risky combination check is completed across all tools together.
  - [ ] Every action is classified and its approval requirement stated.
  - [ ] No secret values were requested or recorded, and no configuration was changed.
  - [ ] Clearly flag your assumptions, whether you reviewed documented or deployed configuration, and the risk acceptance decisions a human must make.