OID-See v1.0.1: Small Release, Sharper Edges

OID-See v1.0.1 is out 🎉

This is a precision release.

No shiny new dashboards.
No dramatic architectural upheaval.
Just tighter logic, fewer false positives, and a scoring model that better reflects how Entra actually behaves in the real world.

If you’re already using OID-See, this release should feel immediately calmer - and more trustworthy.

👉 Release: https://github.com/OID-See/OID-See/releases/tag/v1.0.1

Why this release exists

As more people started using OID-See against real tenants (including very large and very messy ones), a few things became clear:

• Some signals were technically “true” but operationally misleading
• Some risk factors needed context gating, not raw scoring
• A couple of heuristics were doing too much too early

v1.0.1 is about fixing that.

This release is the result of:

• Dogfooding against production Entra tenants
• Feedback from identity architects and defenders
• Me getting annoyed at my own tool for shouting when it shouldn’t 😄

What’s changed in v1.0.1

🔧 App role assignment risk — fixed

Previously, apps with appRoleAssignmentRequired = false could still pick up elevated risk purely due to assignment counts.

That’s backwards.

In v1.0.1:

• Assignment count alone no longer materially increases risk
• Exposure is correctly driven by “assignment not required”
• Privileged roles and scopes are now the deciding factor

This dramatically reduces noise for:

• Microsoft first‑party apps
• Broadly accessible SaaS integrations
• Legitimate enterprise tooling

👤 Ownership: governance vs security

Apps with no owners were previously treated as a security risk. Per Glenn Van Rymenant’s analysis, this increases risk rather than indicating security hygiene. Apps with no owners have reduced mutation attack surface; apps with user owners have highest risk.

In reality:

• This is often a governance gap
• Especially common with third‑party and gallery apps

Now:

• “No owners” is flagged as a governance issue
• It no longer inflates core security risk scoring
• Still visible, still actionable - just correctly classified

🎭 Deception logic — gated and smarter

The deception heuristic has been tightened significantly.

Previously, publisher/app name mismatches could trigger deception signals even when:

• The app was unverified
• The publisher surface wasn’t trustworthy to begin with

In v1.0.1:

• Deception checks are gated behind verifiedPublisherId
• Additional logic handles identity‑laundering patterns, such as:
  • Microsoft‑looking publisher names
  • MSA‑style tenants
  • Non‑Microsoft reply URLs and domains

Result: fewer false alarms, stronger signals when it really matters.

What didn’t change (on purpose)

• The data model
• The JSON schema
• The graph visualisation approach
• The “explainable risk” philosophy

This release is intentionally conservative.
No breaking changes. No schema churn.

What’s next

v1.0.1 clears the ground for bigger things:

• Better signal composition
• More defensible scoring explanations
• Cleaner separation between security risk, governance risk, and design trade‑offs
• Deeper first‑party vs third‑party differentiation

If you’re using OID-See to support:

• Identity risk assessments
• App governance conversations
• Conditional Access strategy
• “Why is this risky?” discussions with stakeholders

This release should make those conversations easier.

Feedback welcome (seriously)

OID-See is shaped by real‑world usage.

If you spot:

• Scoring that feels off
• Signals that lack context
• Things that make you mutter “yeah but…”

Open an issue, start a discussion, or shout at me on LinkedIn / Slack / Mastodon.

Because tools should get better the more they’re used - not louder.