D385 Software Security and Testing is listed under banner number ITEC 2034 and is worth 3 competency units. It covers recognising software security vulnerabilities and planning, developing and testing interventions across web security, permissions and identity, debugging, log file analysis, application programming interface security and cryptography. D385 and ITEC 2034 are one requirement. It is the course that teaches developers to think about how their code fails on purpose rather than by accident.
Almost every vulnerability is a trust mistake
The list of weakness classes in this course looks long until you notice the pattern underneath it. Injection happens because input was trusted as instruction. Broken access control happens because a request was trusted to be authorised. Insecure deserialization happens because data was trusted to be well formed. Once you read vulnerabilities as answers to the question "what did this code trust that it should not have?", the catalogue becomes a small number of ideas rather than dozens of separate facts.
Input handling is the practical centre. Validation should be positive rather than negative: define what is acceptable and reject everything else, because trying to enumerate every bad input is a losing game. Encoding should happen at the point of output and should match the context the data is going into, since the escaping needed for a database is not the escaping needed for a page or for a shell.
Permissions and identity form the second half. Authentication establishes who is asking. Authorisation decides whether they may. The most common serious flaw in real applications is checking the first and assuming the second, which is why an object identifier that can be changed in a request is such a persistent problem. Every request that touches a resource needs its own authorisation decision.
Testing and log analysis then close the loop. Security testing includes negative cases, which are the tests that confirm the application refuses what it should refuse. Logs are the evidence that something was attempted, and the course expects you to know what should be logged, what must never be logged, and how to read a log for signs of probing rather than only for errors.
The record shows Competent or Not Competent, because letter grades and an ordinary grade point average do not exist here, and the 3 competency units measure course size within a six month term sold at one price. All practical work happens against the authorised application and environment your course provides.
Turning aspects into a secure development plan
If your version of D385 uses a performance assessment, expect aspects proven by code changes and aspects proven by explanation or testing evidence. WGU requires a score of 2 in each aspect for a task to pass and judges each aspect alone, so a fixed vulnerability with no test proving the fix leaves the testing aspects unanswered.
Budget across the kinds. Take a rubric with seven scored aspects and a written component near 1,600 words alongside code and test output. Reserve 120 words for the application and environment, and 90 for the close, leaving 1,390. If four aspects are demonstrated by code and tests, allow 140 words each to name the weakness, point at the fix and show the test result, which is 560. The remaining 830 covers three explanatory aspects at roughly 276 each, enough for the trust failure, the intervention and its limits.
For every vulnerability you address, use a fixed order: what the code trusted, how that trust could be abused, what the fix changes, and the test that proves the abuse no longer works. That last element is the one students skip, and it is usually its own aspect.
Reserve budget for what your fix does not cover. A parameterised query stops injection at that call site and says nothing about the other twelve. Naming the boundary of a fix is what separates a security-minded developer from someone who patched a finding.
Shape for a secure code review and remediation
D385 deliverables usually pair code changes with a document. These proportions apply to the document.
| Section | Content | Share |
|---|---|---|
| Application and scope | What the application does, its stack and versions, and which parts you examined. | 10 percent |
| Findings | Each weakness with its location, the trust failure behind it, and how it could be abused. | 22 percent |
| Interventions | The change made for each finding and why that approach rather than an alternative. | 20 percent |
| Testing evidence | Negative tests showing the abuse now fails, plus positive tests showing nothing legitimate broke. | 18 percent |
| Identity and permissions | Where authorisation decisions happen and whether every resource access is covered. | 13 percent |
| Logging | What is recorded, what is deliberately not recorded, and what an attempted attack would look like in the log. | 11 percent |
| Close | Residual weaknesses and the next area you would review. | 6 percent |
Evidence in a course where the code is the proof
Your primary evidence is the code and the test output around it. Show the vulnerable construction and the fixed one side by side where the task permits, and show a test that fails before the fix and passes after. A fix asserted without a demonstration is the most common gap in this subject, and it is easy to close if you capture the failing case before you change anything.
For citations, weakness classifications belong to the recognised public catalogues of software weaknesses, and secure coding guidance belongs to published application security resources and to the language or framework's own security documentation. Where you rely on a framework feature to provide protection, cite its documentation and name the version, because defaults change and a protection that was automatic in one release may require configuration in another.
Be careful with logging claims. Logs must not contain credentials, full payment data, session tokens or unnecessary personal data, and saying explicitly what you excluded is as important as saying what you record. A submission that adds detailed logging without noticing that it now writes passwords to disk has created a worse problem than the one it fixed.
Cryptographic elements should point at current published guidance rather than at habit. Password storage in particular has a settled professional answer that has changed over time, and citing current guidance shows you know the answer is versioned rather than permanent.
Follow the citation style named in your task and put the citation where the assertion actually appears. All testing stays inside the environment your course authorises.
Competent remediation and returned work
Competent submissions explain the trust failure behind each weakness, fix it at the right layer, prove the fix with a negative test, and state what the fix does not cover. The logging section shows judgement about what should never be written down.
Returns follow four shapes. Vulnerabilities are named by category with no explanation of why this code was vulnerable. Fixes are applied at the wrong layer, most often by filtering input in a way that fails on a different code path. There is no test evidence, so the fix is asserted rather than shown. Or the document lists findings from a tool without confirming any of them in the code.
A useful check before submitting: for each fix, describe in one sentence how an attacker would still get in if they were determined. If that sentence is easy to write, either the fix is incomplete or you have found a genuine residual risk worth documenting. Both outcomes improve the submission.
WGU attaches no grade penalty to a revised and resubmitted performance assessment, so completeness beats polish when you are deciding whether to submit, and treat the first submission as a way of buying exact feedback. If your section also carries an objective assessment, WGU objective assessments are proctored and our boundary is absolute: preparation only, with weakness pattern drills, code reading practice and a candid read on your preassessment result. We never sit an exam, stay out of the room entirely, and we neither ask for nor accept portal credentials.
Fixed the bug but cannot prove it?
Send the D385 rubric and your code. We build the negative test set and plan findings, interventions and evidence with word targets.
Eight mistakes that cost time in D385
- Memorising weakness names. Ask what the code trusted. Every category collapses into that one question.
- Blocklist validation. Define what is acceptable and reject the rest. Enumerating bad input never finishes.
- Encoding in the wrong context. Escaping for a page, a query and a shell are different. Encode at output, for the destination.
- Authenticating without authorising. Knowing who is asking does not decide whether they may. Check per resource access.
- No negative test. A fix without a test that used to fail is a claim, not a demonstration.
- Logging secrets. Adding detail without thinking about content can turn a logging improvement into a data breach.
- Tool output as findings. Confirm each reported weakness in the code before writing it up.
- Silent scope. Say which parts of the application you reviewed, because an unstated scope reads as a complete review.
Three questions students ask about D385
How much programming experience does this need?
Which language will the work be in?
Can I practise on real websites?
Where D385 sits in WGU's programs
The July 2026 catalog places this code in 4 current WGU programs. 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.