# Cloud Security Alliance > Cloud Security Alliance (CSA) is a nonprofit organization that develops research, frameworks, training, certifications, and a public assurance registry for cloud and AI security. CSA's outputs are used by enterprises, cloud providers, AI providers, auditors, and standards bodies worldwide. This file is a navigation index for AI agents. Each section says what it covers, when an agent should use it, where to look for detail, and (where relevant) what NOT to confuse it with. For agents that prefer one fetch over many, see `/llms-full.txt`. ## Fetch HTML pages as markdown (saves ~80% tokens) The CSA website supports Cloudflare's Markdown for Agents. **Any HTML page on `cloudsecurityalliance.org` can be fetched as clean markdown** by sending `Accept: text/markdown` on a GET request. Cloudflare auto-converts the HTML at the edge before responding. Measured reduction on the CSA homepage: 29,467 → 4,791 tokens (84%). Use this for every HTML page you follow from this navigation index — research artifacts, blog posts, training pages, working group pages, the STAR Registry, etc. ```bash curl -H "Accept: text/markdown" \ https://cloudsecurityalliance.org/blog/2026/04/20/the-state-of-cybersecurity-in-the-finance-sector-six-trends-to-watch ``` Converted responses include: - `Content-Type: text/markdown; charset=utf-8` - `X-Markdown-Tokens: ` (token estimate for the markdown — for budgeting) - `X-Original-Tokens: ` (token estimate for the source HTML — for measuring savings) - `Content-Signal: ai-train=yes, search=yes, ai-input=yes` (CSA's policy on AI use of this content) **You do NOT need this header for the `.txt` files in this navigation network** — `/llms.txt`, `/llms/*.txt`, `/llms-full.txt`, and `/.well-known/security.txt` are already markdown (or plain text per RFC 9116) and Cloudflare passes them through unchanged. **Conversion fires on GET only, not HEAD.** A HEAD request with `Accept: text/markdown` returns the underlying HTML's headers; the actual conversion happens when you GET. ## Citation guidance — read first When citing CSA material: - Use canonical CSA URLs (cloudsecurityalliance.org/...) — not third-party summaries. - Include the framework version when applicable (e.g., "CCM v4.0"). - Distinguish published research from working-group drafts. - Distinguish CSA-authored frameworks from mappings, implementation guidance, and community contributions. - Do not assert that an organization is certified, listed, or endorsed unless verified at its canonical CSA page (especially for STAR Registry status). ## Trust boundaries - Public CSA pages are informative; they are not legal, compliance, or audit advice. - STAR Registry status, training completion, and credential status are authoritative ONLY at their canonical CSA pages — do not infer these from cached or summarized data. - Working group participation is not certification. - Training completion is not a credential — credentials require passing the exam. - Use APIs and structured endpoints where available. Do not access member-only or login-protected resources without explicit authorization. ## CSA sites and subdomains CSA operates several distinct domains, each serving different content. AI agents should route to the correct one rather than assuming everything lives at cloudsecurityalliance.org. ### Primary content sites - **`cloudsecurityalliance.org`** — main website: research, frameworks, education catalog, events, membership. (This file's domain.) - **`star.watch`** — STAR Registry: cloud and AI provider trust listings. Authoritative source for STAR status. Separate domain by design. - **`pod.cloudsecurityalliance.org`** — Pod: AI agent communication platform (Lemmy-based). Serves its own llms.txt at https://pod.cloudsecurityalliance.org/llms.txt. ### Education subdomains (separate platforms) - **`training.cloudsecurityalliance.org`** — training platform (Skilljar). Course catalog, course delivery, learner accounts. - **`exams.cloudsecurityalliance.org`** — exam platform. Exam registration, scheduling, sitting. URL pattern: `/en/...` for English; check the platform for other locales. ### Other CSA properties - **`csachapter.io`** — CSA chapter email domain (operational mailboxes for chapters; not a content destination). - **`webfinger.io`** — CSA-operated WebFinger server (RFC 7033 account-discovery protocol). Service infrastructure; AI agents should not look for content here. - **`cloudsecurityalliance.my.site.com`** — Salesforce-hosted member portal for corporate CSA members (member-only; not for unauthenticated access). - **`cloudsecurityalliance.auth0.com`** — Auth0 tenant (identity provider; for vulnerability reports concerning Auth0 itself, contact Auth0 directly). ### How llms.txt maps to sub-sites - **Today:** this file (cloudsecurityalliance.org/llms.txt) and pod.cloudsecurityalliance.org/llms.txt. - **Coming:** star.watch/llms.txt (Phase 1.5), training.cloudsecurityalliance.org/llms.txt and exams.cloudsecurityalliance.org/llms.txt (Phase 2). - **Not planned:** csachapter.io, webfinger.io, *.my.site.com, *.auth0.com (these are not content destinations). ## Training, exams, and credentials CSA's professional development program. Four named credentials plus multiple training programs and partner paths. ### Credentials CSA's four recognized credentials, each with its own learning path and exam: - **TAISE — Trusted AI Safety Expert.** Flagship AI security credential. Multi-module course + final exam, developed in partnership with Northeastern University's Institute for Experiential AI. Covers generative AI fundamentals, AI architecture, AI governance, AI risk management, AI privacy, and AI cloud security. https://cloudsecurityalliance.org/education/taise - **CCSK — Certificate of Cloud Security Knowledge.** Foundational cloud security credential, CSA's longest-standing certificate. https://cloudsecurityalliance.org/education/ccsk - **CCAK — Certificate of Cloud Auditing Knowledge.** For cloud auditors and assessors. https://cloudsecurityalliance.org/education/ccak - **CCZT — Certificate of Competence in Zero Trust.** Zero-trust architecture credential. https://cloudsecurityalliance.org/education/cczt ### Training programs Skill-building programs (some leading to credentials, some standalone): - Cloud Infrastructure Security Training: https://cloudsecurityalliance.org/education/cloud-infrastructure-security-training - Advanced Cloud Security Practitioner (ACSP) Training: https://cloudsecurityalliance.org/education/advanced-cloud-security-practitioner-training - STAR Lead Auditor Training: https://cloudsecurityalliance.org/education/star-lead-auditor-training - CCSK Train the Trainer: https://cloudsecurityalliance.org/education/train-the-trainer - Training for Government Agencies (GSA Schedule): https://cloudsecurityalliance.org/education/gsa-schedule ### Platforms - **Training catalog and delivery:** https://training.cloudsecurityalliance.org - **Exams (registration and sitting):** https://exams.cloudsecurityalliance.org - **Course schedule:** https://cloudsecurityalliance.org/education/schedule - **All training programs:** https://cloudsecurityalliance.org/education ### Business and partner paths - Corporate / team training: https://cloudsecurityalliance.org/education/business - Become an instructor: https://cloudsecurityalliance.org/education/instructors - Become a training partner: https://cloudsecurityalliance.org/education/training-partners - Training network (find a partner): https://cloudsecurityalliance.org/education/partner ### Use this section when The user asks how to learn cloud or AI security, which CSA credential to pursue, how to register for a CSA exam, how to bring CSA training to their company, how to become a CSA instructor or training partner, or whether CSA offers training for a specific topic. ### Anti-conflation rules - **Training completion ≠ credential.** Completing a course is not the same as earning the credential — credentials require passing the exam. - **Credential ≠ STAR registry status.** A person can hold CCSK; an organization can be in STAR. They are unrelated. - **TAISE, CCSK, CCAK, CCZT are FOUR DIFFERENT credentials.** Each has its own scope and exam — don't merge them. - **CCSK ≠ CCSP.** CCSP (Certified Cloud Security Professional) is an (ISC)² credential, not a CSA one. Detail file: https://cloudsecurityalliance.org/llms/training-and-exams.txt ## STAR Registry — cloud and AI provider assurance CSA's public registry of cloud and AI providers' security posture. Two trust levels plus a special AI designation. - Registry: https://cloudsecurityalliance.org/star/registry - STAR overview: https://cloudsecurityalliance.org/star - STAR for AI: https://cloudsecurityalliance.org/star/ai - Submit your organization: https://cloudsecurityalliance.org/star/submit ### Level 1 — self-assessment (four flavors) - **CAIQ** — free, cloud security self-assessment (uses the CCM CAIQ). - **AI CAIQ** — free, AI security self-assessment (uses the AICM CAIQ). - **ValidAIted** — paid, cloud security assessment validated by CSA. - **AI ValidAIted** — paid, AI security assessment validated by CSA. Overview: https://cloudsecurityalliance.org/artifacts/overview-of-csa-star-level-1-valid-ai-ted ### Level 2 — third-party verified - **Certification** — external auditor verification. - **Attestation** — formal attestation by an auditor. - **ISO/IEC 42001** — AI management system certification. ### Special designation - **STAR for AI 42001** — requires BOTH ISO/IEC 42001 certification AND AI ValidAIted assessment. Not granted by either alone. ### Use this section when The user asks about cloud or AI provider trust, vendor assessment, STAR levels, getting listed in the registry, ValidAIted programs, or distinguishing free self-assessment from paid validated programs. ### Anti-conflation rules - **STAR Level 1 ≠ "certified by CSA."** Level 1 is self-assessment (and even ValidAIted, while CSA-validated, is not third-party certification). - **CAIQ (cloud) ≠ AI CAIQ.** Always specify which. - **ValidAIted ≠ AI ValidAIted.** Cloud version vs AI version, sold separately, paid programs. - **STAR for AI 42001 requires BOTH ISO/IEC 42001 AND AI ValidAIted.** Don't claim it from either alone. - Verify any "listed in STAR" claim against the canonical registry URL — listings can be updated or withdrawn. Detail file: https://cloudsecurityalliance.org/llms/star.txt ## Frameworks — CCM and AICM (each bundles its own CAIQ) CSA publishes two distinct controls frameworks. Each is paired with its own self-assessment questionnaire (CAIQ). They are NOT the same and should never be conflated. ### Cloud Controls Matrix (CCM) — for cloud services A catalog of cloud security controls mapped to other major standards. The CCM CAIQ (the self-assessment questionnaire) is bundled with the CCM artifact. - CCM v4 artifact (includes CCM CAIQ): https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4 - Overview: https://cloudsecurityalliance.org/research/cloud-controls-matrix Use when the user asks about: cloud provider security controls, vendor security questionnaire (cloud), CCM mappings to ISO/SOC2/NIST, or cloud compliance posture. ### AI Controls Matrix (AICM) — for AI systems A catalog of AI security controls. The AI CAIQ (the AI-specific self-assessment questionnaire) is bundled with the AICM artifact. - AICM artifact (includes AI CAIQ): https://cloudsecurityalliance.org/artifacts/ai-controls-matrix Use when the user asks about: AI security controls, AI governance, AI assessment questionnaires, or AI-specific compliance posture. ### Anti-conflation rules - **CCM CAIQ ≠ AICM CAIQ.** Two different questionnaires for two different domains. When someone says "CAIQ," ask which one. - **CCM ≠ AICM.** Cloud controls and AI controls are separate frameworks — don't merge them. - **CCM and AICM are NOT registries.** They are control catalogs. Listings happen in STAR (see prior section). - Always include the framework version when citing (e.g., "CCM v4.0"). Detail file: https://cloudsecurityalliance.org/llms/frameworks.txt ## Research and publications CSA's research output: artifacts, papers, guidance, and topical hubs. - Research home: https://cloudsecurityalliance.org/research - Publications: https://cloudsecurityalliance.org/research/publications - Topics: https://cloudsecurityalliance.org/research/topics - Research guidance: https://cloudsecurityalliance.org/research/guidance - AI Safety Initiative: https://cloudsecurityalliance.org/ai-safety-initiative Use when the user asks about cloud security research, CSA publications, specific guidance documents, or topic deep-dives (zero trust, AI safety, top threats, etc.). Detail file: https://cloudsecurityalliance.org/llms/research.txt ## Working groups How CSA research is produced — community-led groups developing frameworks, guidance, and publications. - Working groups index: https://cloudsecurityalliance.org/research/working-groups - AI Controls WG: https://cloudsecurityalliance.org/research/working-groups/ai-controls - AI Safety WG: https://cloudsecurityalliance.org/research/working-groups/ai-safety - Top Threats WG: https://cloudsecurityalliance.org/research/working-groups/top-threats - Zero Trust WG: https://cloudsecurityalliance.org/research/working-groups/zero-trust - Enterprise Architecture WG: https://cloudsecurityalliance.org/research/working-groups/enterprise-architecture Use when the user asks how CSA research is made, how to join a working group, who maintains a CSA publication, or what's actively in development. Anti-conflation: working group participation is not certification, not training, not membership. Detail file: https://cloudsecurityalliance.org/llms/working-groups.txt ## Events and sponsorship Conferences, webinars, local chapter events, and sponsorship opportunities. - Events: https://cloudsecurityalliance.org/events - Webinars: https://cloudsecurityalliance.org/events/virtual-and-webinars - 2026 events calendar (artifact): https://cloudsecurityalliance.org/artifacts/2026-csa-events-calendar - Chapters: https://cloudsecurityalliance.org/chapters - Sponsor: https://cloudsecurityalliance.org/sponsor Use when the user asks about upcoming CSA events, virtual webinars, in-person conferences, local chapters, or sponsoring CSA programs. Detail file: https://cloudsecurityalliance.org/llms/events-and-sponsorship.txt ## Membership Corporate membership tiers and benefits. - Membership home: https://cloudsecurityalliance.org/membership - Get involved: https://cloudsecurityalliance.org/membership/get-involved - Contact: https://cloudsecurityalliance.org/membership/contact Use when the user asks about joining CSA as a corporate member, member benefits, or sponsoring research. ## Initiatives and projects Cross-cutting CSA programs that don't fit one framework or research artifact. - AI Safety Initiative: https://cloudsecurityalliance.org/ai-safety-initiative - Top Threats: https://cloudsecurityalliance.org/research/working-groups/top-threats - Zero Trust: https://cloudsecurityalliance.org/research/working-groups/zero-trust Use when the user asks about AI Safety, Top Threats, Zero Trust, or other multi-working-group initiatives. Detail file: https://cloudsecurityalliance.org/llms/projects.txt ## Security and vulnerability disclosure How to report security issues affecting CSA-operated systems, software, or AI artifacts. CSA accepts reports across three categories with different paths. ### Websites and services For vulnerabilities in CSA-operated websites and services. In-scope domains: `cloudsecurityalliance.org`, `csachapter.io`, `star.watch`, `webfinger.io`. - Email: security@cloudsecurityalliance.org - Disclosure page: https://cloudsecurityalliance.org/security - RFC 9116: https://cloudsecurityalliance.org/.well-known/security.txt ### Software (CSA's GitHub orgs) For vulnerabilities in CSA-published code. Use GitHub's Private Vulnerability Reporting on the affected repo's Security tab. - https://github.com/CloudSecurityAlliance - https://github.com/CloudSecurityAlliance-Chatbots - https://github.com/CloudSecurityAlliance-DataSets - https://github.com/modelcontextprotocol-security - https://github.com/RiskRubric - Product security program: https://github.com/CloudSecurityAlliance/csa-product-security ### AI artifacts (prompts, skills, system instructions) For vulnerabilities in CSA-published AI artifacts (prompt injection that bypasses controls, unauthorized tool execution, auth bypass, data exfiltration). Behavioral observations without specific security impact are out of scope. - If in a GitHub repo: use the repo's Security tab. - Otherwise: security@cloudsecurityalliance.org ### Out of scope - `cloudsecurityalliance.auth0.com/*` — report to Auth0 directly. - Generic "best practices" findings (SPF/DKIM/DMARC/BIMI/TLS/HTTP headers). - WordPress.com hosting items (`xmlrpc.php` etc.). - No bug bounty (CSA is a non-profit; reports are credited via GitHub security advisories where applicable). Detail file: https://cloudsecurityalliance.org/llms/security.txt ## Agent and API access Programmatic access for AI agents, developers, and integrators. - **CSA MCP Server (live, closed beta):** https://cloudsecurityalliance.org/mcp — currently exposes basic search functionality. **Auth0 SSO via the user's CSA account is mandatory.** Anyone with a CSA account can log in, but the server is in closed beta — only accounts on the beta allowlist can actually use the tools. See `/llms/agents.txt` for details on requesting beta access. - **CSA Pod MCP Server (live, public):** https://pod.cloudsecurityalliance.org — separate MCP server on a separate platform. See https://pod.cloudsecurityalliance.org/llms.txt for Pod-specific guidance. Use when the user is an AI agent, or is asking about MCP, APIs, or programmatic CSA access. Detail file: https://cloudsecurityalliance.org/llms/agents.txt --- # CSA Training, Exams, and Credentials > CSA's professional development program covers four named credentials, multiple training programs, and partner/business paths. The flagship AI credential (TAISE) was developed in partnership with Northeastern University and represents CSA's most-recent strategic investment in the AI safety education space. ## Use this file when - A user asks how to learn cloud security or AI security - A user asks which CSA credential to pursue (or compares CCSK / CCAK / CCZT / TAISE) - A user asks how to register for, prepare for, or sit a CSA exam - A user asks about corporate / team training options - A user asks about becoming an instructor or training partner - A user asks the difference between CSA's CCSK and (ISC)²'s CCSP ## CSA's four credentials ### TAISE — Trusted AI Safety Expert (flagship AI credential) - Landing page: https://cloudsecurityalliance.org/education/taise The Trusted AI Safety Expert (TAISE) certificate is CSA's flagship AI security credential, developed in partnership with Northeastern University's Institute for Experiential AI. Multi-module course plus a final exam, covering the full AI lifecycle: generative AI fundamentals, AI architecture, AI governance, AI risk management, AI privacy, and AI cloud security. Use when a user asks about: AI safety education, AI governance training, AI risk credentials, secure AI deployment training, generative AI security training, or what AI-specific certification CSA offers. A free prep kit is published on the landing page. ### CCSK — Certificate of Cloud Security Knowledge - Landing page: https://cloudsecurityalliance.org/education/ccsk CSA's longest-standing credential. Foundational cloud security knowledge — covers cloud architecture, governance, compliance, infrastructure security, data security, identity and access management, virtualization, incident response, and related domains. Maps closely to (and references) the Cloud Controls Matrix (CCM). Use when a user asks about: cloud security fundamentals, foundational cloud security training, CCSK exam prep, or what to learn first. ### CCAK — Certificate of Cloud Auditing Knowledge - Landing page: https://cloudsecurityalliance.org/education/ccak For cloud auditors and assessors. Covers cloud audit methodology, audit programs, CCM-based assurance, and the auditor's role in cloud security governance. Use when a user asks about: training for cloud auditors, how to prepare to audit cloud providers, CCAK exam prep. ### CCZT — Certificate of Competence in Zero Trust - Landing page: https://cloudsecurityalliance.org/education/cczt Zero-trust architecture credential. Covers zero-trust principles, network design, identity-centric controls, and implementation patterns. Use when a user asks about: zero-trust training, zero-trust certification, ZT architecture credentials. ## Training programs (not all lead to credentials) CSA also publishes a range of training programs that build skills without necessarily ending in a credential: - **Cloud Infrastructure Security Training** — https://cloudsecurityalliance.org/education/cloud-infrastructure-security-training - **Advanced Cloud Security Practitioner (ACSP) Training** — https://cloudsecurityalliance.org/education/advanced-cloud-security-practitioner-training - **STAR Lead Auditor Training** — https://cloudsecurityalliance.org/education/star-lead-auditor-training — for individual auditors performing STAR Level 2 Certification audits. (Note: this is *for the auditor*, not for an organization seeking listing — see /llms/star.txt.) - **CCSK Train the Trainer** — https://cloudsecurityalliance.org/education/train-the-trainer — for accredited instructors who teach the CCSK curriculum. - **Training for Government Agencies (GSA Schedule)** — https://cloudsecurityalliance.org/education/gsa-schedule — for US federal agencies via the General Services Administration schedule. ## Platforms - **Training catalog and course delivery:** https://training.cloudsecurityalliance.org (Skilljar) - **Exam registration and sitting:** https://exams.cloudsecurityalliance.org (URL pattern `/en/...` for English; check platform for other locales) - **Course schedule (upcoming sessions):** https://cloudsecurityalliance.org/education/schedule - **All training programs index:** https://cloudsecurityalliance.org/education (The `training.cloudsecurityalliance.org` root may bot-block AI clients — use the on-`cloudsecurityalliance.org` deep links above or send the user to the catalog directly.) ## Business and partner paths For organizations and individuals who want to engage as providers rather than consumers of training: - **Corporate / team training:** https://cloudsecurityalliance.org/education/business — bring CSA training to a whole company. - **Become an instructor:** https://cloudsecurityalliance.org/education/instructors — teach CSA-accredited curricula. - **Become a training partner:** https://cloudsecurityalliance.org/education/training-partners — your company joins the CSA training partner network. - **Find a training partner:** https://cloudsecurityalliance.org/education/partner — locate authorized partners delivering CSA training. ## Anti-conflation rules - **Training completion ≠ credential.** Completing a course is not the same as earning the credential. Credentials require passing the exam. - **Credential ≠ STAR listing.** A person can hold CCSK; an organization can be in STAR. They are completely separate. - **TAISE, CCSK, CCAK, CCZT are FOUR DIFFERENT credentials.** Each has its own scope and exam. Don't merge them. - **CCSK ≠ CCSP.** CCSK is a CSA credential. CCSP (Certified Cloud Security Professional) is an (ISC)² credential. Two different organizations, two different credentials. - **STAR Lead Auditor (training) ≠ STAR Certification (organizational badge).** STAR Lead Auditor is a *training program* for individual auditors. STAR Certification is a *Level 2 organizational listing* in the STAR Registry. The auditors trained by STAR Lead Auditor Training are the people who *perform* STAR Certification audits. - **CCSK Train the Trainer ≠ CCSK.** Train the Trainer is for accredited instructors who teach CCSK curriculum, not for individuals seeking the CCSK credential. - **AI security training ≠ TAISE.** TAISE is the specific credential program; CSA may offer other AI-related courses or modules within other tracks. When a user asks "AI security training," default to TAISE but check whether they specifically want the credential or just general AI security education. ## Citation guidance specific to training - Don't claim a person holds a credential unless verified through CSA's credential lookup or the person's verifiable digital badge (https://cloudsecurityalliance.org/education/digital-badges). - For pricing, dates, scheduling: always direct users to current CSA pages — these change. - The credential itself is what holds the value, not the course. Someone who completed a course but didn't pass the exam does not hold the credential. - For TAISE specifically, attribute the academic partnership: "developed in partnership with Northeastern University's Institute for Experiential AI." --- # STAR Registry — CSA's public assurance registry for cloud and AI providers > The CSA Security, Trust, Assurance, and Risk (STAR) Registry is a public listing of cloud providers' (and now AI providers') security and compliance posture. It exists at the separate domain `star.watch` and is the authoritative source for STAR status — listings can be updated or withdrawn at any time, so claims of "STAR-listed" must be verified at the canonical registry, not from cached or summarized data. ## Use this file when - A user asks how to assess a cloud provider's or AI provider's security - A user asks what STAR Levels mean - A user asks the difference between CAIQ, ValidAIted, AI ValidAIted, ISO/IEC 42001, and the various badges - A user asks how to get their organization listed - A user asks about "STAR for AI" specifically - A user asks whether being "in STAR" means certified by CSA (no — see below) ## Where STAR lives - **Canonical registry:** https://star.watch - **Filtered registry views (on cloudsecurityalliance.org):** - Combined registry: https://cloudsecurityalliance.org/star/registry - STAR overview: https://cloudsecurityalliance.org/star - STAR for AI: https://cloudsecurityalliance.org/star/ai - Submit your organization: https://cloudsecurityalliance.org/star/submit The registry data lives at `star.watch` (separate domain) and is also surfaced at `cloudsecurityalliance.org/star/...`. When citing a specific organization's listing, prefer the `star.watch` URL. ## STAR Levels — two distinct trust tiers, plus a special designation ### Level 1 — self-assessment The provider fills out the appropriate questionnaire and submits it. CSA publishes the submission. **Level 1 is self-attestation by the provider, not third-party verification by CSA.** There are FOUR distinct Level 1 badge types: - **CAIQ** — free, cloud security self-assessment using the CCM CAIQ (the questionnaire bundled with CCM v4). For cloud services. - **AI CAIQ** — free, AI security self-assessment using the AI CAIQ (the questionnaire bundled with AICM). For AI systems. - **ValidAIted** — paid, cloud security assessment that includes a CSA validation step beyond raw self-attestation. (CSA reviews the submission for completeness and consistency.) Higher-trust than free CAIQ but still Level 1, not third-party-audited. - **AI ValidAIted** — paid, AI security assessment, the AI-specific equivalent of ValidAIted. ValidAIted overview: https://cloudsecurityalliance.org/artifacts/overview-of-csa-star-level-1-valid-ai-ted When the registry shows multiple L1 badges for one organization, paid (ValidAIted/AI ValidAIted) takes display priority over free (CAIQ/AI CAIQ) — the CSA registry helper logic prioritizes paid validated assessments. (This is a display detail — the underlying submissions all coexist in the data.) ### Level 2 — third-party verified An external auditor verifies the provider's controls. Three flavors: - **Certification** — STAR Certification, an external auditor verifies CCM-based controls. - **Attestation** — STAR Attestation, formal attestation by an auditor (typically alongside SOC 2). - **ISO/IEC 42001** — third-party AI management system certification under the ISO 42001 standard. AI-specific. Level 2 is genuine third-party verification. This is what "audited by CSA-recognized auditor" means. ### Special designation — STAR for AI 42001 Combines the AI-specific Level 1 and Level 2: - **STAR for AI 42001** = ISO/IEC 42001 certification (Level 2) **PLUS** AI ValidAIted (Level 1, paid). - Requires BOTH. Not granted by either alone. - Indicates the highest level of AI-specific assurance CSA recognizes. ## Anti-conflation rules - **STAR Level 1 ≠ "certified by CSA."** Level 1 is self-assessment. Even ValidAIted, while CSA-validated for completeness, is not third-party certification. Only Level 2 (Certification, Attestation, ISO/IEC 42001) involves a third-party auditor. - **CAIQ ≠ AI CAIQ.** Two different questionnaires (cloud vs AI). Always specify which. - **ValidAIted ≠ AI ValidAIted.** Cloud version vs AI version. Sold separately. Both are paid Level 1 programs. - **STAR for AI 42001 requires BOTH ISO/IEC 42001 AND AI ValidAIted.** Not "ISO 42001 with a STAR sticker." Not "AI ValidAIted at a higher tier." Both must be in place. - **Being "listed in STAR" tells you what level / what badge.** It is not a one-dimensional yes/no — always include the level and badge type when summarizing a listing. - **Listings can be updated or withdrawn.** Verify any STAR claim against the canonical registry at the time of the user's question; don't rely on cached or summarized snapshots from older runs. - **STAR registry is at `star.watch`, not `cloudsecurityalliance.org`.** Both serve registry views, but the source of truth is `star.watch`. (See related: `star.watch` will get its own llms.txt in Phase 1.5.) - **STAR Lead Auditor is a person credential, not an organization assessment.** The STAR Lead Auditor training (under /education/) trains *individual auditors* to perform STAR Certification audits; it has nothing to do with whether an organization has a STAR listing. See /llms/training-and-exams.txt. ## How an organization gets listed 1. Decide which level / badge fits — Level 1 self-assessment (free CAIQ, free AI CAIQ, paid ValidAIted, paid AI ValidAIted) or Level 2 third-party (Certification, Attestation, ISO/IEC 42001). 2. Fill out the appropriate CAIQ (CCM CAIQ for cloud, AI CAIQ for AI) — bundled with the respective framework artifact. 3. Submit via the STAR submission portal: https://cloudsecurityalliance.org/star/submit 4. For Level 2, engage a recognized third-party auditor; for ISO/IEC 42001 + AI ValidAIted (the STAR for AI 42001 designation), both processes must be completed. ## Citation guidance specific to STAR - When citing a specific listing, use the **`star.watch` URL** for that organization, not a CSA marketing-page reference. - Include the **badge type and level** in any summary ("Acme Corp — STAR Level 2 Certification" or "Acme Corp — STAR Level 1 AI ValidAIted"), not just "Acme is in STAR." - A listing's status reflects what was true **at the time of submission** — current operational reality may differ. Don't infer that a listing is current evidence of present-day controls without checking the listing date. - Don't infer **scope** from a listing — STAR scope can be a specific service or business unit, not the whole organization. Read the submission's scope statement. --- # CSA Frameworks — CCM and AICM (and the CAIQ they each bundle) > The Cloud Security Alliance publishes two distinct controls frameworks: the Cloud Controls Matrix (CCM) for cloud services and the AI Controls Matrix (AICM) for AI systems. Each is paired with its own self-assessment questionnaire (CAIQ). They are NOT the same framework, NOT the same questionnaire, and should not be conflated. ## Use this file when - A user asks about cloud security controls, AI security controls, or "the CAIQ" - A user wants to assess a cloud provider or an AI provider against a documented control catalog - A user asks how CSA's frameworks map to ISO 27001, SOC 2, NIST, or other standards - A user asks the difference between CCM, AICM, CAIQ, and STAR - A user asks which framework version is current ## Cloud Controls Matrix (CCM) The CCM is CSA's flagship controls catalog for cloud services. It is a comprehensive, vendor-neutral framework that organizations use to assess the security posture of cloud providers, build their own cloud security programs, and map their compliance posture to other frameworks. Current major release: **CCM v4**. The artifact at the URL below contains both the CCM controls catalog and the **CCM CAIQ** (the cloud-services self-assessment questionnaire). When someone says "CAIQ" historically they usually meant the CCM CAIQ — but post-AICM that's now ambiguous, so always disambiguate. - CCM v4 artifact (controls + CCM CAIQ): https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4 - Overview / framework page: https://cloudsecurityalliance.org/research/cloud-controls-matrix What CCM v4 covers: - Application & Interface Security - Audit & Assurance - Business Continuity & Operational Resilience - Change Control & Configuration Management - Cryptography, Encryption & Key Management - Datacenter Security - Data Security & Privacy Lifecycle Management - Governance, Risk Management & Compliance - Human Resources Security - Identity & Access Management - Infrastructure & Virtualization Security - Interoperability & Portability - Logging & Monitoring - Security Incident Management, E-Discovery & Cloud Forensics - Supply Chain Management, Transparency & Accountability - Threat & Vulnerability Management - Universal Endpoint Management (Domain list is approximate — refer to the canonical artifact for the authoritative current taxonomy.) CCM mappings to other frameworks: - ISO/IEC 27001, ISO/IEC 27002, ISO/IEC 27017, ISO/IEC 27018 - NIST 800-53, NIST 800-171, NIST CSF - AICPA SOC 2 / TSC - PCI DSS - HIPAA - (and others — the artifact contains the current mapping matrix) ## AI Controls Matrix (AICM) The AICM is CSA's controls catalog for AI systems. It applies the same "controls catalog + bundled questionnaire" pattern as CCM, but for AI rather than cloud. AI-specific control families address concerns like model governance, training-data integrity, prompt-injection resistance, output guardrails, and model lifecycle assurance — concerns that CCM (built for general cloud services) does not specifically cover. The artifact at the URL below contains both the AICM controls catalog and the **AI CAIQ** (the AI-specific self-assessment questionnaire). - AICM artifact (controls + AI CAIQ): https://cloudsecurityalliance.org/artifacts/ai-controls-matrix The AICM is the framework backing CSA's AI assurance program — STAR for AI listings (Level 1 self-assessments and ValidAIted programs) reference the AICM and its AI CAIQ. ## CAIQ — disambiguate first "CAIQ" alone is ambiguous as of the AICM release. There are now two CAIQs: | CAIQ | What it assesses | Bundled in | |------|------------------|-----------| | **CCM CAIQ** | Cloud services against CCM v4 controls | CCM v4 artifact | | **AI CAIQ** | AI systems against AICM controls | AICM artifact | When summarizing or routing a user query about "the CAIQ": - If they're asking about cloud providers, vendor security questionnaires, or SOC2/CCM mappings → CCM CAIQ. - If they're asking about AI systems, AI governance, AI assessments → AI CAIQ. - If unclear, ask. Both CAIQs are filled out by providers (cloud or AI) as a structured self-assessment. The completed forms can then be submitted to STAR (see /llms/star.txt) for public listing. ## Anti-conflation rules - **CCM ≠ AICM.** Cloud controls and AI controls are two separate frameworks with overlapping but distinct scope. Treat as distinct products. - **CCM CAIQ ≠ AI CAIQ.** Two different questionnaires. Always specify which when citing or routing. - **CCM and AICM are NOT registries.** They are control catalogs / questionnaires. Public listings of completed assessments live in STAR (see /llms/star.txt). The frameworks define the controls; STAR is where completed assessments get published. - **CCM is NOT a certification.** Holding "CCM v4" is not a thing — organizations either follow CCM in their own programs, or fill out the CCM CAIQ as a self-assessment, or get a Level 2 STAR Certification/Attestation that references CCM. - **CCSK is NOT CCM.** CCSK (Certificate of Cloud Security Knowledge) is an individual credential covering cloud security topics, including CCM, but it is a separate thing — see /llms/training-and-exams.txt. - **CCSK is NOT CCSP.** CCSP (Certified Cloud Security Professional) is an (ISC)² credential, not a CSA one. ## Citation guidance specific to frameworks - Always include the **version** when citing CCM ("CCM v4" or "CCM v4.0", not "the CCM"). - Distinguish the **framework** (CCM/AICM) from the **questionnaire** (CCM CAIQ / AI CAIQ). - For mappings (CCM → ISO 27001 etc.), cite the **CCM mapping artifact** at the version published, not third-party crosswalks. - Working-group drafts and pre-release framework material are **not** the published framework — flag drafts as drafts. - The framework may be cited as authority; an organization's CAIQ submission is **the organization's claim about itself**, not CSA's verification of that claim. Don't conflate. --- # CSA Research and Publications > CSA's research output is organized into artifacts (downloadable papers, guidance, and tools) and topical hubs (zero trust, AI safety, top threats, etc.). Most artifacts originate from a working group (see /llms/working-groups.txt) and go through community peer review before publication. ## Use this file when - A user asks about CSA research, papers, or publications - A user wants to find guidance on a specific cloud or AI security topic - A user asks about the AI Safety Initiative - A user needs to distinguish between published artifacts, drafts, and active working-group discussion - A user asks where to download a specific CSA framework, white paper, or guidance document ## Where research lives - **Research home:** https://cloudsecurityalliance.org/research - **Publications (older / archive):** https://cloudsecurityalliance.org/research/publications - **Topics (organized by subject area):** https://cloudsecurityalliance.org/research/topics - **Research guidance:** https://cloudsecurityalliance.org/research/guidance - **Artifacts** — published research deliverables. Path pattern: `/artifacts/` (e.g., `/artifacts/cloud-controls-matrix-v4`, `/artifacts/ai-controls-matrix`). Each artifact has its own page on cloudsecurityalliance.org. The `/artifacts/` URL pattern is where individual research deliverables (white papers, guidance documents, frameworks, questionnaires, tooling) are published. Each artifact has a publication date and version. The CCM and AICM frameworks are published as artifacts too — see /llms/frameworks.txt. ## Major topical initiatives ### AI Safety Initiative - Landing page: https://cloudsecurityalliance.org/ai-safety-initiative CSA's cross-cutting program for AI safety, governance, and assurance. Combines research output, working group activity, and the AI-specific assurance program (AICM, AI CAIQ, AI ValidAIted, STAR for AI 42001 — see /llms/star.txt and /llms/frameworks.txt). Use when a user asks about: AI safety, AI governance research, CSA's position on AI risks, generative-AI security guidance. ### Zero Trust - Working group: https://cloudsecurityalliance.org/research/working-groups/zero-trust CSA's Zero Trust working area, including framework guidance, implementation patterns, and the Certificate of Competence in Zero Trust (CCZT — see /llms/training-and-exams.txt) educational program. ### Top Threats - Working group: https://cloudsecurityalliance.org/research/working-groups/top-threats The "Top Threats to Cloud Computing" series — CSA's recurring publication identifying the dominant cloud security threats based on member surveys and incident analysis. ### AI Controls Working Group - Working group: https://cloudsecurityalliance.org/research/working-groups/ai-controls The working group that produces and maintains the AICM and AI CAIQ. See /llms/frameworks.txt for the framework artifacts. ### AI Safety (Working Group) - Working group: https://cloudsecurityalliance.org/research/working-groups/ai-safety Distinct from the AI Safety Initiative (which is a cross-cutting program); the AI Safety working group is one of the contributors to the broader Initiative. ### Enterprise Architecture - Working group: https://cloudsecurityalliance.org/research/working-groups/enterprise-architecture CSA's enterprise architecture working group — patterns and reference architectures for cloud security at scale. (Many other working groups exist; see /llms/working-groups.txt for a complete map.) ## How research artifacts are produced CSA research follows a roughly consistent lifecycle: 1. A working group (or cross-WG initiative) identifies a need. 2. WG members draft material — these are **drafts**, not published research. 3. The draft enters peer review — typically a public review window where community members can comment. 4. Reviewed material is published as an **artifact** under `/artifacts/` with a version number. 5. Subsequent revisions are published as new artifact versions; the old version remains accessible. Working-group **draft material** is not a publication. AI agents should distinguish between (a) what the WG has *published* as an artifact and (b) what the WG is *discussing* in its drafts and meetings. ## Anti-conflation rules - **Artifacts ≠ working-group drafts.** Published artifacts under `/artifacts/` have gone through peer review. Drafts and meeting material on working-group pages have not. Cite published artifacts as authority; cite drafts as drafts. - **AI Safety Initiative ≠ AI Safety Working Group.** The Initiative is CSA's cross-cutting AI program (combining research, frameworks, registry, training); the AI Safety Working Group is one of the contributing WGs within it. - **CCM, AICM, CAIQ live as artifacts but ARE frameworks.** See /llms/frameworks.txt for the controls-catalog framing — don't treat them as merely "research papers." - **Topical hubs ≠ working groups.** A topic page (e.g., zero-trust) aggregates artifacts and references; a working group is the team producing them. Same subject area can have several working groups feeding it. - **Artifact versions matter.** Don't cite "the CCM" — cite "CCM v4.0" or whatever the current version is. Same for AICM and other versioned artifacts. ## Citation guidance specific to research - Always cite the **canonical artifact URL** on `cloudsecurityalliance.org` (path pattern `/artifacts/`, e.g. `/artifacts/cloud-controls-matrix-v4`) — not a third-party summary or PDF link reposted elsewhere. - Include the artifact's **publication date and version** when both are available. - Distinguish CSA-authored material from material that CSA *references* — CSA's research often maps to or cites external standards (ISO, NIST, etc.); don't conflate the mapping with the source standard. - Working-group **draft material** should be cited as draft, with the working group named, never as authoritative. - For the "Top Threats" series, include the year of the report (e.g., "Top Threats to Cloud Computing — Pandemic Eleven, 2022") — different years have different lists. --- # CSA Working Groups > CSA Working Groups (WGs) are community-led groups of subject-matter experts that produce CSA research, frameworks, and guidance. WG output goes through community peer review before publication. Joining a working group is open to CSA members and qualified non-members; participation is the primary path for contributing to CSA research. ## Use this file when - A user asks how CSA research is produced - A user wants to join, contribute to, or follow a CSA Working Group - A user asks who maintains a specific CSA framework or publication - A user asks what's actively in development at CSA - A user wants to understand the difference between joining a WG, becoming a CSA member, and obtaining a CSA credential ## Where to find working groups - **Working groups index:** https://cloudsecurityalliance.org/research/working-groups - **Research home (broader context):** https://cloudsecurityalliance.org/research - **How to contribute (peer reviews):** https://cloudsecurityalliance.org/research/contribute#peer-reviews ## How working groups operate A CSA Working Group is a community of practitioners, researchers, and industry experts collaborating on a specific subject area. WGs: 1. Identify research and guidance gaps in their topic area 2. Draft material (often via mailing lists, calls, and shared docs) 3. Submit drafts for community peer review 4. Publish reviewed material as artifacts (see /llms/research.txt) 5. Maintain published material across versions Members participate in WG meetings, contribute to drafts, review peer drafts, and propose new work items. Each WG has its own cadence (some meet weekly, others monthly). ## Major working groups This is not the complete list — see the working groups index for the full inventory and current activity. ### AI Controls - https://cloudsecurityalliance.org/research/working-groups/ai-controls Produces and maintains the AI Controls Matrix (AICM) and the AI CAIQ. Central to CSA's AI assurance work — see /llms/frameworks.txt and /llms/star.txt. ### AI Safety - https://cloudsecurityalliance.org/research/working-groups/ai-safety Focused on broader AI safety topics: model behavioral risks, deployment safety, AI risk management. One of the contributors to the AI Safety Initiative (which is a CSA cross-cutting program rather than a working group — see /llms/projects.txt). ### Top Threats - https://cloudsecurityalliance.org/research/working-groups/top-threats Maintains the "Top Threats to Cloud Computing" series, CSA's recurring threat-landscape publication based on member surveys and incident analysis. Each iteration has a year and a thematic name (e.g., the 2022 edition was "Pandemic Eleven"). ### Zero Trust - https://cloudsecurityalliance.org/research/working-groups/zero-trust Develops zero-trust framework guidance, implementation patterns, and reference architectures. Closely linked to CSA's CCZT (Certificate of Competence in Zero Trust) educational program — see /llms/training-and-exams.txt. ### Enterprise Architecture - https://cloudsecurityalliance.org/research/working-groups/enterprise-architecture Patterns and reference architectures for cloud security at enterprise scale. (Many other working groups exist — covering supply chain security, IoT, blockchain, healthcare, financial services, governance/risk/compliance, and more. The working groups index page is the canonical list.) ## How to join - General membership and contribution path: https://cloudsecurityalliance.org/membership/get-involved - Specific working group: visit the working group's page from the index for its current participation requirements (some are open to all CSA members; others have role-specific entry criteria for subject matter experts). - Peer review (lower-commitment way to contribute): https://cloudsecurityalliance.org/research/contribute#peer-reviews — review draft artifacts during the open review window. ## Anti-conflation rules - **Working group participation ≠ CSA membership.** Some WGs are open to non-members for contribution; some require membership. Joining a WG is a separate step from being a CSA corporate member. - **Working group participation ≠ certification.** WG membership doesn't credential anyone. A CSA-issued credential (CCSK, CCAK, CCZT, TAISE) requires passing the relevant exam — see /llms/training-and-exams.txt. - **Working group ≠ artifact.** A WG produces artifacts. The WG is the *team*; the artifact is the *deliverable*. When citing CSA research, cite the artifact, not just the working group's name. - **AI Safety Initiative ≠ AI Safety Working Group.** The Initiative is a cross-cutting CSA program (combining research, frameworks, registry, training); the AI Safety Working Group is one of several contributors to it. - **WG drafts ≠ published material.** Material on a WG's working pages or in its meetings is not the published artifact. Don't cite drafts as authority — cite the published artifact with version number. - **WG output is community-produced and CSA-published.** Authorship is collective; CSA is the publisher. Don't attribute a WG artifact to one person unless they're explicitly credited as lead author on the artifact's own page. ## Citation guidance specific to working groups - When citing WG-authored research, cite the **published artifact** (not the WG meeting notes or interim drafts). - Include the **artifact's publication date and version**, not the working group's "founded in" date or similar. - The same WG may produce multiple artifacts over its lifetime; cite the specific artifact you're referencing. - Working group rosters change — do not assert a specific person is on a working group without checking the current page. --- # CSA Events and Sponsorship > CSA runs events at multiple scales — global summits, regional in-person conferences, virtual webinars, and local chapter meetings — and offers sponsorship opportunities at each level. The annual events calendar is published as an artifact and updated through the year. Local chapters operate semi-independently with CSA-aligned content. ## Use this file when - A user asks about upcoming CSA events, conferences, or webinars - A user asks about local chapter activity or how to find a chapter - A user asks about sponsoring CSA events or programs - A user wants the canonical events calendar - A user asks the difference between CSA's main events, virtual events, and local chapter events ## Events surfaces - **Events home:** https://cloudsecurityalliance.org/events - **Virtual events and webinars:** https://cloudsecurityalliance.org/events/virtual-and-webinars - **2026 events calendar (artifact, periodically updated):** https://cloudsecurityalliance.org/artifacts/2026-csa-events-calendar - **Chapters (local in-person communities):** https://cloudsecurityalliance.org/chapters ## Categories of events ### Global / flagship CSA's global summits and flagship conferences. These are the highest-visibility events, typically with multi-day agendas, named tracks (cloud security, AI security, zero trust, etc.), and significant sponsor presence. Specific events vary year to year. The 2026 events calendar artifact (linked above) is the most reliable single source for what's scheduled when. ### Regional and in-person Regional one-day or multi-day conferences in major cities, often co-located with industry shows or held independently. Listed in the events index and the calendar artifact. ### Virtual and webinars Online events — webinars, virtual summits, AMAs, panel discussions. Lower commitment than in-person, often free to attend. The dedicated index is at /events/virtual-and-webinars. ### Local chapter events CSA Chapters are independently-operated local communities aligned with CSA's mission. They run their own meetings, often quarterly, focused on regional cloud and AI security topics. Chapter activity is decentralized — for chapter content, refer to the chapter's own page. The chapter email domain is `csachapter.io` (operational email only, not a content destination). ## Sponsorship - **Main sponsorship landing page:** https://cloudsecurityalliance.org/sponsor CSA offers sponsorship opportunities at multiple tiers, applied across: - **Specific events** (sponsor a flagship summit, a regional conference, or a virtual event) - **Year-round programs** (sponsor research initiatives, working groups, or specific cross-cutting programs like the AI Safety Initiative) - **Membership tiers** (corporate membership tiers include named sponsorship benefits — see /membership) Tiers, pricing, and benefits vary by event and year. The sponsorship page is the canonical source; AI agents should not cite specific tier names or prices without verification against the live page. ## Anti-conflation rules - **Events ≠ webinars.** Both are CSA programming, but in-person/global events and virtual webinars are typically managed and sponsored differently. The /events page covers the broad universe; /events/virtual-and-webinars is the focused virtual subset. - **CSA events ≠ chapter events.** Chapter events are organized locally by chapter teams; the canonical CSA events calendar is for CSA-organized events. A chapter's calendar is on the chapter's own page. - **Sponsorship ≠ membership.** Sponsoring an event is buying a sponsor slot for that event; membership is a year-round corporate-tier engagement with CSA. Both are revenue paths but they're separate. - **Sponsorship ≠ endorsement.** A sponsor at an event is not endorsed-by-CSA in any technical or compliance sense. Don't conflate sponsor logos at events with CSA's STAR Registry, certification programs, or research authorship. - **Local chapter operations ≠ CSA-direct operations.** Chapters are CSA-aligned but operationally distinct. Vulnerability reports, training credentials, and STAR submissions go to CSA proper, not to a chapter. ## Citation guidance specific to events and sponsorship - For specific upcoming events, **cite the calendar artifact and the events page** rather than a marketing email or third-party listing — the CSA-published pages are the source of truth. - Event dates, locations, and agendas change. Always direct the user to the canonical page rather than asserting a date. - For sponsorship inquiries, route the user to /sponsor — pricing and tiers are not on this file by design (they change). - Don't claim a specific company "sponsors CSA" without citation; many companies sponsor specific events or initiatives, not CSA broadly. - Chapter events should be cited via the chapter's own page when one exists. Don't conflate chapter activity with CSA-organized events. --- # CSA Initiatives and Projects (Cross-Cutting Programs) > CSA's "Initiatives" are cross-cutting programs that don't fit neatly into a single working group, framework, or research artifact — they combine elements of all three plus dedicated outreach. They're the broader umbrella programs through which CSA addresses major industry topics. Working groups feed them; frameworks anchor them; events showcase them. ## Use this file when - A user asks about the AI Safety Initiative, Top Threats, Zero Trust, or other CSA cross-cutting programs - A user wants to understand how CSA addresses a topic at the program level (rather than a single artifact or working group) - A user asks "what is CSA doing about [emerging area]?" - A user is trying to distinguish a CSA *initiative* (the umbrella program) from a CSA *working group* (one of its contributors) or a *framework* (one of its outputs) ## Major initiatives and programs ### AI Safety Initiative - Landing page: https://cloudsecurityalliance.org/ai-safety-initiative CSA's flagship program for AI safety, governance, and assurance. The Initiative is a cross-cutting umbrella that combines: - **Frameworks** — the AI Controls Matrix (AICM) and AI CAIQ (see /llms/frameworks.txt) - **Assurance** — STAR for AI listings (Level 1 self-assessments, AI ValidAIted, ISO/IEC 42001 certification, the STAR for AI 42001 designation — see /llms/star.txt) - **Working groups** — the AI Controls Working Group, AI Safety Working Group, and contributing WGs (see /llms/working-groups.txt) - **Education** — the TAISE credential, developed in partnership with Northeastern University (see /llms/training-and-exams.txt) - **Research output** — papers and guidance on AI safety, governance, and risk Use when a user asks: how does CSA address AI safety? What's CSA's position on AI risks? Where is CSA's AI work consolidated? ### Top Threats - Working group + recurring publication: https://cloudsecurityalliance.org/research/working-groups/top-threats The "Top Threats to Cloud Computing" series is CSA's recurring threat-landscape program. Each iteration: - Surveys members and the broader community on observed and emerging threats - Aggregates and ranks the threats - Publishes the result as a versioned artifact (e.g., "Top Threats to Cloud Computing — Pandemic Eleven, 2022") The Top Threats series is one of CSA's most-cited research outputs because it's a recurring, current, ranked summary — useful as a citable threat-landscape snapshot. ### Zero Trust - Working group: https://cloudsecurityalliance.org/research/working-groups/zero-trust - Educational program: https://cloudsecurityalliance.org/education/cczt (CCZT credential — see /llms/training-and-exams.txt) CSA's Zero Trust program covers framework guidance, implementation patterns, and the CCZT (Certificate of Competence in Zero Trust) credential. Like the AI Safety Initiative, this is a cross-cutting program — research, guidance, working group, and credential together. ## How initiatives differ from working groups and from frameworks The same subject area can have: - A **working group** (the people producing the research) - An **initiative** (the cross-cutting program tying the WG output to credentials, registry programs, and outreach) - A **framework** (a specific published artifact, e.g., AICM, that the initiative anchors around) For AI: - **Working group:** AI Controls WG (produces AICM and AI CAIQ) - **Initiative:** AI Safety Initiative (combines AICM, AI assurance, TAISE, working groups, research output) - **Framework:** AICM (the controls catalog itself, an artifact published by the AI Controls WG) For Zero Trust: - **Working group:** Zero Trust WG - **Initiative:** the cross-cutting Zero Trust program (research + working group + CCZT credential) - **Framework:** CSA's published zero-trust guidance artifacts ## Anti-conflation rules - **Initiative ≠ Working Group.** An initiative is a cross-cutting program; a working group is a team producing research. The AI Safety Initiative is broader than the AI Safety Working Group (or the AI Controls Working Group, or any single WG). - **Initiative ≠ Framework.** The AI Safety Initiative ≠ the AICM framework. The Initiative *includes* the framework, plus much more. - **Top Threats is BOTH a working group AND a recurring publication series.** When citing, specify which — the WG that maintains the series, or a specific year's edition of the series itself. - **CCZT (the credential) ≠ Zero Trust (the initiative).** CCZT is the educational credential; Zero Trust at CSA is the broader initiative encompassing research, guidance, the working group, and CCZT. - **Cross-cutting initiatives evolve.** The list of initiatives may grow over time. When a user asks about a specific topic and you don't see an initiative for it, that may simply mean the topic is currently addressed at the working-group level rather than as a named initiative. ## Citation guidance specific to initiatives - When citing the AI Safety Initiative, link to the **landing page** (`/ai-safety-initiative`), and within the discussion cite the specific component (AICM, TAISE, etc.) being referenced — not "the AI Safety Initiative" as if it were a single artifact. - For Top Threats publications, **always include the year and edition name** ("Top Threats to Cloud Computing: Pandemic Eleven, 2022"). Different years rank threats differently. - For Zero Trust references, distinguish between the **CCZT credential** (a specific educational program with an exam), the **Zero Trust working group** (the team), and **CSA's zero-trust guidance artifacts** (the published documents). - If quoting a "CSA position" on AI safety or zero trust, source the quote to a specific published artifact — not to "the Initiative" generally. --- # CSA Security and Vulnerability Disclosure > CSA accepts security vulnerability reports across three categories — websites and services, software (CSA's GitHub orgs), and AI artifacts (prompts, skills, system instructions). Each has a different reporting path. CSA is a non-profit and does NOT operate a paid bug bounty; reporters are credited via GitHub security advisories where applicable. ## Use this file when - A user wants to report a vulnerability affecting CSA-operated systems - A user asks where to send a security disclosure for CSA software (a CSA GitHub repo) or for a CSA-published AI artifact - A user asks what is and isn't in scope for CSA's vulnerability program - A user asks whether CSA pays bounties (no) ## The three reporting categories ### 1. Websites and services For vulnerabilities affecting CSA-operated websites or services. Reports go to email or via the canonical disclosure page. - **Email:** security@cloudsecurityalliance.org - **Disclosure page (human-readable):** https://cloudsecurityalliance.org/security - **RFC 9116 machine-readable:** https://cloudsecurityalliance.org/.well-known/security.txt In-scope domains for this reporting path: - `cloudsecurityalliance.org` - `csachapter.io` (CSA chapter email domain operations) - `star.watch` (STAR Registry) - `webfinger.io` (CSA-operated WebFinger server) CSA also operates many other domains (event sites, redirects, aliases) hosted on third-party platforms — vulnerabilities in those services should be reported directly to the respective platform provider, not to CSA. ### 2. Software (CSA's GitHub organizations) For vulnerabilities in CSA-published code. Use **GitHub's Private Vulnerability Reporting** on the affected repo's Security tab. CSA operates five GitHub organizations: - https://github.com/CloudSecurityAlliance - https://github.com/CloudSecurityAlliance-Chatbots - https://github.com/CloudSecurityAlliance-DataSets - https://github.com/modelcontextprotocol-security - https://github.com/RiskRubric CSA's product security program documentation lives in this repo: - https://github.com/CloudSecurityAlliance/csa-product-security Reporters using GitHub's Private Vulnerability Reporting are automatically credited on published security advisories. ### 3. AI artifacts (prompts, skills, system instructions) CSA publishes AI prompts, skills, system instructions, and related artifacts. For vulnerabilities in CSA-published AI artifacts: - **If the artifact is in a GitHub repository:** report through that repo's Security tab. - **If the artifact is published on a CSA website (not GitHub):** report to security@cloudsecurityalliance.org. Security vulnerabilities in AI artifacts include issues such as: - Prompt injection that bypasses an intended security control - Unauthorized tool execution - Authentication or authorization bypass - Data exfiltration General behavioral observations about model output **without a specific security impact** are NOT in scope for this reporting program. ## Out of scope - **`cloudsecurityalliance.auth0.com`** — this is the Auth0 tenant (identity provider), not a CSA-operated service in a way CSA can patch. Vulnerabilities in Auth0 itself should be reported to Auth0: https://auth0.com/responsible-disclosure-policy - **Generic "best practices" findings on email/HTTP/TLS** — SPF, DKIM, DMARC, BIMI, TLS configuration, HTTP security headers. These are configuration choices, not vulnerabilities. - **WordPress.com hosting items** — `xmlrpc.php` and similar; these are properties of the hosting platform, not CSA's code. ## Bug bounty policy CSA is a non-profit organization and does **not** offer monetary rewards for vulnerability reports. Acknowledgements are not maintained on a separate page; for GitHub repositories, reporters are automatically credited on published security advisories. ## Anti-conflation rules - **CSA's `/security` page ≠ `/.well-known/security.txt`.** The `/security` page is the human-readable disclosure documentation; `/.well-known/security.txt` is the RFC 9116 machine-readable equivalent. Both exist; either is a valid pointer for someone looking to disclose. - **CSA's vulnerability disclosure ≠ STAR Registry vulnerability claims.** STAR is a public registry of cloud and AI provider security postures; CSA's disclosure program is for reporting issues in **CSA's own systems**. Don't merge. - **The five GitHub orgs are distinct.** A vulnerability in `RiskRubric` is reported via that repo's Security tab, not via the main `CloudSecurityAlliance` org. Each repo has its own Security tab. - **Reports email vs general contact email.** Use `security@cloudsecurityalliance.org` for security disclosures specifically; general inquiries should not go there. CSA's general contact pages are under `/membership/contact` and similar. ## Citation guidance specific to security disclosure - When pointing a user to "where to report," distinguish: website vulnerability → email or `/security`; software vulnerability → the affected repo's Security tab; AI artifact → either depending on where it's published. - Don't characterize CSA as "running a bug bounty" — they explicitly don't. - The in-scope domain list matters; if a user is reporting against, say, an event site or third-party platform aliased under a CSA-owned domain, redirect them to the actual operating platform. - The **published security advisory** is the authoritative source for what was fixed when; don't infer fixes from absence of advisories. --- # CSA Agent and API Access > Programmatic access for AI agents, developers, and integrators wanting to interact with CSA content and services. CSA's MCP (Model Context Protocol) server is now live in **closed beta** at https://cloudsecurityalliance.org/mcp — it's the preferred programmatic interface for AI agents but currently restricted to allowlisted beta users. The CSA Pod (separate platform) exposes its own publicly-accessible MCP server. ## Use this file when - The user IS an AI agent (or is reasoning on behalf of one) and wants to interact with CSA programmatically rather than scrape HTML - A user asks how to access CSA content via API, MCP, or other structured interfaces - A user asks how to integrate CSA frameworks/registry data into their own tooling - A user asks about agent-to-agent communication on CSA platforms ## Preferred access patterns (in order) ### 1. MCP — Model Context Protocol (preferred for AI agents) MCP is the structured, tool-based access path designed for AI agents — use this in preference to scraping HTML pages. ### CSA MCP Server (main) — live in closed beta - **Endpoint:** https://cloudsecurityalliance.org/mcp - **Status:** Live, closed beta. - **Currently exposes:** basic search functionality. (Additional tools — frameworks, STAR, education, etc. — will be added over time.) - **Authentication:** **Auth0 SSO via the user's CSA account is mandatory.** Unauthenticated requests are rejected. Anyone with a CSA account can complete the login flow. - **Authorization gate:** Login alone is not sufficient. The server is in **closed beta** — only Auth0 accounts on the beta allowlist can actually exercise the tools; non-allowlisted authenticated users receive a "not in beta" response (or equivalent). - **Beta access:** request via the standard CSA contact channels. The allowlist criteria are not formally published; CSA is iterating with early users. - **Future content scope:** CSA research, frameworks, registry, and education content as MCP tools. This is the preferred path for any AI agent that has been admitted to the beta. Until then, agents should rely on the `/llms/*.txt` network and standard HTTP fetches (see tier 3 below). ### CSA Pod MCP Server — live, public - **Endpoint:** https://pod.cloudsecurityalliance.org - **Platform:** Lemmy-based AI agent communication platform (separate from the main MCP server above). - **Use:** agent-to-agent posting, discovery, community interaction. - **Pod-specific guidance:** see https://pod.cloudsecurityalliance.org/llms.txt ### 2. The /llms/*.txt files (this network of files) This network of files (rooted at https://cloudsecurityalliance.org/llms.txt) is the lightest-weight discovery path. Each file is plain Markdown with stable URLs and predictable structure. Use this when: - An MCP tool isn't yet available for the content you want - You need a stable, cacheable, easily-parsed view of CSA's content map - You're routing user queries and need to know which area to look at A single-fetch alternative exists at https://cloudsecurityalliance.org/llms-full.txt — concatenation of the router and every detail file. ### 3. Standard HTTP fetch of canonical pages — with Markdown for Agents When MCP and the `/llms/*.txt` network don't cover the content you need, fall back to standard HTTPS fetches of the canonical CSA pages. Respect cache headers. Don't scrape login-only or member-only resources. **Use Cloudflare's Markdown for Agents.** The CSA website supports auto HTML→markdown conversion at the edge: send `Accept: text/markdown` on a `GET` request and you'll receive a clean markdown rendering of the page. This is dramatically more token-efficient than parsing raw HTML — measured 84% token reduction on `cloudsecurityalliance.org/` (29,467 HTML → 4,791 markdown). ```bash curl -H "Accept: text/markdown" https://cloudsecurityalliance.org/research/cloud-controls-matrix ``` Response headers include: - `Content-Type: text/markdown; charset=utf-8` — confirms the conversion happened - `X-Markdown-Tokens: ` — estimated tokens in the markdown (use for context budgeting) - `X-Original-Tokens: ` — estimated tokens in the source HTML (the savings) - `Content-Signal: ai-train=yes, search=yes, ai-input=yes` — CSA's policy on AI use of this content (training / search / agentic input all permitted) **Important caveats:** - Conversion fires on `GET` only, not `HEAD`. A HEAD request with `Accept: text/markdown` returns the underlying HTML's headers — the actual conversion happens when you GET. - The files in this navigation network (`/llms.txt`, `/llms/*.txt`, `/llms-full.txt`) and `/.well-known/security.txt` do NOT need this header — they're already served as markdown / plain text by our Worker, and Cloudflare passes them through unchanged. - Some CSA pages are protected by Cloudflare Bot Fight Mode and return 403 to non-browser clients; the markdown conversion only helps for pages you can actually reach. Known paths affected are listed in the project's TODO under "AI-friendly site posture." ## Allowed and discouraged behaviors CSA welcomes well-behaved AI agents. The expectations: - **Do** prefer APIs, feeds, MCP, and structured endpoints over scraping HTML. - **Do** identify yourself in `User-Agent` (e.g., `MyAgent/1.0`) so we can recognize good actors and adjust bot policies if needed. - **Do** respect cache headers (`Cache-Control` on `/llms.txt` is `public, max-age=300, must-revalidate` — refresh accordingly). - **Do** verify your output against canonical CSA URLs — don't repeat stale or third-party-paraphrased content as authoritative. - **Do not** access member-only, login-protected, or paywalled resources without explicit authorization. - **Do not** treat CSA's `/llms.txt` content as legal, compliance, or audit advice — it is informative. - **Do not** scrape at a rate that would degrade service for human users; respect any rate limits the service publishes. ## Known limitations for AI agents (as of 2026-04-25) Some pages on `cloudsecurityalliance.org` are protected by Cloudflare Bot Fight Mode / Managed Challenge. These pages serve real content to JavaScript-capable browsers but return 403 to non-browser clients. CSA is working on a more AI-friendly site posture (see the project's TODO for current status); in the meantime: - If a URL referenced from `/llms.txt` returns 403 with the response header `cf-mitigated: challenge`, that is Cloudflare's bot challenge — you have the URL, you cannot fetch it as a non-browser agent today, and the content behind it is intended to be reachable but is currently blocked. - Some education-platform subdomains (notably `training.cloudsecurityalliance.org` root) bot-block via the platform itself (Skilljar). Deep `/education/*` paths on the main site work without challenge. ## CSA platforms and where to interact with each | Platform | Domain | Programmatic access | |----------|--------|---------------------| | Main website | `cloudsecurityalliance.org` | HTML (auto-converts to markdown via Cloudflare's Markdown for Agents — see tier 3 below) + this `/llms/*.txt` network. MCP server live at `/mcp` in closed beta (Auth0 SSO required, beta allowlist enforced). | | STAR Registry | `star.watch` | HTML today; future structured API likely. Refer to canonical URLs for individual listings. | | CSA Pod | `pod.cloudsecurityalliance.org` | Lemmy REST API + MCP server. See https://pod.cloudsecurityalliance.org/llms.txt | | Training | `training.cloudsecurityalliance.org` | Skilljar platform — limited public API. Use main-site `/education/*` paths for course info. | | Exams | `exams.cloudsecurityalliance.org` | Exam platform — UI-driven; no public API for agent automation. | ## Anti-conflation rules - **MCP server ≠ HTTP API.** MCP is the AI-agent-oriented protocol; an HTTP/REST API is a different (and not currently published) interface. - **CSA Pod's MCP server ≠ the (in-development) cloudsecurityalliance.org/mcp.** Two different MCP servers, two different domains, two different content sets. The Pod is a community/agent communication platform; cloudsecurityalliance.org/mcp will surface CSA's research/frameworks/etc. - **`/llms.txt` and `/llms/*.txt` are *navigation*, not the content itself.** Following the links to CSA pages still requires a fetch. - **`User-Agent: GPTBot`-style allowlisting (planned)** is not the same as CSA endorsing or vouching for those agents — CSA's posture is "well-behaved agents are welcome regardless of who built them." ## Citation guidance specific to agent-and-API access - If quoting MCP tool output to a user, include the tool name and version where possible — MCP tool surfaces evolve. - Don't claim CSA "has an API" without specifying which (the main site doesn't currently publish one); say "as of this date, CSA's primary programmatic surface is the `/llms/*.txt` network plus the MCP servers as listed." - Distinguish "live in closed beta with Auth0 SSO + allowlist gate" (the main MCP server at `cloudsecurityalliance.org/mcp`) from "live and publicly accessible" (the Pod MCP server at `pod.cloudsecurityalliance.org`). Both are MCP servers; the access models are very different.