By Eddie Knight, Hannah Braswell, and Jenn PowerÂ
Software development has reached a point where traditional Governance, Risk, and Compliance (GRC) can no longer keep up. Compliance activities often exist only as a separate administrative layer, making it difficult for organizations to prove that security measures are in place long after the work is complete.
To tackle this problem head on, the industry has seen the rise of GRC Engineering and related topics such as policy-as-code or compliance-as-code. Yet, there have been massive alignment gaps pertaining to interoperability between tools, teams, and organizations. At the core, the industry suffers from split-brain attempts to cover related problems without standardizing on philosophies, language, or data schemas.
To enable a global standardization effort by beginning with philosophical alignment, we are excited to announce the publication of Gemara: A Governance, Risk, and Compliance Engineering Model for Automated Risk Assessment.
What’s Inside?
This model provides a structure designed to categorize compliance activities and define their functional interactions. These are activities which are inherent to governance and have existed in practice, but lacked a unified engineering architecture with predictable points of exchange. By decomposing these activities into discrete layers, the model facilitates standardized documentation, shared language, and creates a basis for collaborative maintenance of common resources.
The model stems from the CNCF’s Automated Governance Maturity Model. It also incorporates lessons from prior art, such as NIST’s OSCAL, the FINOS Common Cloud Controls project, and the OpenSSF’s Open Source Project Security Baseline.
Just as the OSI Model gave us a common language for networking, Gemara provides a seven-layer architecture, detailing separation of concerns for the GRC stack:
- The Definition Layers (1-3): These layers define what “good security” actually looks like for an organization.
- The Pivot Point (4): This is where policy requirements meet real-world operational activities.
- The Measurement Layers (5-7): These cover the techniques used to evaluate, enforce, and audit how well you’re sticking to those security definitions.
This structure ensures every stakeholder (and tool) has a clear place in the system. For teams looking to treat GRC as an engineering discipline rather than a checklist, the Gemara model offers a practical way forward.
Join Us
The Gemara Project is an open source initiative stewarded by the OpenSSF with founding maintainers from Sonatype, Red Hat, and more.
- Learn about the model [Link]
- Explore the schemas and SDKs on available on GitHub [Link]Â
- Join the ORBIT Working Group [Link]
- Explore OpenSSF Membership [Link]
About the Authors
Jenn Power is a Principal Product Security Engineer at Red Hat where she leads upstream collaboration and cross-industry initiatives centered on automated governance and security data standardization. She serves as a Tech Lead for CNCF TAG Security and Compliance, a member of the ORBIT Working Group, and a maintainer of the OpenSSF Gemara project.
Hannah Braswell is an Associate Product Security Engineer at Red Hat, where she focuses on compliance automation and developing enablement tooling for compliance analysts. With a B.S. in Computer Engineering from NC State University, she brings a deep background in microarchitecture and embedded systems to her work in the open-source ecosystem. Hannah currently serves as the Community Manager for the OpenSSF Gemara project, driving collaboration and security enablement across the community.
Eddie Knight is a Software and Cloud Engineer with a background in banking technology. When he isn’t playing with his 3-year-old son, he combines his passion and job duties by working to improve the security of open source software. Eddie currently helps lead several security and compliance initiatives across the CNCF, OpenSSF, and FINOS.