Provide Trusted Contributors with the ability to import data in opencre.org

Status: Blocked — Auth Work v2

This issue is not ready for implementation. Maintainer direction is to sequence trusted-contributor import capabilities after the auth foundation and role model land. Do not assign or start implementation work against this issue until the dependencies below are complete.

Dependency chain (in order)

1. Auth foundation (v1) — Stable, persistent user identity and OAuth session contract per the User Authentication and MyOpenCRE RFC (merged in #876). Track implementation via:

   • #963 — migrate OAuth routes to /rest/v1/auth/*
   • #943 — frontend useUser hook and header auth UX
   • #949 — GET /api/capabilities feature-flag contract
   • #966 — auth-wrap MyOpenCRE CSV import (deprecate anonymous import)

2. Roles (Auth v2) — Extend auth with a role model that introduces the concept of a trusted contributor (distinct from anonymous users and from full maintainers). Role assignment, enforcement, and admin UX are part of this step; no issue number yet — design alongside auth v1 completion.

3. Trusted-contributor capabilities (this issue) — Once (1) and (2) are done, grant trusted contributors access to:

   • MyOpenCRE import — authenticated mass-import UI/API (today restricted to code maintainers running import scripts)
   • GSoC ingestion pipeline — the autonomous LLM-assisted cheat-sheet → CRE mapping workflow per the Cheatsheets LLM Autonomous Mapping RFC and the broader OWASP living knowledge base design (docs/owasp-graph/)

Blocked until: auth v1 (#963 and related) and the roles/trusted-contributor model are implemented and deployed.

Background

What is the issue?

Currently, new data in opencre.org can be inputted by way of a code-maintainer running an import script. This is inefficient as it greatly restricts who can import data and forces a hard coupling between code maintainers and data authors.

Expected behaviour

Data authors who are trusted contributors should have a strongly authenticated UI which allows them to easily mass-import data into opencre.org. They should also be given the freedom to either manipulate or replace individual mappings. However, special care should be taken to preserve CRE immutability.

Possible implementations (deferred — revisit after Auth v2)

Admin panel connected to an IdP

There is an admin page which uses OpenID Connect and an external identity provider (e.g. Okta) to authenticate a data author. Data authors could provide an email address which, when added to an identity provider solution, gives them access to said admin panel. From there they can provide the URL of a spreadsheet that fits the mapping template and the backend runs the equivalent of python cre.py --add --from-spreadsheet <url>.

Pros: industry-standard solution; on-prem users can hook their own IdP.

Cons: needs an external IdP solution; maintenance burden.

Note: With Auth v1 using Google OAuth and a future trusted-contributor role model, the IdP approach above may be superseded or narrowed. Re-evaluate implementation options once dependencies (1)–(2) are complete.

Related

• Parent/epic: #586 — user accounts and MyOpenCRE online
• Auth RFC: docs/rfc/user-auth-myopencre.md
• GSoC / ingestion RFC: docs/rfc/cheatsheets-llm-autonomous-mapping-rfc.md

Do not start until auth v1 (#963 and related work) and the trusted-contributor role model are deployed. Read docs/rfc/user-auth-myopencre.md, docs/rfc/cheatsheets-llm-autonomous-mapping-rfc.md, and the existing python cre.py --add --from-spreadsheet <url> flow. Done means trusted contributors have authenticated import access for MyOpenCRE and GSoC ingestion while CRE immutability is preserved.