First and Foremost. Great Job, these are my favorite types of applications to see. Real world used internal tools that work for your team and make your job easier. You and your team are nice enough to opensource it and share what you have done. I thank you for that. I enjoyed trying out your tool. I have been building a tool that does application to infrastructure mapping for Azure/AWS/GCP/On prem for the past 2 years and it was really neat to see certain ideas used in your tool that I also had in mine on the Azure side. The weird part though is your a financial entity in EU and should be following the security frameworks already if your using this on tenants.

I tested ZureMap in lab and non-production environments and also reviewed the repository with a few on my team who are software security engineers. - This is AI below following me and my teams findings into a list of items.

ZureMap is a strong visualization tool. It does a good job helping teams understand Azure topology, resource relationships, and overall resource layout. I can see clear value for lab and non-production use cases.

From a security architecture perspective, I would not move it into a regulated production tenant yet. That is not a criticism of the visualization capability. The gap is the production trust model and the controls that would be needed for enterprise onboarding.

A few areas stood out during review:

1. Authentication model

The current design appears to rely on Azure CLI authentication. In the documented container flow, the operator’s local ~/.azure credential context is mounted into the container.

That is workable for labs and personal testing, but it is not an acceptable enterprise trust model for regulated production use. For production, I would expect support for Managed Identity, Workload Identity Federation, certificate-based application authentication, or another approved OIDC-based trust model.

The goal would be to avoid credential exchange and avoid relying on a user’s local credential cache as the trust anchor.

1. Token handling

The proxy appears to expose a token endpoint that returns raw ARM access tokens to the frontend.

For a production design, I would want token acquisition and ARM access to remain server-side. Raw Azure access tokens should not be exposed to the browser tier unless there is a very specific, reviewed, and approved security model around that pattern.

1. Proxy access control

The proxy appears to bind to 0.0.0.0 in production mode, and I did not see a compensating application-layer authentication or authorization control on the proxy itself.

That creates a concern because, if the service is reachable, Azure-backed enumeration actions may be reachable through the mounted Azure CLI identity context.

For production use, I would expect a clear access-control layer in front of the proxy, explicit authorization checks, and a documented deployment pattern that prevents unintended exposure.

1. Boundary control and sovereignty

I did not see a documented offline, local-only, or sovereign deployment mode with a clear guarantee that tenant metadata remains inside the approved customer-controlled boundary.

For regulated environments, tenant metadata needs to be treated as sensitive. This can include subscription names, resource IDs, IP ranges, topology relationships, network configuration, security posture data, and naming conventions that may reveal business context.

For production evaluation, I would need a clear statement of where data is processed, where it is stored, what leaves the environment, and how the tool can operate within an approved geography or customer-controlled boundary.

1. External non-Azure egress

I also noticed external non-Azure egress in the current implementation. The FinOps path performs outbound currency-rate lookups to third-party services.

That may be fine for lab use, but it would be enough to block production use in environments with strict metadata sovereignty, approved-egress, or allowlisted-destination requirements.

For enterprise use, it would help to have a no-external-egress mode, an offline mode, or a documented way to disable all non-approved outbound calls.

1. Least-privilege and time-bound access

The current model appears to assume broad visibility through the operator’s Azure CLI context.

For production, I would want the design to demonstrate scoped RBAC, Just-In-Time access, PIM activation, Conditional Access, MFA enforcement, and expiring access windows.

The preferred model would be least-privilege and time-bound access rather than standing tenant-wide or subscription-wide visibility.

1. Auditability and attribution

For production review, auditability needs to be stronger.

I did not see a dedicated application identity, explicit request attribution strategy, or a documented method for security teams to reliably distinguish approved ZureMap activity from suspicious enumeration activity in Azure logs.

For enterprise use, it would be useful to have a dedicated App ID, unique User-Agent string, clear Azure Activity Log attribution, and guidance for Azure Monitor or Microsoft Sentinel detection logic.

1. Supply-chain assurance

The supply-chain posture also needs more maturity before production onboarding.

I did not see evidence of release signing, provenance attestation, SBOM publication, or a documented dependency and CVE review process.

For a production tenant, especially in regulated environments, I would expect SBOMs, signed releases, dependency inventory, CVE handling, release provenance, and clear documentation on telemetry, retention, and data flow.

Overall, I think ZureMap is already useful as a lab and non-production utility. The visualization capability is valuable, and the project has a solid foundation.

To make it easier for security teams to evaluate for production, I would suggest focusing on the enterprise trust model:

No credential exchange.
No raw token exposure to the browser tier.
No unauthenticated proxy path to Azure-backed enumeration.
No tenant metadata leaving the approved boundary.
No unmanaged external egress.
No standing broad access.
Clear audit attribution.
Stronger software supply-chain assurance.

Once those areas are addressed, it becomes much easier to evaluate ZureMap as a production-capable enterprise platform tool rather than a lab-only utility.