Threat Tribunal

Secure Builds and Deployments

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
  • Deployment identity without stored credentials
  • Release evidence that cannot be changed
  • Build outputs identified by a fixed digest
  • 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

Critical See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate
Business summary
A release is trustworthy only when the reviewed source and every build input produce the same verifiable output. Changeable external inputs can alter production even when the application repository has not changed.
Assessment profile
Ease of attack
Requires supply-chain influenceA production build uses changeable packages, pipeline actions or base images that are not fixed to an approved digest, which is a content identifier.
Impact
Untrusted code in a release that looks approved
  • A compromised upstream input could alter the released application.
  • The change could appear to follow the normal delivery process.
Detection difficulty
Visible in build definition and manifest review
  • Inspect fixed input versions and package locks.
  • Inspect Container Registry image digests and records of where each input came from.
  • Check whether a clean rebuild produces the expected output.
Pattern
Example build-origin and policy pattern
Expected fix Verification
  1. Expected fix Pin source, packages, actions, base images and build tools by immutable version, hash or digest
    Verification A clean rebuild from the same approved inputs must produce the expected digest
  2. Expected fix Verify signatures and origin records before each input enters the build
    Verification A changed hash, invalid signature or unidentified input must fail before the build uses it
  3. Expected fix Run isolated builds with only the network access needed to retrieve approved inputs
    Verification The isolated build must be unable to retrieve an unapproved network input
  4. Expected fix Bind the source revision, software inventory, build record and output digest in signed release evidence
    Verification Signed release evidence must bind the source revision, software inventory, build record and output digest
  5. Expected fix Release only the Azure Container Registry digest produced from those approved inputs
    Verification Only that approved digest may be released from Azure Container Registry

Related illustrative findings: manual release bypass; non-deterministic packages.

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
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.
Assessment profile
Ease of attack
Requires deployment accessProduction releases are assembled or deployed manually without mandatory code, dependency, secret and container checks.
Impact
Unreviewed code reaches production
  • Untested, vulnerable or unapproved code could reach production.
  • The deployment could lack a trustworthy connection to reviewed source.
Detection difficulty
Apparent from release history and audit trails
  • Compare repository state and Azure DevOps pipeline output.
  • Compare approvals and deployment records.
  • Compare the approved digest with the software running in Container Apps.
Pattern
Example governed-delivery pattern
Expected fix Verification
  1. Expected fix Allow only a dedicated Azure DevOps pipeline identity to deploy to production
    Verification A direct production deployment by a person or unapproved identity must fail
  2. Expected fix Promote the same approved artifact digest between environments instead of rebuilding it
    Verification Production must accept only the dedicated Azure DevOps pipeline identity and approved digest
  3. Expected fix Require mandatory scans, separation of approval duties and protected environment gates
    Verification The running Container Apps digest must match source, build, approval and deployment evidence
  4. Expected fix Retain source, build, approval, deployment and running-digest evidence that cannot be changed by the deployer
    Verification A deployer must be unable to approve their own protected release when separation is required
  5. Expected fix Maintain and regularly test a rollback path to the last approved digest
    Verification Rollback to the last approved digest must succeed in a controlled test

Related illustrative findings: approved artifact provenance and digest; AI attack replay and release-blocking evidence.

Illustrative only - not an engagement finding

Containers Run With More System Access Than They Need

Medium See where this finding applies on the diagrams: application zone · CP2 managed-identity edges
Business summary
Running a container as a restricted system user does not prevent vulnerable code from running, but it limits what that code can change and reduces the reach of a successful compromise.
Assessment profile
Ease of attack
Requires code execution in the containerAn application container relies on the image default instead of declaring a restricted system user that does not have root administrator access.
Impact
Greater filesystem and process privilege
  • Successful code execution could gain unnecessary filesystem privileges.
  • It could gain unnecessary process privileges and increase the impact of a container compromise.
Detection difficulty
Visible in container runtime configuration review
  • Inspect image configuration and Container Apps runtime settings for user identity and capabilities.
  • Inspect writable paths and filesystem restrictions.
Pattern
Example runtime-hardening pattern
Expected fix Verification
  1. Expected fix Run each Container Apps workload as a dedicated non-root user with no privilege escalation
    Verification The running process must use the approved non-root user with no privilege escalation
  2. Expected fix Drop unnecessary Linux capabilities and use a read-only filesystem with narrowly writable temporary paths
    Verification Attempts to write protected paths or use removed Linux capabilities must fail
  3. Expected fix Give each workload a separate managed identity with least-privilege Azure roles
    Verification A resource-exhaustion test must stop at the configured CPU, memory or process limit without affecting another workload
  4. Expected fix Set CPU, memory and process limits so one compromised container cannot exhaust the environment
    Verification Unapproved ingress and egress connections must fail
  5. Expected fix Restrict ingress and egress to the service paths the workload actually needs
    Verification Application health checks and approved Azure operations must still pass through the least-privilege managed identity

Related illustrative findings: build origins; reachable dependency risk in the companion review.

Illustrative only - not an engagement finding

Competing Package Files Can Produce Different Builds

Low See where this finding applies on the diagrams: delivery zone [planned] · CP6 supply-chain gate
Business summary
Competing package instructions allow two apparently correct builds to contain different software. That makes vulnerability decisions and emergency rebuilds less dependable.
Assessment profile
Ease of attack
Requires influence over build inputsA project retains competing package-manager files, duplicate package instructions or build tools without fixed versions.
Impact
Build drift and inconsistent remediation
  • Different environments could resolve different packages.
  • That difference could make it harder to judge which vulnerabilities matter.
  • It could make a release harder to reproduce.
Detection difficulty
Visible in a review of the repository's build inputs
  • Identify the authoritative package manager and lockfile.
  • Identify the runtime version and clean-build procedure used for release.
Pattern
Example reproducible-build pattern
Expected fix Verification
  1. Expected fix Keep one authoritative package manager and lockfile for each application
    Verification Repeated clean builds on approved runners must resolve the same package set and artifact digest
  2. Expected fix Use fixed runtime and build-tool versions and verify package integrity during installation
    Verification A missing, bypassed or unexpectedly changed lockfile must fail the pipeline
  3. Expected fix Make the pipeline fail when the lockfile is missing, changed unexpectedly or bypassed
    Verification A package with an invalid hash or unapproved source must fail installation
  4. Expected fix Build from a clean environment and retain the resolved package list and artifact digest
    Verification The retained package inventory must match the built artifact and pass current advisory scanning
  5. Expected fix Scan that package list against current advisories before release
    Verification An approved lockfile and toolchain must still produce a successful build

Related illustrative findings: immutable build inputs; authoritative configuration.