This is the whole report on one page, intended for reading end to end or
printing to PDF. The chaptered edition is the
primary version.
Section 1
Executive Summary
Cloud-security conclusions should be tied to the environment that is
actually deployed, not inferred solely from diagrams or infrastructure
templates.
This review method starts by reconstructing the as-built Azure footprint
and end-to-end data flow. It then examines identity, network boundaries,
configuration, secrets, data services, containers, delivery controls,
logging and alerting through safe evidence. The resulting architecture
view connects each security principle to the service path it protects.
Assessment principle. Treat every cloud claim as a
statement that needs a reproducible source, an evidence boundary and an
explicit confidence level.
Section 2
Scope and Evidence Boundaries
The review covers the deployed application path from browser and API
through configuration, object and queue storage, asynchronous processing
and the operational data store. It considers the identities, network
relationships and data movement that connect those components.
In the illustrative reference architecture these are Microsoft Entra ID,
Azure Container Apps, Azure App Configuration, Azure Blob and Queue
Storage, Azure Cosmos DB, Azure Key Vault, Azure Container Registry and
Azure Monitor with Log Analytics.
Click or tap a zone or checkpoint on the diagram to jump to the related illustrative security examples.
The illustrative reference platform assessed across both reports. The architecture is fictional and representative: it names Azure services to anchor the review method and contains no client environment details. See also the document-processing flow and the trust-boundary view.
Diagnostic coverage, retention and alert ownership
Missing data-plane logs; retention below investigation windows; alerts without an owned response path
Review lenses are generic and drawn from Microsoft security-baseline and
Well-Architected guidance. Representative risks are typical finding
categories for each service, not engagement findings.
Boundary. Read-only configuration evidence can establish
observable control state and service relationships. It does not replace
approved penetration testing, authenticated business-flow testing or
long-term operational monitoring.
Section 3
Methodology
Inventory the footprint. Identify services, workloads, identities, data stores and delivery surfaces in scope.
Trace the data flow. Follow client information from ingress through processing, storage and retrieval.
Map trust boundaries. Record which component can read, transform, route or act on information.
Collect safe evidence. Use read-only cloud queries and preserve the observed result and evidence limit.
Challenge conclusions. Use the Threat Tribunal multi-model harness to propose, challenge and arbitrate observations.
Apply human review. Assess confidence, operational relevance and remediation priority before creating delivery work.
How severity is assigned: each example's severity derives from its
ease of attack and potential impact. In a real engagement the
Confidence field reflects evidence strength; in this public edition it
always reads "fictional example".
Section 4
Architecture and Trust Boundaries
A useful cloud-security diagram must show more than service icons. It
should expose identity, data direction, privilege and the point at which
untrusted input crosses into a more trusted processing context.
Click or tap a zone or checkpoint on the diagram to jump to the related illustrative security examples.
Security checkpoints the review verifies, overlaid on the illustrative platform. [target] marks expected controls; [planned] marks the designed delivery roadmap. See also the full reference architecture on the report overview.
Architecture question
Security purpose
Which identity performs each service-to-service call?
Tests least privilege and removes authorization decisions from application convention.
Where does client information cross a service boundary?
Identifies encryption, authorization, audit and data-minimization requirements.
Which component can transform or act on model output?
Locates the deterministic validation boundary around probabilistic behavior.
Which controls exist only in deployment configuration?
Highlights drift risk between infrastructure definitions and the live environment.
Fictional Security Examples
Illustrative Architecture and Trust-Boundary Examples
Illustrative only - not an engagement finding
Sensitive Operations Lack a Default-Deny Identity Boundary
A public service that accepts sensitive requests without sign-in or per-customer authorization can turn an ordinary endpoint into direct access to protected records and operations.
Possible Weakness
An internet-facing API permits sensitive operations without requiring an authenticated identity and without rechecking object or tenant authorization downstream.
Potential Impact
An external caller could read or change sensitive information, trigger privileged processing or cross a customer boundary.
What an Assessment Verifies
Inspect Container Apps ingress and Entra ID identity settings, trace downstream authorization decisions and run safe tests that confirm access is denied without retrieving real data.
Expected Fix
Enforce identity at the Container Apps ingress and default-deny authorization at the API, object and tenant boundaries.
How to Check the Fix
Signed-out requests and requests using the wrong tenant, role or object identity must fail with 401 or 403 without revealing whether a protected record exists. Repeat the negative tests after every deployment.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how a real report connects one conclusion to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure configuration record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code authorization reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible denied-access test output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Requires tracing callback handling through service code
Pattern
Example destination-validation pattern
Business Summary
A trusted workload can hand its authority to an attacker-controlled destination when it accepts dynamic callback addresses and attaches privileged credentials to the resulting request.
Possible Weakness
A backend service accepts a callback or status address from an upstream response and sends a privileged credential to that destination.
Potential Impact
A manipulated destination could receive credentials or cause the workload to issue unintended outbound requests.
What an Assessment Verifies
Trace where each callback destination originates, how redirects and DNS lookups are handled, when credentials are attached and the outbound network policy of the async worker's Container Apps environment.
Expected Fix
Use fixed or allow-listed destinations, never attach managed-identity credentials to dynamic URLs and restrict the worker's outbound connections.
How to Check the Fix
Safe tests using an unapproved host, redirect, private address, unexpected port and changed DNS result must all fail before a credential is attached or an outbound connection is made.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Production documentation helps legitimate teams use a service, but exposing internal and administrative operations also reduces the discovery work required by an attacker.
Possible Weakness
Production documentation or an API schema is available without sign-in and lists administrative, diagnostic or internal operations.
Potential Impact
The exposed surface gives an attacker a clearer map of available operations, parameters and implementation behaviour.
What an Assessment Verifies
Check signed-out access to documentation, schemas and discovery endpoints on the public Container Apps ingress and compare the result with the intended production audience.
Expected Fix
Disable unnecessary discovery surfaces in production or place them behind the same Entra ID identity and authorization boundary as the API.
How to Check the Fix
Signed-out requests to documentation, schema and discovery routes must return 401, 403 or 404. Approved users should see only the operations their role is permitted to invoke.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Zero Trust requires explicit verification at every boundary. Network
reachability, user sign-in and service identity answer different security
questions and should be assessed separately.
Prefer managed workload identities over embedded connection material.
Scope roles to the smallest service, operation and environment that requires them.
Enforce authorization in downstream services instead of relying on a caller or model to make the decision.
Separate public ingress requirements from management-plane and data-plane access.
Record deliberate exceptions with an owner, expiry condition and verification step.
Fictional Security Examples
Illustrative Identity and Access Examples
Illustrative only - not an engagement finding
One Workload Identity Can Traverse Multiple Trust Zones
A broadly privileged workload identity allows one compromised service to become a stepping stone into configuration, processing and data systems that should have separate trust boundaries.
Possible Weakness
One application identity holds broad permissions across ingress, configuration, processing and data services.
Potential Impact
A compromise in one workload could spread across trust zones and expose administration, credentials and sensitive data.
What an Assessment Verifies
List every Entra ID role assignment, the data-plane permissions on Storage, Cosmos DB and App Configuration, reachable services and the effective access available to each workload identity.
Expected Fix
Use a distinct Entra ID identity per workload, scope every role to the minimum operation and restrict network paths between trust zones.
How to Check the Fix
Each workload must complete its approved function while tests prove that it cannot read, change or administer resources assigned to another trust zone.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how identity configuration, role assignments and safe tests that confirm access is denied are reviewed together. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only role-assignment record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example infrastructure identity definition
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example denied-access test output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Visible in a review of who can read which configuration
Pattern
Example configuration-separation pattern
Business Summary
The public-facing layer should expose the least information and authority. Backend-only configuration in that layer can turn a web-tier compromise into access to more privileged services.
Possible Weakness
A public-facing web workload can read configuration values intended only for APIs, workers or data services.
Potential Impact
A frontend compromise could reveal backend destinations, reusable credentials or access material for more privileged services.
What an Assessment Verifies
Review App Configuration roles, key prefixes, Key Vault secret references and the effective values available to the web app's identity.
Expected Fix
Separate App Configuration scopes, remove backend access from the web app's identity and prefer managed identity over reusable credentials.
How to Check the Fix
The frontend identity must be denied every backend-only key and secret path while the web application continues to operate using only its explicitly approved configuration.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Every unnecessary public endpoint creates another route that must be defended continuously and increases dependence on identity and firewall settings remaining correct.
Possible Weakness
Data, configuration or build services retain public endpoints even though only known application workloads need access.
Potential Impact
The additional network paths expand the attack surface and increase reliance on identity and firewall configuration remaining perfect.
What an Assessment Verifies
Inspect public-network settings, firewall rules and private endpoints across Storage, Cosmos DB, App Configuration and Container Registry, plus name resolution and documented exceptions.
Expected Fix
Prefer private connectivity to Storage, Cosmos DB and App Configuration, scope necessary public exceptions and give every exception an owner and expiry condition.
How to Check the Fix
Connections from an external test location must fail while approved private workloads continue to connect. Any permitted public exception must show an owner, purpose and expiry date.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Configuration services, secret stores and data services should be reviewed
as one access path. A secretless application identity provides little value
if another broadly accessible service still exposes equivalent credentials
or data.
Control pattern. Combine managed identities, restricted
network paths, centralized secret handling, rotation, encryption,
authorization that respects tenant boundaries, backup verification and auditable access.
Fictional Security Examples
Illustrative Data Protection Examples
Illustrative only - not an engagement finding
Long-Lived Cloud Credentials Exist in Source or Build History
Visible in repository and artifact secret scanning
Pattern
Example rotation and identity pattern
Business Summary
A reusable cloud credential can remain valid after it is deleted from the latest source file because earlier repository history and copied build artifacts may still contain a working value.
Possible Weakness
Reusable cloud credentials are committed to repository history, copied into build output or retained in a deployment artifact.
Potential Impact
Anyone who obtains the material could consume paid services, impersonate a workload or reach protected data within the credential scope.
What an Assessment Verifies
Scan current files, repository history and Azure DevOps build artifacts without attempting to use any discovered credential.
Expected Fix
Revoke and rotate exposed material, replace it with an Entra ID managed identity and enforce secret scanning that covers repository history before merge and release in Azure DevOps.
How to Check the Fix
The previous credential must be rejected, current files, history and artifacts must contain no copy, the workload must succeed through managed identity and the pipeline must block a planted test secret.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence demonstrating how repository and cloud evidence can corroborate the same control concern. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example source-code permalink and history reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example secret-scan output covering repository history
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Illustrative only - not an engagement finding
Secrets Are Stored as Shared Application Configuration
Treating passwords and access keys as ordinary configuration broadens the number of services and people that can read them and increases the damage caused by any one compromise.
Possible Weakness
Passwords, access keys or connection material are stored as ordinary configuration values readable by several workloads.
Potential Impact
A compromise of any permitted reader could disclose reusable credentials for more sensitive services or data stores.
What an Assessment Verifies
Classify App Configuration values, identify every reading identity and trace whether equivalent credential-free access through Key Vault references and managed identities is available.
Expected Fix
Move secrets to Azure Key Vault with narrow access, or remove them entirely through managed workload identity.
How to Check the Fix
Unauthorized workload identities must be denied the secret path, approved services must operate through managed identity or narrow secret access, and the configuration inventory must contain no equivalent reusable value.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Requires testing deletion when a step fails midway
Pattern
Example lifecycle-reconciliation pattern
Business Summary
A deletion can appear complete to a user while copies remain in storage or processing queues, creating privacy, retention and incident-response obligations that the application can no longer track reliably.
Possible Weakness
An application deletes its database record while uploaded files or derived objects remain in storage after a partial failure.
Potential Impact
Sensitive material could remain beyond the intended lifecycle and become disconnected from normal access and retention controls.
What an Assessment Verifies
Trace deletion across Cosmos DB records, Blob Storage objects and Queue Storage work items and reconcile expected state after retries and interrupted processing.
Expected Fix
Use cleanup and reconciliation that are safe to retry across Cosmos DB, Blob Storage and Queue Storage, with auditable evidence that every associated object reached the intended state.
How to Check the Fix
Delete a test record while interrupting each cleanup stage, then retry and reconcile. Every related object must reach the approved deleted or retained state with an auditable completion record.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Visible when configuration is reconciled against live services
Pattern
Example startup-validation pattern
Business Summary
Stale destinations make deployments harder to reason about, create noisy failures and can route traffic unexpectedly if an abandoned name is later reused.
Possible Weakness
An unused setting continues to reference a service destination that has been renamed, retired or never provisioned.
Potential Impact
The stale value can create failed routing, confusing diagnostics and uncertainty about which configuration is authoritative.
What an Assessment Verifies
Inventory App Configuration settings, trace runtime references from the API and worker and distinguish active configuration from settings kept only for compatibility.
Expected Fix
Remove stale App Configuration settings and use typed startup validation that fails clearly when a required destination is invalid.
How to Check the Fix
A clean deployment must contain only authoritative settings, and startup must reject a deliberately invalid required destination with a clear, non-sensitive error before serving traffic.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Delivery security should make the approved path the easiest path. The
planned Azure DevOps design automates repeatable checks and preserves
evidence from pull request through release and rollback.
Code and configuration checks
Dependency and secret scanning
Container-image assessment
Policy and approval gates
Secretless deployment identity
Immutable release evidence
Digest-identified artifacts
Controlled rollback
Status distinction. These continuous-integration and
delivery controls describe the designed secure-delivery roadmap. They
are not presented as already operating controls.
Fictional Security Examples
Illustrative Delivery and Release Examples
Illustrative only - not an engagement finding
Unverified Build Inputs Can Produce an Untrusted Release
A release is trustworthy only when the reviewed source and every build input resolve to the same verifiable artifact. Mutable upstream inputs can change production without changing the application repository.
Possible Weakness
A production build resolves mutable dependencies, actions or base images that are not pinned to an approved digest.
Potential Impact
A compromised upstream input could alter the released application while appearing to follow the normal delivery process.
What an Assessment Verifies
Inspect input pinning, dependency locks, Container Registry image digests, records of where each input came from and whether a clean rebuild produces the expected artifact.
Expected Fix
Use immutable build inputs, isolated builds, signed records of each build's origin and release policy that promotes only digest-identified artifacts from Container Registry.
How to Check the Fix
A clean rebuild from the same approved inputs must produce the expected digest, signatures and origin records must verify, and release policy must reject any mutable or unidentified input.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how source, build and runtime records form one release chain. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example immutable source reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example build digest and scanner output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Illustrative only - not an engagement finding
Manual Deployment Path Bypasses Security and Approval Gates
A manual production path breaks the evidence chain from reviewed source to running service and allows required security checks or approvals to be skipped when delivery pressure is highest.
Possible Weakness
Production releases are assembled or deployed manually without mandatory code, dependency, secret and container checks.
Potential Impact
Untested, vulnerable or unapproved code could reach production without a trustworthy connection to reviewed source.
What an Assessment Verifies
Compare repository state, Azure DevOps pipeline output, approvals, deployment records and the digest of the artifact running in Container Apps.
Expected Fix
Use governed continuous delivery in Azure DevOps with mandatory scans, approval gates, immutable promotion evidence and a tested rollback path.
How to Check the Fix
Production must accept only the approved pipeline identity and digest, direct deployment attempts must fail, the running artifact must match promotion evidence and rollback must succeed in a controlled test.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
A restricted container identity does not prevent vulnerable code from running, but it limits what that code can change and reduces the reach of a successful compromise.
Possible Weakness
An application container relies on the image default instead of explicitly declaring a restricted, non-root runtime identity.
Potential Impact
Successful code execution could gain unnecessary filesystem or process privileges and increase the impact of a container compromise.
What an Assessment Verifies
Inspect image configuration and Container Apps runtime settings for user identity, capabilities, writable paths and filesystem restrictions.
Expected Fix
Run each Container Apps workload as a dedicated non-root user, drop unnecessary capabilities and use read-only or narrowly writable filesystems.
How to Check the Fix
The running process must use the approved non-root identity, attempts to write protected paths or use removed capabilities must fail, and application health checks must still pass.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
Visible in a review of the repository's build inputs
Pattern
Example reproducible-build pattern
Business Summary
Competing dependency instructions allow two builds that both look correct to contain different software, making vulnerability decisions and emergency release reproduction less dependable.
Possible Weakness
A project retains competing package-manager files, redundant dependency inputs or an unpinned build toolchain.
Potential Impact
Different environments could resolve different packages, making it harder to judge which vulnerabilities matter and to reproduce a release.
What an Assessment Verifies
Identify the authoritative package manager, lockfile, runtime version and clean-build procedure used for release.
Expected Fix
Keep one authoritative lockfile, pin the toolchain and require clean reproducible builds in the governed pipeline.
How to Check the Fix
Repeated clean builds on approved runners must resolve the same package set and artifact digest, while an unapproved lockfile or toolchain version must fail the pipeline.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
DevOps includes dependable operation as well as delivery. Telemetry becomes
an operational control only when a signal has a defined purpose, owner,
response path and verification step.
Operational layer
Expected outcome
Structured application logging
Events contain consistent context without exposing sensitive information.
Azure activity and data-plane monitoring
Security-relevant changes and access patterns become observable.
Actionable alerts
Defined signals reach an owner through a tested response path.
Evidence retention
Teams can show what happened, what decision followed and how the outcome was verified.
Fictional Security Examples
Illustrative Monitoring and Response Examples
Illustrative only - not an engagement finding
Privileged Changes and Sensitive Access Produce No Actionable Signal
Preventive controls cannot contain every failure. If privileged changes and sensitive access produce no actionable signal, a serious compromise can continue without a timely owner or response.
Possible Weakness
High-impact identity changes and sensitive data access occur without a signal that reaches an accountable responder.
Potential Impact
A serious compromise could continue undetected while privileges, configuration or protected information are changed.
What an Assessment Verifies
Trace diagnostic sources into Azure Monitor and Log Analytics, then alert rules, notification delivery, ownership and a safe test event through the complete response path.
Expected Fix
Enable dependable audit signals in Azure Monitor, route them to an owned on-call path and retain evidence that delivery and response are tested.
How to Check the Fix
A safe test event that simulates a privileged change must create the expected alert, reach the accountable owner within the target time and leave retained evidence of acknowledgement and response.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how a configured signal is traced through collection, delivery and response. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example Azure diagnostic and alert configuration record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example delivery result for a simulated test event
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Illustrative only - not an engagement finding
Security Logs Are Not Centralized or Retained for Investigation
Visible in diagnostic settings and retention review
Pattern
Example retention-and-query pattern
Business Summary
Logs become useful only when investigators can find, trust and retain them. Short-lived service logs can disappear before a team knows that an investigation is required.
Possible Weakness
Authentication, authorization and data-plane events remain scattered across short-lived service logs.
Potential Impact
Investigators may be unable to reconstruct access, distinguish normal behaviour from misuse or determine the affected scope.
What an Assessment Verifies
Map which application and data services produce security logs, centralized collection in Log Analytics, retention periods, query access and protection against unauthorized alteration.
Expected Fix
Centralize security-relevant telemetry in Log Analytics, protect access, retain it for the required period and maintain tested investigation queries.
How to Check the Fix
Test sign-in and data access events must appear in the central store with usable context, and retention, query access and protection against alteration must match the approved policy.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
An alert that nobody owns is not an operational control. It becomes noise until a tested process shows who receives it, what they do and when the issue escalates.
Possible Weakness
Alert rules exist in configuration but lack a named owner, response runbook, escalation path or delivery test.
Potential Impact
Important signals can become noise, remain unread or reach people who cannot take timely action.
What an Assessment Verifies
Review Azure Monitor alert ownership, severity, notification targets, runbooks, escalation timing and the result of an end-to-end alert test.
Expected Fix
Give every actionable Azure Monitor alert an owner, response procedure, escalation route and retained evidence from regular delivery tests.
How to Check the Fix
A scheduled end-to-end test must be delivered, acknowledged and escalated within the approved response times, with retained evidence that the owner followed the current runbook.
Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
az resource show --ids "<illustrative-resource-id>" \
--query "properties.exampleControl"
Illustrative output: {"exampleControl":"enabled"}
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
if not policy.can_access(actor, record):
raise Forbidden()
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
The Azure review assesses running configuration, service relationships
and observable operational controls using safe, read-only evidence. The
application review assesses source code, infrastructure as code,
dependencies and delivery artifacts. Areas of overlap are intentionally
compared. Agreement between the two evidence streams strengthens
confidence, while differences reflect their distinct scopes and
evidence boundaries.
This purpose-built public edition is intended for external sharing. It
contains no client names, tenant or subscription identifiers, resource
names, internal URLs, work-item references, source paths, commit
identifiers, screenshots, sample data, credentials, or combinations of
details that could reconstruct a specific finding.
The severity-labelled material in Sections 4 through 8 consists only of
newly authored fictional examples. It does not report, summarize or
imply any engagement finding or actual severity rating.
Cross-reference links point only to newly authored demonstration
evidence in Section 9. They are not client source links, Azure resource
links or engagement tool output.
Section 11
Limitations
This report explains the assessment scope, methodology, control domains
and generalized security lessons. It does not reproduce client-specific
findings, actual severity ratings, evidence, remediation status or
current production configuration. Severity labels shown in Sections 4
through 8 apply only to newly authored fictional examples and do not
describe the reviewed environment. It is not a penetration-test report,
certification, assurance opinion or statement that any example weakness
was present. Inclusion of a topic means it was assessed, not that a
finding existed.
