Software Supply-Chain Assessment · Application Review

Illustrative Findings Boundary

The severity-labelled scenarios below are newly authored fictional examples informed by the control domains assessed in this work. They do not reproduce or summarize any engagement finding, do not describe the reviewed environment, and do not indicate that any weakness was observed, confirmed, remediated or remains outstanding. Severity labels apply only to these examples and illustrate prioritization methodology.

Each example combines a plain-English business summary, a technical condition, potential impact, the evidence an assessment would seek, the expected control and a measurable way to check the fix.

The review combines manual source and infrastructure analysis with layered security tooling. Tool output is weighed against the application’s real code paths instead of being treated as a raw vulnerability count.

Tool or standard	Purpose
Gitleaks	Detect likely secrets in the current tree and available history.
pip-audit and npm audit	Compare resolved Python and JavaScript dependencies with public advisories.
Trivy	Assess container inputs and vulnerabilities in the image itself.
CWE, OWASP and ASVS	Classify weakness patterns and connect them to verifiable security requirements.

Fictional Security Examples

Illustrative Supply-Chain Examples

Illustrative only - not an engagement finding

Build Materials Contain a Long-Lived Service Secret

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

Ease of Attack: Low effort after obtaining a repository copy
Impact: Unauthorized service use or data access
Detection Difficulty: Visible in repository history secret scanning
Pattern: Example secret-removal pattern

Business Summary: A service key committed to deployment source or copied into build output remains recoverable from history and artifacts even after the latest file is cleaned up.
Possible Weakness: Infrastructure code, setup scripts or documentation contain a reusable cloud credential that is also preserved in repository history.
Potential Impact: Anyone with a repository clone or retained artifact could use the service outside the application until the credential is revoked.
What an Assessment Verifies: Use secret scanning across the current tree, repository history and build artifacts, then determine whether an Entra ID managed identity can replace the credential without attempting to use it.
Expected Fix: Revoke and rotate the credential, purge stored copies, move the workload to an Entra ID managed identity and gate every merge and release in Azure DevOps with secret scanning.
How to Check the Fix: The old value must be rejected, scans that include repository history must find no copy, the workload must operate without a stored key and a planted test secret must fail the pipeline.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence demonstrating how one secret concern is supported by multiple independent evidence types. 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 and history references
This is cross-reference evidence. A real assessment links the reviewed commit and exact lines across the route, service and data boundary so another reader can follow the complete control path.
```
if actor.tenant_id != record.tenant_id:
    raise Forbidden()
```
Example Gitleaks-style scan output
This is cross-reference evidence. A real report retains the tool version, safe test case, expected result and output needed to reproduce the conclusion.
```
security-regression --case "<illustrative-case>" --format json
Illustrative output: {"result":"blocked as expected"}
```
Example managed-identity configuration record
This is cross-reference evidence. A real assessment records a dated read-only identity or configuration query and explains what that result does and does not prove.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "identity.type"

Illustrative output: "SystemAssigned"
```

Illustrative only - not an engagement finding

Known Vulnerable Dependency Handles Untrusted Documents

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

Ease of Attack: Depends on advisory prerequisites
Impact: Unsafe parsing, exhaustion or code execution
Detection Difficulty: Visible in dependency audit output
Pattern: Example reachable-dependency pattern

Business Summary: A package advisory matters most when the affected component is reachable from hostile input. Document parsers and upload readers sit directly on that path.
Possible Weakness: A resolved Python or JavaScript dependency with a published security fix processes attacker-controlled files before application-level validation can contain the behaviour.
Potential Impact: A crafted upload could trigger resource exhaustion, unsafe parsing or code execution in a service that handles sensitive documents.
What an Assessment Verifies: Confirm the resolved Python or npm package version, whether the advisory applies, whether hostile input can reach the affected code, what an exploit would require and whether that code runs in the Container Apps workloads or only in build tooling.
Expected Fix: Upgrade or remove the package, lock the corrected version and use Azure DevOps dependency gates that prioritize the reachable packages handling client data.
How to Check the Fix: The clean build must resolve the corrected version, dependency scanning must pass and a safe regression case must show that the vulnerable processing behaviour is no longer reachable.

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 source-code evidence reference
This is cross-reference evidence. A real assessment links the reviewed commit and exact lines across the route, service and data boundary so another reader can follow the complete control path.
```
if actor.tenant_id != record.tenant_id:
    raise Forbidden()
```
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records a dated read-only identity or configuration query and explains what that result does and does not prove.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "identity.type"

Illustrative output: "SystemAssigned"
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the tool version, safe test case, expected result and output needed to reproduce the conclusion.
```
security-regression --case "<illustrative-case>" --format json
Illustrative output: {"result":"blocked as expected"}
```

Illustrative only - not an engagement finding

Container Scan Results Do Not Block Release Promotion

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

Ease of Attack: Depends on the reported vulnerability
Impact: Known risk reaches production unchanged
Detection Difficulty: Visible in a review of pipeline policy and scan gates
Pattern: Example release-policy pattern

Business Summary: A scanner creates a report, not a control. The result becomes operationally useful only when release policy blocks unacceptable risk or records a governed exception.
Possible Weakness: Container scanning reports high-severity packages, moving base-image tags or missing image metadata, but the release continues without a policy decision.
Potential Impact: A known vulnerable or unverifiable image could reach production even though the delivery system already had enough information to stop it.
What an Assessment Verifies: Inspect Azure Container Registry image inputs, Trivy output, severity thresholds, how reported issues are checked for real exposure, who owns exceptions, digest-based promotion and the evidence linking source to image.
Expected Fix: Promote only digest-identified images from Azure Container Registry that meet policy, with human-approved, time-limited exceptions and retained evidence linking source, build and scan result.
How to Check the Fix: A controlled image that deliberately violates release policy must fail promotion, while an approved exception must expire automatically and remain visible in release evidence.

Example source-code evidence reference
This is cross-reference evidence. A real assessment links the reviewed commit and exact lines across the route, service and data boundary so another reader can follow the complete control path.
```
if actor.tenant_id != record.tenant_id:
    raise Forbidden()
```
Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records a dated read-only identity or configuration query and explains what that result does and does not prove.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "identity.type"

Illustrative output: "SystemAssigned"
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the tool version, safe test case, expected result and output needed to reproduce the conclusion.
```
security-regression --case "<illustrative-case>" --format json
Illustrative output: {"result":"blocked as expected"}
```

Application Review · Control Domain 5 of 5 · Public Edition

Part of the two-report public security-review portfolio.

Report overview