WGU D487: Secure Software Design

What D487 Is and Why It Matters

WGU D487, Secure Software Design, sits in the School of Technology and asks a question every modern developer eventually has to answer: how do you build software that holds up when someone actively tries to break it? Instead of treating security as a patch you bolt on at the end, the course teaches you to weave it through every stage of the software development life cycle (SDLC) — from the first conversation about requirements to the moment a product ships and beyond. You will study how threats are identified, how risk is measured, how testing exposes weaknesses, and how design decisions either invite or resist attack.

Direct answer: To pass D487, learn the secure SDLC as a repeatable process and master the vocabulary that goes with each phase — threat modeling (STRIDE, DREAD), risk scoring, the testing types, maturity models, and major compliance frameworks. This is a concept-and-terminology objective assessment, so consistent recall of definitions and where each activity belongs in the lifecycle matters far more than writing code.

Most students meet D487 partway through a technology or cybersecurity program, often after early programming and information-security coursework. It matters because secure design is now a baseline professional expectation, not a specialty. Employers assume you know why fixing a vulnerability in design costs a fraction of fixing it after release, and that instinct is exactly what this course builds.

What the Assessment Covers

D487 is assessed by an objective assessment (OA) — a multiple-choice style exam rather than a written project. The questions test whether you can recognize concepts, match activities to the correct SDLC phase, and choose the right technique for a given scenario. The core topic areas reported across public course descriptions include:

• Secure SDLC integration — building security into requirements, design, development, testing, and deployment rather than adding it later.
• Threat modeling — structured methods such as STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) and DREAD for rating threats.
• Risk analysis — ranking risk by likelihood and impact, building risk profiles, and planning mitigations; scoring systems like CVSS.
• Testing and analysis techniques — white box, black box, and gray box testing; static analysis, dynamic analysis, penetration testing, fuzz testing, and vulnerability scanning, and knowing what each one reveals.
• Maturity models and frameworks — approaches such as SAMM/OpenSAMM and BSIMM used to assess and improve an organization's security practices.
• Secure design principles and OWASP — common vulnerability categories and the design guidance that heads them off.
• Compliance and policy — how frameworks like HIPAA, PCI DSS, and GDPR shape software requirements.

How Hard It Is and How Long to Budget

Many students describe D487 as manageable but vocabulary-heavy. The challenge is rarely difficult reasoning; it is the sheer number of named models, methodologies, and testing types that look similar until you study them side by side. People with a background in cybersecurity foundations tend to move quickly, while those newer to the material spend more time on the distinctions.

Aggregated student reports put the typical timeline in the range of a few weeks, with an average of roughly six weeks for those balancing it against work and other courses. A focused learner who studies daily can often finish faster. Plan for one to three weeks of concentrated study rather than a single cram session, because spacing the terminology out is what makes it stick. If you have already worked through D430 Fundamentals of Information Security, some of the risk and threat vocabulary will feel familiar and shorten your ramp-up.

A Study Plan That Fits This Course

Because D487 rewards precise recall, lean on study methods proven to build durable memory rather than passive re-reading.

• Map the SDLC first. Draw the phases on one page and, under each, list the security activities that belong there. When a question describes a scenario, you want to instantly place it in the right phase. This single mental model organizes most of the exam.
• Use active recall for terminology. Make flashcards for every model and method — STRIDE vs. DREAD, SAMM vs. BSIMM, static vs. dynamic analysis, white/black/gray box. Quiz yourself until you can define each and, crucially, state how it differs from its neighbors.
• Space your repetition. Review the hardest cards daily and the easy ones every few days. Spreading practice over a week or two beats a marathon and matches how the material is tested.
• Practice with scenarios, not just definitions. The OA often frames concepts as situations. Ask yourself: which testing type would find this flaw? Which threat category does this describe? Testing yourself this way surfaces gaps a definition list hides.
• Study the official course materials in order. Work through the assigned learning resources and any cohort or instructor sessions WGU provides; they signal exactly which distinctions the assessment emphasizes.

The secure-testing mindset here overlaps with D385 Software Security and Testing, so if that course is on your plan, studying them close together reinforces both.

Common Mistakes to Avoid

• Confusing similar models. STRIDE and DREAD both relate to threats but do different jobs — one categorizes threats, the other rates them. Mixing up SAMM and BSIMM is another frequent slip. Build a comparison table so the boundaries are crisp.
• Blurring the testing types. Static analysis inspects code at rest; dynamic analysis watches it run; fuzzing throws malformed input at it; penetration testing simulates an attacker. Learn what each one can and cannot detect.
• Treating security as an end-stage step. A recurring theme is that security belongs in every phase. Answers that push all security work to the end are usually the trap option.
• Memorizing without context. Knowing a definition is not the same as recognizing it in a scenario. If you only drill flat definitions, the applied questions will catch you.
• Underestimating the compliance material. HIPAA, PCI DSS, and GDPR each map to different data and industries; skimming them costs easy points.

Exam Readiness Checklist

• Can you list the phases of the secure SDLC and name at least one security activity in each?
• Can you explain STRIDE and DREAD and state what each is used for?
• Can you distinguish white box, black box, and gray box testing by what the tester knows?
• Can you contrast static analysis, dynamic analysis, penetration testing, and fuzzing by what each detects?
• Can you describe how risk is prioritized using likelihood and impact, and what CVSS contributes?
• Can you compare maturity models such as SAMM/OpenSAMM and BSIMM at a high level?
• Can you match HIPAA, PCI DSS, and GDPR to the kinds of data and organizations they govern?
• Can you explain why addressing a vulnerability early in the SDLC is cheaper than after release?
• Can you identify common OWASP-style vulnerability categories and a design choice that mitigates each?

FAQ

Is D487 an OA or a PA?

D487 is assessed by an objective assessment (OA), a proctored multiple-choice style exam. There is no separate written performance task, so your preparation should center on concept recall and applied recognition rather than a project submission.

How hard is D487?

Many students report it as moderate. The reasoning is not especially difficult, but there is a large volume of named models, frameworks, and testing types to keep straight. Steady terminology practice, rather than raw study hours, is what most people say made the difference.

How long does it usually take to finish?

Timelines vary with your background, but aggregated reports cluster around a few weeks, with roughly six weeks as a common average for students juggling work. A focused daily plan often compresses that considerably.

Do I need to write code to pass?

No. D487 is about secure design thinking and process, not hands-on programming. You should understand where vulnerabilities come from and how design and testing address them, but the exam tests concepts, not coding.

What should I study first?

Start with the secure SDLC as your backbone, then attach each threat-modeling method, testing type, maturity model, and compliance framework to the phase where it lives. That structure turns a long list of terms into an organized map you can navigate under exam pressure.

What other WGU courses connect to this one?

Security foundations from D430 feed directly into the risk and threat concepts here, and the testing focus overlaps with D385. If you are exploring the professional-conduct side of technology, D333 Ethics in Technology and the programming groundwork in D286 Java Fundamentals round out the picture. Browse the full School of Technology hub or the complete guide index for more.