Salesforce, Python, SQL, & other ways to put your data where you need it

Microsoft wishlist

18 May 2026 🔖 professional development
💬 EN

Table of Contents

Hi, Microsoft! Here’s that wishlist I approached you about toward the end of the day at the Linux Foundation’s Open Source Summit:

1 - JIT AuthZ

Entra-native / access-control-platform-native (e.g. Azure-RBAC-native / Entra-App-Role-native) “just-in-time authZ elevation” / “PIM” / “eligible, but not active unless there is proof of fresh human intent/approval and only active for a limited timespan” authorization (authZ) for workload identities.

We’ve already got machine-gets-stuck-until-human-approves flows with Azure Pipelines deployment approval checks and GitHub Actions environment approvals.

Let’s make things where Entra service principals are eligible for certain privileged access control grants, but has to wait to move forward because it only active after the machine requests escalation if one of a designated Entra group of humans personally approves it.

  • I’ve wanted this even back when machines were all deterministic.
    • (Again, we already have an implementation in ADO and GH CI/CD; we just didn’t have it more generally/natively for all Entra-attached authZ platforms).
  • But now I really want it in the era of nondeterministic machines running around doing things.

See my blog post “Securing authenticated agentic AI.”

  • (Say, what was that standards organization you suggested I get involved with? I-something-something-F, maybe?)

2 - CDEvents

Please jump with both feet into the CDEvents protocol pool.

Please make both GitHub and Azure DevOps natively publish events and natively subscribe to / consume events.

CDEvents is as impactful as OpenTelemetry! (Which Azure Monitor invested in becoming capable of consuming, and Azure Application Insights invested in becoming capable of producing.)

Particularly because CDEvents can be used as a form of infosec-critical observability, e.g. to centrally monitor whether every CI pipeline run is also accompanied by a corresponding SBOM generation run, etc. In the post-Sha1-Hulud era, enterprises need CDEvents publication yesterday out of our hyperscaler-owned CI/CD platforms.

  • (Making GH/ADO able to subscribe to / consume CDEvents is probably less urgent than making them able to publish / produce CDEvents, as a question of security. Even if I also think subscribe/consume nonetheless seems important as a question of developer experience.)

3 - Provenance

GitHub, I loved your “Code-to-cloud risk visibility with Microsoft Defender for Cloud is now generally available” blog post, but I was heartbroken it only applies to containerization.

Azure App Service team, can you please partner with the Defender team and the GitHub team (and Azure DevOps team, for that matter!) to find a way to provide the same type of attestation/provenance party tricks when simply running an npm run build CI/CD build step followed by an azure/webapps-deploy CI/CD deploy step?

Easy-button “Buy” application developers deserve provenance just as much as hard-mode “Build” (container-trained) application developers! 🥰

I know that azure/webapps-deploy is just making a .zip file and throwing it over the fence at Azure App Service over HTTPS, which isn’t inherently as “hashed” as container-building is, and that Kudu potentially lets Azure App Service owners introduce drift even after that, but …

Could you find a way somehow, maybe, at least for the happy path?

I really like the idea of it being obvious that:

  1. “this Azure App Service resource GUID’s contents were last built from this Git commit SHA” and, in the other direction,
  2. “this Git commit SHA was deployed into this Azure App Service resource GUID.”

Thanks so much!

--- ---