Secrets, Configuration and Data Protection

Illustrative only - not an engagement finding

Long-Lived Cloud Credentials Exist in Source or Build History

Critical See where this finding applies on the diagrams: delivery zone [planned] · CP7 workload identity federation

Ease of Attack: Low effort after obtaining a copy
Impact: Cloud impersonation, cost or data access
Detection Difficulty: 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.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```
Example workload-identity 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"}
```

Illustrative only - not an engagement finding

Secrets Are Stored as Shared Application Configuration

High See where this finding applies on the diagrams: Azure Key Vault · CP4 secrets boundary

Ease of Attack: Requires access to shared configuration
Impact: Reusable credentials for sensitive services
Detection Difficulty: Visible in configuration store review
Pattern: Example credential-free access pattern

Business Summary: 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.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Illustrative only - not an engagement finding

Record Deletion Can Leave Associated Objects Behind

Medium See where this finding applies on the diagrams: data and configuration zone

Ease of Attack: Triggered by partial failure or retry
Impact: Unexpected retention of sensitive objects
Detection Difficulty: 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.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Illustrative only - not an engagement finding

Unused Configuration Points to a Retired Service Destination

Low See where this finding applies on the diagrams: App Configuration edges

Ease of Attack: Requires configuration influence
Impact: Routing ambiguity and operational failure
Detection Difficulty: 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.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Illustrative Data Protection Examples

Long-Lived Cloud Credentials Exist in Source or Build History

Secrets Are Stored as Shared Application Configuration

Record Deletion Can Leave Associated Objects Behind

Unused Configuration Points to a Retired Service Destination