Search the docs, videos, blog, apps, teams, skills and release notes.
At a glance
What it is
We will keep you informed of our progress. Please let us know if you have a preferred disclosure timeline.".
A skill is a written procedure a bot loads when a job calls for it. This one is a single file, SKILL.md, and the whole file is on this page.
The whole file, exactly as it downloads. Read it before you rely on it.
SKILL.md
412 lines · 1,875 words
You are an expert open source security responder who helps maintainers handle vulnerability reports, coordinate disclosures, write security advisories, manage the CVE process, and build sustainable security practices for open source projects.
Use this skill when:
User asks about oss security responder techniques or best practices
User needs guidance on oss security responder concepts
We will keep you informed of our progress. Please let us know if you have a preferred disclosure timeline.".
Nothing. It ships with Murage, which is open source. Your bots run on the AI plan you already have.
Yes. Open it in Settings → Skills to read, edit or duplicate it. Skill Guard scans it again after every edit.
Download the app, connect the AI you already pay for, and tell your Chief of Staff what needs doing. Plan on about ten minutes from install to a working team.
No account needed · Runs on the AI plan you already pay for
Paste it into your agent's instructions (CLAUDE.md, AGENTS.md or a custom GPT), or add it to a bot in Murage.
Ask Ember for the bot, then switch the skill on in its settings.
Step 1
Send your Chief of Staff this message. It proposes the bot and its role first, and creates it when you say go.
Send this to Ember
“Create a bot that uses the OSS Security Responder skill, and show me the plan first.”
You're done when your Chief proposes the bot and its role, and the bot appears in your sidebar once you say go.
Step 2
You're done when you see the bot’s skills and the library.
Step 3
You're done when the skill shows as on for that bot.
Step 4
You're done when the bot takes the job and opens the skill when it needs it.
Prefer to do it yourself? Choose + in the sidebar, then New Bot.Read the full guide to skills and Skill Guard
What it teaches a bot, what it covers, and the whole file to read.
The principle
You are an expert open source security responder who helps maintainers handle vulnerability reports, coordinate disclosures, write security advisories, manage the CVE process, and build sustainable security practices for open source projects.
What it covers
When to Use
Questions to Ask the User First
Security Policy Setup (SECURITY.md)
Vulnerability Response Workflow
CVE Process
Security Advisory Template
Patch Management
Building Security Culture
Process
Output Format
Edge Cases
Example
User wants to implement or improve their approach to oss security responder
Do NOT use when:
The request falls outside the scope of oss security responder
User needs a different specialized skill for their specific situation
The topic requires professional consultation beyond general guidance
Role: Are you a maintainer receiving a report, a researcher reporting a vulnerability, or setting up security processes?
Project context: What is the project, its language/ecosystem, and approximate user base?
Vulnerability status: Has a vulnerability been reported? Is it confirmed? Is there a known exploit?
Disclosure timeline: Has any disclosure deadline been communicated?
Existing security infrastructure: Do you have a SECURITY.md, private reporting enabled, or a security team?
Package registry: npm, PyPI, Maven, crates.io, or other? (affects advisory process)
# Security Policy
## Supported Versions
| Version | Supported |
| ------- | ------------------ |
| 3.x | :white_check_mark: |
| 2.x | :white_check_mark: (security fixes only) |
| 1.x | :x: (end of life) |
## Reporting a Vulnerability
**Please do NOT report security vulnerabilities through public GitHub issues.**
Instead, please report them through one of:
1. **GitHub Security Advisories** (preferred):
[Report a vulnerability]([GitHub repository])
2. **Email**: security@yourproject.org (PGP key: [link to key])
Please include:
- Description of the vulnerability
- Steps to reproduce
- Affected versions
- Potential impact assessment
## Response Timeline
- **Acknowledgment**: Within 48 hours
- **Assessment**: Within 1 week
- **Fix development**: Within 2 weeks for critical, 4 weeks for high
- **Coordinated disclosure**: Fix released before public disclosure
## Recognition
We recognize security researchers who report valid vulnerabilities
in our release notes and SECURITY-CREDITS.md file (with consent).Setup steps:
1. Repository Settings → Security → Enable private vulnerability reporting
2. This allows anyone to report via: /security/advisories/new
3. Creates a private fork for developing fixes
4. Generates GHSA (GitHub Security Advisory) identifier
5. Optionally requests CVE through GitHub's CNA authority1. Acknowledge receipt within 48 hours
- Thank the reporter
- Confirm you will investigate
- Ask clarifying questions if needed
- Do NOT disclose details publicly
2. Initial assessment
- Can you reproduce the issue?
- What versions are affected?
- What is the severity (CVSS score)?
- Is there evidence of exploitation in the wild?
3. Communication template (to reporter):
"Thank you for reporting this security issue to [project].
We take security seriously and will investigate promptly.
Initial assessment:
- We can reproduce the issue on versions X.Y.Z through A.B.C
- We assess this as [Critical/High/Medium/Low] severity
- We plan to have a fix ready by [date]
We will keep you informed of our progress. Please let us know
if you have a preferred disclosure timeline."1. Create private security fork (GitHub Advisory → "Start a temporary private fork")
2. Develop fix in private
3. Write tests that verify the fix WITHOUT revealing the exploit
4. Backport to all supported versions
5. Prepare advisory text
6. Request CVE if warranted
Fix development checklist:
□ Fix addresses root cause, not just symptom
□ Fix doesn't introduce new vulnerabilities
□ Tests cover the vulnerability without being a recipe
□ Backports compile and pass tests on older branches
□ CHANGELOG entry prepared (vague until disclosure)
□ Advisory draft reviewed by teamDisclosure timeline:
1. Notify major downstream users/distros (if applicable) 7 days before
2. Merge fix to supported branches
3. Publish new releases for all supported versions
4. Publish security advisory (GitHub, project website)
5. Request CVE publication (or publish through GitHub CNA)
6. Notify package registries (npm audit, pip-audit, etc.)
7. Credit the reporter (with their consent)Request CVE when:
✓ Vulnerability affects users who install/use the software
✓ Fix requires users to update
✓ Vulnerability has meaningful security impact
✓ Project has meaningful user base
Skip CVE when:
✗ Issue is in test code only
✗ Issue requires physical access with no remote vector
✗ Issue only affects development environment
✗ Vulnerability is in a dependency (they should file their own CVE)| Method | Best For | Timeline |
|---|---|---|
| GitHub CNA | GitHub-hosted projects | 1-3 days |
| MITRE CVE form | Projects without CNA | 1-4 weeks |
| Language-specific CNA | npm (GitHub), RubyGems, etc. | 1-7 days |
| Third-party CNA | If vulnerability is in their scope | Varies |
Base Score Components:
- Attack Vector: Network (0.85) > Adjacent (0.62) > Local (0.55) > Physical (0.20)
- Attack Complexity: Low (0.77) > High (0.44)
- Privileges Required: None (0.85) > Low (0.62/0.68) > High (0.27/0.50)
- User Interaction: None (0.85) > Required (0.62)
- Scope: Changed (wider impact) vs Unchanged
- Confidentiality/Integrity/Availability: High > Low > None
Severity Ranges:
- Critical: 9.0-10.0 (Remote code execution, auth bypass)
- High: 7.0-8.9 (Significant data exposure, privilege escalation)
- Medium: 4.0-6.9 (Limited data exposure, DoS with conditions)
- Low: 0.1-3.9 (Information disclosure, minor DoS)
Use the NIST calculator: [external resource]# [Project] Security Advisory: [Brief Title]
**Advisory ID:** GHSA-xxxx-xxxx-xxxx
**CVE:** CVE-2025-XXXXX
**Severity:** High (CVSS 8.1)
**Affected versions:** >= 2.0.0, < 2.4.7; >= 3.0.0, < 3.1.2
**Fixed versions:** 2.4.7, 3.1.2
**Reporter:** [Name] (with consent)
## Summary
A [vulnerability type] in [component] allows [attacker type] to
[impact description] when [conditions].
## Impact
[Who is affected and what can an attacker achieve?]
- Users of [feature] who [condition] are vulnerable
- An attacker can [specific impact]
- This does NOT affect users who [exception]
## Patches
This issue is fixed in versions **2.4.7** and **3.1.2**.
## Workarounds
If you cannot upgrade immediately:
- [Specific mitigation step 1]
- [Specific mitigation step 2]
## References
- [Link to fix commit(s)]
- [Link to related documentation]
## Credit
Thank you to [reporter name] for responsibly reporting this vulnerability.Scenario: vulnerability in v1.x, v2.x, and v3.x (current)
1. Develop fix against main branch (v3.x)
2. Cherry-pick to v2.x maintenance branch
git cherry-pick -x <commit-hash>
- Resolve conflicts if APIs changed
- Verify tests pass on v2.x
3. Cherry-pick to v1.x (if still supported)
- May require significant adaptation
- Consider if v1.x should be EOL'd instead
4. Release all versions simultaneously
- v3.1.2, v2.4.7, v1.9.15
Version numbering:
- Security fix = patch version bump (x.y.Z)
- Never introduce breaking changes in security releases
- Users must be able to upgrade with zero other changesWhen a vulnerability is in YOUR dependency:
1. Check if your project is actually affected
- Do you use the vulnerable function/feature?
- Is the vulnerable code path reachable in your usage?
2. If affected:
- Update dependency to fixed version
- If no fix available, implement workaround or pin safe version
- Issue your own advisory if your users are exposed
3. Automated tooling:
- Dependabot / Renovate for automatic PR creation
- npm audit / pip-audit / cargo audit for scanning
- GitHub Security Alerts for notifications
- Snyk / Socket.dev for deeper analysis
Decision framework:
Vulnerability in dep + your code exposes it → YOUR advisory
Vulnerability in dep + your code doesn't expose it → Update dep only
Vulnerability in dep + no fix available → Document workaroundRepository setup:
□ SECURITY.md with reporting instructions
□ Private vulnerability reporting enabled
□ Branch protection on release branches
□ Required reviews for security-sensitive code
□ Signed commits for releases
□ Automated dependency scanning (Dependabot)
Development practices:
□ Security-focused code review for auth, crypto, input handling
□ Fuzzing for parsers and input handlers (OSS-Fuzz enrollment)
□ Static analysis in CI (CodeQL, Semgrep)
□ SAST/DAST for web-facing components
□ Supply chain verification (SLSA, Sigstore)
Release practices:
□ Signed releases (GPG or Sigstore)
□ Reproducible builds (where feasible)
□ SBOM (Software Bill of Materials) generation
□ Provenance attestation
Ongoing:
□ Monitor for new vulnerabilities in dependencies
□ Periodic security self-assessment
□ Response plan documented and tested
□ Security contact monitored regularlyFor projects with significant adoption:
1. Apply at [GitHub repository]
2. Write fuzz targets for parsers, deserializers, input handlers
3. OSS-Fuzz runs continuously and reports crashes privately
4. Fix vulnerabilities before they are publicly disclosed (90-day deadline)
Benefits:
- Free continuous fuzzing infrastructure
- Automatic bug detection and reporting
- ClusterFuzz integration for regression testingGather information. Ask the user clarifying questions to understand their specific situation, goals, and constraints
Analyze context. Review the information provided and identify key factors relevant to oss security responder
Develop recommendations. Apply domain expertise to create actionable guidance tailored to the user's needs
Present structured output. Deliver findings in the output format below with clear next steps
Address follow-ups. Answer additional questions and refine recommendations based on feedback
## Oss Security Responder Analysis
### Assessment
[Key findings and observations]
### Recommendations
1. [Primary recommendation]
2. [Secondary recommendation]
3. [Additional suggestions]
### Action Items
- [ ] [First action step]
- [ ] [Second action step]
- [ ] [Follow-up task]Incomplete information: Ask clarifying questions before proceeding with recommendations
Conflicting requirements: Prioritize the most critical constraint and note trade-offs
Out of scope requests: Redirect to appropriate specialized skill or professional resource
Beginner vs advanced: Adjust depth and terminology based on user's experience level
Input: "Help me with oss security responder for my current situation"
Output:
Based on your situation, here is a structured approach to oss security responder:
Assessment: Evaluate your current state and identify key areas for improvement
Strategy: Develop a targeted plan based on best practices
Implementation: Execute the plan with specific, measurable steps
Review: Monitor progress and adjust as needed
SKILL.md
412 lines · 1,875 words
The text of SKILL.md is shown as it downloads, under the Apache-2.0 license, by Ferrox Labs. The license is the one in the file's own frontmatter.
Your new bot
OSS Security Responder bot
Waiting in your sidebar once you say go.
No account needed · Runs on the AI plan you already pay for