This project is pre-1.0. Only the latest release receives security fixes.

Please do not open a public issue, pull request, or discussion for a security vulnerability.

Report it privately through GitHub's private vulnerability reporting. This creates a private advisory visible only to the maintainer.

Please include:

• A description of the issue and its impact
• Steps to reproduce, or a proof of concept
• The affected version and environment
• Any suggested mitigation

• Acknowledgement: within 7 days.
• Assessment: within 14 days, with a severity judgement and a rough fix timeline.
• Fix and disclosure: coordinated with you. A GitHub Security Advisory and a CVE will be published where warranted, and you will be credited unless you prefer otherwise.

This is a solo-maintained hobby project — there is no bug bounty, and response times are best effort.

In scope:

• The groupme_mcp_server package and its published distributions
• The GitHub Actions workflows and release/supply-chain configuration in this repository

Out of scope:

• Vulnerabilities in GroupMe's own API or services — report those to Microsoft/GroupMe
• Vulnerabilities in upstream dependencies — report those upstream, though please do tell us if this project's usage makes one exploitable
• Findings from automated scanners without a demonstrated impact
• Social engineering, physical access, or denial of service through resource exhaustion

This server talks to GroupMe on a user's behalf and therefore touches access tokens and private message content. When reporting or reproducing an issue:

• Never include a real GroupMe access token in a report, log, or test fixture. Redact it.
• Never include real message content, phone numbers, or user IDs.
• Credentials are supplied through environment variables only — they are never read from committed files, and .env is git-ignored.

• CodeQL code scanning (security-extended + security-and-quality) on every push, pull request, and weekly
• Secret scanning with push protection
• Dependabot alerts and weekly dependency updates
• Dependency review on pull requests, failing on moderate or higher severity
• zizmor static analysis of GitHub Actions workflows
• OpenSSF Scorecard, published weekly
• All GitHub Actions pinned to full commit SHAs
• Workflows default to permissions: {} and opt into the minimum needed
• PyPI publishing via Trusted Publishing (OIDC) with build provenance attestations — no long-lived API tokens exist for this project

Scorecard results are uploaded into GitHub code scanning, so a failing check appears alongside real findings. Scorecard reports posture advice, not vulnerabilities, and three of its checks cannot be satisfied by a solo-maintained repository. Those are dismissed as "won't fix" with reasons recorded on each alert:

Fuzzing and CII-Best-Practices are left open — they are genuinely actionable, just not yet worth doing for a project with no parsing code.

Dismissals persist across Scorecard's weekly re-runs, so anything newly open in code scanning is worth reading. If a second maintainer ever joins, revisit the first two: requiring one approval would fix both at once.