Secure Software Development Lifecycle

The code is a set of promises

Every piece of software is a set of promises about how the organization’s rules will be enforced. An application that checks authorization before showing a record is a control, and it is no different in kind from the firewall rule in front of it or the badge reader on the data center door. All three exist so that a stated policy holds in practice. This is the thought that makes software development a security subject at all: when an application is built without security being part of how it is built, the organization has delegated its policy enforcement to whoever happened to write the code, and the result is a control surface that nobody reviewed, tested, or accepted.

The exam’s Domain 8, Software Development Security, is the domain where that thought becomes a discipline. It asks about the lifecycle in which software is conceived and built, the practices that make the building secure, the pipeline that carries the software into production, and the way a manager governs all of it. This chapter covers the lifecycle itself: the models organizations use, the security activities that belong in each phase, the DevSecOps operating model, the security of the delivery pipeline, and the change and supply chain governance that wraps around the whole thing. The companion chapter that follows covers the testing and coding craft: the OWASP taxonomy of vulnerabilities, injection and cross-site attacks, and the tools that find them. This chapter is the frame; the next chapter is the craft inside the frame.

Two facts anchor why this matters. First, most successful attacks end in software: the attacker does not need to defeat a perimeter if an application defect hands them the session, the file, or the command. Second, defects are cheapest to fix when they are caught early in the lifecycle, and the cost rises steeply as software moves from design to production. Research dating back to Barry Boehm’s work on software economics showed the gap growing by roughly an order of magnitude per lifecycle stage: a requirements error caught during requirements costs little, the same error found in production costs multiples more, and that ratio has only widened as operations have become more automated and attacks more industrial. A manager who understands nothing else about this domain understands that security review at the end of a project is the most expensive possible placement of the cheapest kind of fix.

What the lifecycle is, and why it is a control

The software development lifecycle, SDLC, is the structured process by which software moves from idea to retirement: requirements, design, implementation, testing, deployment, operation, and eventually decommissioning. The word lifecycle matters twice. It means the phases have an order and an owner, and it means the software does not end when it ships, because the operating years are where vulnerabilities get found, patched, and exploited.

Why is a process a security control? Because a control is a safeguard that makes an outcome more likely, and a lifecycle makes secure outcomes more likely through gates, records, and accountability. A phase gate is a point where work is reviewed and approved before it moves forward, which creates the moment where security can say no, or can say fix it here. A record, such as a requirements document, a design decision, or a test result, creates the audit trail that tells an assessor whether security was considered. Accountability assigns each decision a person, which is what makes the others enforceable. NIST SP 800-53 Revision 5 (Security and Privacy Controls for Information Systems and Organizations, September 2020) formalizes this in control SA-3, System Development Life Cycle, which requires the organization to manage the system using a development life cycle that incorporates security and privacy considerations. The control’s existence is the point: a mature organization treats the lifecycle as a managed process, not a style preference.

Two ideas carry the rest of the chapter. The first is phase placement: every security activity has a natural home in the lifecycle, and putting it in the wrong home wastes the activity. The second is traceability: a security requirement that cannot be connected to a design element and a test case is a hope, not a requirement. Security requirements traceability, the thread from requirement to design to test to acceptance, is what turns an SDLC from paperwork into evidence, and it is exactly what an auditor, a regulator, or a plaintiff’s expert will look for later. PCI DSS v4.0 Requirement 6 exists for the same reason the ISO/IEC 27001:2022 Annex A controls 8.25 through 8.34 exist: the bodies that write these requirements concluded that secure software is produced by a documented, enforced process, not by individual heroics.

The models, and where security lives in each

There is no best development model, and the exam does not pretend there is one. It tests whether you know each model’s shape, its failure mode, and where security activity naturally belongs in it, because the manager’s job is to place security work correctly given the model the organization actually uses.

Waterfall is the classic sequential model: requirements, design, implementation, testing, deployment, each phase completed and approved before the next begins. Its strengths are discipline, documentation, and predictability; its weakness is that change is expensive and late discovery is painful, because nothing downstream happens until the phase before it closes. Security’s home in waterfall is the phase gate: a security review at the end of design, a security test plan at the end of implementation, and a security acceptance gate before deployment. The model’s failure mode is the temptation to treat security as the last gate, which converts every discovered flaw into a schedule crisis. Waterfall tolerates well-specified, stable requirements and projects where failure is catastrophic, which is why heavily regulated engineering domains still use it.

The V-model is waterfall with a verification spine. The left leg descends from requirements through high-level design to detailed design; the right leg ascends through unit testing, integration testing, system testing, and acceptance testing, with each test level tied by a line back to the requirement level it verifies. Unit tests verify the detailed design, integration tests verify the high-level design, system tests verify the requirements, and acceptance tests verify the business need. Security’s home is the same geometry: security requirements on the left get a matching security test on the right, and the traceability lines are the whole point. The V-model is popular where the regulator demands evidence of verification, such as aerospace, defense, and medical software, because the mapping from requirement to test is explicit and auditable.

The spiral model, proposed by Barry Boehm in 1988, is the iterative model that built risk analysis into the loop. Each cycle passes through four quadrants: determine objectives, identify and resolve risks, develop and verify the product, and plan the next iteration. Security’s home is the second quadrant, because threat modeling, vulnerability analysis, and risk resolution happen on a schedule, every cycle, instead of once at the end. For high-risk projects the spiral is the model that forces the conversation the other models postpone. Its cousin is iterative development generally, including rapid application development, RAD, which builds prototypes and refines them quickly with user feedback. The iterative family’s failure mode is the prototype that becomes production: a demo built for speed, with no authentication, no logging, and no review, that nobody ever rebuilds.

The agile family, which the Agile Manifesto of 2001 named, works in short time-boxed iterations with working software delivered continuously, requirements held as a prioritized backlog, and the team self-organizing around the work. Scrum organizes iterations into sprints with ceremonies and roles; Kanban visualizes and limits work in progress without fixed iterations. Security’s home in agile is inside the iteration: security acceptance criteria attached to user stories, security tasks estimated and scheduled like any other work, and a Definition of Done that includes the security checks. The failure mode is the one every agile team has met: security treated as a backlog item that never quite reaches the top, or worse, as a phase that happens after the sprints end, which recreates waterfall’s last-gate problem without waterfall’s discipline. The correction is to make security a property of every increment, not a feature of the release.

DevOps, the operating model that emerged from the 2000s, fuses development and operations: small changes, continuous integration, automated testing, continuous delivery, and fast feedback from production. Its security answer is DevSecOps, the subject of a later section, and its failure mode is automation without review: a pipeline that deploys instantly will also deploy mistakes instantly. The general lesson for every model is the same. The model decides when the organization looks at the software; security decides what it is able to see when it looks. An organization that reviews security only in the phase the model happens to favor is fine if that phase is early and repeated, and doomed if it is last.

Security activities, phase by phase

The lifecycle’s phases are where the abstract commitment becomes a schedule. This section walks each phase and names the security work that belongs to it, with the standards that anchor the work. This is the core content the exam draws from: not that a given tool exists, but that a given activity belongs to a given phase and is required by a given control.

Requirements. Before anything is built, the organization must know what security the software must provide. This means defining security requirements, which NIST SP 800-218 (Secure Software Development Framework, SSDF, Version 1.1, February 2022) names as its first practice under the Prepare the Organization group, PO.1, Define security requirements for software development. Security requirements are not vague intentions; they are testable statements derived from the organization’s risk appetite, the data the software touches, and the obligations that bind the organization, such as GDPR for personal data or PCI DSS for cardholder data. Two tools make requirements concrete. Threat modeling, covered in Chapter 4 with STRIDE and other taxonomies, asks what could go wrong and records the answers as requirements. Misuse cases, sometimes called abuse cases, invert the normal use case: they describe what a hostile actor will try to do, and each misuse case produces a defensive requirement. The requirements phase is also where the security level is chosen. OWASP’s Application Security Verification Standard, ASVS, offers a tiered checklist of verification requirements, and adopting a level, for example the standard’s Level 1 for low-assurance applications up to Level 3 for the most critical, converts “be secure” into a concrete, auditable scope. Traceability starts here: each requirement gets an identifier that design and tests will reference.

Design. The design phase turns requirements into architecture, and the security work here is threat modeling at the architecture level, design review, and the application of engineering principles. NIST SP 800-53 SA-8, Security and Privacy Engineering Principles, points at NIST SP 800-160 Volume 1 (Engineering Trustworthy Secure Systems, Revision 1, November 2022) for the principles themselves, and ISO/IEC 27001:2022 Annex A 8.27, Secure system architecture and engineering principles, requires that engineering principles be applied when systems are designed. The SSDF carries the same idea in Produce Well-Secured Software: PW.1, Design software to meet security requirements and mitigate security risks, and PW.2, Review software design to verify compliance with security requirements and risk information. Concretely, design review means reading data flow diagrams for trust boundaries, checking where authentication and authorization are enforced, confirming that secrets are not in configuration, choosing vetted cryptographic libraries rather than inventing cryptography, minimizing the attack surface by removing unneeded features and interfaces, and applying the design principles from Chapter 12, least privilege, defense in depth, and fail-secure defaults. The design review is cheaper than every later fix, which is why the SSDF and ISO both put review work here rather than at acceptance.

Implementation. The build phase is where code is written and, with it, where most vulnerabilities are introduced. The controls of this phase are coding standards, review, static analysis, dependency hygiene, and training. ISO/IEC 27001:2022 Annex A 8.28, Secure coding, requires that secure coding principles be applied to software development, and the industry has standards to apply: the SEI CERT secure coding standards for C, C++, and Java prescribe specific rules for the languages most prone to memory and type confusion errors. Static application security testing, SAST, runs during the build and finds flaw patterns without executing the code; it is the tool that scales review to every commit. Peer review with a security focus remains necessary because tools miss design-level errors. NIST SP 800-218’s PW.4, Review and/or analyze human-readable code to identify vulnerabilities and verify compliance with security requirements, names the activity. Two hygiene practices belong here as well. Secrets must never enter the repository: credentials, API keys, and certificates found in code are a supply chain event waiting to happen, and the remedy is a secrets manager plus scanning that blocks secrets from being committed. And dependencies are code you did not write, which means they carry the same risk with less oversight, so the team must verify third-party components, SSDF PS.3, and keep a current inventory of them, a subject the pipeline section returns to.

Testing. The test phase verifies that the software does what it is supposed to do and does not do what it must not. ISO/IEC 27001:2022 Annex A 8.29, Security testing in development and acceptance, requires security testing during development and acceptance, and PCI DSS v4.0 Requirement 6 requires that custom software be reviewed prior to release or deployment. The test menu includes unit and integration tests with security cases, dynamic application security testing, DAST, which probes the running application, fuzzing, which feeds malformed inputs to find robustness failures, vulnerability scanning of dependencies, and penetration testing of the assembled system, all of which the next chapter treats in detail. The phase’s governance question is coverage: does the security test plan trace back to the security requirements from the first phase, and does acceptance sign off on that trace? The V-model’s geometry is this trace made visible.

Deployment and release. The transition to production is where process discipline matters most, because the software stops being a test artifact and starts being a control the organization runs on. The controls here are the separation of environments, ISO/IEC 27001:2022 Annex A 8.31, Separation of development, test and production environments, which keeps production change from being an ordinary developer act; configuration management, which makes the deployed environment match the tested one; artifact integrity, which ensures that what was tested is what is deployed; and change management, which owns the release decision and is covered in its own section below. NIST SP 800-53 Rev. 5 carries the same obligations across CM-3, Configuration Change Control, CM-4, Impact Analyses, CM-5, Access Restrictions for Change, and CM-6, Configuration Settings. Deployment is also the handoff to operations: the runbook, the monitoring hooks, and the rollback plan must exist before the deploy, not after the incident.

Operations. After deployment, the lifecycle continues with the work of keeping the running software secure: watching for newly disclosed vulnerabilities, applying patches, and responding to findings. ISO/IEC 27001:2022 Annex A 8.8, Management of technical vulnerabilities, and the SSDF’s Respond to Vulnerabilities group, RV.1, Identify and confirm vulnerabilities on an ongoing basis, RV.2, Assess, prioritize, and remediate vulnerabilities, and RV.3, Analyze vulnerabilities and identify their root causes, define the loop: watch, confirm, rank, fix, and learn. The last step is the one that closes the lifecycle: the root cause from a production incident or a red-team finding becomes a requirement for the next iteration, so the lifecycle is genuinely a cycle. Runtime protection, monitoring, and feature flags that can disable a risky feature are operations controls, and they belong in the design conversation, not discovered afterward.

Retirement. Software eventually ends, and an ended application is a security problem if it is handled casually. Decommissioning means removing the application from the environment, deleting or preserving its data according to the retention rules of Chapter 10, revoking its accounts, integrations, and certificates, and removing it from the asset inventory. NIST SP 800-53 SA-22, Unsupported System Components, requires that unsupported components be replaced, or mitigated and documented if they must remain, because software that no longer receives patches is a standing invitation. The retirement phase is routinely skipped in practice, which is why old exposed services keep appearing in breach reports years after the project that built them was archived.

DevSecOps: security becomes part of the flow

DevSecOps is the answer the DevOps movement gave to the question its own success raised. When teams deploy continuously, a security review that happens once, at the end, either blocks the flow or is skipped, and neither outcome is acceptable. DevSecOps is the operating model in which security is not a phase but a property of the flow: security activities are automated, security decisions are made by the team that owns the software, and security feedback travels as fast as everything else. It is a change in who is accountable and how work moves, not a purchase of tools, and the exam expects the manager to recognize it as an operating model and a culture rather than a product category.

The signature move is shift-left: move security activities earlier in the lifecycle, into requirements, design, and the pipeline, where they are cheapest. Shift-left does not mean abandoning the right side: monitoring, response, and detection remain, because software fails in production no matter how well it was built. The more precise formulation is that security now happens everywhere, with the emphasis moving left.

The concrete practices of DevSecOps follow from the model. Security as code means security controls are written as version-controlled, reviewed artifacts like any other code: pipeline steps that run scans, policy definitions that gate promotion, configuration baselines, and test cases that assert security properties. Because they live in the repository, they get review, history, and testing like everything else. Automation means the checks run on every change without asking anyone’s permission, which is the only way a check runs on every change. Shared accountability means the product team owns the security of its product, with security specialists as consultants, reviewers, and standards-setters rather than gatekeepers; a team that needs the security team’s sign-off on every commit has not adopted DevSecOps, it has recreated the gate. Culture work completes the model: security champions inside teams, blameless postmortems so findings surface instead of being hidden, and feedback loops that carry production lessons back into the backlog.

Metrics are how the model is verified, and this is a manager topic the exam likes. The DevOps measurement tradition, shaped by the DORA State of DevOps research, uses four metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. To those, a DevSecOps practice adds security-flavored metrics: time to remediate a vulnerability, vulnerability density in shipped code, the age of the oldest unpatched critical issue, and the share of changes that passed automated security checks. The discipline of the metrics is the same as the discipline of the model: the number only matters if the team sees it, owns it, and acts on it, and the measure of success is that security quality moves like the other quality signals, steadily, with the team in control.

The pipeline as a system to protect

The delivery pipeline is the machine DevSecOps runs on, and the exam expects you to see it as a system with its own attack surface. A typical pipeline moves a change through stages: source control, build, test, package, publish to an artifact repository, and deploy to environments. Every stage is a potential point of compromise, and because the pipeline is trusted, a compromise there is worse than a compromise of any single product: an attacker who controls the build controls every artifact it produces.

The source stage holds the code, so it holds the secrets, the intent, and the review. Threats here include malicious or accidental commits, secrets committed to the repository, and a history that no one audits. The defenses are branch protection, required reviews, signed commits, secrets scanning, and access control over who may merge and who may force-push. The source stage is also where dependency risk enters: third-party packages are fetched by name, and the ecosystem is vulnerable to typosquatting, packages published under names that look like popular ones, and dependency confusion, where a package with the same name as an internal package is published to a public registry and resolves instead of the intended private one. The defenses are pinning and lock files, which fix exact versions and their hashes, serving dependencies from a vetted private registry, and continuously verifying third-party components, SSDF PS.3, with software composition analysis tooling that maps components to known vulnerabilities.

The build stage turns source into artifacts, and here the trust question becomes technical. A build is only as trustworthy as the agent that runs it, so build agents should be isolated, disposable, and unable to touch anything beyond the build. Hermetic or reproducible builds, which depend only on pinned inputs and produce the same output for the same source, make tampering detectable. The artifact itself must be signed, so consumers can verify who produced it and that it has not been altered, and stored in a repository that is treated as a production system, with access control and audit. The SSDF formalizes the intent across its groups: PO.2, Implement and maintain secure environments for software development, and PO.3, Protect all forms of code from unauthorized access and tampering, from the Prepare the Organization group, together with PS.1, Use all provisions of software from trusted, vetted sources, from the Protect the Software group, cover the environment, the code, and the sourcing respectively. This is the family of concerns that Executive Order 14028, Improving the Nation’s Cybersecurity, May 12, 2021, pushed into federal contracting, directing NIST to publish a secure software development framework, which became SP 800-218, and requiring agencies to obtain software bills of materials, SBOMs, for the software they acquire.

The SBOM deserves a precise definition because it is now a fixed part of the vocabulary. A software bill of materials is a machine-readable inventory of the components, including third-party and open-source components and their versions, that make up a piece of software. Its uses are inventory, vulnerability matching, license compliance, and supply chain analysis, and its formats include SPDX, which is standardized as ISO/IEC 5962:2021, and CycloneDX, published under the OWASP foundation. An SBOM does not fix vulnerabilities; it makes the vulnerability conversation possible at all, because a consumer cannot know whether CVE X affects its software without knowing that component Y, at version Z, is inside it.

The provenance movement adds the other half of the answer: not just what is inside the software, but how it was built. SLSA, Supply-chain Levels for Software Artifacts, developed in the OpenSSF community with a first major release in 2023, defines levels that add integrity and provenance controls: stronger source control and build requirements at the lower levels, and at the higher levels verifiable claims, called provenance, about exactly how an artifact was produced, including that the build was hermetic. The manager’s summary is simple: the industry’s answer to the supply chain problem has three parts, know what is inside the software, SBOM, verify who built it and that it was not altered, provenance and signing, and control the environment it was built in, isolated and reproducible builds.

The deployment stage moves the artifact into live environments, and its threats are the ones already met in the operations chapters: over-privileged credentials, secrets in configuration, and humans with too much power. The defenses are least privilege, short-lived credentials issued from a secrets manager, deployment credentials that cannot be reused outside the pipeline, and promotion through environments with gates, so nothing reaches production without passing the checks and approvals the organization chose. The pipeline itself needs change management like any production system: pipeline configuration is code, and it should be reviewed like code, because a change to the pipeline is a change to the trust the whole organization places in its software.

Change management: the discipline that makes releases safe

Change management is the governance of the moment software moves from intended to actual. Its purpose is to make changes predictable, reversible, and accountable, and it is the control that prevents the classic failure, a production change made quietly by someone who meant well and could not have known better. The exam treats change management as a discipline with a vocabulary, not a bureaucracy.

The change process starts with a request for change, RFC, which describes what will change, why, what the impact is, and how the change will be reversed. The change is assessed for risk and impact, which NIST SP 800-53 CM-4, Impact Analyses, requires before a change is implemented. It is tested in an environment other than production, which is where ISO/IEC 27001:2022 Annex A 8.31’s separation of environments does its work. It is approved, which NIST SP 800-53 CM-3, Configuration Change Control, and ISO 8.32, Change management, require. It includes a backout plan, so that failure is a known path rather than an improvisation. And the whole thing is recorded, because the record is the audit trail that proves the organization knows what it runs.

The approval bodies and change types form the exam’s vocabulary. A change advisory board, CAB, is the group that reviews significant changes, though its size and form vary; ITIL-style practice distinguishes normal changes, which follow the standard review path, standard changes, which are pre-approved because they are low risk and repeatable, and emergency changes, which are needed too quickly for the normal path. The emergency change is the test of the system: it bypasses or compresses the normal approval, but it is documented, it is reviewed afterward, and it still carries a backout plan, because urgency is not a license to skip reversibility. NIST SP 800-53 CM-5, Access Restrictions for Change, adds the people dimension: only authorized users may implement changes, and a change implemented outside the process is a finding regardless of outcome.

The separation of environments, ISO 8.31, is the enforcement mechanism underneath all of it. If a developer can write directly to production, change management is a fiction, because the control is not whether changes happen but whether they are knowable. The exam-relevant phrasing is separation of duties: the person who builds a change should not be the only person who approves and applies it. Test information gets the same respect, through ISO 8.33, Test information: test data must be selected, protected, and controlled, and production data, especially personal data, must not be used in test environments without masking, because a test environment with real data is a breach waiting to be discovered by a red team or an attacker. And audit testing itself is governed, ISO 8.34, Protection of information systems during audit testing: scans and tests against production must be agreed, scoped, and carried out without disrupting the systems they test, which is the operational cousin of the rules of engagement in Chapter 22.

Outsourced development and the software supply chain

Most organizations no longer write all their software, and the exam’s governance questions follow the work. ISO/IEC 27001:2022 Annex A 8.30, Outsourced development, requires that outsourced development be directed, supervised, and monitored by the organization, because outsourcing transfers the work, not the accountability. The practical expression is contractual: the agreement must carry security requirements, delivery standards, acceptance criteria, and the right to verify, and the organization must actually exercise that right with acceptance testing and review. Two further controls matter. Source code escrow, where a third party holds the vendor’s code and releases it to the customer under defined conditions such as the vendor’s failure or insolvency, protects the customer’s continuity of operation, and NIST SP 800-53 SA-21, Developer Screening, requires that the organization verify that individuals who develop its systems are screened appropriately, which is the personnel half of trusting the vendor. SA-10, Developer Configuration Management, and SA-11, Developer Testing and Evaluation, carry the process half: the vendor’s configuration management must be adequate, and the vendor’s testing must be evidence the organization can examine. The manager’s question at every outsourcing decision is the same: who is accountable when the delivered software fails, and what proof do we hold that failure was prevented?

Practice questions

1. A project manager reports that a security requirement omitted from the requirements phase was discovered during user acceptance testing, and the fix will delay the release by two weeks. The manager asks where the requirement should have been caught. Which answer reflects the underlying principle of the secure software development lifecycle?

   A. The requirements phase, because defects found later in the lifecycle are far more expensive to correct than defects found where they were introduced B. The deployment phase, because security requirements are confirmed against the production environment C. The testing phase, because tests are the only reliable way to discover missing requirements D. The retirement phase, because requirements can be renegotiated once the software is in operation

2. An aerospace software team must demonstrate to a regulator that each safety requirement was verified by a corresponding test. Which development model is best suited to that demonstration?

   A. Waterfall, because it produces the most documentation of any model B. Kanban, because limiting work in progress shortens the verification cycle C. The V-model, because it links each design level to a matching test level with explicit traceability D. Rapid application development, because prototyping produces testable artifacts early

3. A risk manager reviewing a proposal for a high-risk system notices that the chosen model schedules risk analysis once, during the initial design review. Which model would have forced risk analysis to occur repeatedly throughout development?

   A. The waterfall model, which requires a review gate before each phase B. The spiral model, which includes a risk identification and resolution quadrant in every cycle C. The V-model, which mirrors each design level with a test level D. Kanban, which limits work in progress to reduce risk

4. An agile team’s Definition of Done currently lists features, tests, and documentation but nothing about security. A security manager wants security built into every increment. Which change best achieves that?

   A. Add security acceptance criteria to user stories and include security checks in the Definition of Done B. Schedule one security hardening sprint before every major release C. Require a security architect to approve the release plan each quarter D. Move security testing to the production support team after deployment

5. During design review, an architect proposes that the application use a custom encryption routine because the standard libraries are “too slow”. Per the design principles the exam expects, what is the correct response?

   A. Approve the custom routine if it passes unit tests B. Approve the routine for non-critical data only C. Defer the decision to the development phase, when performance can be measured D. Reject the custom routine and require the use of vetted, well-tested cryptographic libraries

6. An organization’s pipeline scans every commit with a static analysis tool that inspects source code for vulnerability patterns. Which SSDF practice from NIST SP 800-218 does this implement?

   A. PO.1, Define security requirements for software development B. PW.4, Review and/or analyze human-readable code to identify vulnerabilities C. RV.3, Analyze vulnerabilities and identify their root causes D. PS.2, Reuse and refresh existing well-secured software when feasible

7. A security manager learns that a developer has been committing database credentials directly to the source repository. Which control addresses the root cause rather than only the symptom?

   A. Rotate the credentials and remind the developer to be careful B. Restrict the developer’s repository access C. Move secrets to a secrets manager and add scanning that blocks secrets from entering the repository D. Encrypt the repository so stored credentials are unreadable

8. An application team wants to comply with ISO/IEC 27001:2022 Annex A 8.31. Which statement of the control’s requirement is correct?

   A. Development, test, and production environments must be separated to reduce the risk of unauthorized access or changes to production B. All environments must run identical software so that tests are always representative C. Production must be reachable from the development environment to speed troubleshooting D. Development environments must be decommissioned once production is stable

9. A change advisory board is reviewing a request to update a database configuration in production. Under the change management practices of NIST SP 800-53, which element is required before the change is approved?

   A. Written approval from the database vendor B. Proof that no similar change has been made in the past C. A certificate of source code authorship from the change’s author D. An impact analysis under CM-4 and a defined backout plan

10. A system being decommissioned still contains data governed by retention rules and has no receiving team. What is the correct handling?

A. Leave the system running until someone asks for the data B. Apply the organization’s retention and deletion rules to the data, then remove the system from the asset inventory C. Copy the data to the development environment for safekeeping D. Erase the disks immediately without consulting the retention rules

11. An organization relies on an internal package registry. An attacker publishes a public package with the same name as an internal library that the build fetches by name. What is the name of this attack, and which defense directly prevents it?

A. Typosquatting; require developers to type library names carefully B. A poisoning attack; disable the internal registry entirely C. Dependency confusion; resolve dependencies from a vetted private registry with pinned versions and integrity hashes D. A backdoor supply chain attack; sign every commit with the same key

12. A compliance officer asks what a software bill of materials is for. Which answer is most accurate?

A. It is a machine-readable inventory of the components and versions inside a software product, used for vulnerability matching and inventory B. It is a contract requiring a vendor to fix known vulnerabilities within 30 days C. It is a list of the licenses the organization must sell to use the software D. It is an audit report produced after a penetration test

13. A team’s builds currently run on a shared server that also hosts the development chat tool, using long-lived credentials stored in environment files. Which change best aligns the build stage with SSDF practice?

A. Add more tests to the build so that compromised builds are detected sooner B. Grant the build server access to production so it can verify deployments C. Schedule builds only during low-traffic hours D. Isolate the build environment, use short-lived credentials, and make builds reproducible from pinned inputs

14. Under PCI DSS v4.0 Requirement 6, which practice is required of an organization that develops bespoke and custom software?

A. Use of a specific commercial framework for all development B. Annual replacement of all software not written in-house C. A documented software development lifecycle with security included, and review of custom code before release D. Certification that no open-source components are used

15. A production incident traced to a defect is being investigated. The team finds the defect was introduced in an early iteration and no test covered the condition. Per the SSDF’s Respond to Vulnerabilities group, which practice did the organization fail to perform adequately?

A. PO.1, Define security requirements for software development B. RV.3, Analyze vulnerabilities and identify their root causes C. PS.1, Use all provisions of software from trusted, vetted sources D. PW.8, Check software for vulnerabilities and verify compliance with security requirements prior to release

16. A security manager is asked whether shift-left means the security team can stop monitoring production. What is the correct position?

A. Shift-left only applies to waterfall projects B. Shift-left replaces all runtime security with build-time checks C. Shift-left transfers monitoring responsibility to the vendor D. Shift-left moves security activities earlier, but monitoring, detection, and response remain essential

17. An organization wants to use production personal data in its test environment to reproduce a bug. What does ISO/IEC 27001:2022 Annex A 8.33 require?

A. Test environments are exempt from data protection obligations B. Production data may be used only if the bug is critical C. Test information must be selected, protected, and controlled, and production data used for testing must be protected, for example by masking D. Test data must be deleted within 24 hours regardless of masking

18. A security architect wants to verify that a security requirement stated in the requirements phase was actually tested. What supports that verification?

A. A traceability thread linking the requirement to its design element and its test cases B. A signed statement from the development lead C. The number of commits in the release branch D. A comparison of the requirement to a template library

19. A vendor delivers outsourced software and the customer wants continuity if the vendor fails. Which arrangement directly addresses that concern?

A. A longer service-level agreement B. Source code escrow, releasing the code to the customer under defined conditions such as vendor failure C. Acceptance testing repeated every quarter D. A requirement that the vendor hire screened developers

20. A change that must go into production within the hour is approved by a single senior manager, bypassing the normal change advisory board path. Which statement describes the correct treatment of this emergency change?

A. It is invalid because emergency changes are never permitted B. It requires no record because urgency justifies the action C. It must be approved by the full board within 24 hours before being implemented D. It must be documented, tested where possible, and reviewed after implementation, with a backout plan

Answers and rationales

1. A. The cost-of-change curve is the foundation of the secure SDLC: a requirement defect found where it was introduced is cheapest, and the cost of correction grows steeply in later phases. Missing requirements are the classic example, because no test can verify a requirement that was never written, and the defect surfaces only when the software is exercised against real expectations. The other options place the discovery and correction in phases that are either too late or outside the lifecycle.

2. C. The V-model’s defining feature is its verification spine: each design level on the left leg is tied to a test level on the right, so a requirement maps to a system test and a detailed design maps to a unit test. That geometry is exactly the traceable evidence a regulator wants. Waterfall documents well but without the explicit level-to-level mapping (option A), Kanban (option B) and RAD (option D) are not verification models.

3. B. The spiral model schedules risk identification and resolution as a quadrant of every cycle, so risk analysis repeats throughout development rather than happening once. A single design review (the scenario described) is a waterfall-style gate (option A), and the V-model (option C) and Kanban (option D) do not embed recurring risk analysis as the spiral does.

4. A. In agile, security must be a property of every increment: security criteria in acceptance and a Definition of Done that includes the security checks. A hardening sprint before release (option B) recreates the end-of-project gate, quarterly architecture approval (option C) leaves every other iteration uncovered, and moving testing to support (option D) abandons the shift-left principle.

5. D. Custom cryptography is a standing design rejection: the risk of a subtle flaw that defeats the entire scheme is high, and vetted libraries have received public scrutiny. Passing unit tests (option A), limiting to non-critical data (option B), or deferring to the build phase (option C) all accept a risk with no compensating evidence.

6. B. Static analysis of source code during the build implements PW.4, reviewing or analyzing human-readable code to identify vulnerabilities. PO.1 concerns requirements (option A), RV.3 concerns post-release root cause (option C), and PS.2 concerns reusing well-secured software (option D).

7. C. The root cause is that secrets and code share a channel and nothing prevents it; a secrets manager removes the need to store secrets in code, and scanning prevents recurrence. Rotating credentials (option A) fixes this exposure only; restricting access (option B) treats the symptom; encrypting the repository (option D) leaves the secrets usable and inside the code.

8. A. Annex A 8.31 requires separation of development, test, and production environments to reduce the risk of unauthorized access or changes to production. Identical environments (option B) and direct connectivity (option C) are the opposite of separation, and decommissioning development (option D) misunderstands the control.

9. D. NIST SP 800-53 CM-4 requires impact analyses before change, and sound change control includes a backout path; CM-3 frames the approval itself. Vendor approval (option A) and precedent (option B) are not the control’s requirements, and source code authorship (option C) is irrelevant to a configuration change.

10. B. Retirement follows the same discipline as every other phase: apply the retention and deletion rules to the data, then remove the system from the inventory and revoke its integrations. Leaving it running (option A) or copying data to development (option C) preserves the exposure; erasing without consulting retention (option D) violates the rules the organization is bound by.

11. C. The attack is dependency confusion, in which a public package outranks or outresolves the intended internal one, and the direct defense is to resolve dependencies from a vetted private registry with pinned versions and integrity hashes. Typosquatting (option A) is a related but distinct attack with a different defense, disabling the registry (option B) breaks the build, and commit signing (option D) does not govern which package resolves.

12. A. An SBOM is a machine-readable inventory of components and versions, used for vulnerability matching, inventory, and license compliance. It is not a contract (option B), a license list (option C), or a test report (option D).

13. D. SSDF practice is served by protecting the build environment and code: isolation, least-privilege and short-lived credentials, and reproducible builds from pinned inputs. More tests (option A) detect defects but do not protect the build; granting production access (option B) and scheduling tricks (option C) increase or ignore the exposure.

14. C. PCI DSS v4.0 Requirement 6 requires a documented, security-inclusive development lifecycle for bespoke and custom software and review of custom code before release, along with vulnerability management and change controls. The other options are not requirements of Requirement 6.

15. B. RV.3 requires analyzing vulnerabilities and identifying their root causes, which is exactly the step that feeds lessons back into the lifecycle. PO.1 (option A) concerns requirements, PS.1 (option C) concerns sourcing, and PW.8 (option D) applies to release checks and does not cover the missing-test root cause analysis.

16. D. Shift-left moves security earlier, where it is cheaper, and does not replace the right side: monitoring, detection, and response remain essential because software fails in production. The other options describe an abandonment that shift-left does not imply.

17. C. Annex A 8.33 requires test information to be selected, protected, and controlled, and requires that production data used for testing be protected, typically by masking, so that a test environment never exposes real personal data. The other options assert exemptions that the control does not grant.

18. A. Traceability, the thread from requirement to design element to test case, is the evidence that a requirement was actually verified. Signatures (option B), commit counts (option C), and template comparison (option D) do not establish that the requirement was designed and tested.

19. B. Source code escrow releases the vendor’s code to the customer under defined conditions, such as vendor failure or insolvency, protecting continuity. Service agreements (option A), repeated acceptance testing (option C), and screening (option D) address other risks.

20. D. Emergency changes may compress the normal approval path, but they remain documented, tested where possible, reviewed after implementation, and backed by a backout plan. They are not forbidden (option A), not exempt from records (option B), and cannot wait for full-board approval before implementation (option C), since that would defeat the point of the emergency path.

Secure software development on one page

The lifecycle is a control. Software enforces policy, so how it is built decides whether the policy holds, and a documented lifecycle with gates, records, and owners is how an organization makes secure outcomes likely.

Phase placement matters. Requirements define security requirements (SSDF PO.1) and misuse cases; design adds threat modeling and review (PW.1, PW.2, ISO 8.27, SA-8); implementation adds coding standards (ISO 8.28), SAST, review (PW.4), secrets management, and dependency hygiene (PS.3); testing verifies (ISO 8.29, PCI DSS Requirement 6); deployment separates environments (ISO 8.31) and preserves artifact integrity; operations runs the vulnerability loop (ISO 8.8, RV.1 to RV.3); retirement removes the software and its data (SA-22). Traceability connects every requirement to a design and a test.

Models differ in where security lands: waterfall gates, the V-model’s test mapping, the spiral’s recurring risk analysis, agile’s Definition of Done, DevOps’s automation. DevSecOps makes security part of the flow: shift-left, security as code, shared accountability, and metrics (DORA’s four plus security time-to-remediate).

The pipeline is a system to protect: source (reviews, signed commits, secrets scanning), dependencies (pinning, private registries, SBOM, SCA), build (isolated agents, reproducible builds, signing), artifacts (trusted repository, provenance), and deployment (short-lived credentials, gated promotion). Executive Order 14028 and NIST SP 800-218 set the federal baseline; SBOM formats include SPDX (ISO/IEC 5962:2021) and CycloneDX; SLSA adds provenance levels.

Change management makes releases safe: RFC, impact analysis (CM-4), testing, approval (CM-3), backout, records; CABs with normal, standard, and emergency changes; separation of environments and duties (CM-5); protected test data (ISO 8.33); scoped audit testing (ISO 8.34).

Outsourcing transfers work, not accountability (ISO 8.30): contracts with security requirements, acceptance, escrow, developer screening (SA-21), and vendor evidence (SA-10, SA-11).