Skip to navigation
Research and SpikesMalware Scanning Approach

Malware Approaches

This page describes three malware scanning approaches for files uploaded to Azure Blob Storage containers. Each approach reflects a different tradeoff between response timing, cost, and operational complexity

Approach 1: Fully Asynchronous Malware Scanning using Defender for Storage

Overview

  • File is uploaded and immediately persisted to an untrusted Blob Storage container
  • Malware scanning is triggered automatically by Defender for Storage
  • Scan results are published asynchronously via Event Grid and Service Bus
  • Downstream systems react to scan outcomes

Sequence Diagram

High-Level Flow

  • Client -> File Intake API: POST upload request
  • File Intake API -> Blob Storage: Upload file to untrusted container
  • Blob Storage -> Defender for Storage: Trigger malware scan
  • Defender for Storage -> Event Grid -> Service Bus: Publish scan result
  • Downstream consumer processes scan result
  • File is promoted, quarantined, or deleted based on outcome

API Responses

  • Upload accepted: HTTP 200 Upload accepted
  • Malware status is not returned synchronously

Cost Drivers

  • Defender for Storage per-GB scanning
  • Blob storage transactions
  • Minimal Event Grid and Service Bus usage

Operational Considerations

  • No compute, patching, or scaling logic required
  • Highly scalable and predictable cost model
  • Requires clear downstream handling of scan outcomes
  • Files must be treated as untrusted until a clean result is received

Approach 2. Asynchronous Malware Scanning with Short Poll Window

Overview

  • File is uploaded immediately to Blob Storage
  • Malware scanning occurs asynchronously using Defender for Storage
  • API polls Service Bus for a bounded time window to attempt near-synchronous feedback

Sequence Diagram

High-Level Flow

  • Client -> File Intake API: POST upload request
  • File Intake API -> Blob Storage: Upload file with correlationId metadata
  • Blob Storage -> Defender for Storage: Trigger scan
  • Defender for Storage -> Event Grid -> Service Bus: Publish scan result
  • File Intake API -> Service Bus: Poll for scan result up to a fixed window
  • File Intake API -> Client: Return scan result or pending state

API Responses

  • Clean within poll window: HTTP 200 scanResultType = Clean
  • Malware within poll window: HTTP 200 scanResultType = Malware
  • Failed within poll window: HTTP 200 scanResultType = ScanFailed (Error scenario)
  • No result within window: HTTP 200 scanResultType = ScanPending

Cost Drivers

  • Defender for Storage per-GB scanning
  • Blob storage transactions
  • Event Grid and Service Bus messaging

Operational Considerations

  • No dedicated compute required
  • Increased API complexity due to polling
  • Poll window must be tightly bounded to avoid resource contention

Approach 3: Synchronous Malware Scanning using Defender for Endpoint on VM or VMSS

Overview

  • File is scanned synchronously during the upload request
  • API response is blocked until a scan result is returned
  • Defender for Endpoint runs on VM or VMSS infrastructure

Sequence Diagram

High-Level Flow

  • Client -> File Intake API: POST upload request
  • File Intake API -> VM or VMSS: Stream file for local scan
  • VM or VMSS -> File Intake API: Scan result
  • File Intake API -> Blob Storage: Upload file if clean
  • File Intake API -> Service Bus: Publish accepted or validated file message
  • File Intake API -> Client: HTTP response based on scan result

API Responses

  • Clean: HTTP 200 Upload accepted
  • Malware detected: HTTP 422 Malware detected
  • Scan failed or timed out: HTTP 503 Scan unavailable

Cost Drivers

  • Always-on VM or VMSS compute
  • OS disk and temp storage
  • Defender for Endpoint licensing
  • Scaling for peak upload volume

Operational Considerations

  • Requires OS patching and AV signature updates
  • Capacity planning required to avoid throttling uploads
  • Higher failure risk during traffic spikes