Skip to content

vulnerability-disclosure-policy.md

Latest commit

 

History

History
113 lines (86 loc) · 4.79 KB

vulnerability-disclosure-policy.md

File metadata and controls

113 lines (86 loc) · 4.79 KB

Vulnerability Disclosure Policy

Version: 1.0 (2026-02-25)

This policy describes how reporters can disclose security vulnerabilities to the Cloud Security Alliance (CSA). It mirrors the categories listed at the CSA security page.

Scope

CSA accepts reports for the following assets:

  • Websites and services — cloudsecurityalliance.org, csachapter.io, star.watch, webfinger.io, hosted portals, and first-party APIs.
  • Software — Repositories under the CloudSecurityAlliance GitHub organization, MCP servers and clients, SDKs, and extensions.
  • AI prompts and instructions — CSA-published prompts, guardrails, skills, and system instructions, including those embedded in MCP servers and clients.

Issues involving third-party platforms, general AI model behavior with no CSA artifact, or infrastructure we do not control are out of scope.

How to report

Select the intake channel based on where you found the issue:

  • GitHub Private Vulnerability Reporting (PVR) — Preferred for software and repo-hosted AI artifacts. Open the repository’s Security tab, choose Report a vulnerability, and provide details. GitHub requires you to be logged in; your GitHub account will appear on the advisory if it is published.
  • Email — security@cloudsecurityalliance.org. Use this for websites, services, or AI artifacts published outside GitHub. Include reproduction details, impact, and whether you wish to be credited. This channel supports anonymous or pseudonymous submissions and PGP on request.

Please describe the vulnerability, reproduction steps, affected assets or versions, and potential impact. Proof-of-concept material is welcome when it can be shared safely.

Disclosure model and SLAs

CSA practices coordinated disclosure with a bias toward openness:

  • Acknowledgment: We reply within five business days via the channel used for submission.
  • Status updates: We provide updates at least every 30 days while a case is active.
  • Remediation or disclosure target: We aim to resolve or coordinate publication within 90 days of acknowledgment unless a different timeline is mutually agreed.

Advisories for software are typically published through GitHub quickly, even if a fix is still in progress. Website and service issues may result in public updates or private coordination depending on sensitivity. Extensions beyond 90 days require mutual agreement documented in the case record. See the governance framework and SLA commitments for more detail.

Identifiers and credit

  • Software advisories receive a GHSA identifier automatically and may also include a CVE ID requested via GitHub. GitHub credits the reporter’s GitHub account unless they request otherwise before publication.
  • Website and service issues may be summarized in public updates without a GHSA record. Credit is generally not published for these assets.
  • Email submissions for software can receive credit if both parties agree, typically using the reporter’s GitHub handle.

No bug bounties

CSA is a nonprofit organization and does not offer monetary rewards for vulnerability reports.

Safe harbor

CSA supports good-faith security research. Researchers acting in alignment with this policy will not face legal action from CSA, provided they:

  • Demonstrate impact without unnecessary exploitation or service disruption.
  • Avoid accessing or retaining more data than required to explain the issue.
  • Report the vulnerability promptly to CSA and keep details confidential until we reach a coordinated disclosure decision.

Out of scope

The following are out of scope for this program:

  • Third-party services CSA uses (e.g., GitHub itself, authentication providers, CDNs, hosting vendors).
  • Social engineering attacks against CSA staff or volunteers.
  • Denial of service without demonstrated security impact.
  • Automated scanner output without a validated proof of concept.
  • Issues in upstream dependencies that are already public (report upstream or via Dependabot alerts instead).
  • General model behavior observations without a CSA-attributable AI artifact.

Related resources