11. Dependency, Software Supply-Chain and DevSecOps Security

Introduction and Context

Modern web applications are rarely built entirely from code written by one organisation. A typical application depends on open-source libraries, commercial components, container images, operating-system packages, build tools, cloud services, deployment scripts and infrastructure-as-code modules. These dependencies accelerate development, but they also extend the organisation’s security boundary. A vulnerability, malicious change or compromised build process in any one component may affect thousands of applications.

Software supply-chain security addresses this extended boundary. It concerns the people, processes, systems and artefacts through which software is selected, developed, built, distributed and operated. DevSecOps applies security throughout this lifecycle rather than treating it as a final approval activity. The objective is not to slow delivery with manual inspections; it is to create trustworthy, observable and repeatable delivery processes.

For a postgraduate full-stack developer, this topic has two dimensions. The technical dimension includes dependency analysis, secure repositories, software bills of materials, provenance, signed artefacts, container security and protected pipelines. The organisational dimension includes risk ownership, governance, supplier assurance, vulnerability prioritisation and evidence for audit. Effective security requires both.

Learning Objectives

After completing this chapter, a learner should be able to:

1. Explain software dependency and supply-chain risk in modern web applications.

2. Distinguish software composition analysis, vulnerability scanning, SBOMs, provenance and signing.

3. Design security controls for source repositories, CI/CD pipelines, containers and infrastructure as code.

4. Develop a risk-based dependency patching and exception-management process.

5. Apply DevSecOps principles while balancing security, delivery speed and operational reliability.

6. Evaluate emerging practices such as policy as code, attestations and automated remediation.

The Software Supply Chain as a Security System

A software supply chain can be understood as a chain of transformations. Source code is written and reviewed; dependencies are resolved; code is compiled or packaged; tests and security checks run; artefacts are stored; images or packages are deployed; and the resulting service is monitored. Each transformation should preserve integrity and provide sufficient evidence about what occurred.

This perspective changes the central question from “Is the application secure?” to “Can the organisation demonstrate what entered the application, who changed it, how it was built, and where it is running?” The answer requires traceability. A build that produces a binary without recording its source revision, dependency versions, build environment and test results is difficult to investigate or reproduce.

Supply-chain risk commonly arises through:

• vulnerable or obsolete third-party libraries;
• typosquatted or malicious packages;
• compromised developer, repository or package-manager accounts;
• poisoned build runners and exposed CI/CD credentials;
• untrusted container base images;
• tampered artefacts or unsigned releases;
• insecure infrastructure-as-code modules;
• abandoned projects with no effective maintainer;
• excessive permissions granted to automation; and
• inadequate monitoring after deployment.

Risk is not determined solely by the number of vulnerabilities. A vulnerability in a dormant development tool may be less urgent than a moderate vulnerability in a publicly exposed authentication service. Exploitability, reachability, business importance, exposure, available mitigations and the reliability of the supplier must be considered together.

Essential Concepts and Terminology

A dependency is an external software component required by an application or build process. Direct dependencies are declared by the project; transitive dependencies are introduced by those direct dependencies. A dependency graph records these relationships.

Software Composition Analysis (SCA) is the automated identification and assessment of third-party and open-source components. SCA tools typically compare component versions with vulnerability databases, licences and sometimes project-health indicators. Their results require interpretation because version matching can produce false positives, while incomplete inventories can create false negatives.

A Software Bill of Materials (SBOM) is a structured inventory of software components and their relationships. It may include package names, versions, suppliers, identifiers, licences and dependency relationships. Common exchange formats include SPDX and CycloneDX. An SBOM is an inventory, not a guarantee that the software is safe.

Provenance is evidence describing where an artefact came from and how it was produced. It can record the source repository, commit, builder, workflow, dependencies, parameters and timestamps. An attestation is a signed statement about an artefact or process, such as “this image was built from commit X by workflow Y and passed policy Z.”

A digital signature provides integrity and origin evidence when the verification key is trusted and protected. Signing does not make vulnerable software secure; it helps determine whether the artefact is authentic and unchanged. Provenance and signatures therefore complement, rather than replace, SCA and testing.

A vulnerability is a weakness that can be exploited. A security advisory describes a reported issue and may contain identifiers, affected versions and remediation guidance. Reachability analysis attempts to determine whether vulnerable code is actually callable in a particular application. A false positive is a reported issue that is not applicable or exploitable in context; a false negative is an undetected issue.

DevSecOps is the integration of security practices, responsibility and automated controls into development and operations. Shift left means identifying issues earlier, while shift everywhere is a more accurate principle: security must operate across design, coding, building, deployment and production.

A Risk-Based Dependency Management Process

Dependency governance begins with visibility. Teams should maintain inventories for application dependencies, build-time tools, container images, operating-system packages, plugins, infrastructure modules and deployment actions. The inventory must be connected to owners and production services; an unowned list quickly becomes obsolete.

Selection should consider more than popularity. A team should examine maintenance activity, release practices, vulnerability response, licence compatibility, security contact information, dependency depth and whether the component is critical to the application. Internal approval may be appropriate for high-impact components, while low-risk components can follow a lighter process.

Dependencies should be declared using manifests and resolved through lockfiles where supported. Lockfiles provide repeatability by recording exact versions and integrity information. However, they must be updated deliberately. Blindly accepting every new version can introduce breaking changes or malicious updates, whereas never updating creates accumulated vulnerability and compatibility debt.

Repositories should use trusted registries, package allow-lists or proxy repositories where appropriate. Package downloads should verify checksums or signatures when available. A secure build should be capable of operating from a controlled and reviewable source of dependencies rather than downloading arbitrary packages during production deployment.

Patching should be prioritised rather than performed solely by age or severity score. Useful factors include:

1. whether the vulnerable component is reachable;

2. whether exploitation is known or credible;

3. internet exposure and privilege of the affected service;

4. sensitivity of processed data;

5. availability of a fixed version or compensating control; and

6. operational risk of changing the component.

A practical policy assigns remediation deadlines to risk classes, tracks exceptions with an owner and expiry date, and requires evidence for compensating controls. Suppressing a scanner finding permanently is not risk management; it is loss of visibility.

Secure CI/CD Architecture

The CI/CD pipeline is a privileged production system. It can read source code, access secrets, build artefacts and deploy infrastructure. It should therefore be designed as carefully as an application server.

Source repositories require strong identity controls, multi-factor authentication, protected branches, mandatory peer review and auditable changes. Direct pushes to release branches should normally be prohibited. Repository applications and webhooks should have narrowly scoped permissions, and unused integrations should be removed. Secrets must not be stored in source code, logs or pull-request content. Secret managers and short-lived credentials are preferable to long-lived static tokens.

A secure pipeline separates stages and privileges. Code compilation and untrusted tests should not automatically receive production credentials. Deployment jobs should obtain temporary, environment-specific authority only after required checks pass. Self-hosted runners need isolation, patching and lifecycle control because a malicious build step may attempt to access the runner or other workloads.

Pipeline definitions themselves are code and require review. Controls should address dependency installation, script execution, artefact naming, environment variables, branch conditions and deployment destinations. A common weakness is allowing a pull request from an untrusted contributor to execute with access to sensitive secrets. The safe design treats untrusted code as hostile and withholds privileged credentials.

Security checks should be layered. Typical checks include secret detection, SCA, static application security testing, infrastructure-as-code scanning, container scanning, licence analysis, unit and integration tests, dynamic testing in a suitable environment, and deployment-policy validation. A check should have a defined purpose, owner and failure response. Excessive noisy gates cause developers to bypass controls; silent checks provide little protection.

SBOMs, Provenance and Signed Artefacts

SBOM generation should occur at build time and be associated with the exact artefact produced. For a container, this may include the application packages, operating-system packages and base image relationship. SBOMs should be stored, versioned and made available to incident-response teams. They are particularly valuable when a newly disclosed vulnerability requires rapid identification of affected services.

Provenance improves confidence in the build process. A useful provenance record answers questions such as: Which source revision was used? Which workflow and builder ran? Which dependencies were fetched? Was the build performed in an approved environment? Which tests and policies were satisfied? Attestations should be bound to immutable artefact digests rather than ambiguous tags.

Signing must be supported by verification. Organisations should protect signing keys, define trust roots, rotate or revoke keys when necessary, and verify signatures before promotion or deployment. Image tags such as “latest” are mutable and should not be treated as identity. Deployment systems should prefer immutable digests and reject unsigned or unapproved artefacts.

These mechanisms form a chain of evidence:

Source revision → reviewed change → controlled build → tested artefact → SBOM and provenance → signed digest → policy-approved deployment.

The chain is only as strong as its weakest trusted component. If an attacker controls the build runner or signing key, a signature may confirm the attacker’s artefact. Consequently, key protection, isolated builders, reproducible or highly observable builds and independent verification remain important.

Container and Infrastructure-as-Code Security

Container security begins with image selection. Teams should prefer trusted, minimal and regularly maintained base images. Unnecessary shells, package managers and services increase attack surface. Images should be scanned for operating-system and application vulnerabilities, but teams must understand that scanners cannot prove the absence of exploitation paths.

Containers should run as non-root users where possible, use read-only filesystems when feasible and receive only required Linux capabilities. Runtime policies should restrict privilege escalation, host mounts, host networking and access to sensitive metadata services. Images must be promoted through controlled registries, and deployments should reference verified digests.

Infrastructure as code (IaC) makes infrastructure reviewable and repeatable, but insecure templates can reproduce insecure settings at scale. Scanning should detect public storage, unrestricted network rules, excessive identity permissions, unencrypted data stores and exposed management interfaces. Secrets should not be embedded in templates or state files. State must be protected because it may contain sensitive values and information about the environment.

Policy as code expresses organisational rules in machine-evaluable form. For example, a deployment may be rejected if an image lacks an approved signature, a storage resource is public, or a production service lacks encryption. Policy exceptions should be explicit, time-limited and auditable rather than hidden in conditional logic.

Applying DevSecOps in Organisations

DevSecOps is a socio-technical operating model, not merely a collection of scanners. Developers remain responsible for the security of code they create, security specialists provide expertise and guardrails, and operations teams protect runtime environments. Product owners and managers decide risk acceptance and allocate resources. Responsibility is shared, but it must not become accountability without ownership.

Maturity can be assessed across several dimensions: inventory quality, automation, developer feedback, identity and access management, evidence generation, incident response and continuous improvement. A mature team measures meaningful outcomes such as time to remediate exploitable vulnerabilities, percentage of production artefacts with verified provenance, age of policy exceptions, and percentage of critical services with current SBOMs. Counting scanner findings alone can encourage superficial improvement.

Security controls should be placed close to the decision they influence. Dependency errors are cheapest to correct during development; deployment-policy violations should be blocked at promotion; runtime anomalies require monitoring and response. This layered approach avoids relying on one final security gate.

Illustrative Case Study: The Compromised Build Path

Background

A fictional online education company operates a React front end, several API services and a containerised cloud platform. Its teams use a shared CI system and multiple open-source packages. Builds are fast, but the organisation has no central SBOM inventory and deployment uses mutable image tags.

Situation and Problem

A developer installs a package with a name resembling a popular utility. The package executes a script during installation and attempts to read environment variables. The first build runner contains a long-lived cloud token. The malicious package does not immediately affect production, but the token permits access to an artefact registry.

Analysis

The incident is not simply a developer error. Weak package-source controls allowed an untrusted dependency; the pipeline granted excessive privileges; secrets were long-lived; and mutable tags prevented reliable identification of what was deployed. The absence of an SBOM delayed the search for the package across services.

Strategy and Solution

The company revokes the exposed token, audits runner and registry activity, rebuilds affected artefacts and deploys by immutable digest. It introduces a controlled package proxy, lockfile review and installation-script restrictions where practical. CI jobs receive short-lived, narrowly scoped credentials. Every release produces an SBOM and provenance attestation, and the registry accepts only signed artefacts from approved workflows. Repository protections and dependency-update pull requests are introduced, while exceptions require an owner and expiry date.

Outcome

The organisation can identify affected artefacts rapidly, prevent unapproved images from promotion and reduce the potential impact of a future compromised package. It also discovers that emergency response depends on inventory quality and identity controls, not solely on vulnerability scanners.

Learning Points

The case demonstrates four principles: dependency selection is a security decision; CI systems are high-value targets; authenticity must be verified at deployment; and supply-chain resilience requires both prevention and incident readiness.

Challenges, Limitations and Common Mistakes

SCA tools may disagree because they use different databases, package identifiers and dependency-resolution methods. A vulnerability may be reported in code that is not reachable, while a vulnerable system component may be missed if the image is opaque or the inventory is incomplete. Findings therefore require technical triage.

Another difficulty is remediation compatibility. A fixed library may require framework changes, introduce a licence concern or break a business-critical integration. Risk-based temporary mitigation may be reasonable, but exceptions must not become permanent substitutes for maintenance.

Organisations also underestimate non-production dependencies. Test frameworks, build plugins and deployment actions can access source code or credentials and can become attack paths. Similarly, signing programmes fail when verification is optional, keys are poorly protected or teams sign artefacts without establishing trust policy.

Common mistakes include trusting package popularity, copying container images without examining their origin, storing secrets in pipeline variables visible to logs, using one powerful cloud identity for every job, ignoring IaC state security, and treating compliance evidence as equivalent to security. Automation is valuable, but automated decisions based on inaccurate inventories can produce false confidence.

Governance, Ethics and Professional Responsibility

Supply-chain governance should define minimum controls, ownership, evidence retention, supplier expectations and incident-reporting procedures. Contracts may require vulnerability notification, supported versions, secure development evidence and cooperation during investigations. Regulatory obligations differ by jurisdiction and sector, but traceability, access control and timely response are broadly relevant.

Ethically, organisations should not conceal known critical defects from customers when disclosure is necessary to protect them. Developers should respect open-source licences and acknowledge that free availability does not eliminate obligations to maintain or securely use a component. Security teams should avoid punitive practices that encourage hiding vulnerabilities; transparent reporting and fair remediation processes produce better information.

Contemporary Developments

Current practice is moving toward machine-readable security evidence. SBOMs are increasingly integrated with asset inventories, vulnerability management and incident response. Build attestations and verified provenance support admission policies in registries and orchestration platforms. Software supply-chain frameworks increasingly emphasise secure source control, build integrity, dependency management and operational response.

Automated dependency updates can reduce patch delay when combined with tests, staged rollout and human review for high-risk changes. AI-assisted coding and package recommendation systems create additional risks: generated code may introduce vulnerable patterns, and automated suggestions may select poorly maintained libraries. AI tools should therefore operate within the same repository, dependency, secret and review controls as other development tools.

The emerging goal is not absolute certainty, which is unattainable, but evidence-based trust: every released component should have an identifiable origin, a controlled transformation history, a known dependency context and a monitored operational owner.

Best-Practice Blueprint

An organisation implementing this chapter’s principles should:

• maintain an owner-linked inventory of direct, transitive, build and runtime dependencies;
• use lockfiles, trusted registries and integrity verification;
• generate and retain SBOMs for released artefacts;
• produce provenance and sign artefacts in protected build environments;
• verify signatures, provenance and policy before deployment;
• protect branches, runners, registries and secrets with least privilege;
• scan source, dependencies, containers and IaC with defined triage processes;
• deploy immutable artefact digests rather than mutable tags;
• patch according to exploitability, reachability and business impact;
• record time-limited exceptions and compensating controls;
• monitor production and rehearse supply-chain incident response; and
• measure remediation and evidence quality, not merely the number of scans.

Chapter Summary

Software supply-chain security extends application security to dependencies, repositories, build systems, artefacts and deployment environments. SCA provides component and vulnerability visibility, while SBOMs provide a structured inventory for analysis and response. Provenance, attestations and digital signatures strengthen trust in how artefacts were produced and whether they were altered, but they do not replace vulnerability analysis or secure build design.

DevSecOps integrates security into development and operations through protected repositories, least-privilege pipelines, secret management, layered testing, container hardening, IaC controls and policy as code. A risk-based process prioritises reachable and exposed vulnerabilities, records accountable exceptions and uses immutable, verified artefacts. Effective practice combines technical automation with governance, professional judgement and continuous improvement.

Key Terms

Dependency: External software required by an application, build or operational process.

Transitive dependency: A component introduced indirectly through another dependency.

Software Composition Analysis: Automated identification and assessment of third-party components.

SBOM: A structured inventory of software components and their relationships.

Provenance: Evidence describing an artefact’s origin and production process.

Attestation: A signed statement about an artefact, build or security property.

Digital signature: Cryptographic evidence of integrity and the asserted signer.

Lockfile: A file recording exact dependency versions and often integrity data.

Vulnerability: A weakness that may be exploited to cause harm.

Reachability analysis: Assessment of whether vulnerable code can be invoked in context.

DevSecOps: Integration of security responsibility and controls throughout delivery and operations.

CI/CD pipeline: Automated processes for integrating, testing, packaging and deploying software.

Immutable artefact: A released object identified by content, commonly a digest, that is not changed in place.

Container image: A packaged filesystem and metadata used to create a container.

Infrastructure as code: Declarative or programmatic management of infrastructure through versioned files.

Policy as code: Machine-evaluable rules that enforce security or governance requirements.

Software supply chain: People, processes and systems involved in producing and delivering software.

Compensating control: An alternative safeguard applied when the preferred control is unavailable.

Dependency confusion: An attack in which a malicious package is selected instead of an intended internal package.

Review Questions

Short Answer Questions

1. What is the difference between a direct and a transitive dependency?

2. Why is an SBOM useful during vulnerability response?

3. What does provenance add to a signed software artefact?

4. Why should CI/CD credentials be short-lived and narrowly scoped?

5. What is the purpose of a lockfile?

Long Answer Questions

1. Explain how SCA, SBOMs, provenance and digital signatures complement one another.

2. Design a secure CI/CD pipeline for a containerised web application.

3. Discuss a risk-based process for prioritising dependency vulnerabilities.

4. Explain the major security controls for container images and infrastructure as code.

5. Analyse the organisational responsibilities required for effective DevSecOps.

Analytical / Application Questions

1. A critical vulnerability is found in a library used by an internet-facing API, but upgrading it may break a payment integration. How should the team analyse and manage the risk?

2. A pipeline builds images from pull requests and has access to production cloud credentials. Identify the weaknesses and propose a safer design.

3. An organisation has signed images but no SBOMs, uses mutable tags and does not verify signatures at deployment. Evaluate the security value of its current approach and recommend improvements.

22. Multiple Choice Questions with Answers

Question 1

Which artefact primarily provides a structured inventory of software components and their relationships?

A. SBOM

B. Digital certificate

C. Firewall rule set

D. Runtime log

Correct Answer: A. SBOM

Question 2

A dependency is present in an application only because it is required by another declared library. It is a:

A. Static dependency

B. Transitive dependency

C. Signed dependency

D. Runtime exception

Correct Answer: B. Transitive dependency

Question 3

Why should deployment systems prefer image digests over mutable tags?

A. Digests make images smaller

B. Digests identify content immutably

C. Digests remove all vulnerabilities

D. Digests eliminate the need for testing

Correct Answer: B. Digests identify content immutably

Question 4

Which control best limits the impact of a compromised CI job?

A. A single permanent administrator token

B. Short-lived, narrowly scoped credentials

C. Disabling source-code review

D. Using the latest image tag

Correct Answer: B. Short-lived, narrowly scoped credentials

Question 5

What does provenance primarily describe?

A. The business value of an application

B. The origin and production history of an artefact

C. The number of users logged in

D. The encryption algorithm used by a database

Correct Answer: B. The origin and production history of an artefact

Question 6

A vulnerability scanner reports a vulnerable library, but the affected function cannot be called by the application. Which activity helps assess this situation?

A. Reachability analysis

B. Branch deletion

C. Key rotation only

D. Image compression

Correct Answer: A. Reachability analysis

Question 7

Which pipeline design is most secure for untrusted pull requests?

A. Give every pull request production secrets

B. Run them with isolation and without privileged credentials

C. Allow direct deployment to production

D. Disable all automated tests

Correct Answer: B. Run them with isolation and without privileged credentials

Question 8

What is the main purpose of policy as code?

A. To replace all software developers

B. To express and automatically enforce machine-evaluable rules

C. To conceal infrastructure configuration

D. To make vulnerabilities impossible

Correct Answer: B. To express and automatically enforce machine-evaluable rules

Question 9

Which statement about digital signatures is correct?

A. A signature proves that software has no vulnerabilities

B. A signature provides integrity and asserted-origin evidence when trust is established

C. A signature replaces dependency inventories

D. A signature guarantees a secure build runner

Correct Answer: B. A signature provides integrity and asserted-origin evidence when trust is established

Question 10

A team permanently suppresses dependency findings because the scanner is noisy. What is the principal risk?

A. Improved traceability

B. Loss of visibility into genuine issues

C. More reliable provenance

D. Stronger least privilege

Correct Answer: B. Loss of visibility into genuine issues