CS375: Software Engineering - Cybersecurity Capstone: Secure Your System End to End (100 Points)

Assignment Goals

The goals of this assignment are:
  1. To produce a complete STRIDE threat model of a software system, supported by a data-flow diagram
  2. To integrate automated static analysis and dependency scanning into a continuous integration pipeline that must pass on the main branch
  3. To conduct a penetration test following a documented, repeatable methodology and to rate findings by severity using CVSS
  4. To build a security regression test suite of abuse cases that prevents fixed vulnerabilities from returning
  5. To remediate discovered vulnerabilities and report the engagement in a professional format validated against the OWASP Application Security Verification Standard (ASVS)

Background Reading and References

Please refer to the following readings and examples offering templates to help get you started:

The Assignment

This capstone is for students who want to specialize in cybersecurity. It takes the four-fix Securing Your Software assignment and turns it into a complete, professional security engagement against your team project (or, with the instructor’s approval, against a designated target such as OWASP Juice Shop). You will threat-model the whole system, automate security scanning in your pipeline, run a methodical penetration test, remediate what you find, and report it the way a professional security team would.

Treat this as if you were hired to assess the system. Everything you claim should be reproducible by the reader from your report.

1. Threat Model (Design)

Produce a data-flow diagram of your system that marks every trust boundary (where data crosses from less-trusted to more-trusted, e.g. browser → server, server → database). Then apply STRIDE systematically to each element and data flow. For every plausible threat, record the property it violates (CIA), a mapped mitigation with its OWASP category and/or CWE, and where in the system it is addressed. A free tool such as OWASP Threat Dragon is ideal for the diagram.

2. Automate Security in CI (Deployment)

Extend the continuous integration workflow you built in the CI/CD activity and required for your Test Plan so that, on every push, it runs:

  • Static application security testing (SAST) – CodeQL or Semgrep – to find vulnerable code patterns.
  • Dependency / supply-chain scanning – Dependabot, npm audit, or GitHub dependency review – to catch components with known CVEs (recall the real polyfill.io supply-chain incident in this course’s own history).

These checks must pass (green) on your main branch, and your report must link to a passing run. Triage every finding: fix it, or justify it as accepted risk with a reason.

3. Penetration Test (Verification)

Conduct a penetration test following a documented methodology – the OWASP Web Security Testing Guide or the PTES. Define and state your scope and rules of engagement first (only test systems you are authorized to test). For each finding, record:

  • reproduction steps and evidence (request/response, screenshot, or script);
  • the vulnerability class (OWASP/CWE);
  • a CVSS vector and score;
  • the impact, expressed in terms of the CIA triad.

Practicing against a deliberately vulnerable app first – WebGoat or Juice Shop – is a good way to build technique before testing your own system.

4. Remediate and Add Abuse-Case Tests

Remediate findings in severity order (highest CVSS first). For each remediated finding, add an abuse-case regression test – a test of what must not be allowed (e.g., “an unauthenticated request receives 401”, “user Bob cannot read user Alice’s note”, “a 10 MB note is rejected”). Each test should fail before your fix and pass after, and it should run in CI so the vulnerability cannot silently return. These extend the layered test matrix from the testing activity with a security lens.

5. Security Report (with ASVS Validation)

Write a professional security report containing:

  • an executive summary (non-technical: what you assessed, the headline risks, and their business/user impact);
  • scope, methodology, and rules of engagement;
  • findings, each with evidence, CWE, CVSS, and remediation status;
  • an ASVS validation: choose an appropriate level of the OWASP Application Security Verification Standard, justify the level, and record pass/fail against its requirements for your system;
  • residual risk and next steps.

Deliverable

Submit the report, the threat-model diagram, and links to your passing CI run and your abuse-case tests, all in your project repository and linked from your project website. As with all professional security work, ensure everything is reproducible from your documentation, and only ever test systems you are authorized to test.

Submission

In your submission, please include answers to any questions asked on the assignment page, as well as the questions listed below, in your README file. If you wrote code as part of this assignment, please describe your design, approach, and implementation in a separate document prepared using a word processor or typesetting program such as LaTeX. This document should include specific instructions on how to build and run your code, and a description of each code module or function that you created suitable for re-use by a colleague. In your README, please include answers to the following questions:
  • Describe what you did, how you did it, what challenges you encountered, and how you solved them.
  • Please answer any questions found throughout the narrative of this assignment.
  • If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work?
  • Please identify any and all portions of your submission that were not originally written by you (for example, code originally written by your buddy, or anything taken or adapted from a non-classroom resource). It is always OK to use your textbook and instructor notes; however, you are certifying that any portions not designated as coming from an outside person or source are your own original work.
  • Approximately how many hours it took you to finish this assignment (I will not judge you for this at all...I am simply using it to gauge if the assignments are too easy or hard)?
  • Your overall impression of the assignment. Did you love it, hate it, or were you neutral? One word answers are fine, but if you have any suggestions for the future let me know.
  • Using the grading specifications on this page, discuss briefly the grade you would give yourself and why. Discuss each item in the grading specification.
  • Any other concerns that you have. For instance, if you have a bug that you were unable to solve but you made progress, write that here. The more you articulate the problem the more partial credit you will receive (it is fine to leave this blank).

Assignment Rubric

Description Pre-Emerging (< 50%) Beginning (50%) Progressing (85%) Proficient (100%)
Threat Model and Data-Flow Diagram (20%) No threat model is provided, or it is a list of generic risks not tied to the system A partial threat model is provided but lacks a data-flow diagram or applies STRIDE to only part of the system A data-flow diagram identifies trust boundaries, and STRIDE is applied to the major components with plausible threats and mitigations A clear data-flow diagram marks every trust boundary, STRIDE is applied systematically to each element and data flow, threats are prioritized, and each carries a mapped mitigation (OWASP/CWE) and a link to where it is (or will be) addressed
Automated Scanning in CI (Static Analysis and Dependencies) (20%) No automated security scanning is present in the pipeline A scanner (CodeQL, Semgrep, or dependency review) is configured but does not run on push or is failing on the main branch Static analysis and dependency scanning run on each push and pass on the main branch, with findings triaged Static analysis and dependency scanning both run on each push, gate the pipeline, pass on the main branch with a linked run, and the report explains how triaged findings were resolved or justified as accepted risk
Penetration Test Methodology and Findings (25%) No penetration testing was performed, or testing is undocumented and not reproducible Some testing was performed but without a stated methodology, or findings lack evidence or severity ratings Testing follows a documented methodology (OWASP Testing Guide or PTES), and each finding has evidence, a CVSS severity, and reproduction steps Testing follows a documented methodology with defined scope and rules of engagement, and each finding has evidence, reproduction steps, a CVSS vector and score, and an assessed impact tied to the CIA triad
Remediation and Security Regression Tests (20%) Findings were not remediated and no security tests were added Some findings were remediated but without tests, or abuse-case tests exist but do not cover the findings The significant findings are remediated and each is covered by an abuse-case regression test that fails before the fix and passes after Findings are remediated by severity order, each is covered by an abuse-case regression test wired into CI, and the report demonstrates the before/after (failing then passing) for each
Security Report and ASVS Validation (15%) No report, or the report does not follow a recognizable professional structure A report exists but omits key sections (scope, methodology, findings, remediation) or does not reference ASVS The report follows a professional structure and maps the system against a chosen OWASP ASVS level The report follows a professional pentest structure with an executive summary and technical detail, maps the system against a justified ASVS level with per-requirement pass/fail, and states residual risk and next steps

Please refer to the Style Guide for code quality examples and guidelines.