Domain 8 · Software Development Security · Lesson 8 of 8
Build security into software decisions and delivery
About 16 minutes · Introductory draft · Checked 2026-10-22
AI editorial review for introductory study; independent review and complete exam alignment remain pending. Read course scope and remaining gaps.
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
What you will learn
- Translate security needs into testable software requirements.
- Distinguish review, static testing and running-application testing.
- Manage dependencies, build authority and post-release changes.
Define secure behavior early
Security requirements should describe what the software must permit, deny, preserve or recover. For a shared reporting system, specify that one customer cannot retrieve another customer’s records through either the interface or the API. A requirement to use encryption alone would not address that authorization boundary.
Threat modeling connects assets, data flows, trust boundaries and plausible misuse to design decisions. Revisit it as features and dependencies change. Include logging, error behavior, privacy, retention and recovery rather than leaving operational requirements until the last release meeting.
Use complementary checks
Code review examines implementation and design decisions. Static analysis inspects code without running the application; dynamic testing examines behavior of a running system. Dependency analysis identifies known component risks within its coverage. These methods answer different questions and can have false positives and false negatives.
Use approved test identities and synthetic data to check both denied and permitted behavior. Parameterized queries separate database instructions from values, while context-appropriate encoding helps keep untrusted output from becoming active page content. Neither control substitutes for resource authorization or secure session handling.
Protect the delivery and maintenance chain
Restrict who can change source, approve sensitive changes and publish releases. Protect build credentials and artifacts, review dependencies and retain traceability from reviewed source to deployed output. A signature can support origin and integrity under a trust model, but does not prove the released code has no vulnerabilities.
Maintenance includes responding to newly discovered weaknesses, replacing unsupported components and testing changes for regressions. Review AI-assisted code as carefully as other contributed code: it can invent APIs, copy unsafe assumptions or introduce unnecessary dependencies. Never paste secrets or private source into an unapproved service. No tool-generated success message replaces verification of the actual security requirement.
Work through a scenario
Fictional facts for learning. This exercise is not scored.
A release passes a dependency scan but lets a test user download another tenant’s report. Should it be considered secure because the scan passed?
Compare your reasoning
No. The scan provides evidence about known component issues within its scope, while the observed behavior shows an authorization failure. Correct the server-side access rule, test both tenant isolation and legitimate access, and review related paths. Retain the scan as useful evidence without extending its conclusion to every software property.
Applied study · Added 2026-10-22
Build verifiable security gates into delivery
Continue beyond the introduction. Work through the evidence before opening the model answer.
See it · Try it · Recall it
Picture the topic
Remember this: Security requirements should travel through every iteration.
Explore the anchors
Define abuse cases and acceptance criteria.
Concept matching activity
Match this task or description to its concept:
Implement review and test controls.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
Visual recap for topic 8.1. Open its full syllabus chapter.
Place controls where the failure can be prevented
Security requirements and threat modeling should inform design; code review and static analysis examine implementation; dynamic tests assess a running system; dependency analysis examines known component exposure and provenance. A tool finding needs context and a remediation owner. Passing one scanner does not establish secure software. Define which failures block release, how exceptions are approved and how production feedback returns to development. Protect build identities, artifacts and configuration as part of the software supply chain.
Treat generated and acquired code as untrusted input to review
AI-assisted code and third-party components still need licensing, security, test and provenance review appropriate to their use. Never assume an assistant’s explanation proves that a function checks authorization. Validate the specific failure paths and sensitive-data flows. Keep production secrets out of unapproved generation tools. A rollback plan must account for schema, data and compatibility changes; restoring yesterday’s binary may not safely reverse a database migration. Use staged validation and explicit recovery conditions.
Evidence case
Fictional facts for learning; no real organization or person is described.
- A release uses an updated component and AI-generated authorization code.
- The dependency scan is clean, but no test checks whether one tenant can access another tenant’s records.
Your task
- Explain the assurance gap.
- Define a release test and decision criterion.
Compare with the model answer
A dependency scan does not validate tenant authorization in the application’s own logic. Review the enforcement point and test allowed and rejected requests with separate synthetic tenants. Define the result that blocks release and an authorized exception process. Treat generated code as implementation requiring evidence, not as assurance. Preserve build provenance and a compatible recovery plan.
This case has two original scenario questions in the expanded practice bank. Practice this course · Edition, coverage and remaining study
Remember
- Write testable security requirements before implementation.
- Combine methods and understand what each result can establish.
- Review the source-to-release chain and maintain controls after launch.
Orientation and further reading
Original examples and explanations. Background references do not establish complete exam coverage.