Secure Software Development Lifecycle and DevSecOps

Introduction

Modern applications are assembled from source code, open-source components, cloud services, containers, infrastructure definitions, APIs, identities, and data stores. A vulnerability in any of these elements can compromise confidentiality, integrity, availability, safety, or privacy. Security therefore cannot be treated as a final testing activity. It must be managed throughout the software development lifecycle (SDLC), from business requirements through retirement.

The secure SDLC embeds security decisions into planning, requirements, architecture, implementation, verification, release, operation, and maintenance. DevSecOps extends this principle by integrating security practices into collaborative development and operations workflows. Its goal is not simply to add more tools, but to provide rapid, evidence-based feedback while software is being designed and delivered.

This chapter explains security activities, controls, automation, governance, and professional practices for an advanced-diploma student preparing to work in application security, software engineering, cloud operations, or security assurance.

Learning Objectives

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

1. Explain how security is embedded in each SDLC phase.
2. Distinguish SAST, DAST, IAST, SCA, secret scanning, and infrastructure-as-code scanning.
3. Design security gates and risk-based exception processes in CI/CD pipelines.
4. Explain SBOMs, provenance, secure releases, and software supply-chain risk.
5. Apply DevSecOps practices to an illustrative application scenario.
6. Evaluate technical, organizational, ethical, and governance limitations of automated security testing.

1. Secure SDLC Foundations

A conventional SDLC may contain planning, requirements, design, development, testing, deployment, operation, and retirement. A secure SDLC adds security objectives and evidence to every phase. Security is a quality attribute, like reliability and performance, but it also has special characteristics: threats adapt, vulnerabilities can be exploited after release, and security failures may create legal and societal harm.

A useful principle is shift left, but do not stop left. Earlier activities reduce the cost of correcting design defects, while operational monitoring and incident response remain necessary because no pre-release process proves that software is secure under all conditions.

Security work should be risk-based. A practical risk model is:

Likelihood describes the probability or plausibility of exploitation; impact describes the resulting harm. This is a qualitative or semi-quantitative model rather than a precise physical law. Organizations may use ordinal scales, such as 1–5, but multiplying ordinal scores assumes that the scale supports meaningful arithmetic. Results should therefore guide discussion, not create false precision.

Security objectives should be traceable. A requirement should lead to a design decision, implementation control, test, and release evidence. This traceability supports audits, incident investigation, and informed risk acceptance.

Security principles

Important principles include least privilege, secure defaults, fail-safe behavior, defense in depth, complete mediation, separation of duties, minimizing attack surface, threat-informed design, secure error handling, and protection of secrets. These principles apply to people, processes, code, infrastructure, and third-party services.

2. Security Activities Across the Lifecycle

2.1 Planning and governance

Planning establishes ownership, scope, regulatory obligations, data classification, delivery constraints, and security assurance expectations. The team should identify a product security owner, define escalation routes, and decide which evidence is required before release.

Governance should answer questions such as:

• What information will the system process?
• Which privacy, financial, health, or critical-infrastructure obligations apply?
• Who may approve residual risk?
• What vulnerability severity requires blocking release?
• How will vulnerabilities be reported and remediated?
• How will the product be supported after deployment?

Security must be funded and scheduled. If it is treated as unplanned work, it is commonly deferred during delivery pressure.

2.2 Security requirements

Security requirements express verifiable protection goals. Examples include:

• An authenticated user must access only records authorized for that user’s tenant.
• Password-reset tokens must be single-use, time-limited, and invalidated after successful use.
• Administrative actions must produce tamper-resistant audit records.
• Sensitive data must be encrypted in transit using approved protocols.
• Production secrets must not be stored in source control or build artifacts.

Requirements should identify actors, assets, trust boundaries, abuse cases, acceptance criteria, and test methods. Privacy requirements should address collection limitation, retention, purpose limitation, access rights, and deletion where applicable.

2.3 Threat modeling

Threat modeling is a structured analysis of what can go wrong and how design choices reduce risk. A team identifies assets, actors, entry points, trust boundaries, data flows, and security assumptions. It then considers threats such as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

A data-flow diagram can expose overlooked paths: an API may accept input from an untrusted browser, call an internal service with excessive privileges, and write to a shared database. Controls might include authentication, authorization at the service boundary, input validation, rate limiting, query parameterization, and audit logging.

Threat modeling is not a one-time document. It should be revisited when data flows, dependencies, deployment environments, or business functions change.

2.4 Secure design and architecture

Design reviews examine trust boundaries, identity flows, authorization models, cryptographic use, error handling, resilience, logging, and dependency choices. Security architecture should avoid relying on a single control. For example, a sensitive operation may require strong authentication, server-side authorization, transaction validation, and monitoring.

Architects should distinguish authentication from authorization. Authentication establishes who or what an entity is; authorization determines what that entity may do in a particular context. Client-side checks improve usability but cannot replace server-side enforcement.

Security design should also address availability. Rate limits, bounded resource use, timeouts, circuit breakers, graceful degradation, and recovery procedures can reduce denial-of-service risk. Excessive logging, however, can expose personal data or create its own availability problem.

2.5 Secure implementation

Developers should use approved frameworks and secure coding standards. Common controls include parameterized database queries, contextual output encoding, robust session management, safe file handling, strict input validation, secure deserialization, appropriate cryptographic libraries, and consistent error handling.

Validation should be performed on the server and should define permitted types, lengths, formats, ranges, and encodings. It is not a substitute for output encoding or authorization. A string that is valid as an input may still be dangerous when inserted into HTML, a shell command, SQL, or a log.

Secrets include passwords, API keys, signing keys, tokens, and private certificates. They should be generated securely, stored in an approved secret-management system, scoped narrowly, rotated, monitored, and excluded from repositories and logs. If a secret is exposed, merely deleting the line from the latest commit is insufficient; the secret must be revoked or rotated and repository history assessed.

Peer review should consider both functional correctness and security properties. Reviewers should examine authorization at every sensitive operation, boundary validation, error paths, logging, dependency changes, and tests for abuse cases.

3. Verification Technologies

No single scanner detects all vulnerabilities. Tools differ in visibility, timing, coverage, and false-positive behavior.

3.1 Static Application Security Testing

SAST analyzes source code, bytecode, or compiled representations without executing the application. It can identify dangerous data flows, injection patterns, weak cryptography, insecure APIs, and missing validation. Results should be triaged by reachability, exploitability, data sensitivity, and business context.

SAST performs best when integrated with pull requests and when developers receive precise, actionable findings. A tool that generates large numbers of unreviewed warnings creates alert fatigue. Baselines may be used for legacy findings, but new issues should be visible and governed.

3.2 Dynamic Application Security Testing

DAST interacts with a running application, often using crawlers and attack payloads. It can identify problems such as missing security headers, authentication weaknesses, exposed endpoints, and some injection flaws. Test environments must contain realistic routes and roles, but test data must not expose real personal or production information.

DAST cannot see unreachable code or reliably determine the root cause. A finding should be reproduced, confirmed, assigned, fixed, and retested.

3.3 Interactive testing

IAST instruments an application while functional or security tests execute. It can connect an external request to internal code and data flows, reducing some ambiguity. Its results depend heavily on test coverage and supported languages and frameworks. IAST complements, rather than replaces, SAST and DAST.

3.4 Software Composition Analysis

Modern systems contain direct and transitive dependencies. SCA inventories packages, versions, licenses, and known vulnerabilities. Teams should establish policies for vulnerable dependencies, including severity, exploit availability, reachability, compensating controls, and upgrade feasibility.

A vulnerability identifier alone does not determine organizational risk. A vulnerable function may not be reachable, while a lower-scored issue in an exposed authentication component may deserve urgent action. Dependency pinning, lockfiles, trusted registries, update automation, and review of maintainer or package behavior reduce supply-chain risk.

3.5 Secret scanning and IaC scanning

Secret scanning should run before code is accepted and should inspect commits, branches, pull requests, repositories, build outputs, and relevant logs. Detection patterns should be supplemented with provider-side verification where safe. Confirmed credentials require immediate revocation or rotation.

Infrastructure-as-code scanning reviews definitions for issues such as public storage, overly broad identity permissions, unencrypted data stores, unrestricted network exposure, and missing logging. It should be combined with policy-as-code, secure modules, peer review, and runtime drift detection.

4. CI/CD Security Gates

A CI/CD pipeline is a sequence that builds, tests, packages, and promotes software. Security gates are decision points that prevent or conditionally permit progression. A mature pipeline may include:

1. Developer pre-commit checks and secret scanning.
2. Pull-request review and SAST.
3. Dependency, license, and IaC analysis.
4. Build in an isolated environment.
5. Unit, integration, and security tests.
6. Artifact signing and provenance generation.
7. DAST or IAST in a controlled environment.
8. Approval and promotion to production.
9. Post-deployment verification and monitoring.

Gates should be risk-based rather than blindly universal. A critical, exploitable vulnerability in an internet-facing authentication service should normally block release. A low-confidence informational result may create a ticket instead. Every exception should have a reason, owner, compensating control, expiry date, and approving authority.

Pipeline security is itself important. Build identities should have least privilege; pull requests from untrusted contributors should not gain access to production secrets; runners should be isolated; dependencies and actions should be pinned or verified; logs should be protected; and artifacts should be immutable. A compromised pipeline can distribute malicious software even when application code appears safe.

Quality metrics and evidence

Useful measures include time to remediate vulnerabilities, percentage of builds with complete SBOMs, scan coverage, exception age, dependency freshness, critical findings by environment, and rate of security defects escaping to production. Metrics should support improvement rather than encourage concealment or superficial compliance.

5. SBOMs, Provenance, and Secure Releases

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

An SBOM improves vulnerability response: when a new vulnerability is announced, an organization can search affected products and versions rather than manually inspect every repository. An SBOM is not a security certificate. It may be incomplete, outdated, or unable to prove how a component was built.

Provenance records describe where, when, and how an artifact was produced. Stronger assurance can be obtained by generating build attestations, signing artifacts, verifying signatures during deployment, and using trusted, reproducible or tightly controlled build processes. The exact assurance depends on key protection, identity binding, build isolation, and verification practice.

Secure release practices include:

• immutable, uniquely versioned artifacts;
• separation of build and deployment permissions;
• signed artifacts and verified provenance;
• protected branches and reviewed release changes;
• staged rollout, canary deployment, or feature flags;
• a tested rollback plan;
• migration safety and backup verification; and
• release notes that communicate security-impacting changes.

Rollback is not always safe: database migrations may be irreversible, and reverting code may reintroduce a vulnerability. Release engineering must therefore plan forward fixes, compatibility, and recovery.

6. Operations, Maintenance, and Incident Response

Security continues after deployment. Runtime logs, endpoint protection, web-application firewalls, configuration monitoring, vulnerability management, and incident detection provide operational feedback. Monitoring should be designed around meaningful events, such as repeated authorization failures, anomalous administrative activity, impossible travel, unusual data export, and unexpected service-to-service calls.

Patch management should prioritize exposure, exploitability, asset criticality, and available mitigations. Teams should maintain ownership of unsupported components and define end-of-life decisions. Vulnerability disclosure processes should provide a reporting channel, acknowledgement expectations, triage, remediation, and coordinated communication.

Incident response connects operational evidence to containment, eradication, recovery, and lessons learned. Post-incident analysis should examine technical and organizational causes, including unsafe defaults, unclear ownership, inadequate tests, and excessive pipeline privilege. Blaming an individual developer commonly obscures systemic weaknesses.

7. Illustrative Case: The Meridian Payments Platform

This is a fictional illustrative case.

Background

Meridian, a medium-sized retailer, is developing a cloud-based payment and loyalty platform. The service uses a web front end, mobile APIs, a payment provider, several open-source libraries, container images, and infrastructure-as-code. The initial team runs SAST only before major releases.

Problem

A security review discovers three weaknesses: an API authorizes access using a client-supplied account identifier, a build script prints an access token in logs, and a transitive library has a known high-severity vulnerability. Infrastructure definitions also permit public access to a development storage bucket. Releases are delayed because findings are discovered late and ownership is unclear.

Analysis

Threat modeling identifies the account API as a high-value authorization boundary. Secret exposure is treated as an incident because logs are retained and accessible to several teams. SCA determines that the vulnerable library is loaded by the production service and is reachable through a public endpoint. IaC review shows that the development account is connected to shared testing resources, so the public bucket has greater impact than its label suggests.

Approach and solution

Meridian introduces security acceptance criteria for authorization, secret handling, dependency management, and cloud exposure. The API derives the account context from the authenticated server-side identity and checks tenant ownership on every request. The exposed token is revoked and replaced through a secret manager; log access is reviewed and historical logs are handled according to incident and privacy procedures.

The pipeline adds pull-request SAST, SCA, secret scanning, IaC scanning, container scanning, and a staging DAST test. A critical or high-risk exploitable issue blocks promotion, while lower-risk findings require an owner and due date. SBOMs and signed provenance are generated for each release. Production deployment uses a short-lived identity with only the permissions required for that deployment. A canary release and rollback procedure are tested.

Outcome

Security findings become visible during development rather than at the release meeting. Dependency upgrades are tracked automatically, cloud policies are checked before deployment, and the security team focuses on threat modeling and high-risk exceptions instead of manually reviewing every change.

Learning points

The case demonstrates that tools are effective only when connected to ownership, evidence, remediation, and release decisions. It also shows that a vulnerability’s importance depends on context: reachability, exposure, data sensitivity, and compensating controls matter alongside severity scores.

8. Limitations, Ethics, and Governance

Automation cannot prove the absence of vulnerabilities. Scanners may miss business-logic errors, insecure design, race conditions, authorization flaws requiring complex workflows, and vulnerabilities in unobserved execution paths. False positives consume engineering capacity, while false negatives create unjustified confidence.

Security testing must be authorized and controlled. Penetration testing against production systems can affect availability or expose personal data. Test accounts, synthetic data, access controls, retention limits, and documented rules of engagement are essential. Researchers and defenders should respect applicable law, contractual boundaries, privacy requirements, and responsible disclosure norms.

AI-assisted coding and security analysis introduce additional considerations. Generated code may contain insecure dependencies, hallucinated APIs, licensing concerns, or subtle authorization errors. AI tools may also receive confidential source code or prompts. Organizations should define approved tools, data-handling rules, human review requirements, provenance expectations, and testing standards. AI can accelerate triage and code analysis, but accountability remains with the organization and responsible human decision-makers.

Regulatory and contractual obligations may require secure development evidence, vulnerability disclosure, breach reporting, privacy controls, or software-component inventories. Compliance is a baseline, not a substitute for threat-informed engineering. Governance should preserve an auditable record of decisions without turning security into paperwork disconnected from risk.

9. Best-Practice Operating Model

A practical DevSecOps operating model has the following characteristics:

• security is a shared responsibility with named owners;
• developers receive fast, contextual feedback;
• controls are automated where automation is reliable;
• human review is reserved for ambiguity, high impact, and design decisions;
• policies are version-controlled and tested;
• findings are prioritized by risk and exploitability;
• exceptions expire and are reviewed;
• artifacts, SBOMs, test results, and approvals are retained as evidence;
• production monitoring feeds improvements back into design and testing; and
• teams rehearse incident response and recovery.

The most mature organizations treat security as a continuous learning system. Incidents, near misses, new advisories, and changes in architecture update requirements, threat models, tests, and controls.

Chapter Summary

Secure software development integrates security into planning, requirements, design, coding, testing, release, operation, and retirement. Threat modeling and security requirements address risk before implementation, while secure coding, peer review, and automated analysis reduce defects during development. SAST examines code, DAST tests a running application, IAST combines instrumentation with execution, SCA inventories dependencies, secret scanning detects exposed credentials, and IaC scanning evaluates infrastructure definitions. These techniques are complementary and have different coverage and limitations.

DevSecOps embeds security into CI/CD through risk-based gates, protected pipelines, least-privilege identities, secure artifacts, signed provenance, SBOMs, and controlled exceptions. Security continues after release through monitoring, patching, vulnerability disclosure, incident response, and recovery. Ethical testing, privacy protection, human oversight of AI tools, and auditable governance are essential. The central lesson is that secure delivery is a socio-technical capability: tools help, but ownership, design judgment, process discipline, and continuous learning determine outcomes.

Key Terms

Secure SDLC: A software lifecycle that incorporates security activities and evidence in every phase.

DevSecOps: The integration of security with development and operations collaboration and automation.

Threat modeling: Structured analysis of assets, actors, trust boundaries, threats, and mitigations.

Security requirement: A verifiable statement of a security property or control.

SAST: Static Application Security Testing of source, bytecode, or binaries.

DAST: Dynamic Application Security Testing of a running application.

IAST: Interactive testing using instrumentation during application execution.

SCA: Software Composition Analysis of third-party and open-source components.

Secret scanning: Automated detection of credentials, keys, tokens, and similar sensitive values.

Infrastructure as code: Machine-readable definitions used to provision or configure infrastructure.

Security gate: A decision point that permits, blocks, or conditions software progression.

Exception: An authorized temporary departure from a security policy or gate.

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

Provenance: Evidence describing the origin and production process of an artifact.

Software supply chain: The people, processes, tools, components, and systems used to create and deliver software.

Least privilege: Granting only the access required for an authorized task.

Defense in depth: Using multiple independent or partially independent protective controls.

Residual risk: Risk remaining after controls and mitigations are applied.

Secure release: A controlled deployment supported by verified artifacts, approvals, testing, and recovery plans.

Review Questions

Short Answer Questions

1. What is meant by the principle “shift left, but do not stop left”?
2. Distinguish authentication from authorization.
3. What is the purpose of an SBOM?
4. Name two controls that protect a CI/CD pipeline itself.
5. Why should exposed credentials be revoked or rotated rather than merely deleted from source code?

Long Answer Questions

1. Explain how security requirements, threat modeling, secure design, and testing can be connected through traceability.
2. Compare SAST, DAST, IAST, and SCA, including their strengths and limitations.
3. Describe a risk-based security-gate strategy for an internet-facing application.
4. Explain how secure release practices reduce software supply-chain risk.
5. Discuss why DevSecOps is an organizational and cultural change rather than simply the installation of security tools.

Analytical / Application Questions

1. A pipeline reports a high-severity vulnerability in a transitive dependency. Explain the evidence you would collect before deciding whether to block release.
2. Design a secure CI/CD workflow for a containerized web application, identifying where secret scanning, SAST, SCA, IaC scanning, SBOM generation, signing, and DAST should occur.
3. A development team wants to use an AI coding assistant with proprietary source code. Analyze the security, privacy, licensing, and governance questions that should be resolved before approval.

Multiple Choice Questions with Answers

Question 1

Which activity best represents threat modeling?

A. Counting lines of source code

B. Identifying assets, trust boundaries, threats, and mitigations

C. Compressing release artifacts

D. Rotating a database index

Correct Answer: B. Identifying assets, trust boundaries, threats, and mitigations

Question 2

Which technique primarily analyzes source code or bytecode without executing the application?

A. DAST

B. IAST

C. SAST

D. Canary deployment

Correct Answer: C. SAST

Question 3

What is the principal purpose of an SBOM?

A. To replace penetration testing

B. To inventory software components and their relationships

C. To encrypt application databases

D. To authenticate end users

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

Question 4

Which action is most appropriate after a confirmed API key is committed to a repository?

A. Delete only the latest source line

B. Rename the repository

C. Revoke or rotate the key and investigate exposure

D. Disable all code review

Correct Answer: C. Revoke or rotate the key and investigate exposure

Question 5

Which testing approach interacts with a running application from an external perspective?

A. SCA

B. DAST

C. Secret scanning

D. IaC scanning

Correct Answer: B. DAST

Question 6

Which is an example of a risk-based release gate?

A. Blocking every informational message permanently

B. Ignoring all scanner findings until an incident occurs

C. Blocking a release for a critical exploitable issue while documenting lower-risk exceptions

D. Allowing deployment without any test evidence

Correct Answer: C. Blocking a release for a critical exploitable issue while documenting lower-risk exceptions

Question 7

What does least privilege require?

A. Every service receives administrator access

B. Access is granted only to the extent required for an authorized task

C. Users share one account for easier auditing

D. Permissions are never changed after creation

Correct Answer: B. Access is granted only to the extent required for an authorized task

Question 8

Which statement about security scanners is most accurate?

A. One scanner can prove that software has no vulnerabilities

B. Scanners eliminate the need for design review

C. Different scanners provide complementary visibility and have limitations

D. False positives never occur in mature tools

Correct Answer: C. Different scanners provide complementary visibility and have limitations

Question 9

Why is artifact provenance useful?

A. It describes where and how an artifact was produced

B. It increases database storage capacity

C. It replaces authorization checks

D. It guarantees that every dependency is vulnerability-free

Correct Answer: A. It describes where and how an artifact was produced

Question 10

Which practice most directly protects a build pipeline from excessive compromise impact?

A. Giving every build job production administrator rights

B. Using least-privilege, isolated build identities and runners

C. Printing secrets in build logs for troubleshooting

D. Disabling artifact verification

Correct Answer: B. Using least-privilege, isolated build identities and runners