6. Secure Software Engineering and DevSecOps

Introduction and Context

Software has become an essential control surface for organisations, governments, and critical infrastructure. A vulnerability in an application can expose confidential data, interrupt operations, enable fraud, or provide a pathway into internal systems. Consequently, application security cannot be treated as a final testing activity performed immediately before release. It must be integrated into requirements, architecture, coding, testing, deployment, operations, and retirement.

Secure software engineering is the disciplined application of security principles throughout the software development life cycle (SDLC). DevSecOps extends this approach by integrating development, security, and operations through shared responsibility, automation, continuous feedback, and risk-based decision-making. Its purpose is not simply to add security tools to a DevOps pipeline. It is to make secure behaviour a normal and measurable part of how software is designed, built, delivered, and operated.

This chapter examines the relationship between threat modeling, secure design, coding standards, security testing, dependency management, API protection, CI/CD controls, infrastructure as code (IaC), software bills of materials (SBOMs), and vulnerability management. These practices are most effective when treated as connected capabilities rather than isolated activities.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the principles and business significance of secure software engineering and DevSecOps.

2. Apply threat modeling to identify and prioritise application risks.

3. Relate secure design principles and coding standards to common vulnerability classes.

4. Distinguish the purposes and limitations of SAST, DAST, SCA, interactive testing, and manual review.

5. Design security controls for APIs, CI/CD pipelines, and infrastructure as code.

6. Explain the role of SBOMs, vulnerability intelligence, remediation priorities, and exception governance.

7. Evaluate organisational, ethical, regulatory, and managerial issues in implementing DevSecOps.

From Secure SDLC to DevSecOps

Traditional development often separated responsibilities: developers produced functionality, a security team reviewed it later, and operations deployed it. This separation created predictable problems. Security findings arrived when changes were expensive to correct, security teams became release bottlenecks, and developers lacked immediate feedback about the causes of vulnerabilities.

A secure SDLC introduces security activities at each stage. Requirements may include authentication, privacy, resilience, and auditability. Architecture reviews examine trust boundaries and failure modes. Developers use approved libraries and defensive coding practices. Automated tools analyse source code, dependencies, containers, and deployment configurations. Dynamic testing examines running systems, while operations monitor abuse and newly disclosed vulnerabilities.

DevSecOps retains the delivery speed and automation of DevOps but makes security a shared responsibility. It has three closely related dimensions:

• People and culture: developers, security practitioners, and operators collaborate and understand their respective risks and constraints.
• Process: security requirements, risk acceptance, review gates, incident feedback, and remediation ownership are embedded in delivery workflows.
• Technology: automated analysis, policy enforcement, secrets management, secure build systems, and monitoring provide rapid and repeatable control.

The objective is not that every developer become a specialist in every security domain. Rather, teams require appropriate security knowledge, usable guardrails, expert support for difficult decisions, and clear accountability.

Threat Modeling as a Design Activity

Threat modeling is a structured method for identifying what can go wrong, why it might happen, and how the system should reduce the associated risk. It is most valuable early in design, when architectural changes are still feasible, but it should be repeated when major functionality, integrations, or deployment conditions change.

A practical threat-modeling process begins by defining the system scope, business purpose, assets, actors, and security objectives. Architects then draw data-flow diagrams showing processes, data stores, external entities, and trust boundaries. A trust boundary is a point at which data or control moves between components with different levels of authority or reliability. Examples include a browser-to-server connection, an application-to-database connection, or a cloud service-to-on-premises link.

The team identifies threats using structured prompts. STRIDE, for example, considers spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Attack trees, abuse cases, and misuse cases can complement STRIDE by expressing how an attacker might achieve a specific objective. Threats should then be assessed according to likelihood, impact, affected assets, exploitability, and existing controls.

Threat modeling is not a search for every imaginable attack. It is a decision-support activity. A useful output links each important threat to a design control, test condition, owner, and residual risk. For example, a threat that an attacker could alter payment instructions may lead to transaction signing, segregation of duties, strong authorisation, audit logging, and tamper-evident monitoring.

Secure Design and Coding Foundations

Secure design seeks to prevent vulnerabilities through architecture rather than relying solely on later detection. Important principles include least privilege, complete mediation, fail-safe defaults, separation of duties, minimisation of attack surface, defence in depth, secure defaults, and economy of mechanism. These principles have practical consequences. A service should receive only the permissions it needs; every access request should be authorised rather than trusting an earlier decision; and failure should deny dangerous actions rather than grant access.

Security requirements should be specific and testable. “The system must be secure” is not an adequate requirement. More useful requirements state that administrative functions require phishing-resistant multifactor authentication, sensitive records must be encrypted in transit and at rest, or an account must be locked or rate-limited after defined suspicious activity.

Secure coding standards translate design expectations into implementation practices. Developers should validate input according to context, encode output appropriately, use parameterised database queries, protect credentials and cryptographic keys, handle errors without exposing sensitive details, and avoid insecure deserialisation. Authentication and authorisation must be distinct: proving identity does not establish permission to perform every operation. Object-level authorisation is especially important in APIs, where a valid user may attempt to access another user’s record by changing an identifier.

Cryptography should be used through well-maintained libraries and approved configurations rather than invented algorithms. Passwords should be stored using an adaptive, salted password-hashing scheme. Secrets should not be committed to source repositories, embedded in images, or printed in logs. Logging should support detection and investigation while avoiding passwords, tokens, unnecessary personal data, and other sensitive values.

Security coding standards do not eliminate the need for design review and testing. They reduce predictable errors, create a common vocabulary, and make code review more consistent.

Security Testing Across the Pipeline

No single testing technique detects all application weaknesses. Their value depends on what they inspect, when they run, and how their results are interpreted.

Static application security testing (SAST) analyses source code, bytecode, or intermediate representations without executing the application. It can identify patterns associated with injection, unsafe API use, weak cryptography, and data-flow errors early in development. SAST is useful for rapid feedback but may generate false positives, miss configuration-dependent weaknesses, and fail to understand business logic.

Dynamic application security testing (DAST) tests a running application from an external perspective. It can identify exposed endpoints, misconfigurations, injection behaviour, authentication weaknesses, and security-header problems. DAST requires a representative and safely configured environment. It may not reach hidden code paths or understand intended authorisation rules.

Interactive application security testing (IAST) combines runtime observation with information about application execution. It can provide more contextual findings, but it requires compatible instrumentation and may impose operational complexity.

Software composition analysis (SCA) inventories open-source and third-party components, identifies known vulnerabilities, and may detect licence obligations. It is essential because an application’s risk includes code that the organisation did not write. SCA findings must be interpreted carefully: the presence of a vulnerable component does not always mean the vulnerable function is reachable, while an unlisted or modified dependency may escape detection.

Manual secure code review, penetration testing, architectural review, fuzzing, and abuse-case testing remain important. Business-logic flaws, complex authorisation failures, chained attacks, and design weaknesses often require human reasoning. Testing should be risk-based. A payment service, identity provider, or internet-facing administrative interface normally warrants more extensive review than a low-impact internal utility.

A mature pipeline establishes severity thresholds, ownership, suppression rules, and retesting procedures. Suppressing a finding should require justification, an expiry date, and an accountable approver. Tool output is not equivalent to risk; it is evidence that must be triaged.

API Security and Service-to-Service Trust

Modern applications are frequently assembled from APIs, mobile clients, microservices, event brokers, and external platforms. This distributed structure increases the number of interfaces and trust relationships.

API security begins with an explicit inventory and an accurate specification. Unused, undocumented, and obsolete endpoints create unnecessary exposure. Authentication should use an appropriate protocol and secure token handling. Authorisation must be enforced at the endpoint, function, and object levels. The server must not rely on client-supplied role indicators, hidden fields, or interface restrictions.

Important controls include strict schema and content validation, request-size limits, rate limiting, replay protection where needed, secure error responses, transport encryption, and controlled cross-origin access. Sensitive operations should receive stronger assurance and monitoring than ordinary queries. Service-to-service authentication should use short-lived credentials, workload identity, mutual TLS, or another controlled mechanism rather than shared permanent secrets.

API gateways can centralise routing, authentication, throttling, and basic inspection, but they do not replace authorisation inside services. Developers must also consider mass assignment, excessive data exposure, server-side request forgery, injection, insecure file handling, and denial-of-service conditions.

CI/CD and Build-System Controls

A CI/CD pipeline is a security-critical production system. It can access source code, signing keys, cloud accounts, deployment environments, and customer-facing infrastructure. Compromise of the pipeline may therefore bypass application controls entirely.

Pipeline protection should include strong identity assurance, least-privilege service accounts, protected branches, mandatory review for sensitive changes, isolated build workers, dependency pinning, signed or attestable build outputs, and controlled promotion between environments. Secrets should be obtained from a dedicated secrets-management service at runtime, with short lifetimes and rotation. Pipeline logs must be protected because they can contain tokens or proprietary information.

Security gates should be proportional. A pipeline might block release for a newly introduced critical vulnerability with a credible exploit path, while routing lower-risk findings to a remediation backlog. Gates that block every warning encourage unsafe workarounds or indiscriminate suppression. Conversely, a pipeline that never stops a release provides little governance value.

Build reproducibility and provenance are increasingly important. Organisations should be able to determine which source revision, dependencies, tools, and build environment produced an artifact. This supports incident investigation and helps prevent substitution of an unapproved artifact during deployment.

Infrastructure as Code and Secure Environments

Infrastructure as code represents networks, identities, compute resources, storage, and security settings in machine-readable form. It improves consistency and reviewability, but insecure code can replicate a weakness across many environments.

IaC should be stored in version control, reviewed like application code, scanned for insecure configurations, and tested before deployment. Typical checks examine publicly exposed storage, unrestricted network rules, excessive identity permissions, unencrypted databases, disabled logging, and unsafe container or Kubernetes settings. Modules should be approved, versioned, and maintained; unverified modules can introduce hidden dependencies or privilege escalation paths.

State files may contain resource identifiers, secrets, or sensitive configuration and therefore require access control, encryption, integrity protection, and secure storage. Drift detection compares declared infrastructure with deployed reality. When manual changes are necessary, they should be recorded and reconciled rather than allowed to become permanent undocumented exceptions.

SBOMs and Vulnerability Management

An SBOM is a machine-readable inventory of an application’s components, versions, suppliers, and relationships. It may include direct and transitive dependencies, operating-system packages, libraries, plugins, and build information. Formats such as SPDX and CycloneDX support exchange, although an SBOM is useful only when it is accurate, current, and linked to a specific artifact.

SBOMs improve vulnerability response by answering questions such as: Which deployed services contain an affected library? Which supplier products use the component? Which versions are exposed? They also support licence review, procurement assurance, and software provenance. They do not prove that software is secure; they identify composition and enable targeted analysis.

Vulnerability management is a lifecycle rather than a scan. It includes discovery, validation, prioritisation, remediation, verification, and reporting. Priority should consider technical severity, exploit availability, exposure, asset criticality, data sensitivity, reachability, compensating controls, and operational consequences. A critical issue in an isolated test environment may be less urgent than a medium-severity flaw in an internet-facing identity service.

Effective programmes define remediation service levels, assign owners, track exceptions, and verify closure. Risk acceptance should be explicit, time-bounded, evidence-based, and approved by an authority with an appropriate view of business consequences. Repeated exceptions often indicate architectural debt or unrealistic delivery processes rather than isolated developer failure.

An Illustrative Case: The Meridian Payments Platform

Background

Meridian, a fictional financial-services organisation, replaced a monolithic payment application with cloud-hosted microservices. Releases occurred several times each week. The platform used external identity, fraud-detection, and notification APIs, while infrastructure was managed through IaC.

Situation and Problem

A penetration test found that an authenticated customer could alter an account identifier in a transaction-status request and retrieve another customer’s information. SCA also identified an outdated framework with a publicly known vulnerability. The CI pipeline stored a cloud credential as a long-lived environment variable, and the organisation could not determine which deployed services contained the vulnerable framework.

Analysis

Threat modeling showed that the original design treated authentication as sufficient and did not model object-level authorisation or the pipeline as a high-value target. The API specification was incomplete, and services trusted identity claims without consistently verifying resource ownership. The lack of an SBOM slowed impact assessment. The cloud credential increased the potential impact of a pipeline compromise.

Approach

Meridian introduced a threat-model review for material architecture changes and created data-flow diagrams for payment and identity services. Object-level authorisation was implemented in the service layer, with tests for cross-account access. The vulnerable framework was upgraded after compatibility testing. SCA and SBOM generation were added to the build process, and deployment was blocked when defined high-risk conditions were met.

The long-lived credential was replaced with workload identity and short-lived permissions. IaC scanning examined public exposure, encryption, identity permissions, and logging. DAST was run against a representative staging environment, while targeted manual testing examined payment workflows. Findings were assigned to service owners and tracked through risk-based remediation deadlines.

Outcome

The immediate authorisation flaw was corrected and verified through automated regression tests and manual assessment. Meridian gained an inventory of affected components and could determine whether future advisories affected production. The pipeline became more resistant to credential theft, although the organisation recognised that tool deployment alone would not solve design and ownership problems.

Learning Points

The case demonstrates that application risk is systemic. An API defect, dependency exposure, weak pipeline credential, and absent inventory reinforced one another. Threat modeling, secure design, automated analysis, identity controls, SBOMs, and governance produced greater value as an integrated system.

Organisational, Ethical, and Governance Considerations

DevSecOps changes responsibilities and incentives. Security teams must avoid becoming a central approval bottleneck; developers must treat security findings as engineering work; and leaders must provide time, skills, and investment for remediation. Metrics should reward reduced exposure and timely risk treatment rather than merely counting scans or vulnerabilities.

Privacy must be considered in telemetry, testing data, logs, and monitoring. Production data should not be copied into development environments without lawful purpose and appropriate protection. Security testing must be authorised, scoped, and conducted without causing avoidable harm. Supply-chain assessments should be proportionate and should not encourage unsupported claims that a vendor or open-source maintainer can guarantee complete security.

Regulatory and contractual obligations may require secure development practices, breach reporting, audit evidence, vulnerability response, access control, or software transparency. Organisations should map obligations to controls and retain evidence without collecting unnecessary personal data. Senior management remains accountable for accepting material risk; delegation of remediation does not eliminate governance responsibility.

Challenges and Common Failure Modes

Common failures include treating tools as a substitute for expertise, scanning only at the end of development, accepting large numbers of false positives, ignoring business logic, and failing to test the deployed configuration. Other weaknesses arise when teams share credentials, permit unreviewed pipeline changes, use unmaintained dependencies, create SBOMs only for compliance, or allow permanent vulnerability exceptions.

DevSecOps also faces cultural resistance. Developers may perceive security as unpredictable, while security specialists may underestimate delivery constraints. The response should include enablement, secure reusable patterns, office hours, threat-model facilitation, developer-friendly findings, and gradual automation. Controls should be evaluated for effectiveness and friction, then refined using evidence.

Emerging Directions and Best Practices

Current practice is moving toward software supply-chain assurance, signed provenance, identity-based workload access, policy as code, continuous exposure management, and automated evidence collection. Artificial intelligence is increasingly used to assist code review, generate tests, classify findings, and detect suspicious patterns. Such systems can improve productivity but may produce incorrect suggestions, reproduce insecure code, expose proprietary material, or create an illusion of assurance. Human review, data-governance controls, and validation remain necessary.

A practical DevSecOps programme should:

• define security requirements and risk ownership early;
• maintain threat models for important systems;
• use secure frameworks, approved libraries, and reusable controls;
• combine SAST, DAST, SCA, IaC analysis, manual review, and operational feedback;
• protect source repositories, build systems, artifacts, and deployment identities;
• generate and validate SBOMs for released artifacts;
• prioritise vulnerabilities using business context and exploitability;
• measure remediation, exception age, coverage, and recurring causes; and
• learn from incidents, near misses, and production telemetry.

Chapter Summary

Secure software engineering embeds security across the SDLC, while DevSecOps integrates development, security, and operations through shared responsibility and automation. Threat modeling connects assets, trust boundaries, threats, controls, and residual risk. Secure design and coding practices reduce vulnerabilities before testing. SAST, DAST, SCA, IAST, manual review, and penetration testing provide complementary evidence rather than interchangeable answers.

API security requires strong authentication, object-level authorisation, validation, rate control, and secure service trust. CI/CD and IaC must be protected because they control software and infrastructure at scale. SBOMs provide component visibility, while vulnerability management combines discovery, contextual prioritisation, remediation, verification, and governed exceptions. Effective programmes balance automation with expert judgment, privacy, accountability, and continuous improvement.

Key Terms

Threat modeling: A structured process for identifying, assessing, and treating threats to a system.

DevSecOps: An approach integrating development, security, and operations throughout continuous delivery.

Trust boundary: A point where data or control crosses between components with different trust or privilege levels.

STRIDE: A threat categorisation method covering spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

Secure-by-design: Designing architecture and requirements so that security is built into functionality rather than added later.

Least privilege: Giving users, services, and processes only the permissions necessary for their tasks.

SAST: Automated analysis of source, bytecode, or intermediate code without executing the application.

DAST: Security testing performed against a running application.

IAST: Runtime security analysis combining execution information with application context.

SCA: Analysis of third-party and open-source components for vulnerabilities and other risks.

API security: Controls protecting application interfaces, data, authentication, authorisation, and availability.

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

Infrastructure as code: Machine-readable definition and management of infrastructure resources.

SBOM: A machine-readable inventory of software components and their relationships.

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

Vulnerability triage: The process of validating, contextualising, and prioritising security findings.

Risk acceptance: Formal approval to tolerate a defined risk for a specified period or condition.

Policy as code: Machine-readable security or compliance rules that can be automatically evaluated.

Supply-chain security: Protection of software, dependencies, tools, build systems, and suppliers from compromise.

Review Questions

Short Answer Questions

1. What is the principal difference between a secure SDLC and a traditional late-stage security review?

2. Define a trust boundary and give one software example.

3. What types of evidence do SAST and DAST provide?

4. Why is object-level authorisation important in API security?

5. What is the purpose of an SBOM?

Long Answer Questions

1. Explain a complete threat-modeling process and show how its results should influence design and testing.

2. Compare SAST, DAST, SCA, IAST, manual review, and penetration testing, including the limitations of each.

3. Discuss the security requirements for a CI/CD pipeline that deploys cloud infrastructure.

4. Explain how vulnerability management should combine technical severity with business context.

5. Analyse the organisational and governance changes required to implement DevSecOps effectively.

Analytical / Application Questions

1. A service authenticates users correctly but allows them to change a record identifier in a request. Identify the likely weakness, explain how it could be tested, and propose design controls.

2. An organisation discovers a critical dependency vulnerability but cannot determine which production systems use the dependency. Evaluate the process failures and recommend a remediation plan.

3. A development team proposes blocking every pipeline whenever any security scanner reports a finding. Assess this proposal and design a more effective risk-based release policy.

22. Multiple Choice Questions with Answers

Question 1

Which activity most directly connects identified threats to design controls and test conditions?

A. Generating an SBOM

B. Threat modeling

C. Dependency pinning

D. Log aggregation

Correct Answer: B. Threat modeling

Question 2

A scanner analyses source code without running the application. Which technique is being used?

A. DAST

B. IAST

C. SAST

D. Fuzz testing

Correct Answer: C. SAST

Question 3

Why does an SBOM improve vulnerability response?

A. It proves that the application has no vulnerabilities

B. It identifies which software components are present in deployed artifacts

C. It automatically patches every vulnerable dependency

D. It replaces penetration testing

Correct Answer: B. It identifies which software components are present in deployed artifacts

Question 4

A valid user changes an object identifier and receives another customer’s record. Which control is most directly missing?

A. Object-level authorisation

B. Transport encryption

C. Source-code signing

D. Password hashing

Correct Answer: A. Object-level authorisation

Question 5

Which pipeline practice best reduces the risk of credential compromise?

A. Storing a permanent cloud key in an environment variable

B. Printing deployment tokens in build logs

C. Using workload identity and short-lived permissions

D. Sharing one administrator account across projects

Correct Answer: C. Using workload identity and short-lived permissions

Question 6

What is a significant limitation of DAST?

A. It cannot test a running application

B. It may fail to reach hidden paths or understand business logic

C. It only analyses third-party libraries

D. It always produces source-code-level explanations

Correct Answer: B. It may fail to reach hidden paths or understand business logic

Question 7

Which factor should influence vulnerability remediation priority besides technical severity?

A. The colour of the development team’s interface

B. Asset criticality and exposure

C. The number of lines in the application only

D. Whether the finding was discovered on a Monday

Correct Answer: B. Asset criticality and exposure

Question 8

Why should infrastructure-as-code modules be reviewed and versioned?

A. They can replicate insecure configurations across many environments

B. They eliminate the need for access control

C. They prevent all cloud outages

D. They make vulnerability management unnecessary

Correct Answer: A. They can replicate insecure configurations across many environments

Question 9

Which statement best describes DevSecOps?

A. Security is performed only by a central security department

B. Security is postponed until after deployment

C. Development, security, and operations share responsibility supported by integrated processes and automation

D. Security tools are purchased without changing development practices

Correct Answer: C. Development, security, and operations share responsibility supported by integrated processes and automation

Question 10

What is the most appropriate governance for a vulnerability exception?

A. Allow it indefinitely without documentation

B. Suppress it silently to protect delivery metrics

C. Document the rationale, assign an approver, and set an expiry or review date

D. Delete the finding from the security tool

Correct Answer: C. Document the rationale, assign an approver, and set an expiry or review date