Secure Delivery, Cloud and Software Supply Chains

Introduction

Modern web applications are assembled and operated through a delivery system rather than produced as a single artifact. Source code, third-party libraries, build tools, container images, infrastructure definitions, cloud services, credentials, and deployment workflows all influence security. A vulnerability may therefore enter through application logic, a transitive dependency, a compromised build runner, an over-permissive cloud role, or an unverified container image.

Secure delivery is the discipline of embedding security controls throughout the software development and operations lifecycle. It is commonly associated with DevSecOps: the integration of development, security, and operations practices so that security becomes a shared engineering responsibility rather than a final inspection stage. The objective is not to eliminate all risk, which is impossible, but to reduce the probability and impact of security failures while preserving delivery speed and reliability.

This chapter examines code review, automated testing, software composition analysis, secret and container scanning, infrastructure as code, CI/CD controls, software bills of materials, dependency governance, patching, and the cloud shared-responsibility model.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain how DevSecOps integrates security into software delivery.
2. Distinguish SAST, DAST, SCA, secret scanning, and container scanning.
3. Design practical controls for source repositories, CI/CD pipelines, and release approvals.
4. Explain SBOMs, dependency governance, vulnerability prioritization, and patching strategies.
5. Identify security risks in infrastructure as code and cloud deployments.
6. Apply the cloud shared-responsibility model to operational decisions.
7. Evaluate the governance, ethical, and business implications of secure software supply chains.

1. The Software Supply Chain as a Security Boundary

A software supply chain includes every component and process used to create, distribute, and operate software. A simplified chain is:

Developer → Source repository → Build system → Dependencies
     → Container/package registry → Deployment platform → Production service

Each link has assets, identities, trust relationships, and possible attack paths. Examples include:

• a developer account whose credentials are stolen;
• malicious code inserted into a dependency or build script;
• a pull request that bypasses review;
• a CI runner that exposes signing keys;
• a container image containing a vulnerable operating-system package;
• an infrastructure definition that opens a database to the public internet;
• a cloud role that grants excessive permissions.

Supply-chain security consequently requires more than testing application functionality. It requires provenance: evidence about where an artifact came from, how it was built, what it contains, and whether its integrity was preserved.

A useful design principle is least privilege. Each person, service, pipeline, and workload should receive only the permissions necessary for its role and for the shortest practical duration. Another is separation of duties: no single account should be able to modify source code, approve its own change, publish a trusted artifact, and deploy it to production without independent controls.

2. DevSecOps and Security as a Continuous Activity

Traditional development often placed security testing near the end of a project. This creates expensive rework because architectural flaws and insecure interfaces may be discovered after implementation. DevSecOps shifts security activities left, while also retaining controls during deployment and operation. The phrase “shift left” should not be interpreted as “security happens only early.” A mature program shifts security throughout the lifecycle:

DevSecOps is a socio-technical model. Tools are useful, but they do not replace ownership, judgment, or a process for handling findings. A scanner that reports thousands of issues without triage can reduce security by creating alert fatigue. Effective programs define who owns a finding, how it is prioritized, when it must be fixed, and how exceptions expire.

3. Code Review and Secure Design

Code review is a structured examination of proposed changes by one or more people other than the author. Its security value is greatest when reviewers assess behavior and design rather than merely formatting. Reviewers should consider:

• authentication and authorization decisions;
• input validation and output encoding;
• use of cryptography and key management;
• error handling and logging;
• handling of personal or confidential data;
• concurrency, race conditions, and resource exhaustion;
• changes to dependencies, permissions, and deployment configuration;
• tests for misuse and failure cases.

A review policy should require protected branches, authenticated reviewers, status checks, and traceable approvals. High-risk changes—such as identity code, payment logic, cryptographic libraries, or production infrastructure—may require two reviewers or a security specialist.

Reviewers should avoid approving code merely because an automated tool is green. Static analysis can miss business-logic vulnerabilities, while human reviewers may miss subtle data-flow problems. The strongest practice combines peer review, automated analysis, tests, and threat modeling.

Threat modeling is a systematic way to ask what can go wrong, who might cause it, and how the design will resist or detect it. A team can model trust boundaries, valuable assets, entry points, abuse cases, and security controls before implementation. For example, an administrative API should be analyzed for privilege escalation, replay, insecure direct object references, and excessive data exposure.

4. Security Testing in the Delivery Pipeline

4.1 Static Application Security Testing

SAST analyzes source code, bytecode, or an intermediate representation without executing the application. It can identify patterns such as unsafe input flows, injection risks, weak cryptographic APIs, and insecure deserialization. SAST is relatively early and repeatable, but it may produce false positives and usually lacks full knowledge of runtime configuration and business intent.

SAST should be configured to understand the project’s languages and frameworks. Teams should establish quality gates based on severity and confidence rather than blocking every warning. Findings should be tracked to closure, suppression, or documented risk acceptance.

4.2 Dynamic Application Security Testing

DAST tests a running application from the outside. It can discover observable weaknesses such as missing security headers, authentication defects, injection behavior, and exposed endpoints. DAST is valuable because it examines deployed behavior, but its coverage depends on the routes, credentials, test data, and attack payloads provided. It may also cause state changes, so it must be run against controlled environments.

Authenticated DAST is often more useful than unauthenticated scanning for applications with role-based functionality. Test accounts should be synthetic, limited, and monitored.

4.3 Software Composition Analysis

SCA inventories direct and transitive dependencies and compares their versions with vulnerability databases and licensing information. A direct dependency is explicitly selected by the project; a transitive dependency is introduced by another dependency. Transitive components are especially important because developers may not know they are present.

SCA findings require context. A vulnerable library may be unreachable, disabled by configuration, or mitigated by compensating controls. Conversely, a vulnerability with a lower published severity may be critical when the affected function is internet-facing and processes sensitive data. Teams should examine exploitability, exposure, affected code paths, availability of a fix, and business impact.

4.4 Secret Scanning

Secret scanning searches source code, commits, build logs, configuration files, and artifacts for credentials such as API keys, private keys, database passwords, and tokens. Prevention is preferable to detection: credentials should be stored in a managed secrets service or injected through short-lived workload identity.

A secret accidentally committed to a repository must be considered exposed even if the commit is later deleted. The response is to revoke or rotate it, investigate use, remove it from future history where appropriate, and correct the process that allowed it. Simply hiding the string or rewriting Git history does not invalidate the original credential.

4.5 Container and Image Scanning

Containers package application code and user-space dependencies, but they still rely on a kernel and other host or platform services. Image scanning identifies vulnerable packages, insecure configuration, embedded secrets, and risky permissions. Good practices include:

• use minimal, maintained base images;
• pin image versions or immutable digests;
• build from trusted sources;
• avoid running as root;
• exclude unnecessary shells and package managers from production images;
• scan both images and running workloads;
• sign images and verify signatures at deployment.

A clean image scan does not prove that an application is secure. It does not necessarily detect business-logic flaws, runtime misconfiguration, or vulnerabilities introduced after deployment.

5. CI/CD Pipeline Security

The CI/CD system is a high-value target because it can read source code, access secrets, create artifacts, and deploy to production. Pipeline security should address both the workflow definition and the execution environment.

Important controls include:

1. Strong identity: use multifactor authentication for human users and federated, short-lived identities for workloads.
2. Least privilege: give each job only the permissions needed for its stage.
3. Protected configuration: require review for changes to workflow files, deployment manifests, and release policies.
4. Isolated runners: use ephemeral or well-hardened runners and prevent untrusted pull-request code from accessing production secrets.
5. Pinned actions and tools: identify actions by trusted versions or immutable references and review their permissions.
6. Artifact integrity: generate checksums, attestations, and signatures; store artifacts in controlled registries.
7. Gated promotion: require successful tests, policy checks, approvals, and provenance verification before production deployment.
8. Auditability: retain logs of source revisions, actors, approvals, tool versions, and deployment targets.

A pipeline should not treat a branch name or a client-supplied variable as proof of authorization. Authorization must be determined by the CI/CD platform’s trusted identity and policy controls. Build logs must also be treated as sensitive because commands can accidentally print tokens or personal data.

6. Software Bills of Materials and Provenance

A software bill of materials (SBOM) is a machine-readable inventory of software components and their relationships. It may include package names, versions, suppliers, licenses, hashes, and dependency relationships. Common exchange formats include SPDX and CycloneDX.

An SBOM supports several activities:

• identifying whether a newly disclosed vulnerability affects an organization;
• understanding transitive dependencies;
• checking license obligations;
• supporting customer and regulatory inquiries;
• improving incident response and asset inventory.

An SBOM is not itself a security certificate. It may be incomplete, stale, or inaccurate. It must be generated from a trustworthy build process, associated with a specific artifact, updated when the artifact changes, and protected against tampering. Provenance metadata adds information about the source revision, builder, workflow, and parameters used to create the artifact.

A practical chain of evidence is:

Source revision → Controlled build → SBOM and test results
       → Signed artifact → Verified deployment → Runtime inventory

The value of this chain depends on its weakest link. If an attacker can replace the artifact after signing or alter the inventory, a signature alone does not establish trustworthy deployment.

7. Dependency Governance and Patching

Dependency governance is the managed selection, monitoring, updating, and retirement of third-party components. A governance policy should define approved sources, supported versions, ownership, licensing requirements, update frequency, and exception procedures.

Automated update tools can create pull requests for new versions, but automation requires tests and review. Blindly accepting updates may introduce breaking changes or malicious packages. Conversely, refusing all updates creates technical debt and increases exposure to known vulnerabilities.

Patching decisions should consider:

• severity and exploitability;
• whether the vulnerable component is reachable;
• internet exposure and privilege level;
• availability and quality of a fix;
• operational disruption;
• compensating controls;
• legal, contractual, and regulatory obligations.

A vulnerability-management service level agreement may specify target remediation times, such as rapid treatment for actively exploited critical issues and longer windows for low-risk findings. Exact times should be based on organizational risk, not copied uncritically from another organization.

When a patch is unavailable, compensating actions may include disabling an affected feature, adding a web application firewall rule, restricting network access, reducing permissions, or isolating the workload. These measures reduce risk but do not replace eventual remediation.

8. Infrastructure as Code and Policy as Code

Infrastructure as code (IaC) expresses networks, compute resources, databases, identity roles, and policies in declarative or programmatic files. IaC improves repeatability, reviewability, and recovery, but insecure definitions can reproduce a vulnerability across many environments.

IaC review should examine:

• public exposure of services and storage;
• network segmentation and egress rules;
• encryption in transit and at rest;
• identity permissions and trust policies;
• logging, monitoring, and backup settings;
• secure defaults and deletion protection;
• secret handling and state-file protection.

Policy as code turns organizational requirements into machine-evaluated rules. For example, a policy may reject storage resources without encryption, prohibit unrestricted administrative ingress, or require tags identifying an owner and data classification. Policies should be version-controlled, tested, and accompanied by an exception process. Poorly designed policies can block legitimate work or encourage unsafe workarounds.

IaC state files may contain resource identifiers, configuration details, and sometimes secrets. They require access control, encryption, versioning, and careful separation between environments.

9. Cloud Shared Responsibility

Cloud security is shared between the provider and the customer, but the division varies by service model and contract. The provider generally secures the physical facilities, hardware, and foundational platform. The customer remains responsible for appropriate identity management, data protection, configuration, application security, and often guest operating systems.

These boundaries are not universal; students must consult the provider’s current documentation and service agreement. A provider’s certification does not make a customer’s storage bucket private, nor does managed infrastructure eliminate the need for secure application code.

Cloud security should be treated as a configuration and identity problem as much as a perimeter problem. Centralized logging, organization-level policies, workload identity, key management, network controls, backup testing, and continuous configuration monitoring are essential. Teams should also plan for provider outages, account compromise, data residency requirements, and exit or portability concerns.

10. A Risk-Based Release Model

A secure pipeline should make risk decisions explicit. A useful release record identifies the artifact, source revision, test results, known vulnerabilities, approvals, deployment target, and exceptions. A release may be blocked when a critical vulnerability is exploitable in the deployed context, when provenance is missing, when a secret is detected, or when a required approval is absent.

Not every finding should automatically block deployment. A mature process distinguishes:

• false positive: the reported issue is not actually present;
• accepted risk: the issue is understood and authorized for a defined period;
• mitigated risk: controls reduce the likelihood or impact;
• remediated issue: the underlying weakness has been corrected.

Exceptions should name an accountable owner, explain the rationale, identify compensating controls, specify an expiry date, and be reviewed periodically. Permanent exceptions are usually undocumented risk, not governance.

Applied Case: Illustrative Online Retail Platform

Background

An illustrative online retailer operates a web application in the cloud. Its team deploys containers through a hosted CI/CD platform. Developers can add open-source packages, and infrastructure is defined through IaC. The company processes payment-related information through a third-party provider and stores customer contact data.

Problem

A routine scan identifies a high-severity vulnerability in a transitive JavaScript dependency. A separate review finds that a pull-request workflow can access a cloud deployment token. The production container also runs as root, and the team has no reliable inventory of deployed components.

Analysis

The dependency finding is not the only problem. The workflow token creates a supply-chain escalation path: malicious code in an untrusted pull request might use the token to alter infrastructure or publish an artifact. Running as root increases the impact of a container compromise. The absence of an SBOM slows the investigation and prevents the team from confidently determining where the dependency is deployed.

Approach

The retailer takes the following actions:

1. It revokes the exposed deployment token and replaces it with short-lived, environment-specific identity federation.
2. It prevents untrusted pull requests from receiving production credentials.
3. It upgrades or replaces the vulnerable dependency after testing, then records the result in the dependency inventory.
4. It generates an SBOM during each trusted build and associates it with a signed image digest.
5. It changes the container to a non-root user and removes unnecessary packages.
6. It adds IaC policies prohibiting public databases and unrestricted administrative access.
7. It requires protected-branch review and an approval for production promotion.
8. It establishes remediation deadlines and an exception process with expiry dates.

Outcome

The organization gains a reproducible release record, faster vulnerability impact analysis, and stronger separation between development and production. It does not claim that scanning has made the system secure. Instead, it has reduced attack paths and improved its ability to detect, contain, and recover from failures.

Learning Points

The case demonstrates that secure delivery is a system of controls. Dependency updates alone would not have addressed the pipeline credential, container privilege, or inventory deficiency. Security improvements are most effective when they protect source, build, artifact, deployment, and runtime stages together.

11. Limitations, Ethics, and Contemporary Developments

Automated tools have limitations. SAST and DAST can produce false positives and false negatives. SCA databases may lag behind disclosures. Image scanners may disagree about severity or fail to understand runtime reachability. SBOMs can be incomplete. Human review can be inconsistent, and cloud dashboards can hide configuration drift.

Security teams must therefore communicate uncertainty honestly. It is unethical to label an application “secure” solely because a scan passed. Organizations should minimize collection of personal data in logs and scanning systems, restrict access to vulnerability reports, and avoid using security monitoring as unjustified employee surveillance.

Software supply-chain attacks have increased attention to signed artifacts, build provenance, isolated builders, reproducible or hermetic builds, and in-toto-style attestations. Artificial intelligence can assist with code review, dependency analysis, and anomaly detection, but generated code may contain vulnerabilities, reproduce insecure patterns, or introduce licensing and confidentiality concerns. AI-generated changes require the same review, testing, provenance, and ownership as human-written code.

Regulatory and contractual expectations increasingly require vulnerability management, secure development practices, incident reporting, and component transparency. Requirements vary by jurisdiction and sector, so organizations must map controls to applicable law and contract terms rather than assuming that one framework satisfies every obligation.

Best-Practice Checklist

• Protect branches and require meaningful peer review.
• Use SAST, DAST, SCA, secret scanning, and container scanning in suitable stages.
• Treat detected secrets as compromised and rotate them immediately.
• Use short-lived identities and least privilege in CI/CD.
• Isolate untrusted builds from production credentials.
• Generate, protect, and update SBOMs for released artifacts.
• Sign artifacts and verify signatures and provenance before deployment.
• Scan and test IaC before applying it.
• Establish dependency ownership, patch targets, and expiring exceptions.
• Monitor cloud configuration, identity use, runtime behavior, and drift.
• Test backups, recovery procedures, and incident-response playbooks.
• Measure outcomes such as remediation time, exposure duration, and recurring root causes—not merely the number of scans performed.

Chapter Summary

Secure delivery treats the software supply chain as a security boundary extending from source code to cloud runtime. DevSecOps integrates security into planning, coding, building, testing, releasing, deploying, and operating software. Code review and threat modeling address design and business logic, while SAST, DAST, SCA, secret scanning, and container scanning identify different classes of weakness. No single tool provides complete assurance.

CI/CD systems require strong identity, least privilege, isolation, protected workflow definitions, artifact integrity, provenance, and auditable promotion controls. SBOMs improve component visibility but must be accurate, current, and linked to specific artifacts. Dependency governance balances timely patching with compatibility, exploitability, and business context. IaC and policy as code provide repeatability and enforceable guardrails, while cloud security depends on understanding the provider–customer division of responsibility. Finally, secure delivery is a governance practice: findings need owners, exceptions need expiry dates, and security claims must reflect evidence and uncertainty.

Key Terms

DevSecOps: Integration of development, security, and operations throughout the delivery lifecycle.

Software supply chain: The people, processes, tools, dependencies, artifacts, and platforms used to create and operate software.

SAST: Static Application Security Testing performed without executing the application.

DAST: Dynamic Application Security Testing performed against a running application.

SCA: Software Composition Analysis of direct and transitive dependencies.

Secret scanning: Detection of credentials and sensitive tokens in code, logs, and artifacts.

Container scanning: Analysis of container images for vulnerabilities, secrets, and insecure configuration.

CI/CD: Continuous integration and continuous delivery or deployment practices and tooling.

SBOM: Software Bill of Materials listing components and dependency relationships.

Provenance: Evidence describing an artifact’s source, builder, process, and integrity.

Artifact: A build output such as a package, binary, or container image.

Dependency: External software required by an application or another component.

Transitive dependency: A dependency introduced indirectly through another dependency.

Infrastructure as Code: Declarative or programmatic management of infrastructure resources.

Policy as code: Machine-evaluated rules expressing security or governance requirements.

Least privilege: Granting only the permissions necessary for a task.

Separation of duties: Dividing sensitive responsibilities among independent actors or controls.

Compensating control: An alternative safeguard that reduces risk when the preferred control is unavailable.

Shared responsibility model: Allocation of cloud security duties between provider and customer.

Configuration drift: Unplanned divergence between approved configuration and deployed state.

Review Questions

Short Answer Questions

1. What is the main purpose of an SBOM?
2. How does SAST differ from DAST?
3. Why must a committed secret be rotated rather than merely deleted from a repository?
4. What is a transitive dependency?
5. Name two responsibilities commonly retained by a cloud customer.

Long Answer Questions

1. Explain how code review, automated testing, and threat modeling complement one another in a DevSecOps program.
2. Describe the security controls required to protect a CI/CD pipeline from source commit through production deployment.
3. Discuss the benefits and limitations of SBOMs and artifact provenance.
4. Explain how IaC and policy as code can improve cloud security, including risks caused by insecure definitions.
5. Compare the provider’s and customer’s responsibilities in IaaS, PaaS, and SaaS environments.

Analytical / Application Questions

1. A build pipeline detects a critical dependency vulnerability, but the vulnerable function is not reachable and no patch is available. What evidence and compensating controls should be considered before release?
2. Design a release gate for a production container that includes requirements for review, secrets, vulnerabilities, provenance, and cloud permissions.
3. An organization’s SBOM shows that a vulnerable library exists in several images, but the runtime inventory is incomplete. Analyze the immediate investigation and governance actions required.

Multiple Choice Questions with Answers

Question 1

Which technique analyzes application source code without executing the application?

A. DAST

B. SAST

C. Runtime monitoring

D. Backup testing

Correct Answer: B. SAST

Question 2

Why is a secret committed to a repository treated as compromised even after the commit is deleted?

A. Repository deletion always destroys audit logs

B. The credential may already have been copied or used

C. Secret scanners cannot detect deleted files

D. Cloud providers automatically reject deleted secrets

Correct Answer: B. The credential may already have been copied or used

Question 3

What is the primary purpose of an SBOM?

A. To guarantee that software has no vulnerabilities

B. To replace all code review activities

C. To inventory software components and their relationships

D. To encrypt application data

Correct Answer: C. To inventory software components and their relationships

Question 4

Which control best protects production credentials from untrusted pull-request code?

A. Making the credentials available to every build

B. Using production credentials in source files

C. Isolating untrusted jobs and withholding production credentials

D. Disabling all automated tests

Correct Answer: C. Isolating untrusted jobs and withholding production credentials

Question 5

What does least privilege mean in a CI/CD context?

A. Every pipeline job receives administrator access

B. Each job receives only the permissions required for its task

C. Developers cannot access any source code

D. All credentials are shared across environments

Correct Answer: B. Each job receives only the permissions required for its task

Question 6

Which activity is most characteristic of DAST?

A. Inspecting a running application for observable weaknesses

B. Listing package licenses from a lockfile

C. Reviewing a pull request manually

D. Generating an infrastructure state file

Correct Answer: A. Inspecting a running application for observable weaknesses

Question 7

Which statement about a cloud provider’s security certification is correct?

A. It makes the customer’s storage private automatically

B. It eliminates the need for application security

C. It does not remove the customer’s configuration and identity responsibilities

D. It guarantees that every customer workload is compliant

Correct Answer: C. It does not remove the customer’s configuration and identity responsibilities

Question 8

What is a transitive dependency?

A. A dependency explicitly installed by an operating-system administrator

B. A dependency introduced indirectly through another dependency

C. A dependency that has no software license

D. A dependency used only during incident response

Correct Answer: B. A dependency introduced indirectly through another dependency

Question 9

Which practice strengthens container supply-chain security?

A. Running every production container as root

B. Using unverified floating image tags

C. Signing images and verifying them before deployment

D. Disabling image scanning to accelerate delivery

Correct Answer: C. Signing images and verifying them before deployment

Question 10

Which item should normally be included in a time-limited security exception?

A. No accountable owner

B. A rationale, compensating controls, and expiry date

C. A promise never to review the issue

D. A permanent waiver without documentation

Correct Answer: B. A rationale, compensating controls, and expiry date