Software Development Security

Software Development Security carries 10% of the CISSP exam and reduces to a single security goal applied across the lifecycle: gain justified confidence that the code your organization runs does what it should and nothing it shouldn't. Five subtopics partition that goal by where the work happens. Security in the SDLC governs the process you build through; Dev Environment Security hardens the toolchain and pipeline that process runs on; Secure Coding fixes the code itself; Software Security Effectiveness proves, with evidence, that the controls actually work; and Acquired Software Security applies the same scrutiny to software you did not write. The unifying CISSP altitude is that you are a manager deciding which control or assessment is right, not a developer typing the fix.

The cost-of-correction curve (a flaw is cheapest to fix while it is still a sentence in a requirements document and most expensive once it is live code customers depend on) is the single idea that orders this entire domain. It is why security requirements and threat modeling come first in the SDLC, why static analysis (SAST) and software composition analysis (SCA) run inside the IDE and pipeline rather than after release, and why secure-coding defenses are structural (parameterized queries, output encoding) rather than reactive patching. "Shift-left" is the name for pulling each security activity to the earliest phase where it can act. Its opposite, penetrate-and-patch (ship, get breached, fix) is the antipattern the whole domain is built to replace.

Buying, downloading, or subscribing to software outsources the building, but the residual risk of running it stays with you the instant you deploy it: a vulnerability in acquired code is a vulnerability in your system, with no vendor to absorb it. That is why Acquired Software Security is an assessment discipline, not a procurement footnote. Your assessment method follows your visibility: source you can read (open source, custom-contract deliverables) you scan and review directly; opaque software (closed COTS, SaaS) you assess indirectly through attestation, certifications, and contract terms. For operated services, the cloud shared-responsibility model draws the line (the provider secures of the cloud, you secure in the cloud) and your data, identities, and configuration stay yours in every model.

No software in this domain is declared secure by the absence of complaints; effectiveness is judged by objective evidence that the security requirements are met. Two questions run through every assessment: verification asks "did we build the software right?" (does it meet the specification), and validation asks "did we build the right software?" (does it counter the real threat). NIST modernized the old Certification and Accreditation into Assessment and Authorization (A&A): an independent assessor produces the evidence, and a senior authorizing official makes the management decision to accept the residual risk: the assessor never accepts it themselves. Metrics that feed that decision (defect density, mean time to remediate, vulnerability recurrence) must be risk-weighted, because a raw "90% patched" is meaningless if the unpatched 10% are the crown jewels.

Every tool that touches the build (the language and runtime, third-party libraries, the IDE, the source-code-management (SCM) repository, and the CI/CD pipeline) is in scope, because an attacker who subverts the toolchain can inject flaws the cleanest source review will never see. The repository is the integrity boundary (governed by least privilege, branch protection, mandatory peer review, and signed commits) and the pipeline is the enforcement gate where shift-left becomes automatic (SAST/SCA scans, secrets detection, artifact signing). Build credentials and signing keys belong in a secrets vault, never hard-coded; signed artifacts let downstream consumers verify provenance and detect tampering.