Threat Tribunal

Third-Party Software and Build Security

The review combines manual analysis of source code and cloud setup files with several security tools. Reviewers check each reported issue against the application's real code paths instead of treating the tool's raw count as the result.

Tool or standard Purpose
Gitleaks Detect likely secrets in the current tree and available history.
pip-audit and npm audit Compare the exact installed Python and JavaScript packages with public security advisories.
Trivy Check the software used to build a container image and the vulnerabilities inside that image.
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 Files Contain a Reusable Service Key

Critical See where this finding applies on the diagrams: delivery zone [planned] · CP7 workload identity federation
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.
Assessment profile
Ease of attack
Repository or artifact accessA reusable cloud credential remains in source history, build output, caches or deployment files.
Impact
Unauthorized service use
  • Anyone with a retained copy could use the service outside the application.
  • Access continues until the credential is revoked.
Detection difficulty
History and artifact scanSearch the current tree, repository history, build artifacts, caches and deployment output without attempting to use the secret.
Pattern
Remove reusable credentialsWorkloads use scoped Entra ID identities instead of service keys stored with source or builds.
Expected fix Verification
  1. Expected fix Revoke and investigate exposure Credential owner and Azure Monitor logs: Revoke and rotate the value, then review its known exposure window for unauthorized use.
    Verification Reject the old value The revoked credential no longer authenticates, and the log review covers its full exposure window.
  2. Expected fix Purge every retained copy Azure DevOps repository, artifacts, caches and deployment output: Remove the credential from current and historical material.
    Verification Find no surviving copy Secret scans of current files, history, artifacts, caches and deployment output return no match.
  3. Expected fix Use a least-privilege workload identity Container Apps managed identity and Entra ID role assignments: Grant only the service roles the workload requires.
    Verification Enforce the approved role boundary The workload operates through managed identity and cannot perform operations outside its approved roles.
  4. Expected fix Remove stored-key fallback Application code and App Configuration: Remove settings and fallback paths that still accept the reusable key.
    Verification Run without a stored credential The workload completes its approved work with no stored-key configuration or fallback path.
  5. Expected fix Gate merges and releases on scanning Azure DevOps validation and release pipelines [planned]: Block current files, history or generated artifacts that contain credentials.
    Verification Block a planted secret A controlled test credential stops both merge and release.

Related illustrative findings: container release gates; live credential roles, rotation and alerts in Azure.

Illustrative only - not an engagement finding

Unsafe Third-Party Software Processes Uploaded Documents

High See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate
Business summary
The application relies on third-party libraries to open and read uploaded documents. If one of those libraries has a known security flaw, an attacker may trigger it simply by uploading a file designed for that parser. The flaw could run before the application has a chance to reject the document.
Assessment profile
Ease of attack
The attacker supplies a file the library opensA customer-controlled upload reaches an installed Python or JavaScript library whose known flaw applies to that file type and processing path.
Impact
The service can crash or run attacker-controlled code
  • A malicious document could exhaust memory or processing time, crash the worker or exploit unsafe file handling.
  • A severe flaw could run attacker-controlled code inside a service that processes documents containing personally identifiable information (PII) or other protected customer data.
Detection difficulty
Check whether uploaded files reach the vulnerable functionConfirm the installed library version, the file types and conditions needed to trigger the flaw, and whether the Container Apps worker sends customer uploads through that code.
Pattern
Prioritize flaws that users can actually reachA release should consider both how serious the published flaw is and whether an uploaded file can trigger the affected code.
Expected fix Verification
  1. Expected fix Upgrade or remove the vulnerable library Python or JavaScript package files: Install a corrected version or remove the library, then lock the approved version used by clean builds.
    Verification Confirm a clean build installs the fix A build started from an empty environment installs the corrected library version and not the vulnerable one.
  2. Expected fix Block uploaded files from the vulnerable code until it is fixed Container Apps upload and document-processing worker: Disable the affected feature or reject the relevant file type so customer uploads cannot reach the vulnerable library.
    Verification Confirm a test upload cannot reach the flaw A controlled test file is rejected before the vulnerable library runs, while unaffected file types continue to work.
  3. Expected fix Make every clean build install the same package versions Python uv and npm build files: Use one approved lockfile for each runtime and verify downloaded packages against their recorded integrity values.
    Verification Match the reviewed package list A clean build installs only the versions recorded in the approved lockfiles and rejects a package whose integrity check fails.
  4. Expected fix Record and scan every library shipped in the release Azure DevOps build and release evidence [planned]: Generate a list of every shipped package and version, then compare it with current security advisories.
    Verification Confirm the shipped version The final release package list contains the corrected version, excludes the vulnerable version and passes the advisory scan.
  5. Expected fix Block release while an exploitable library flaw remains Azure DevOps release rules [planned]: Stop release when customer input can reach a known flaw, unless a named owner approves a time-limited exception.
    Verification Require an owner and expiry for every exception The release stops without approval. Any exception names its owner, explains why exposure is accepted and expires automatically.

Related illustrative findings: document resource budgets; container release gates.

Illustrative only - not an engagement finding

Known Container Risks Do Not Stop a Release

Medium See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate
Business summary
A container scan may report known vulnerabilities, but it does not prevent deployment. If the release pipeline only saves the report and continues, the same vulnerable container image can still reach production. The pipeline must stop that image or require a named owner to accept the risk for a limited time.
Assessment profile
Ease of attack
The exploit depends on the reported flawThe important control failure is that Azure DevOps allows an image with a known vulnerability or missing proof of origin to continue toward production.
Impact
Known risk reaches production
  • A container with a known exploitable flaw could be deployed unchanged.
  • The team may be unable to prove that the deployed image is the one built from reviewed source and scanned.
Detection difficulty
Follow one image from build to deploymentConfirm which image entered Azure Container Registry, which scan result belongs to it, who accepted any exception and which identity deployed it.
Pattern
Approve and deploy the same container imageThe source, build record, package list, scan and deployment must all name the same fixed image fingerprint, called a digest.
Expected fix Verification
  1. Expected fix Deploy the exact image that was approved Azure Container Registry and Container Apps deployment [planned]: Release an image by its fixed digest rather than by a reusable name or tag.
    Verification Move the approved image without rebuilding it The approved digest is deployed to the target environment without creating or substituting another image.
  2. Expected fix Attach source and scan results to that image Azure DevOps build record [planned]: Link the reviewed source revision, list of shipped packages and vulnerability scan to the image digest.
    Verification Confirm every record names the same image The source revision, build, package list, scan result and deployment all identify the same digest.
  3. Expected fix Stop images that violate the approved risk rules Azure DevOps release gate [planned]: Block an image when a vulnerability is serious enough and the running application can reach the affected code.
    Verification Confirm a known violation stops deployment A test image that violates the release rules cannot be deployed.
  4. Expected fix Require an owner and expiry for every exception Azure DevOps release approval [planned]: Require a named owner, a written reason for accepting the risk and an automatic expiry date.
    Verification Keep every accepted risk visible An exception names its owner and reason, remains attached to the release record and expires automatically.
  5. Expected fix Allow only the release pipeline to deploy images Azure DevOps pipeline managed identity [planned]: Give deployment permission only to the controlled pipeline and only for an approved digest.
    Verification Block manual or unauthorized deployment A person or service identity outside the controlled pipeline cannot deploy an image.

Related illustrative findings: reachable dependency risk; governed deployment in the companion review.