D487 Secure Software Design is listed under banner number ITAS 6231 and is worth 3 competency units. It covers secure software acquisition and development throughout the software development lifecycle, across people, technology, tools and processes, with Defense in Depth as its organising principle. D487 and ITAS 6231 are one requirement. The argument it builds is that security introduced late is expensive and partial, and security designed in is neither.
Every phase has a security activity that belongs to it
The structuring idea is simple to state and demanding to apply: each phase of software development has a security activity that is natural to it and expensive anywhere else. Requirements is where security requirements get written as testable statements. Design is where threat modelling happens, because that is when changing the architecture is still cheap. Implementation is where secure coding standards and code review apply. Testing is where security testing joins functional testing. Deployment is where configuration and secrets management matter. Maintenance is where dependency and vulnerability management live.
Threat modelling is the highest value activity in the list and the one worth practising hardest. It asks four questions in order: what are we building, what can go wrong, what are we going to do about it, and did we do a good enough job. A design document that answers all four is doing the core work of this course, and one that only describes controls has skipped the second question that justifies them.
Defense in Depth is named in the course description and should show in your designs rather than being asserted. It means layered protections with different failure modes, so that a bypass of one does not become a total compromise. Input validation plus parameterised queries plus least privilege database accounts plus monitoring is depth, because each fails differently. Three variations of input filtering is not.
Acquisition is the strand students underweight. Most software in an organization is bought or pulled from public repositories rather than written, and the security questions differ: how you evaluate a vendor, what you require contractually, how you assess a dependency, and how you know what is in a build. A graduate submission that addresses only code the team wrote has answered half the course.
Assessment closes as Competent or Not Competent, and neither letter grades nor an ordinary grade point average are recorded, while the 3 competency units simply size the course inside a flat-priced six month term.
Turning aspects into a lifecycle plan
If your version of D487 uses a performance assessment, the aspects usually map onto lifecycle phases plus a threat model. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a strong threat model will not carry unaddressed acquisition or maintenance aspects.
Budget before drafting. Take a rubric with seven scored aspects and a target near 2,100 words. Reserve 150 words for the application, its users and its data, and 110 for the close, leaving 1,840 across seven aspects, or roughly 262 each. Weight by demand: two aspects requiring a threat model and a layered design take 400 each, which is 800; the five remaining aspects, covering requirements, coding standards, testing, acquisition and maintenance, take 208 each, which is 1,040. Together that is 1,840.
Write security requirements as testable statements, because that is what makes the requirements aspect scoreable. "The application must be secure" cannot be tested. "Session tokens must be invalidated server-side on logout and must expire after thirty minutes of inactivity" can be, and a tester could confirm it.
Reserve budget to show the layers explicitly. A short table listing each threat and the two or three independent controls that address it, with the failure mode of each, is the clearest possible demonstration of Defense in Depth and it is far more convincing than a paragraph claiming the principle was applied.
Shape for a secure development plan
D487 deliverables usually build a secure development approach for a described application. These proportions fit that document.
| Section | Content | Share |
|---|---|---|
| Application and context | What it does, who uses it, what data it holds and how it is deployed. | 11 percent |
| Security requirements | Testable statements derived from the data sensitivity and the obligations that apply. | 14 percent |
| Threat model | Assets, entry points, trust boundaries, threats and the design responses to them. | 22 percent |
| Layered controls | Each threat with independent controls and the different failure mode of each layer. | 17 percent |
| Build practices | Coding standards, review, secrets handling and the security tests that run automatically. | 16 percent |
| Acquisition and dependencies | Vendor evaluation, contractual requirements, dependency assessment and build contents. | 13 percent |
| Maintenance | Vulnerability response for dependencies, patch cadence and how the model is revisited. | 7 percent |
Sourcing secure development practice
Secure development guidance belongs to published application security resources, standards body documentation on secure development lifecycles and national agency guidance. Weakness classes belong to the recognised public catalogues. Language and framework specifics belong to their own security documentation, cited by version because protections that are automatic in one release may need configuration in another.
Where you claim a practice reduces defects or vulnerabilities, that is an empirical claim and belongs to research or industry data with a year attached. There is genuine published work on the cost of fixing defects at different lifecycle phases, and citing it properly is better than repeating a widely quoted figure whose origin nobody can produce.
Be precise about what each control actually stops. A dependency scanner reports known vulnerabilities in known components; it does not find logic flaws or unknown weaknesses. Static analysis finds patterns; it does not understand intent. Stating these limits is the difference between a plan that would work and a plan that assumes tools do more than they do.
For acquisition, the evidence question is what you would require rather than what you would hope. Naming the specific artifacts you would ask a vendor for, and what you would do if they declined, turns a general statement about vendor risk into a process.
Follow the citation style named in your task and cite at the point of claim.
Competent designs and returned work
Competent submissions place the right activity in the right phase, produce a real threat model with trust boundaries, demonstrate layering with independent failure modes, and treat acquired software and dependencies as seriously as written code.
Returns follow four shapes. Security appears only at the testing phase, which is the exact pattern the course exists to correct. The threat model lists threats with no trust boundaries, so nothing explains where they enter. Layering is claimed but the controls all fail the same way. Or acquisition and dependencies are absent from a plan for an application that certainly uses third-party components.
The plans that read best also acknowledge friction. Security activities compete with delivery pressure, and a process that adds a week to every release will be routed around within two months. Saying which activities are automated, which are gated and which are advisory, and roughly what each costs in delivery time, is the difference between a plan a team would adopt and one they would nod at.
A quick check: pick your most important asset and trace every path by which untrusted input can reach it. If any path has a single control on it, that is where the design lacks depth, and naming it is better than leaving the evaluator to find it.
Nothing is deducted when performance assessment work goes back for revision, so a complete draft should go to the evaluator rather than back to you, rather than holding it back for another pass. If your section also carries an objective assessment, WGU objective assessments are proctored and our boundary is absolute: preparation only, with threat modelling drills, requirement writing practice and a candid read on your preassessment result. Nobody here sits an assessment, stay out of the room entirely, and portal credentials are never requested or handled.
Threat model not producing a design?
Send the D487 rubric and your application description. We build trust boundaries, layered controls and testable requirements with word targets.
Eight mistakes that cost time in D487
- Security only at testing. Each phase owns an activity. Placing them correctly is the point of the course.
- Untestable requirements. If a tester cannot confirm it, it is an aspiration rather than a requirement.
- Threats with no trust boundaries. A threat needs an entry point. Draw the boundaries and the list becomes concrete.
- Fake depth. Three variations of the same control share a failure mode. Layers must fail differently.
- Ignoring dependencies. Most code in a modern application was written by someone else. Assess it.
- Overstating tools. Scanners find known patterns. Say what they miss and what covers that gap.
- Vendor risk as a sentence. Name the artifacts you would require and what happens if they are refused.
- No revisit trigger. Threat models age with the architecture. Say what change would prompt a new one.
Three questions students ask about D487
Do I need to be a developer?
Which threat modelling method should I use?
How does this differ from D385?
Where D487 sits in WGU's programs
The July 2026 catalog places this code in 1 current WGU program. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.