Wiki · Concept · Last reviewed June 25, 2026

OpenCRE

OpenCRE is OWASP's Open Common Requirement Enumeration: a catalog and mapping layer that links security requirements across standards, guidelines, cheat sheets, tools, threats, and weaknesses.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI governance, security requirements, OpenCRE, OWASP, control mapping, agent security

Definition

OpenCRE is the Open Common Requirement Enumeration. The OWASP OpenCRE repository describes it as an interactive content-linking platform for uniting security standards and guidelines, with a public application at opencre.org, a catalog of Common Requirements, mapping data from those requirements to sections of standards, and tools for contributing or running the application.

OpenCRE is not a control framework, certification, audit result, or proof that a system is secure. It is a cross-reference layer. A Common Requirement can act as the hub between overlapping sections of standards, guides, weaknesses, threats, testing instructions, and countermeasures. The governance value is not that OpenCRE replaces the source standards; it helps readers find how several standards talk about the same security idea.

For AI and agent systems, that matters because a deployed system may be governed by security engineering, model-risk, privacy, procurement, and audit teams at the same time. Requirements for secrets handling, logging, identity, input validation, dependency review, and access control often live in different documents. OpenCRE gives teams a way to keep those conversations connected.

How It Works

OpenCRE works by mapping sections of a source standard or guide to a Common Requirement, usually identified by a CRE number. The contributing guidance says a mapping for a new standard assigns each relevant section to the corresponding Common Requirement at opencre.org. Once several sources are mapped to the same requirement, a reader can move from one standard's wording to related material in other sources.

The OWASP Developer Guide describes OpenCRE as a catalog of security requirements that enumerates security topics and links to standards, cheat sheets, and guides. It lists examples such as CWE, NIST Special Publications 800-53 and 800-63, OWASP ASVS, OWASP Top 10, OWASP Proactive Controls, OWASP Cheat Sheets, OWASP WSTG, and ZAP.

The OpenCRE repository also describes the software side: a Python web and command-line application, public hosting at opencre.org, catalog data, mapping data, and tooling for local or private use. That matters for governance because a team can inspect mappings as data rather than treating each crosswalk as a hand-edited spreadsheet.

Agent Context

AI agents turn security requirements into operating boundaries. A coding agent may install packages, edit workflows, call model APIs, read secrets, open pull requests, or route work through remote tools. A business agent may query private records, send messages, update tickets, or trigger payments. The same action can raise application-security, identity, privacy, supply-chain, logging, and human-oversight requirements.

OpenCRE can help an agent team avoid requirement drift. Instead of saying "we comply with security standards" in the abstract, the team can map a concrete agent control, such as tool authorization or secret handling, to a requirement hub and then review the linked guidance. The result is a better evidence trail for procurement, secure development, red-team planning, and post-incident review.

The limit is important: OpenCRE does not decide whether an AI model is reliable, whether a particular use is lawful, or whether an agent should be allowed to act. It can organize security-control references around the systems that contain the model.

Governance and Safety

The governance value is crosswalk discipline. Institutions often face many partly overlapping frameworks. Without a shared requirement map, the same control may be reviewed three times under different names, while a real gap remains unseen. OpenCRE can reduce that fragmentation by making the links explicit.

The main failure mode is crosswalk theater. A mapped requirement is not the same as an implemented control. A control that appears in ASVS, NIST guidance, or a cheat sheet still needs a system owner, evidence, test result, exception process, and review date. OpenCRE helps locate related requirements; it does not perform the engineering, assessment, or risk acceptance.

Defense Pattern

Source Discipline

Claims about OpenCRE should distinguish the project from the mapped sources. The OpenCRE repository and OWASP Developer Guide are appropriate sources for what OpenCRE is, how mappings work, and which examples OWASP lists. They are not substitutes for the original NIST, OWASP, CWE, or other source documents when making a compliance claim.

For AI governance, source discipline also means naming the layer. A security requirement for a tool gateway is not the same as a model evaluation, a privacy impact assessment, a legal approval, or an AI safety case. OpenCRE can help with security-requirement navigation, but it should not be stretched into a general proof of AI trustworthiness.

Spiralist Reading

Spiralism reads OpenCRE as a map against institutional amnesia.

The machine age multiplies standards, dashboards, and assurances until every team can claim a different vocabulary. OpenCRE does not end that disorder. It asks a humbler question: when several texts name the same security need, can the institution remember the connection and show what it actually did?

Open Questions

Sources

Return to Wiki