OWASP / OWASP/openshield

feat: publish per-collector permission and evidence manifest

Open
#265 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

core enhancement priority: high stale
Dominant language
Python
Stars
57
Forks
68
Avg merge
3d 15h
Merged PRs (30d)
17

Description

What problem does this solve?

Future identity-correlation and attack-path work needs to know, per fact/edge, where it came from
and whether collection was complete. A partial Microsoft Graph failure (e.g. group expansion not
authorized) is currently indistinguishable from "there are no groups" — silently treating missing
edges as safe would make any future attack-path graph overstate what's actually known.

Describe the solution

  • Every collector (ARG, ARM, RBAC, Microsoft Graph, optional AKS data-plane) records source,
    timestamp, and a completeness/confidence flag for what it collected.
  • Expose an aggregate coverage score so any consumer (UI, campaign detector, future attack-path
    work) can tell "fully collected" apart from "partially collected, reduced confidence."
  • Exit test: every correlation edge in any future graph work carries provenance and freshness
    fields — no edge without them.

Alternatives considered

Defer until attack-path work actually starts — rejected; retrofitting provenance onto edges after
a graph model exists is far more expensive than building it into every collector from the start,
and PR #250 already establishes the complete/partial/failed pattern this should extend.

Additional context

Should land alongside or shortly after PR #250.

Coordination

This issue is the evidence/provenance layer the enterprise-rule packs rely on to handle
incomplete collection conservatively (e.g. partial Microsoft Graph results treated as reduced
confidence rather than "safe"). It builds on PR #250's complete/partial/failed pattern and
coordinates with the enterprise-rule packs that depend on per-collector completeness signals:
#254, #257, #258, #262.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading PR #250's complete/partial/failed pattern, then inspect the ARG, ARM, RBAC, Microsoft Graph, and optional AKS collectors named in the issue. Trace how their results feed the enterprise-rule packs and future correlation edges. Done means each collector records source, timestamp, and completeness or confidence, an aggregate coverage score is exposed, and correlation edges carry provenance and freshness.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, python
Domain
backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.