9. Secure Software, Data and DevSecOps

Introduction and Context

Software has become a primary control surface for organisational security. Business processes, public services, industrial systems, financial transactions, healthcare records and research infrastructures are increasingly mediated by applications and application programming interfaces (APIs). Consequently, cybersecurity cannot be treated as a perimeter function added after software deployment. A vulnerability in source code, a compromised dependency, an exposed database, an insecure pipeline or an incorrectly governed dataset can create consequences that are operational, legal, financial and societal.

Secure software, data protection and DevSecOps address this problem as a connected system. Secure software development establishes security requirements, architectural constraints, coding practices and verification activities. Data security governs information throughout its lifecycle, from collection and classification to retention and destruction. DevSecOps integrates security into development and operations through collaboration, automation, continuous assurance and feedback. The objective is not merely to find more defects, but to make secure decisions earlier, make evidence observable, and reduce the probability and impact of failure.

At doctoral level, the subject should be understood as socio-technical rather than purely technical. Tools do not create security independently of organisational incentives, developer behaviour, governance structures, threat models and accountability. A technically sophisticated scanning programme may still fail if teams suppress findings to meet delivery targets, if ownership is unclear, or if security requirements are disconnected from business risk.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the relationship between secure development lifecycles, requirements engineering, secure coding and application assurance.

2. Evaluate models and practices for integrating security into agile and DevOps environments.

3. Analyse API, database, software supply-chain and CI/CD risks.

4. Design a data lifecycle governance approach incorporating classification, protection, retention and disposal.

5. Interpret the role and limitations of SBOMs, automated testing and security analytics.

6. Recommend organisational, technical and ethical controls for secure software delivery.

7. Apply these ideas to a realistic enterprise case and defend trade-offs between security, usability, cost and delivery speed.

Security as a Property of the Development System

A secure application is not simply one that has passed a penetration test. Security is an emergent property of requirements, architecture, implementation, deployment configuration, operational monitoring and maintenance. This observation has two implications. First, security must be considered throughout the software development lifecycle (SDLC). Second, security assurance must continue after release because threats, dependencies, configurations and business uses change.

Traditional waterfall approaches often placed security reviews at formal stage boundaries. Agile methods shortened delivery cycles and encouraged iterative development, but could unintentionally reduce the time available for security analysis. DevOps improved collaboration between development and operations, yet its automation and release velocity introduced new risks in build systems, repositories, secrets management and deployment platforms. DevSecOps responds by embedding security responsibilities and controls across the value stream rather than assigning them exclusively to a security team.

The secure SDLC commonly includes the following activities:

• security governance and definition of roles;
• abuse-case and threat analysis during requirements and design;
• secure architecture and trust-boundary review;
• secure coding and peer review;
• automated and manual security testing;
• controlled release and deployment;
• vulnerability management, monitoring and incident response; and
• lessons learned, patching and secure retirement.

These activities are not necessarily sequential. In contemporary development, they operate as a feedback loop. A production incident may reveal a missing requirement; that requirement can become a test, a coding rule, an architectural constraint and a monitoring signal.

Requirements Engineering and Threat-Informed Design

Security requirements translate business, legal and threat concerns into verifiable system properties. Functional requirements describe what a system must do; security requirements constrain how it must behave under normal and hostile conditions. Examples include authentication assurance, authorisation boundaries, auditability, confidentiality, availability objectives, privacy obligations and recovery capabilities.

Weak requirements are often expressed as broad aspirations, such as “the system must be secure.” Strong requirements are testable and contextual. For example, “administrative actions must require phishing-resistant multi-factor authentication and must be recorded with actor, timestamp, target and outcome” provides a basis for design and verification. Requirements should also identify assumptions, assets, trust boundaries, misuse conditions and acceptance criteria.

Threat modelling is a structured method for anticipating how a system could be attacked or misused. A practical process is to:

1. define system scope, assets and security objectives;

2. diagram data flows, components, identities and trust boundaries;

3. identify threats using structured prompts or threat libraries;

4. assess likelihood, impact and uncertainty;

5. select mitigations and assign owners; and

6. link mitigations to requirements, tests and operational controls.

STRIDE, for example, prompts consideration of spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Attack trees model how an adversary could achieve a goal through alternative paths. Abuse cases describe malicious or unintended use from an attacker’s perspective. These methods are aids to reasoning, not substitutes for expert judgement. Their quality depends on system knowledge, current threat intelligence and honest treatment of uncertainty.

Risk-based prioritisation is essential. A low-severity coding issue in an isolated internal tool may deserve less immediate attention than a moderate authorisation weakness in an API exposing sensitive data. Nevertheless, risk scoring should not become a mechanism for ignoring systemic weaknesses. Repeated low-level issues may indicate inadequate engineering practices, poor training or an unsafe architecture.

Secure Architecture and Coding

Secure architecture reduces the number and consequence of implementation errors. Important architectural principles include least privilege, defence in depth, secure defaults, separation of duties, fail-safe behaviour, complete mediation, minimisation and explicit trust boundaries. Security design should address identity, session management, service-to-service communication, cryptographic key handling, error behaviour, logging and recovery.

Secure coding converts these principles into implementation practices. Input validation should be based on expected type, length, range, format and business context. Validation is not a complete defence against injection; parameterised queries, contextual output encoding and safe APIs are also required. Authentication must be distinguished from authorisation: verifying who a user is does not establish what that user may do. Authorisation decisions should be centralised where appropriate, deny by default and checked on every sensitive operation.

Common application weaknesses include injection, broken access control, insecure deserialisation, server-side request forgery, cross-site scripting, weak cryptography, unsafe file handling, information leakage and poor error recovery. Secure coding standards should prohibit hard-coded secrets, uncontrolled dynamic execution, insecure random number generation and logging of credentials or sensitive personal data.

Cryptography illustrates the difference between using a technology and applying it correctly. Organisations should use reviewed libraries and established protocols rather than inventing algorithms. Key generation, storage, rotation, revocation, backup and access control are often more important than selecting an algorithm in isolation. Encryption does not solve an authorisation failure if an attacker can obtain decryption privileges through a compromised application identity.

Code review is most effective when reviewers examine design assumptions, data flows, privilege boundaries and failure modes, rather than merely style. Static application security testing (SAST) analyses source or compiled code; dynamic application security testing (DAST) examines running applications; interactive testing instruments applications during execution; and software composition analysis (SCA) identifies vulnerable or prohibited dependencies. Each has blind spots. SAST may produce false positives and miss deployment weaknesses, while DAST may not reach untested paths or understand business logic.

Application, API and Identity Security

APIs expose business capabilities directly and are therefore a major security boundary. API security requires more than transport encryption. It includes strong authentication, precise authorisation, schema validation, rate controls, input and output handling, inventory management, secure error responses and monitoring of abnormal use.

Object-level authorisation is a particularly important concern. An API may correctly authenticate a user but fail to verify whether that user may access the specific object identified in a request. Similarly, excessive data exposure occurs when an endpoint returns more fields than the client requires. Mass assignment can allow clients to modify fields that should be server-controlled. Defences include server-side allow-lists, policy enforcement close to the protected resource, non-guessable identifiers where appropriate, pagination limits and explicit response models.

API gateways can provide authentication integration, traffic controls, schema enforcement and observability, but they should not become the sole location of security logic. Microservices must also validate identity and authorisation in their own context. Service identities should be short-lived and narrowly scoped. Secrets should be stored in managed secret systems, not source repositories, container images or pipeline variables visible to unauthorised users.

Software Supply-Chain Assurance and SBOMs

Modern software is assembled from open-source libraries, commercial components, container images, build tools, plugins, hosted services and machine-generated code. This creates a software supply-chain problem: an organisation may be compromised through a dependency or build process even when its own source code appears sound.

Supply-chain controls should include dependency pinning, trusted registries, provenance verification, digital signatures, vulnerability monitoring, reproducible or attestable builds, restricted build permissions and separation between source, build and release authority. Dependency updates should be tested and prioritised according to exploitability, exposure, reachability and business impact rather than severity alone.

A software bill of materials (SBOM) is a structured inventory of software components and their relationships. It supports vulnerability response, licensing review, asset visibility and supplier assurance. However, an SBOM is not proof that software is secure. It may be incomplete, stale, ambiguous about component versions or unable to reveal malicious behaviour. Its value depends on standard formats, reliable generation, validation, ownership and integration with vulnerability and asset-management processes.

The emerging concept of software supply-chain levels emphasises progressively stronger controls: documented build processes, protected source repositories, two-person review for sensitive changes, hardened build environments, provenance metadata and verifiable release artefacts. Organisations should apply controls proportionately, recognising that small suppliers may lack the resources of large vendors. Contractual requirements, support and shared assessment mechanisms can reduce this imbalance.

CI/CD Security and DevSecOps Operating Models

Continuous integration and continuous delivery pipelines are privileged production systems. Anyone able to alter pipeline definitions, inject build steps or access signing keys may influence released software. Pipeline security therefore requires strong identity management, protected branches, mandatory review, isolated runners, minimal tokens, secret scanning, dependency controls, signed artefacts and tamper-evident logs.

Security checks should be placed at points where they provide useful feedback. Pre-commit and pull-request controls can catch secrets and unsafe patterns early. Build stages can perform SAST, SCA, container analysis and infrastructure-as-code checks. Staging environments can support DAST, API testing and attack simulation. Release gates should incorporate risk, test results, exceptions and approval authority. Production monitoring should detect abnormal behaviour and provide feedback to development.

Automation does not eliminate governance. A failed scan may represent a false positive, a compensating control or a genuinely unacceptable risk. Exception processes should record the finding, rationale, owner, expiration date and compensating measures. Permanent exceptions are often evidence that the control is ineffective or the risk has been normalised.

DevSecOps also changes professional roles. Developers need practical security competence; security specialists need knowledge of engineering workflows; operations teams need to understand identity, configuration and evidence; and leaders must align incentives so that secure delivery is valued alongside speed. A useful measure is not the number of tools deployed, but the reduction in exploitable exposure, time to remediate, recurrence of defects and uncertainty about release integrity.

Data Protection Across the Information Lifecycle

Data security begins with governance. Organisations should know what data they collect, why they collect it, where it is stored, who can access it, how it flows between systems and when it should be deleted. Classification schemes commonly distinguish public, internal, confidential and highly restricted information, although labels must be linked to actual controls.

The data lifecycle includes collection, creation, processing, storage, sharing, archival, retention and secure destruction. Collection should be limited to legitimate and necessary purposes. Data quality controls are security controls because inaccurate records can cause incorrect access decisions, fraud or unsafe operations. During processing, access should be based on role, purpose and context, with privileged access monitored and periodically reviewed.

Database protection includes network segmentation, strong administrative authentication, patching, secure configuration, encryption in transit and at rest, activity monitoring, backup protection and tested recovery. Database accounts should be separated by application, administrator and operational function. Applications should not use unrestricted database-owner privileges. Parameterised queries and stored procedures may reduce injection risk, but they do not replace application-level authorisation.

Backups must be treated as high-value data. They require access control, encryption, integrity protection, retention rules and recovery testing. Immutable or offline copies can reduce the impact of ransomware, but recovery plans must also address identity services, application dependencies, key availability and data consistency.

Privacy engineering complements security engineering. Techniques such as minimisation, tokenisation, pseudonymisation, aggregation and privacy-preserving analytics can reduce exposure, but pseudonymised data may remain personal data if re-identification is reasonably possible. Data governance must therefore consider purpose limitation, transparency, individual rights, cross-border transfers, retention and lawful access.

Illustrative Case: Meridian Health Services

Background

Meridian Health Services, a fictional regional healthcare provider, operated patient portals, clinical applications and mobile services. Its development teams released updates weekly through a cloud-based CI/CD pipeline. The organisation maintained a central API gateway, several microservices and databases containing clinical and administrative information.

Situation and Problem

A security review discovered that a mobile API returned excessive patient fields and that object-level authorisation was inconsistently enforced. A dependency used by multiple services had a newly disclosed vulnerability. Meridian possessed SBOMs for some applications but could not determine which production services used the affected component. Pipeline credentials were long-lived, and backups were encrypted but accessible through the same administrative identity used for production databases.

Analysis

The immediate issues were technical, but the deeper problem was fragmented assurance. Security requirements had not been translated into reusable API tests. Service ownership was unclear, dependency inventories were incomplete, and the pipeline had greater privilege than necessary. The backup design lacked separation of duties. A narrow penetration test could identify some symptoms but would not address the systemic weaknesses.

Approach and Strategy

Meridian established a product-security working group involving clinical governance, privacy, development, operations and risk management. It classified patient data as highly restricted and defined explicit API requirements for object authorisation, field minimisation, auditability and rate control. Automated tests were added to pull requests and staging environments. Services adopted short-lived workload identities, and database permissions were reduced to the queries required by each service.

The organisation standardised SBOM generation and validation at release time, linked components to service owners and added vulnerability intelligence to its asset register. The vulnerable dependency was prioritised according to exposure and exploitability. Pipeline permissions were redesigned, signing keys were isolated, and protected branches required independent review. Backup administration was separated from production administration, and restoration exercises were scheduled.

Outcome

The changes did not guarantee the absence of vulnerabilities, but they improved visibility, reduced privilege, shortened vulnerability triage and made security requirements testable. Meridian could identify affected services and owners more quickly, demonstrate governance evidence to auditors and detect unauthorised API access more reliably.

Learning Points

The case demonstrates that secure software is a chain of mutually dependent practices. An SBOM without ownership is an inventory without response capability. Encryption without identity separation does not adequately protect backups. API authentication without object authorisation leaves sensitive resources exposed. Most importantly, DevSecOps is an operating model in which people, process, architecture and automation reinforce one another.

Challenges, Limitations and Common Errors

Security automation can create alert fatigue when findings are numerous, duplicated or poorly prioritised. Excessive blocking can encourage teams to bypass controls, while insufficient enforcement produces a compliance ritual rather than assurance. Tool results should therefore be risk-ranked, deduplicated and connected to remediation workflows.

A second limitation is the difficulty of testing business logic. Automated scanners are useful for known patterns but may not understand unusual workflows, conflicting permissions or harmful combinations of legitimate actions. Manual review, threat modelling, red teaming and domain expertise remain necessary.

Third, organisations often confuse compliance evidence with security effectiveness. A completed checklist may show that a process exists, not that it works under realistic conditions. Metrics should include control performance, recurring defects, exploitable exposure, remediation quality and recovery capability.

Other common errors include retaining data indefinitely, treating development and test copies as harmless, placing secrets in logs, relying on a gateway for all authorisation, accepting unverified dependencies, failing to test restoration and granting broad administrative access for convenience.

Governance, Ethics and Professional Responsibility

Secure development involves decisions about surveillance, autonomy, access, discrimination, disclosure and acceptable risk. Logging may support accountability but can create a secondary privacy risk. Security analytics and AI-assisted coding can improve productivity while introducing false positives, biased decisions, insecure generated code or leakage of proprietary information. Human review, data minimisation, model governance and traceability are therefore necessary.

Responsible vulnerability disclosure requires coordinated communication, preservation of evidence, protection of affected users and avoidance of unnecessary public harm. Organisations should not punish good-faith researchers who follow an authorised disclosure process. At the same time, researchers must respect legal boundaries, minimise data access and avoid destructive testing.

Governance should assign accountable owners for applications, data, dependencies, pipelines and exceptions. Boards and senior leaders need meaningful risk information rather than raw vulnerability counts. Regulations and standards can establish minimum expectations, but professional judgement remains necessary where requirements conflict or technology changes faster than formal rules.

Emerging Directions

Software assurance is moving toward continuous evidence: signed artefacts, provenance attestations, policy-as-code, runtime telemetry and automated mapping between requirements, tests and releases. Confidential computing, stronger workload identity and privacy-enhancing technologies may reduce exposure in shared environments. Artificial intelligence is increasingly used for code generation, vulnerability triage and anomaly detection, but generated code must be treated as untrusted output requiring review and testing.

The future challenge is not simply adding more scanners. It is creating trustworthy, explainable and resilient delivery systems in which evidence can be interpreted by humans, controls adapt to changing threats and security remains effective under operational pressure.

Best Practices for Secure Software and Data Operations

Effective programmes generally share the following characteristics:

• security requirements are explicit, testable and linked to business risk;
• threat modelling occurs when architecture and significant changes are designed;
• secure defaults and least privilege are built into reusable platforms;
• APIs enforce object-level authorisation and minimise returned data;
• dependencies, build processes and release artefacts are inventoried and protected;
• pipelines use short-lived credentials, isolated runners and auditable approvals;
• SAST, DAST, SCA, secret detection and manual assessment are used according to purpose;
• data is classified, minimised, encrypted, monitored, retained and destroyed appropriately;
• exceptions are time-limited, owned and supported by compensating controls; and
• incidents, defects and near misses generate measurable improvement.

Chapter Summary

Secure software, data and DevSecOps form an integrated assurance discipline. Secure SDLC practices begin with threat-informed, testable requirements and continue through architecture, coding, testing, deployment, monitoring and retirement. API security requires both authentication and resource-level authorisation. Supply-chain assurance depends on trusted dependencies, protected builds, provenance and useful SBOMs. CI/CD pipelines must be treated as privileged systems and secured through identity, isolation, review and evidence.

Data protection spans collection to destruction and requires classification, minimisation, access control, encryption, monitoring, backup security and recovery testing. Automation improves speed and consistency but cannot replace judgement, governance or manual analysis of business logic. The central lesson is that cybersecurity outcomes depend on the whole delivery system: technology, people, incentives, processes and accountability.

Key Terms

Secure SDLC: A development lifecycle that integrates security activities from conception through retirement.

DevSecOps: An operating approach that embeds security responsibilities, collaboration and automation across development and operations.

Threat modelling: A structured analysis of assets, trust boundaries, threats, risks and mitigations.

Abuse case: A description of how a system may be misused or attacked.

Least privilege: Giving an identity only the permissions necessary for authorised tasks.

Secure default: A configuration that provides protection without requiring the user to activate it.

SAST: Automated analysis of source or compiled code for security weaknesses.

DAST: Testing of a running application to identify observable security weaknesses.

Software composition analysis: Examination of third-party and open-source components for risk, vulnerability and licensing issues.

API: A defined interface through which software components exchange data or invoke functions.

Object-level authorisation: Verification that a requester may access the particular resource identified in a request.

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

Software provenance: Evidence describing where and how a software artefact was produced.

CI/CD pipeline: Automated processes that integrate, test, build and deliver software.

Data classification: Categorisation of information according to sensitivity and required protection.

Data minimisation: Limiting collection and processing to information necessary for a defined purpose.

Pseudonymisation: Replacing identifying attributes with substitutes while retaining the possibility of controlled re-identification.

Policy as code: Expressing governance or security rules in machine-readable form for automated enforcement.

Review Questions

Short Answer Questions

1. Why is security considered an emergent property of the development system rather than merely a feature of source code?

2. Distinguish authentication from authorisation in an API context.

3. What information does an SBOM provide, and what does it not prove?

4. Why should backups be governed as high-value data?

5. Define data minimisation and explain its security relevance.

Long Answer Questions

1. Explain how threat modelling can connect requirements engineering, architecture, testing and operational monitoring.

2. Evaluate the complementary strengths and limitations of SAST, DAST and software composition analysis.

3. Discuss the controls required to secure a CI/CD pipeline as a privileged production system.

4. Analyse how data classification, retention and destruction contribute to information assurance.

5. Explain why DevSecOps is an organisational operating model rather than simply a collection of security tools.

Analytical / Application Questions

1. An API correctly authenticates users but permits them to retrieve records belonging to other users by changing an identifier. Analyse the weakness and propose controls at the application, API and monitoring layers.

2. A critical dependency vulnerability is announced, but an organisation has incomplete SBOM coverage. Develop a prioritised response strategy that addresses technical, governance and supply-chain issues.

3. Design a secure release process for a healthcare application containing sensitive data. Identify requirements, pipeline controls, testing activities, data governance measures and evidence needed for accountable approval.

22. Multiple Choice Questions with Answers

Question 1

Which statement best explains the purpose of threat modelling in a secure SDLC?

A. It replaces the need for penetration testing after deployment.

B. It identifies assets, trust boundaries, threats and mitigations early enough to influence design.

C. It guarantees that all vulnerabilities will be discovered before release.

D. It focuses only on choosing encryption algorithms.

Correct Answer: B. It identifies assets, trust boundaries, threats and mitigations early enough to influence design.

Question 2

A user is authenticated successfully but can retrieve another patient's record by changing an object identifier in an API request. What is the primary weakness?

A. Insufficient object-level authorisation

B. Weak transport encryption

C. Excessive password complexity

D. Inadequate SBOM generation

Correct Answer: A. Insufficient object-level authorisation

Question 3

Which statement most accurately describes an SBOM?

A. A guarantee that every component is free from malicious code.

B. A structured inventory of software components and their relationships.

C. A replacement for vulnerability management and ownership.

D. A record containing only internally developed source files.

Correct Answer: B. A structured inventory of software components and their relationships.

Question 4

Why should CI/CD pipelines receive strong security protection?

A. They are used only for documentation and therefore have low privilege.

B. They can influence build outputs, release artefacts and production deployments.

C. They eliminate the need for source-code review.

D. They prevent all insider threats when automated.

Correct Answer: B. They can influence build outputs, release artefacts and production deployments.

Question 5

Which control most directly reduces the risk of an application modifying unauthorised database records?

A. Granting the application database-owner privileges

B. Using separate, narrowly scoped database identities and enforcing application authorisation

C. Disabling database activity logging

D. Returning all database columns to the client for transparency

Correct Answer: B. Using separate, narrowly scoped database identities and enforcing application authorisation

Question 6

What is a significant limitation of automated application security scanning?

A. It cannot identify any syntactic coding errors.

B. It may miss business-logic flaws and generate false positives.

C. It makes manual review legally prohibited.

D. It works only on paper-based systems.

Correct Answer: B. It may miss business-logic flaws and generate false positives.

Question 7

Which practice best supports secure software supply-chain assurance?

A. Downloading dependencies from any convenient public location

B. Using trusted registries, pinned versions, provenance evidence and protected build processes

C. Allowing unrestricted pipeline tokens to simplify automation

D. Updating dependencies without testing or ownership

Correct Answer: B. Using trusted registries, pinned versions, provenance evidence and protected build processes

Question 8

Which activity is an example of data minimisation?

A. Collecting every available field in case it becomes useful later

B. Retaining all personal data permanently for convenience

C. Collecting and processing only the information necessary for a defined purpose

D. Copying production data into every development environment

Correct Answer: C. Collecting and processing only the information necessary for a defined purpose

Question 9

Why is encryption alone insufficient for protecting organisational data?

A. Encryption cannot be implemented in databases.

B. Unauthorised identities may still obtain decryption privileges or access data through the application.

C. Encryption prevents auditing.

D. Encrypted data cannot be backed up.

Correct Answer: B. Unauthorised identities may still obtain decryption privileges or access data through the application.

Question 10

Which metric would provide stronger DevSecOps insight than simply counting vulnerabilities?

A. Number of security tools purchased

B. Number of pages in the security policy

C. Recurring defect rate, exploitable exposure and time to remediate

D. Total number of developers in the organisation

Correct Answer: C. Recurring defect rate, exploitable exposure and time to remediate