D785 DevOps Security is banner number ITSW 6102 and three competency units in the School of Technology, in the graduate DevOps sequence. The catalog describes it as tools for continuously monitoring security risks and fortifying code repositories using industry best practices. Two ideas are named there and both are specific. Continuous monitoring means security is a running process rather than an audit, and fortifying repositories means the source itself, and everything that can reach it, is treated as an asset worth defending.
Security placed inside the delivery process
The premise of this course is that security applied at the end is security applied too late and too weakly. A review that happens after a release is built can only reject or accept, and rejection at that point is expensive enough that it gets negotiated away. Moving the checks earlier changes the economics: a dependency with a known vulnerability caught at commit is a version bump, and the same dependency caught in production is an incident.
The categories of automated check are worth naming precisely because aspects use them. Static analysis reads source without running it and finds injection patterns, unsafe handling and hardcoded secrets. Dependency scanning compares your declared libraries against known vulnerability data, which matters because most of the code in a modern application was written by strangers. Secret scanning looks for credentials committed by accident. Container and image scanning inspects the base layers you inherited. Dynamic testing exercises the running application. Each finds a different class of problem and none substitutes for another.
Repository hardening is the second named subject. Branch protection so nothing reaches the main line unreviewed, required reviews from someone other than the author, signed commits where provenance matters, least privilege on who can write and who can administer, and the same care for the automation credentials that the pipeline uses. The build system is a high value target precisely because it is trusted by everything downstream.
Supply chain integrity has become part of this subject. Where your dependencies come from, whether the versions you build with are the versions you reviewed, and whether you can produce an inventory of what is in a release are questions a graduate paper is expected to address rather than to assume.
Turning scored aspects into controls and a word budget
Aspects are scored individually and each needs a 2. In a security course the productive mapping is aspect to control, and every control needs three things stated: what it detects, where in the process it runs, and what happens when it fires.
Budget it. Suppose eleven scored aspects and a document of about 2,100 words. Eleven into 2,100 is 191 each. Sort them. Three are inventory aspects answered by a control table, needing 110 each of framing, which is 330 and releases about 240. Three are justification aspects covering control selection, placement and response, at 300 each, or 900. Two cover repository and access hardening, at 260 each, or 520. One covers monitoring and metrics, 250. Two are short framing sections at 60 each, or 120. That totals 330 plus 900 plus 520 plus 250 plus 120, which is 2,120, on target, with justification and hardening carrying more than two thirds.
Write the response policy for every control before you write prose. A finding that stops the pipeline, a finding that raises a ticket, and a finding that is recorded and reviewed weekly are three different policies, and a control without one is an alert nobody owns.
On the D785 deliverable?
Send the aspects plus the environment context. You get a control map with placements and response policies, plus a hardening checklist.
A control map from developer to production
| Control | Catches | Placed at | Response when it fires |
|---|---|---|---|
| Pre-commit secret detection | Credentials about to enter history | The developer's machine | The commit is refused before anything is pushed |
| Secret scanning on the repository | Credentials already committed | The hosting platform, continuously | Rotate the credential first, then remove it from history |
| Static analysis | Unsafe patterns in your own code | Every pull request | Blocks the merge above a severity threshold |
| Dependency scanning | Known vulnerabilities in libraries | Every build, and on a schedule | Blocks release above a threshold, ticket below it |
| Image scanning | Vulnerable base layers and packages | Artifact build | Rebuild on a patched base before promotion |
| Configuration checks | Permissive rules and exposed storage | Before infrastructure is applied | Blocks the apply, with the offending resource named |
| Runtime monitoring | Behavior that differs from the expected baseline | Production, continuously | Alerts a named owner with a defined first action |
Note the second row's ordering. A committed credential is compromised the moment it is pushed, so rotation comes before history rewriting, and getting that sequence backwards is a common and consequential error.
Evidence, safe handling and citation
Security evidence has to be produced without creating a new exposure. Redact everything identifying: real hostnames, account identifiers, internal addresses, tokens and the full output of any scanner that names a live system. State in the document that values are redacted or synthetic. A graduate paper that publishes a real finding against a real environment has created the problem it was analyzing.
Where you show tool output, annotate it. A screenshot of a scanner is not an argument; a screenshot with the finding, the severity basis and your response decision beside it is. Where you claim a control reduces risk, connect it to a specific threat rather than to security in general.
For sources, published security frameworks, recognized vulnerability classification and scoring systems, and established guidance on secure development practice are the strong citations, in APA where your program requires it. Use severity scoring properly, including the distinction between a base score and the contextual adjustment that reflects your environment, because a graduate evaluator will notice a severity treated as absolute. Vendor documentation is authoritative for what a tool detects and is not evidence of how much risk it removes.
What clears, and what returns
Work at WGU is Competent or Not Competent, and revision after a return costs time rather than record. In a six month flat rate term the days are the expense, so a first submission with response policies already stated is the efficient target.
Documents that clear place controls deliberately rather than listing tools. They state thresholds and say who owns a finding. They treat repository and pipeline access as part of the attack surface rather than as administration. They acknowledge what their control set does not catch, which reads as judgment rather than as weakness.
Returns come from four habits. A tool inventory with no placement or policy. Severity used as an absolute rather than adjusted for context. Repository hardening reduced to a sentence about branch protection. And a monitoring section that describes alerting without naming an owner or a first action, which leaves the response aspect unanswered.
Six mistakes that cost D785 students time
- Listing tools instead of designing controls. Placement, threshold and response are what turn a tool into a control.
- Deleting a leaked secret without rotating it. Rewriting history does not un-share a credential. Rotate first, always.
- Blocking on every finding. A pipeline that stops for low severity noise gets its checks disabled, which is worse than a threshold.
- Forgetting the pipeline's own credentials. Build automation usually holds the most powerful access in the organization and is often the least reviewed.
- Publishing unredacted findings. Real hostnames, tokens or scanner output in a submitted document create an exposure that the document is arguing against.
- Ignoring the supply chain. Most of the code in a release was not written by your team, and a paper that only examines your own source has examined the smaller half.
How we work on this course
D785 support is control design and safe writing. Send the scored aspects and the environment context and you get a control map with placement, thresholds and response policies, a repository and access hardening checklist, a redaction pass so nothing sensitive reaches a submitted document, and a model paper in the register WGU graduate evaluators expect. Where a section of your course is assessed by an objective assessment, our work is preparation only. Objective assessments are proctored, we prepare students and never sit or assist during any assessment, and we never ask for or touch portal credentials or any live system.
Security papers are among the ones that go wrong quietly, because a document can look thorough while every control in it lacks an owner. Fixing that at the planning stage is what keeps a six month flat rate term on schedule.
Three questions D785 students ask
Is D785 the same course as ITSW 6102?
Do I need to run scans against a real system?
What do I do if I find a real credential in my repository?
Where D785 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.