agentleFS
mick-gskmick-gsk/drift/.github/skills/drift-security-triage/SKILL.md

drift-security-triage

Skill14 starsChanged 7 months agoMITView on GitHub

Security report triage workflow for drift. Use when evaluating incoming vulnerability reports, GitHub Security Advisories, or Dependabot alerts.

  • Installs packages

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the report matches any of these → respond with the out-of-scope template (Step 5).

    line 46
  2. Very specific:

    Check if the vulnerable dependency is in [project.dependencies] (runtime) or [project.optional-dependencies.dev] (dev-only)

    line 105
  3. Very specific:

    Update via pip install --upgrade <package> → regenerate uv.lock → test → release

    line 108

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Drift Security Triage Skill

Purpose

Guide Copilot agents through consistent, policy-aligned triage of security reports for the drift repository.

When to Use

  • Evaluating a new GitHub Security Advisory (GHSA)
  • Triaging a vulnerability report submitted via email or private advisory
  • Assessing Dependabot security alerts
  • Responding to CodeQL or detect-secrets findings

Triage Workflow

Step 1: Trust Model Check

Drift operates under the same trust level as local shell access. Before classifying severity, determine:

  1. Does the vulnerability require prior write access to the target repository? → If YES: likely out of scope (attacker already has equal privileges).
  2. Does drift execute any analyzed code? → No. drift uses ast.parse() and tree-sitter for parsing — no code execution.
  3. Does drift make network requests? → No. drift is fully local — no exfiltration vector exists.

Step 2: Out-of-Scope Classification

The following are explicitly NOT vulnerabilities in drift (see SECURITY.md):

CategoryReason
Malicious source files causing misleading findingsSame trust boundary — attacker already has write access
Resource exhaustion on huge repositoriesOperational concern, not a vulnerability
Static analysis false positivesSignal quality issue — use false-positive template
Secret-scanning baseline entriesIntentional test fixtures with non-reversible hashes
Git history tamperingHistory integrity is the repo owner's responsibility

If the report matches any of these → respond with the out-of-scope template (Step 5).

Step 3: Severity Assessment

For in-scope vulnerabilities, assess using CVSS v3.1 principles:

Factordrift-specific consideration
Attack vectorAlways Local (drift requires file system access)
Privileges requiredAt minimum Low (read access to target repo)
User interactionTypically Required (user must invoke drift)
ScopeUnchanged (drift cannot escape its process boundary)
Confidentialitydrift reads files user already has access to — typically None
Integritydrift produces reports — at most Low (misleading output)
AvailabilityResource exhaustion possible — Low to Medium

Step 4: Response Timeline

Per SECURITY.md commitments:

  • Acknowledgment: within 72 hours
  • Resolution timeline: within 7 days of acknowledgment
  • Coordinated disclosure: patch before public disclosure

Step 5: Response Templates

Out-of-Scope Response

Thank you for your report. After review against our [Trust Model](SECURITY.md#trust-model),
this finding falls outside drift's security scope:

**Category:** [category from out-of-scope table]
**Reason:** [specific reason]

drift operates at the same trust level as local shell access. [Brief explanation
of why this specific scenario is not a vulnerability.]

If you believe this assessment is incorrect, please provide additional context
about an attack scenario that does not require prior repository write access.

In-Scope Acknowledgment

Thank you for your security report. We've confirmed this is within drift's
security scope and are investigating.

**Tracking:** [internal reference / GHSA ID]
**Severity assessment:** [Low/Medium/High/Critical]
**Expected resolution timeline:** [date]

We follow coordinated disclosure and will notify you before any public advisory.

Dependabot Alert Triage

For dependency vulnerabilities:

  1. Check if the vulnerable dependency is in [project.dependencies] (runtime) or [project.optional-dependencies.dev] (dev-only)
  2. Dev-only dependencies have reduced severity (not shipped to users)
  3. Runtime dependencies affecting drift's actual usage patterns are high priority
  4. Update via pip install --upgrade <package> → regenerate uv.lock → test → release

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.