github.com/gemaraproj/gemara@v1.3.0

docs/schema/index.md raw

  1---
  2layout: page
  3title: Gemara Schemas
  4nav-title: Schema
  5---
  6
  7Schemas (CUE format) standardize the expression of elements in the model and enable automated interoperability between GRC tools. These schemas provide validation across all layers.
  8
  9Click on an artifact to view its schema:
 10
 11<div class="layer-grid">
 12  <a href="guidancecatalog.html" class="layer-card">
 13    <span class="layer-badge">Layer 1</span>
 14    <h3>Guidance Catalog</h3>
 15    <p>High-level guidance on cybersecurity measures from industry groups and standards bodies.</p>
 16  </a>
 17
 18  <a href="vectorcatalog.html" class="layer-card">
 19    <span class="layer-badge">Layer 1</span>
 20    <h3>Vector Catalog</h3>
 21    <p>Attack vectors and techniques used to compromise information systems.</p>
 22  </a>
 23
 24  <a href="principlecatalog.html" class="layer-card">
 25    <span class="layer-badge">Layer 1</span>
 26    <h3>Principle Catalog</h3>
 27    <p>Foundational values that guide governance, design, and operational decisions.</p>
 28  </a>
 29
 30  <a href="controlcatalog.html" class="layer-card">
 31    <span class="layer-badge">Layer 2</span>
 32    <h3>Control Catalog</h3>
 33    <p>Technology-specific, threat-informed security controls for protecting information systems.</p>
 34  </a>
 35
 36  <a href="capabilitycatalog.html" class="layer-card">
 37    <span class="layer-badge">Layer 2</span>
 38    <h3>Capability Catalog</h3>
 39    <p>Technology capabilities that can be leveraged to implement security controls.</p>
 40  </a>
 41
 42  <a href="threatcatalog.html" class="layer-card">
 43    <span class="layer-badge">Layer 2</span>
 44    <h3>Threat Catalog</h3>
 45    <p>Threats mapped to technology capabilities and security controls.</p>
 46  </a>
 47
 48  <a href="riskcatalog.html" class="layer-card">
 49    <span class="layer-badge">Layer 3</span>
 50    <h3>Risk Catalog</h3>
 51    <p>Organizational risk categories, severity levels, and risk appetite definitions.</p>
 52  </a>
 53
 54  <a href="policy.html" class="layer-card">
 55    <span class="layer-badge">Layer 3</span>
 56    <h3>Policy</h3>
 57    <p>Risk-informed guidance tailored to your organization's specific needs and risk appetite.</p>
 58  </a>
 59
 60  <a href="evaluationlog.html" class="layer-card">
 61    <span class="layer-badge">Layer 5</span>
 62    <h3>Evaluation Log</h3>
 63    <p>Inspection of code, configurations, and deployments against policies and controls.</p>
 64  </a>
 65
 66  <a href="enforcementlog.html" class="layer-card">
 67    <span class="layer-badge">Layer 6</span>
 68    <h3>Enforcement Log</h3>
 69    <p>Prevention or remediation based on assessment findings.</p>
 70  </a>
 71
 72  <a href="auditlog.html" class="layer-card">
 73    <span class="layer-badge">Layer 7</span>
 74    <h3>Audit Log</h3>
 75    <p>Review of organizational policy and conformance.</p>
 76  </a>
 77</div>
 78
 79**[Browse all schemas in the CUE Central Registry →](https://registry.cue.works/docs/github.com/gemaraproj/gemara@latest)**
 80
 81## Schema Documentation
 82
 83Schema documentation generated from CUE. One page per schema file:
 84
 85<!-- SCHEMA_LIST_START -->
 86
 87- [Aliases & Base Types](base.html)
 88- [Metadata](metadata.html)
 89- [Mapping Primitives](mapping-inline.html)
 90- [Guidance Catalog](guidancecatalog.html)
 91- [Vector Catalog](vectorcatalog.html)
 92- [Principle Catalog](principlecatalog.html)
 93- [Control Catalog](controlcatalog.html)
 94- [Capability Catalog](capabilitycatalog.html)
 95- [Threat Catalog](threatcatalog.html)
 96- [Risk Catalog](riskcatalog.html)
 97- [Policy](policy.html)
 98- [Mapping Document](mappingdocument.html)
 99- [Lexicon](lexicon.html)
100- [Evaluation Log](evaluationlog.html)
101- [Enforcement Log](enforcementlog.html)
102- [Audit Log](auditlog.html)
103
104<!-- SCHEMA_LIST_END -->
105
106### Validation with CUE
107
108```bash
109# Install CUE
110go install cuelang.org/go/cmd/cue@latest
111
112# Validate a control catalog using the ControlCatalog definition
113cue vet -c -d '#ControlCatalog' github.com/gemaraproj/gemara@latest your-controls.yaml
114```
115
116## Architecture Decisions
117
118Significant implementation changes are documented in [Architecture Decision Records (ADRs)](../adrs/index.html).
119
120## Schema Standards
121
122Schemas follow these naming standards:
123
124| Layer | Category    | Atomic Unit (Interactive) | Atomic Unit (Defensive) | Collection (Interactive) | Collection (Defensive) |
125|:------|:------------|:--------------------------|:------------------------|:-------------------------|:-----------------------|
126| 1     | Definition  | Vector                    | Guidance                | Vector Catalog           | Guidance Catalog       |
127| 2     | Definition  | Threat                    | Control                 | Threat Catalog           | Control Catalog        |
128| 3     | Definition  | Risk                      | Policy                  | Risk Catalog             | —                      |
129| 4     | —           | —                         | —                       | —                        | —                      |
130| 5     | Measurement | Control Evaluation        | Control Evaluation      | Evaluation Log           | Evaluation Log         |
131| 6     | Measurement | Action Result             | Action Result           | Enforcement Log          | Enforcement Log        |
132| 7     | Measurement | —                         | Audit Result            | —                        | Audit Log              |
133
134**Note:** "—" indicates no planned schema implementation.
135
136**Naming conventions**:
137- **Definition layers (1-3)**: Collections of atomic units are called **Catalogs**
138- **Measurement layers (5-7)**: Collections of atomic units are called **Logs**
139
140## Versioning and Maintenance
141
142Project release deliverables are divided into the **Core Specification** and language-specific **SDKs**.
143
144* **Core Specification Release:** The CUE schemas are versioned and released as the core specification. These schemas implement the Model, which is published separately.
145* **SDK Releases:** Language-specific implementations that provide tooling, types, and helpers to work with Gemara documents. SDK types are generated from the CUE schemas.
146
147Each **maintains its own** independent [SemVer](https://semver.org/) lifecycle.
148
149### Specification Release Versioning
150
151The core specification release versions the CUE schemas as a single unit.
152
153| Change Type | Version Bump | Examples                                                     |
154|:------------|:-------------|:-------------------------------------------------------------|
155| Major       | v2.0.0       | Breaking changes to Stable schemas.                         |
156| Minor       | v1.(x+1).0   | Additive changes, schema promotions, or new optional fields. |
157| Patch       | v1.x.(y+1)   | Bug fixes in schema logic or documentation.                  |
158
159### Schema Lifecycle and Major Version Example
160
161Possible schema states include: **Experimental** → **Stable** → **Deprecated**. These are denoted on each schema file with a `@status(experimental|stable|deprecated)` attribute.
162
163The following table illustrates how schemas progress through their lifecycle and how major version changes are handled:
164
165| Version | Status              | Change Type | Example Scenario                        |
166|:--------|:--------------------|:------------|:----------------------------------------|
167| v1.0.0  | Experimental        | Initial     | Schema first published                  |
168| v1.1.0  | Experimental        | Minor       | Optional fields added                   |
169| v1.2.0  | Stable              | Minor       | Promoted to Stable                      |
170| v1.3.0  | Stable              | Minor       | Additive changes                        |
171| v1.3.1  | Stable              | Patch       | Bug fix                                 |
172| v1.4.0  | Stable              | Minor       | Field deprecated, replacement added     |
173| v1.5.0  | Stable → Deprecated | Minor       | Original deprecated, replacement Stable |
174| v2.0.0  | Stable              | Major       | Deprecated schema removed               |
175| v2.1.0  | Stable              | Minor       | Additive changes                        |
176
177### Experimental Status
178* All new schemas start as Experimental.
179* Adding Experimental schemas or making breaking changes triggers minor version increments.
180* Breaking changes and performance issues may occur during this phase.
181* These schemas may not be feature-complete.
182
183### Stable Status
184
185* Schemas promote independently and at different times (e.g., ControlCatalog can be Stable while Policy remains Experimental).
186* When a schema is promoted to Stable, all types it references must also be Stable (e.g., promoting `#ControlCatalog` requires `#Catalog`, `#Metadata`, `#Group`, and any other referenced types to already be Stable).
187* Stable schemas may only reference other Stable types.
188* Stable schemas maintain backward and forward compatibility within major versions, allowing **additive optional changes** only.
189* Breaking changes require major version increments and should be avoided in all normal circumstances.
190
191### Deprecated Status
192
193* Schemas or fields within schemas may be deprecated when replaced.
194* Replacement schema or field must be added in Experimental status and promoted to Stable before deprecation.
195* Deprecated schemas and fields maintain the same support guarantees as Stable schemas and remain functional.
196* Deprecated schemas are removed in the next major version release.
197
198## Contributing
199
200The Schemas evolve based on community needs. If you find an error or have suggestions for a schema improvement, open a [GitHub Issue](https://github.com/gemaraproj/gemara/issues) or raise your suggestion on a [community](/community) meeting.
201
202See the [Contributing Guide](https://github.com/gemaraproj/gemara/blob/main/CONTRIBUTING.md) for details.
203
204## Relationship to Other Components
205
206### [The Model](../model)
207The Model is published separately and provides the conceptual foundation. These CUE schemas are an implementation of the model, with each schema corresponding to a layer in the model.
208
209### [The SDKs](../sdk/)
210SDKs support programmatic access to Gemara documents. SDK types are generated from these schemas, ensuring consistency between validation and programmatic access.
211
212## Questions or Feedback
213
214For questions about versioning strategy or to propose changes:
215
216* Open an issue on [GitHub](https://github.com/gemaraproj/gemara/issues)
217* Discuss in the [OpenSSF Slack #gemara channel](https://openssf.slack.com/archives/C09A9PP765Q)
218* Attend the [biweekly Gemara meeting](https://calendar.google.com/calendar/u/0?cid=czYzdm9lZmhwNWk5cGZsdGI1cTY3bmdwZXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ)