The presence of .blob.core.windows.net in our DIG outbound proxy whitelist as it’s a DLP risk is there solution to mitigate the risk?

@Ravikumar Eswarappa I hope you are doing well,

The presence of *.blob.core.windows.net in your DIG outbound proxy whitelist poses a Data Loss Prevention (DLP) risk because it allows broad access to Azure Blob Storage, potentially enabling unauthorized data exfiltration or access to sensitive data. Whitelisting the entire domain is necessary for many Azure services, like Azure DevOps (ADO), which dynamically create blobs, but this broad access increases exposure.

Spin up self-hosted build/​release agents inside your own VNet. • Configure a Private Endpoint for the storage account that Azure DevOps uses (you’ll need to query your Org’s artifact store to find the storage account name, e.g. orgXYZ[GUID].blob.core.windows.net). • Lock down the storage account’s firewall to only your VNet. • Your on-prem/​cloud-hosted agents communicate over private IP—no public DNS/IPs needed.

Pros:

Only one blob account is reachable.

All public blob.core.windows.net is blocked.

Cons:

You must operate self-hosted agents.

You need to discover and maintain the target storage account name.

By implementing private endpoints and firewall rules, you can significantly reduce DLP risks while supporting ADO’s dynamic blob usage, avoiding the need for broad *.blob.core.windows.net whitelisting. Let me know if you need help with setup or have additional details!

If all your concerns have been resolved, I would greatly appreciate it if you could mark the answer as "Accepted." This helps both us and others in the community.