Chapter 10
DevSecOps, Risk and Software Supply Chains
Certificate in DevOps
DevOps & Agile Fundamentals
•
Certificate
DevSecOps, Risk and Software Supply Chains
Introduction
DevOps integrates development, operations, automation, and feedback so that software can be delivered rapidly and reliably. DevSecOps extends this idea by making security a continuous responsibility shared across the product lifecycle. Security is not a final inspection performed immediately before release; it is a set of practices embedded in planning, design, coding, testing, deployment, operation, and retirement.
This approach is necessary because modern software is assembled from many sources: application code, open-source packages, container images, cloud services, build tools, infrastructure definitions, and third-party APIs. A weakness in any component can affect the delivered system. Attackers may exploit insecure code, stolen credentials, vulnerable dependencies, compromised build systems, or tampered release artifacts.
DevSecOps therefore combines three concerns:
Security engineering: identifying threats and designing appropriate protections.
Risk management: deciding how to reduce, transfer, accept, or avoid security risk.
Software supply-chain assurance: establishing confidence that software and its components are authentic, traceable, and appropriately maintained.
The objective is not to eliminate all risk. Complete elimination is usually impossible and may prevent useful innovation. The objective is to make risk visible, reduce it systematically, and ensure that remaining risk is understood and governed.
Learning Objectives
By the end of this chapter, you should be able to:
explain the purpose and principles of DevSecOps;
identify threats and security risks across a delivery pipeline;
apply threat modelling and secure coding principles;
manage dependencies, secrets, vulnerabilities, and access privileges;
distinguish major forms of automated security testing;
describe software supply-chain threats and controls;
explain the value of software bills of materials, signing, provenance, and reproducible builds;
recommend a practical DevSecOps operating model for a small team; and
evaluate ethical, governance, and regulatory responsibilities in security work.
1. From DevOps to DevSecOps
Traditional development models often placed security at the end of the lifecycle. A security team might conduct a penetration test after most design decisions had been made. This created late findings, expensive rework, and conflict between delivery and security objectives.
DevSecOps changes the timing and ownership of security. Developers, operations specialists, security professionals, product owners, and managers collaborate throughout the lifecycle. Security controls are automated where appropriate, but automation does not replace professional judgement.
data disposal, credential revocation, archival decisions
The principle of shift left means addressing security earlier, when changes are cheaper to make. However, security must also shift right: production monitoring, incident response, and learning from real events remain essential. A mature programme shifts security throughout the lifecycle rather than merely moving it to an earlier point.
2. Security Risk and Threat Awareness
A threat is a potential cause of harm, such as credential theft, malicious code injection, or denial of service. A vulnerability is a weakness that may be exploited. An asset is something valuable, including data, services, credentials, infrastructure, intellectual property, or customer trust. Risk is the possibility that a threat will exploit a vulnerability and produce an undesirable consequence.
Risk is often discussed qualitatively using likelihood and impact. A simple qualitative model is:
Risk ≈ Likelihood × Impact
Likelihood describes how probable or feasible an event is; impact describes the severity of its consequences. The expression is a decision-support model, not a precise physical law. It is useful when the organisation uses consistent rating scales, but it should not imply that security risk can always be measured with exact numerical accuracy.
A team may classify risks as low, medium, high, or critical. It should document the reasoning, assumptions, affected assets, existing controls, and owner. Risk treatments include:
Mitigation: reduce likelihood or impact, for example through multi-factor authentication.
Avoidance: stop the risky activity, such as removing an unnecessary exposed service.
Transfer or sharing: allocate some consequences through insurance or contractual arrangements, while recognising that accountability may remain.
Acceptance: consciously retain the risk after assessing it and obtaining appropriate approval.
Threat modelling
Threat modelling is a structured process for asking how a system could be attacked and how it should be protected. A practical method is:
Define the system, users, assets, and security objectives.
Draw the major data flows and trust boundaries.
Identify threats at each component and boundary.
Estimate their significance.
Select controls and record residual risk.
Review the model when architecture or threats change.
The STRIDE mnemonic is frequently used to stimulate analysis:
Spoofing: pretending to be another identity;
Tampering: unauthorised modification;
Repudiation: denying an action without adequate evidence;
Information disclosure: exposing protected information;
Denial of service: reducing availability;
Elevation of privilege: gaining unauthorised capabilities.
Threat models are not merely diagrams. Their value lies in the decisions they produce, such as requiring server-side authorisation, encrypting a data flow, or isolating a build service.
3. Secure Design and Coding
Secure design begins with explicit security requirements. Examples include: users must access only records permitted by their role; passwords must never be stored in recoverable form; administrative actions must be auditable; and sensitive data must be encrypted in transit and at rest where justified by risk.
Important design principles include:
Least privilege: grant only the permissions required for a task and only for as long as needed.
Fail securely: when an error occurs, do not expose sensitive data or default to excessive access.
Defence in depth: use multiple independent protections rather than relying on one control.
Secure defaults: the safest reasonable configuration should be the default.
Complete mediation: check authorisation whenever access is required, not only at login.
Separation of duties: avoid giving one person or process unchecked control over sensitive operations.
Minimisation: collect, retain, and expose only the data required for a legitimate purpose.
Secure coding includes validating input, encoding output for its context, using parameterised database queries, applying safe error handling, and avoiding dangerous dynamic evaluation. Validation should occur on the server because client-side checks can be bypassed. Input validation should use an allow-list where practical, defining acceptable types, lengths, ranges, and formats.
Authentication establishes identity; authorisation determines what that identity may do. These concepts must not be confused. A valid login does not justify unrestricted access. Passwords should be processed with a modern, deliberately slow password-hashing function and a unique salt. Secrets should not be embedded in source code, container images, or chat messages.
Code review is most effective when reviewers examine security assumptions, trust boundaries, error paths, access control, logging, and data handling rather than only style. Automated tools can identify patterns, but a clean scan does not prove that a system is secure.
4. Dependency and Secret Management
Modern applications commonly depend on hundreds of external packages. Dependencies reduce development effort but introduce risks including known vulnerabilities, malicious packages, abandoned maintenance, licence incompatibility, and transitive dependencies that developers did not select directly.
A sound dependency-management practice includes:
recording direct and transitive dependencies;
using lockfiles or equivalent mechanisms to make builds predictable;
obtaining packages from trusted repositories;
reviewing package maintainers, release history, and permissions;
scanning versions against reliable vulnerability sources;
updating regularly and testing updates; and
removing unnecessary packages.
A vulnerability identifier, such as a CVE, is useful information but is not a complete risk decision. The team must consider whether the vulnerable function is used, whether the affected service is reachable, whether compensating controls exist, and whether exploitation is occurring.
A secret is sensitive authentication or cryptographic material, such as an API key, private key, database password, or signing credential. Good practice includes storing secrets in a managed secret store, limiting access, rotating them, auditing use, and preventing them from appearing in logs. If a secret is committed to a repository, deleting the visible line is insufficient: repository history, caches, build logs, and forks may retain it. The exposed credential should be revoked or rotated immediately, followed by investigation.
5. Automated Security Testing in the Pipeline
Security testing should be layered because each technique observes different evidence.
Technique
Main evidence
Typical limitation
SAST
source or bytecode patterns
may produce false positives and miss runtime context
DAST
behaviour of a running application
limited by test coverage and authentication access
SCA
known risks in dependencies
may not identify novel or configuration-specific flaws
Secret scanning
exposed credentials and key-like material
patterns can be missed or falsely detected
IaC scanning
insecure infrastructure definitions
cannot prove the deployed environment matches code
Container scanning
vulnerable packages and image configuration
base-image findings may be difficult to remediate
Penetration testing
realistic attack paths
periodic and scope-limited rather than continuous
A pipeline should have proportionate gates. For example, a confirmed leaked production credential should block release, while a low-confidence warning may create a backlog item for review. If teams receive too many unactionable alerts, they may ignore all alerts. Findings therefore need ownership, severity, evidence, due dates, and an exception process.
Security tests should run in isolated environments using synthetic or carefully protected data. Testing must be authorised; scanning systems without permission can be unlawful or disruptive.
6. Vulnerability Management and Incident Response
Vulnerability management is a lifecycle, not a one-time scan:
discover assets and components;
identify and validate vulnerabilities;
prioritise according to technical and business context;
remediate, mitigate, or formally accept the risk;
verify the fix; and
learn from the result.
A severity score helps compare technical characteristics, but business exposure and exploitability must also be considered. A severe flaw in an unreachable test component may be less urgent than a moderate flaw in an internet-facing payment service.
An incident response capability should define preparation, detection and analysis, containment, eradication, recovery, and lessons learned. For a compromised software credential or build system, response may include isolating the pipeline, revoking signing keys, preserving evidence, identifying affected releases, notifying stakeholders, and issuing a trusted rebuild.
Security logs should support investigation without unnecessarily collecting sensitive personal data. Logs require integrity protection, time synchronisation, access control, retention rules, and alerting that is tuned to meaningful events.
7. Software Supply-Chain Security
The software supply chain includes everyone and everything involved in creating and delivering software: developers, source repositories, package registries, build servers, CI/CD runners, signing systems, artifact stores, deployment tools, cloud platforms, and vendors.
Supply-chain attacks may involve:
a malicious or compromised open-source package;
dependency confusion, in which an attacker publishes a package with a misleading name;
typosquatting, using a name resembling a legitimate package;
compromise of a maintainer account;
poisoned build scripts or CI/CD runners;
tampered artifacts or container images;
stolen signing keys;
unauthorised changes to infrastructure-as-code; or
a vendor compromise affecting many customers.
Controls should address identity, integrity, provenance, and recovery. Examples include protected branches, mandatory review, multi-factor authentication, isolated and ephemeral build runners, restricted network access, pinned dependencies, verified package sources, artifact repositories, and strong separation between build and production privileges.
A software bill of materials (SBOM) is an inventory of software components and relevant metadata. It supports vulnerability response, licence analysis, procurement assurance, and impact assessment when a component is disclosed as vulnerable. An SBOM is not itself proof that components are safe: it must be accurate, maintained, and linked to the actual released artifact.
Provenance records where and how an artifact was produced, including source revision, builder, dependencies, and relevant parameters. Artifact signing uses cryptographic keys to help establish authenticity and integrity. Verification is essential; signing without a trustworthy key-management and verification process provides limited protection. Key rotation, protected storage, revocation, and access auditing are therefore necessary.
Reproducible builds aim for the same source and declared inputs to produce the same output. They can make unauthorised build changes easier to detect, although complete reproducibility may be difficult because of timestamps, nondeterministic tools, environment differences, and unavailable historical dependencies.
Software supply chain with security controls from source to deployment
Figure: Software supply chain with security controls from source to deployment
Figure: Security controls applied across a software supply chain.
8. Least Privilege and Secure Delivery Architecture
CI/CD systems are high-value targets because they can write source code, access secrets, build artifacts, and deploy to production. A compromised pipeline may therefore bypass ordinary application controls.
Practical safeguards include separate identities for build, test, and deployment; short-lived credentials; narrowly scoped permissions; approval for production changes; protected signing keys; network segmentation; and independent audit records. A deployment service should not automatically have permission to alter source repositories, and a build job should not receive a permanent production administrator credential.
Policy as code can express requirements such as “images must originate from an approved registry” or “production deployments require a signed artifact.” Automated policy improves consistency, but policies need ownership, testing, exception handling, and periodic review.
Illustrative Case: A Compromised Dependency in an Online Retailer
Background. An illustrative online retailer operates a web application through a cloud-based CI/CD pipeline. The application uses a popular package for processing customer addresses.
Problem. The package maintainer account is compromised, and a new version collects environment variables during installation. The retailer’s build process automatically accepts the newest compatible version. A build runner contains a cloud credential with permission to publish images and deploy to a staging environment.
Analysis. The immediate threat is secret disclosure during the build. The broader risks include unauthorised image publication, lateral movement through the cloud account, customer-data exposure, and loss of trust. The retailer has no current SBOM and cannot quickly determine which releases contain the package.
Approach. The team first isolates affected runners, revokes and rotates exposed credentials, and preserves logs for investigation. It identifies affected builds from package-lock data and repository history, blocks the malicious version, and rebuilds from a verified source. It then introduces dependency pinning, a private proxy with review controls, SCA scanning, SBOM generation, signed artifacts, short-lived build credentials, and separate deployment identities. A tabletop exercise tests the response procedure.
Outcome. The retailer can identify component versions associated with each release, prevent unsigned images from deployment, and limit the effect of a future build compromise. The controls do not guarantee safety, but they reduce exposure and improve detection and recovery.
Learning points. Supply-chain security requires both prevention and recoverability. Automatic updates without governance can create unacceptable exposure; conversely, never updating creates accumulating vulnerabilities. Risk-based review, traceability, and credential isolation are more valuable than a single scanning tool.
9. Governance, Ethics, and Regulation
Security decisions affect users, employees, suppliers, and the public. Organisations should collect only necessary data, protect it appropriately, explain relevant processing, and retain it only as long as justified. Monitoring must be proportionate and governed; excessive surveillance can damage privacy and trust.
Security professionals have a duty to obtain authorisation before testing, avoid unnecessary disruption, protect discovered information, and disclose vulnerabilities responsibly. A vulnerability report should normally provide evidence, reproduction steps, impact, and a constructive remediation path without publishing dangerous details prematurely.
Governance should define risk ownership, security requirements, approval authority, supplier responsibilities, incident notification, audit rights, and exception expiry. Depending on the sector and jurisdiction, obligations may arise from data-protection, critical-infrastructure, payment, health, or software-security legislation. Legal advice may be required because requirements vary by location and service.
Artificial intelligence can assist with code review, anomaly detection, dependency analysis, and incident triage. However, generated code may contain vulnerabilities, reproduce biased assumptions, or expose confidential prompts and source material. AI outputs require human review, controlled data handling, testing, and clear accountability. AI should augment—not replace—threat modelling and security judgement.
10. Implementation Roadmap for a Small Team
A small organisation can begin without purchasing a large security platform. A staged roadmap is practical:
Stage 1: Establish foundations. Inventory repositories, services, dependencies, secrets, and production accounts. Enable multi-factor authentication, protected branches, backups, and centralised logging.
Stage 2: Add preventive controls. Introduce peer review, secret scanning, dependency lockfiles, secure coding guidance, and least-privilege service accounts.
Stage 3: Automate feedback. Add SAST, SCA, container and infrastructure scanning. Define severity thresholds, owners, remediation targets, and an exception process.
Stage 4: Strengthen assurance. Generate SBOMs, sign artifacts, verify provenance, isolate runners, and test incident-response procedures.
Stage 5: Improve continuously. Measure useful outcomes, review false positives, conduct threat-model updates, learn from incidents, and reassess suppliers.
Useful measures include the age of critical vulnerabilities, percentage of releases with an SBOM, percentage of privileged accounts using multi-factor authentication, secret-leak response time, and the proportion of production artifacts whose signatures are verified. Metrics should support improvement rather than encourage teams to hide findings or optimise for superficial compliance.
Challenges and Limitations
DevSecOps can fail when responsibility is declared “shared” but no one owns decisions. Automation can also create alert fatigue, block urgent fixes, or provide false confidence. Security controls may slow delivery if poorly designed, although well-integrated controls can reduce rework. Legacy systems may lack tests, ownership, or build repeatability. Third-party assurance may be incomplete, and a supplier certificate does not eliminate the customer’s responsibility to configure and monitor its own environment.
The correct response is not to abandon controls but to make them proportionate, observable, and continually improved. Security should be treated as a quality attribute and a business capability, not as an obstacle imposed by a separate department.
Chapter Summary
DevSecOps embeds security across planning, design, coding, testing, release, deployment, operation, and retirement. Threat modelling connects assets, trust boundaries, threats, vulnerabilities, controls, and residual risk. Secure coding relies on least privilege, secure defaults, input validation, safe output handling, strong authentication, authorisation, and careful data management.
Dependency and secret management reduce risks created by external packages and exposed credentials. SAST, DAST, SCA, secret scanning, infrastructure scanning, and penetration testing provide different kinds of evidence and must be used with ownership and judgement. Vulnerability management includes discovery, prioritisation, remediation, verification, and learning.
Software supply-chain security requires trusted sources, protected repositories, isolated builds, short-lived credentials, SBOMs, provenance, artifact signing, policy verification, and recovery planning. Governance and ethics require authorised testing, privacy protection, responsible disclosure, accountability, and proportionate monitoring. The central lesson is that secure delivery is a continuous socio-technical process involving people, practices, technology, and informed risk decisions.
Key Terms
DevSecOps: An approach that integrates security practices and responsibility throughout the software delivery lifecycle.
Asset: Something valuable that requires protection, such as data, credentials, services, or reputation.
Threat: A potential cause of harm to an asset.
Vulnerability: A weakness that can be exploited by a threat.
Risk: The possibility of harm arising from threats exploiting vulnerabilities.
Threat modelling: A structured analysis of system components, trust boundaries, threats, and controls.
Least privilege: Providing only the permissions necessary for a task.
Authentication: Establishing or verifying an identity.
Authorisation: Determining what an authenticated identity may do.
SAST: Static application security testing of source code or bytecode.
DAST: Dynamic application security testing of a running application.
SCA: Software composition analysis of dependencies and their known risks.
Secret: Sensitive credential or cryptographic material requiring controlled protection.
SBOM: A software bill of materials listing components and relevant metadata.
Provenance: Evidence describing where and how an artifact was produced.
Artifact signing: Applying a cryptographic signature to support integrity and authenticity verification.
Supply chain: The people, processes, tools, services, and components involved in producing and delivering software.
Vulnerability management: The lifecycle of discovering, prioritising, remediating, and verifying security weaknesses.
Residual risk: Risk remaining after controls have been applied.
Review Questions
Short Answer Questions
What is the main difference between DevOps and DevSecOps?
Define a vulnerability and give one software example.
Why should secrets not be stored in source code?
What information does an SBOM provide?
State two principles of secure design.
Long Answer Questions
Explain how threat modelling can influence software architecture and delivery decisions.
Compare SAST, DAST, and SCA, including one strength and one limitation of each.
Describe a complete vulnerability-management lifecycle.
Explain how least privilege should be applied to a CI/CD pipeline.
Discuss why artifact signing and provenance are useful but do not, by themselves, guarantee secure software.
Analytical / Application Questions
A development team discovers that a production API key was committed to a public repository. Analyse the immediate response, investigation, remediation, and preventive controls that should follow.
An organisation automatically accepts the latest versions of all dependencies. Evaluate the security and operational advantages and disadvantages of this policy, then recommend a balanced alternative.
Design a basic DevSecOps roadmap for a five-person software team with limited budget. Justify the order of controls and identify the risks that remain after implementation.
Multiple Choice Questions with Answers
Question 1
Which statement best describes DevSecOps?
A. Security is performed only by a specialist team before release.
B. Security responsibility and practices are integrated throughout the delivery lifecycle.
C. Operations is replaced by automated security tools.
D. All software risk is eliminated before development begins.
Correct Answer: B. Security responsibility and practices are integrated throughout the delivery lifecycle.
Question 2
What is the primary purpose of threat modelling?
A. To estimate developer productivity
B. To identify possible threats and select appropriate controls
C. To replace all penetration testing
D. To calculate the exact probability of every attack
Correct Answer: B. To identify possible threats and select appropriate controls
Question 3
Which practice best protects a database password used by a deployment process?
A. Store it in a public README file
B. Embed it in the application source code
C. Store it in a managed secret store with restricted access
D. Place it in a container image label
Correct Answer: C. Store it in a managed secret store with restricted access
Question 4
What does SCA primarily analyse?
A. The visual design of a user interface
B. Software dependencies and their known vulnerabilities
C. Network bandwidth during production use
D. Employee attendance records
Correct Answer: B. Software dependencies and their known vulnerabilities
Question 5
Which statement about an SBOM is correct?
A. It guarantees that every listed component is secure.
B. It inventories software components and supports impact analysis.
C. It replaces the need for access control.
D. It is used only for recording application users.
Correct Answer: B. It inventories software components and supports impact analysis.
Question 6
Which control most directly limits the damage caused by a compromised build job?
A. Giving the job permanent production administrator access
B. Using short-lived, narrowly scoped credentials
C. Disabling all build logs
D. Allowing unrestricted network access
Correct Answer: B. Using short-lived, narrowly scoped credentials
Question 7
What is the main purpose of artifact signing?
A. To increase application execution speed
B. To support verification of artifact integrity and origin
C. To remove all vulnerabilities from dependencies
D. To replace source-code review entirely
Correct Answer: B. To support verification of artifact integrity and origin
Question 8
A package vulnerability is rated technically severe, but the affected function is not used and the service is unreachable. What is the best conclusion?
A. It must always be ignored.
B. Technical severity alone determines the response.
C. Business context and exploitability should inform prioritisation.
D. The package should always be deleted immediately without testing.
Correct Answer: C. Business context and exploitability should inform prioritisation.
Question 9
Which activity is an example of DAST?
A. Inspecting source code for unsafe functions
B. Comparing package versions with vulnerability databases
C. Testing a running web application for observable weaknesses
D. Listing components in an SBOM
Correct Answer: C. Testing a running web application for observable weaknesses
Question 10
What should normally happen after a production secret is exposed?
A. Only delete the visible line from the current file
B. Rotate or revoke the secret and investigate where it may have spread
C. Publish the secret so users know it is compromised
D. Wait until the next scheduled annual review
Correct Answer: B. Rotate or revoke the secret and investigate where it may have spread