Container, Infrastructure and Delivery Controls

Illustrative only - not an engagement finding

Unverified Build Inputs Can Produce an Untrusted Release

Critical See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate

Ease of Attack: Requires supply-chain influence
Impact: Untrusted code in a release that looks approved
Detection Difficulty: Visible in build definition and manifest review
Pattern: Example build-origin and policy pattern

Business Summary: 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.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```
Example configuration record of the running image
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

High See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate

Ease of Attack: Requires deployment access
Impact: Unreviewed code reaches production
Detection Difficulty: Apparent from release history and audit trails
Pattern: Example governed-delivery pattern

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

Illustrative only - not an engagement finding

Container Workloads Use an Unrestricted Default Runtime Identity

Medium See where this finding applies on the diagrams: application zone · CP2 managed-identity edges

Ease of Attack: Requires code execution in the container
Impact: Greater filesystem and process privilege
Detection Difficulty: Visible in container runtime configuration review
Pattern: Example runtime-hardening pattern

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

Illustrative only - not an engagement finding

Competing Package Inputs Make Builds Non-Deterministic

Low See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate

Ease of Attack: Requires influence over build inputs
Impact: Build drift and inconsistent remediation
Detection Difficulty: 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.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Illustrative Delivery and Release Examples

Unverified Build Inputs Can Produce an Untrusted Release

Manual Deployment Path Bypasses Security and Approval Gates

Container Workloads Use an Unrestricted Default Runtime Identity

Competing Package Inputs Make Builds Non-Deterministic