Networking had no common language until 1984. Engineers at different vendors described the same functions using different terms. Troubleshooting meant decoding tribal knowledge. Then the OSI model introduced seven layers, and every network engineer on the planet could point to the exact layer where a problem lived. Routing was Layer 3. Sessions were Layer 5. The taxonomy did not build the network. It gave everyone a shared map for building, debugging, and improving networks at scale.
Governance, risk, and compliance engineering faces the same problem in 2026 that networking faced in 1983. Organizations manage controls in one platform, evaluate them in another, enforce policies through a third system, and audit results through manual evidence pulls that connect to none of the above. The tools exist. The interoperability does not. Open source malware grew 75% in 2025, reaching 1.23 million known malicious packages across npm, PyPI, Maven Central, NuGet, and Hugging Face [Sonatype 2026]. Software supply chain attacks doubled globally during the same period [ReversingLabs 2026]. The compliance stack that protects against these threats operates without a shared architectural model.
The OpenSSF Gemara model changes that. Released in March 2026 by the Open Source Security Foundation, Gemara provides the OSI model for GRC: seven categorical layers that decompose compliance activities into discrete, interoperable functions with standardized schemas. The name stands for Governance, Risk, and Compliance Engineering Model for Automated Risk Assessment. It does not replace your existing frameworks. It gives every tool, team, and organization in your compliance stack a common architecture for describing what they do and how their outputs connect.
The OpenSSF Gemara model provides a seven-layer architecture for automated GRC engineering, decomposing compliance activities into discrete layers with CUE-based schemas for machine-readable interoperability. With 9.8 trillion open source downloads in 2025 [Sonatype 2026] and supply chain attacks doubling year over year [ReversingLabs 2026], Gemara standardizes the compliance stack the same way the OSI model standardized networking.
What Problem Does the OpenSSF Gemara Model Solve?
Software development has reached a velocity where traditional GRC cannot keep pace. Compliance activities exist as a separate administrative layer, disconnected from the engineering workflows they govern. The industry suffers from what Gemara’s creators call “split-brain” governance: multiple teams covering related problems without standardizing on philosophies, language, or data schemas [OpenSSF 2026]. A control defined in one tool cannot be automatically evaluated by another. Evidence collected in one platform requires manual mapping to satisfy a different framework. Every tool-to-tool handoff introduces rework, and that rework compounds across every audit cycle, every framework addition, and every organizational change.
The scale of the problem matches the scale of the threat. Open source downloads reached 9.8 trillion in 2025, up 67% year over year [Sonatype 2026]. Over 70% of organizations reported at least one software supply chain security incident during the same period [ReversingLabs 2026]. FedRAMP is mandating OSCAL-based machine-readable compliance by September 2026 [FedRAMP 2026]. The compliance infrastructure protecting these systems needs the same architectural clarity that the systems themselves already have.
Gemara addresses this by providing a logical model that describes the categories of compliance activities, how they interact, and the schemas to enable automated interoperability between them [OpenSSF 2026]. By decomposing activities into discrete layers, the model creates standardized documentation, a shared vocabulary, and a basis for collaborative maintenance of common resources. Organizations stop reinventing control definitions. Tool vendors stop building proprietary schemas. Auditors stop translating between platforms.
Map your current GRC toolchain against the seven Gemara layers described below. For each layer, identify which tool or process handles that function today. Layers with no tooling represent architectural gaps. Layers where two tools overlap without schema interoperability represent integration debt. Both categories are candidates for your next GRC engineering investment. Start with the fundamentals of GRC engineering if your team has not yet formalized this mapping.
The Seven Layers of the Gemara Architecture
Gemara organizes all GRC activities into seven categorical layers arranged in two groups with a pivot point between them. Layers 1 through 3 are Definition Layers: they establish what good security looks like for an organization. Layers 5 through 7 are Measurement Layers: they evaluate, enforce, and audit how well the organization adheres to those definitions. Layer 4 sits at the pivot point where policy requirements meet operational reality [OpenSSF 2026]. Each layer produces outputs that feed the layers above it, and every output follows a CUE schema that makes it machine-readable and interoperable across tools.
The architecture deliberately mirrors the OSI model’s separation of concerns. A change at Layer 1 (new regulatory guidance) propagates upward through controls and policies without requiring changes to evaluation or enforcement tooling. A change at Layer 5 (new evaluation technique) applies to existing policies without rewriting the underlying control definitions. This separation is what makes automation possible at scale.
Layer 1: Vectors and Guidance
The foundation layer. Activities here provide high-level rules pertaining to cybersecurity measures. Guidance is typically developed by industry groups, government agencies, or international standards bodies [OpenSSF 2026]. Think NIST Cybersecurity Framework, ISO 27001 Annex A, CIS Controls, and the EU Cyber Resilience Act. Layer 1 is stable by design: these are the enduring principles that rarely change and form the bedrock for everything above them.
Layer 2: Threats and Controls
Layer 2 translates foundational guidance into technology-specific objectives. The recommended process: assess the technology’s capabilities, identify threats to those capabilities, and develop controls to mitigate those threats [OpenSSF 2026]. The FINOS Common Cloud Controls project and the OpenSSF Open Source Project Security Baseline (OSPS Baseline) both operate at Layer 2, defining concrete technical controls derived from Layer 1 guidance. This is where abstract principles become testable requirements.
Layer 3: Risk and Policy
Layer 3 applies general frameworks to a specific organization’s context. Activities here provide risk-informed governance rules that, while based on best practices and industry standards, are tailored to the organization’s risk appetite, regulatory obligations, and operational constraints [OpenSSF 2026]. A Layer 2 control requiring encryption at rest becomes a Layer 3 policy specifying AES-256 encryption on all production databases using AWS KMS with annual key rotation. Compliance-as-code implementations translate Layer 3 policies into executable rules.
Layer 4: Sensitive Activities (The Pivot Point)
Layer 4 identifies the actions that might introduce risk: code commits, infrastructure deployments, access grants, configuration changes, third-party integrations. This is the pivot point where the Definition Layers meet the Measurement Layers. Every sensitive activity is a potential compliance event. The Gemara architecture formalizes this layer as a distinct category (per ADR-0009 in the project documentation) because the boundary between “what we require” and “how we verify” is where most compliance programs break down [OpenSSF 2026].
Layer 5: Intent and Behavior Evaluation
The first Measurement Layer. Activities here inspect sensitive activities to determine whether they align with intended outcomes [OpenSSF 2026]. This is where continuous compliance monitoring operates: scanning infrastructure configurations against policies, evaluating code changes against security requirements, and assessing deployments against approved baselines. The Privateer project, which includes the OSPS Baseline Plugin, provides tooling at this layer.
Layer 6: Preventive and Remediative Enforcement
Layer 6 implements corrective actions for noncompliance. When Layer 5 evaluation detects a deviation, Layer 6 responds: blocking a deployment, reverting a configuration change, triggering a remediation workflow, or escalating to a human reviewer [OpenSSF 2026]. This is the enforcement mechanism that converts monitoring from observation into action. Organizations at higher GRC engineering maturity levels automate Layer 6 responses, reducing the gap between detection and correction from days to seconds.
Layer 7: Audit and Continuous Monitoring
The top layer validates the efficacy of everything below it. Layer 7 activities review all previous outputs to determine whether the entire system works as intended [OpenSSF 2026]. This is where audit evidence aggregates, compliance posture dashboards generate, and continuous assurance reporting provides stakeholders with real-time visibility. Layer 7 feeds back into Layer 1 through 3 by identifying where definitions, controls, or policies need revision based on observed performance.
For each of the seven layers, identify one process in your organization that currently operates without a standardized schema. Layer 2 controls defined in spreadsheets. Layer 5 evaluations producing PDF reports instead of structured data. Layer 7 audit evidence stored in shared drives. Each unstructured output represents a manual handoff that Gemara’s CUE schemas are designed to eliminate. Prioritize the handoff that consumes the most hours per audit cycle. See API-driven audit evidence collection for implementation patterns.
How Does Gemara Connect to OSCAL, SLSA, and SBOM?
Gemara does not compete with existing standards. It provides the architectural framework that explains where each standard operates and how their outputs interoperate. NIST’s Open Security Controls Assessment Language (OSCAL) provides machine-readable formats for expressing security controls, assessment plans, and assessment results. In Gemara terms, OSCAL operates primarily at Layers 2 and 3 (control definitions and organizational policies) with outputs that feed Layer 5 evaluation and Layer 7 audit [OpenSSF 2026]. FedRAMP’s September 2026 OSCAL mandate means every cloud service provider selling to the federal government will need Layer 2 and 3 artifacts in machine-readable format [FedRAMP 2026].
Supply Chain Levels for Software Artifacts (SLSA) provides a security framework for software supply chain integrity. SLSA requirements map to Gemara Layers 4 and 5: Layer 4 defines the sensitive activities in the build pipeline (source control, build process, provenance generation), and Layer 5 evaluates whether those activities meet the SLSA level requirements. Software Bills of Materials (SBOMs) are Layer 4 artifacts: structured records of the components present in a software deployment, providing the raw data that Layer 5 evaluation tools use to assess vulnerability exposure and license compliance.
The power of the Gemara architecture is the connection between these standards. An SBOM (Layer 4) feeds a vulnerability evaluation (Layer 5) that triggers a remediation workflow (Layer 6) that generates audit evidence (Layer 7) that maps back to the control requirement (Layer 2) derived from NIST guidance (Layer 1). Every handoff follows a CUE schema. Every output is machine-readable. The entire chain runs without manual translation between tools or formats.
If your organization generates SBOMs, trace the data flow from SBOM generation through vulnerability assessment, remediation, and audit evidence. Count the manual handoffs. Each handoff is a point where Gemara’s schema-based interoperability eliminates rework. Organizations already using OSCAL for FedRAMP should map their OSCAL artifacts to Gemara layers to identify where the automation pipeline has gaps between control definition and evidence generation.
What Makes CUE Schemas the Foundation of Gemara Interoperability?
Gemara uses CUE (Configure, Unify, Execute) as its schema language, and the choice is deliberate. CUE combines data validation, configuration, and code generation into a single language that enforces types and constraints at the schema level [OpenSSF Gemara GitHub]. The project repository at github.com/ossf/gemara contains 315 commits across 50+ releases (v0.22.0 as of March 2026), with the codebase split between Go (61.7%) and CUE (31.5%) [GitHub ossf/gemara]. A Go SDK (go-gemara) provides programmatic access to Gemara schemas for tool developers building integrations.
The CUE schemas standardize how every layer expresses its outputs. A Layer 2 control definition follows the same schema structure whether it comes from the FINOS Common Cloud Controls project, the OpenSSF OSPS Baseline, or an organization’s internal control library. A Layer 5 evaluation result follows the same schema whether it comes from Privateer, a commercial scanning tool, or a custom pipeline. This schema consistency is what makes cross-tool interoperability possible without custom integrations for every tool pair.
For GRC engineers, CUE schemas solve a specific problem: validation at the boundary. When a Layer 3 policy references a Layer 2 control, the CUE schema validates that the reference is valid and the policy’s requirements are compatible with the control’s specification. When a Layer 5 evaluation produces evidence against a Layer 3 policy, the schema validates that the evidence format matches what Layer 7 audit expects to consume. Every layer-to-layer handoff carries built-in validation. Bad data fails at the boundary instead of propagating through the system and surfacing as an audit finding months later.
Evaluate your current compliance data formats. If controls live in spreadsheets, policies in Word documents, and evidence in PDFs, every layer-to-layer handoff requires human translation. Start by converting one Layer 2 control set to structured data (JSON or YAML). Then validate it against the Gemara CUE schemas available in the project’s CUE registry. This single conversion demonstrates the interoperability benefit and establishes the pattern for migrating additional layers. Non-human identity governance provides a practical example of structured control definitions.
How Should Organizations Adopt the Gemara Model?
Gemara is not a product to deploy. It is an architectural model to adopt, the same way organizations adopted the OSI model: as a shared reference for designing, building, and evaluating systems. The founding maintainers from Sonatype and Red Hat, along with contributors from the CNCF TAG-Security community, designed the model to be stable and rarely changing at its core, because it reflects the longstanding reality of GRC activity types [OpenSSF 2026]. The schemas and tooling on top of the model evolve rapidly. The layer definitions do not.
Adoption starts with mapping. Take your existing GRC stack and plot every tool, process, and artifact against the seven layers. Most organizations discover that Layers 1 through 3 are well-covered (they have guidance, controls, and policies) but Layers 4 through 7 contain gaps, manual processes, or tools that produce outputs in proprietary formats. The Measurement Layers are where automation delivers the most value and where schema standardization eliminates the most rework.
The CNCF Automated Governance Maturity Model, which preceded Gemara, provides a self-assessment framework with over 50 independent practices across four categories: Policy, Evaluation, Enforcement, and Audit [CNCF 2025]. Organizations can use the AGMM to assess their current maturity across Gemara’s Measurement Layers and build a prioritized roadmap for adoption. The ORBIT Working Group within OpenSSF provides the community forum for organizations implementing Gemara and contributing to its development.
For organizations already using OSCAL, SLSA, or SBOM standards, Gemara provides the connective architecture. The model does not require replacing existing tools or abandoning current frameworks. It provides the layer taxonomy that explains how those tools relate to each other and the schema standards that make their outputs interoperable. The goal is not another platform. The goal is a shared language that makes every platform in the compliance stack work together without custom integration.
Begin with a 90-minute workshop: assemble your compliance, security, and engineering leads. Present the seven Gemara layers and ask each team to identify which layers they own. The conversation itself reveals organizational gaps. Teams that cannot name the owner of Layer 6 (enforcement) or Layer 7 (continuous monitoring) have identified their highest-priority GRC engineering investments. Use the CNCF Automated Governance Maturity Model as the self-assessment tool for the Measurement Layers.
The OpenSSF Gemara model is not the next compliance product. It is the architectural taxonomy that compliance products have needed since the first GRC platform shipped without a standard way to describe what it does. Organizations that adopt Gemara’s seven-layer framework gain a shared language for GRC engineering, CUE-schema interoperability across tools, and a clear map showing exactly where their compliance automation has gaps and where it already works.
Frequently Asked Questions
What is the OpenSSF Gemara model?
Gemara is a seven-layer architectural model for GRC engineering released by the Open Source Security Foundation in March 2026. The acronym stands for Governance, Risk, and Compliance Engineering Model for Automated Risk Assessment. It decomposes compliance activities into seven categorical layers with CUE-based schemas for machine-readable interoperability, similar to how the OSI model standardized networking [OpenSSF 2026].
How does Gemara differ from NIST OSCAL?
OSCAL provides machine-readable formats for expressing security controls, assessment plans, and results. Gemara provides the architectural framework that defines where OSCAL operates within the broader GRC stack. OSCAL primarily addresses Layers 2 and 3 (controls and policies) in the Gemara model. Gemara covers all seven layers, including sensitive activities (Layer 4), enforcement (Layer 6), and continuous monitoring (Layer 7), areas OSCAL does not address directly [OpenSSF 2026].
What are the seven layers of the Gemara architecture?
The seven layers are: Layer 1 Vectors and Guidance (foundational regulations), Layer 2 Threats and Controls (technology-specific objectives), Layer 3 Risk and Policy (organization-specific rules), Layer 4 Sensitive Activities (the pivot point where definition meets measurement), Layer 5 Intent and Behavior Evaluation (inspection of activities), Layer 6 Preventive and Remediative Enforcement (corrective actions), and Layer 7 Audit and Continuous Monitoring (efficacy review) [OpenSSF 2026].
How does the Gemara model relate to software supply chain security?
Software supply chain attacks doubled globally in 2025, with open source malware growing 75% to 1.23 million known malicious packages [Sonatype 2026]. Gemara provides the architectural framework for connecting supply chain security tools: SBOMs map to Layer 4, SLSA requirements span Layers 4 and 5, vulnerability evaluation operates at Layer 5, and remediation enforcement at Layer 6. The CUE schemas enable automated data flow across this entire chain.
What tools currently implement Gemara schemas?
Three projects actively implement Gemara Layer 2 schemas: the FINOS Common Cloud Controls project, the OpenSSF Open Source Project Security Baseline (OSPS Baseline), and the Privateer security tooling project with its OSPS Baseline Plugin at Layer 5 [OpenSSF Gemara GitHub]. The Go SDK (go-gemara) provides programmatic access for developers building custom integrations. The project has 50+ releases as of March 2026.
How do you start adopting the Gemara model?
Start by mapping your existing GRC stack against the seven layers. Identify which tools handle each layer, where gaps exist, and where outputs use proprietary formats instead of standardized schemas. Most organizations find strong coverage in Definition Layers 1 through 3 and gaps in Measurement Layers 5 through 7. Use the CNCF Automated Governance Maturity Model to assess your readiness across the measurement categories [CNCF 2025].
Does Gemara replace existing compliance frameworks like SOC 2 or ISO 27001?
Gemara does not replace any compliance framework. SOC 2 trust service criteria and ISO 27001 Annex A controls operate at Layer 1 (guidance) and Layer 2 (controls) within the Gemara architecture. Gemara provides the taxonomy for organizing how those frameworks are implemented, evaluated, enforced, and audited across Layers 3 through 7. Organizations adopt Gemara alongside their existing frameworks, not instead of them.
What is the relationship between Gemara and the CNCF Automated Governance Maturity Model?
Gemara evolved from the CNCF Automated Governance Maturity Model (AGMM), which was developed by TAG-Security contributors including Eddie Knight, Matt Flannery, and Jon Zeolla [CNCF 2025]. The AGMM provides a self-assessment framework with over 50 practices across four categories (Policy, Evaluation, Enforcement, Audit). Gemara extends this foundation into a full seven-layer architecture with CUE schemas for automated interoperability across the entire GRC stack.
Get The Authority Brief
Weekly compliance intelligence for security leaders. Frameworks decoded. Audit strategies explained. Regulatory updates analyzed.
