Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-10-05 14:46:55 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
bcquality/custom/knowledge/architecture/exposed-objects-must-be-in-a-permission-set.md
Michael Dieringer dd5637b1db Custom-laget bestaar nu begge CI-checks: 72 validator-fejl -> 0 
Normalisering af alle 39 custom knowledge-filer til READ-kontraktens
skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne):

- R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer
  (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6
  kraevede noegler; keywords haandskrevet pr. fil da de driver
  worklist-selektionen i INDEX/knowledge-index
- R09: manglende Description-sektion - regel-agtige foersteoverskrifter
  (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat
  efter titlen hvor intro-tekst fandtes
- R10: fenced code blocks konverteret til 4-space indrykkede blokke
  i alle filer (indhold uaendret)
- R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk
  tab (ai-eval-scores 143->100, git-lifecycle 121->97,
  permission-sets 113->99, test-feature-scenario-tags 105->91)
- R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet
  til maks 10

Ingen regler er fjernet eller aendret i betydning - kun form.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-01 23:47:31 +02:00

2.1 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
architecture
permission-set
api-page
web-service
exposure
security
al
w1
all

Exposed objects must be in at least one permission set

Description

Rule (CURABIS-ARCH-011): Every exposed object in a CURABIS app must be a member of at least one permission set shipped by that app. "Exposed" means any object reachable from outside the app's own UI:

  • API pages (PageType = API)
  • Web-service-enabled pages and queries (ServiceEnabled = true, published web services)
  • API queries

Why

An exposed object that is in no permission set is unusable and invisible to the users and service identities that are supposed to call it. This is exactly how the MCP API pages (CUR MCP Projects, CUR MCP Active Tasks, CUR MCP Task Comments) failed: the tables behind them were granted, but the pages themselves had no = X execute permission, so the MCP server could not see or call them.

It is also a governance gap: an endpoint that nobody deliberately put in a permission set is an endpoint nobody is deciding who may reach. Exposure must be an explicit choice.

How to apply

  1. For every exposed object, add an execute entry (page "..." = X, query "..." = X) to a permission set in the app.
  2. Sensitive endpoints go in a dedicated admin permission set (e.g. CUR ... Admin) that is not part of the default assignable set — so reaching them is a deliberate grant, not the default.
  3. If an object should not be reachable from outside at all, remove the exposure instead (drop PageType = API / ServiceEnabled) rather than leaving an orphaned endpoint.

How to check

Scan the app for exposed objects and verify each is referenced in a permission set:

  • find every PageType = API, ServiceEnabled = true, and API query
  • confirm each appears as a page/query = X entry in at least one permissionset
  • flag any exposed object with no permission-set membership

A reviewer (or an automated check) should fail the change if an exposed object is missing from every permission set.