CSE-60770 (40770) Secure Software Engineering

This Is Not The Course Website You Are Looking For

This course website is from a previous semester. If you are currently in the class, please make sure you are viewing the latest course website instead of this old one.

Course Objectives:

Upon successful completion of this course, students will be able to:

  • Comprehend security principles and be able to apply security principles through the software development lifecycle;
  • Identify the differences and commonalities across vulnerability detection techniques & practices.
  • Be able to follow a systematic process to collect and analyze metrics for assessing and improving the security of a software system.
  • Be able to develop techniques to (semi-)automatically detect software vulnerabilities
  • Critically evaluate and recommend the most appropriate security solutions for a software stack.
ABET Outcomes
Analyze a complex computing security problem and apply principles of computing and other relevant disciplines to identify solutions. Design, implement, and evaluate a computing-based solution to meet a given set of security requirements in the context of the program’s discipline. Communicate effectively in a variety of professional contexts. Function effectively as a member or leader of a team engaged in activities appropriate to the program’s discipline.
Text Books

All necessary materials will be provided in the lecture notes, code samples, and through weekly readings. However, some course materials have been taken from the following books, which students may choose to purchase:

  • McGraw, Gary. Software Security: Building Security in. Germany, Addison-Wesley, 2006. http://www.swsec.com/
On CSE 60770 vs. CSE 40770
The default version of this course is 60770. All graduate students must enroll in the 60770 version of the course, whereas undergraduate students must enroll in the 40770 version of the course. Although the same concepts will be taught for both sessions, the assignments will have differences for graduate and undergraduate students to tailor the intellectual challenge accordingly. Thus, there will be different expectations different expectations for the scope or intellectual novelty of the assignments. These will be explicitly expressed in each assignments' document.
Prerequisites
At least one of the following courses or the permission of the instructor: Programming Paradigms, or Software Engineering. Advanced programming skills are desirable.

This is the approximate schedule for the course; however, the schedule will be adapted if needed. Slide decks are linked in advance but will be modified up until the lecture.

Week # Monday Wednesday
Week 1 Jan 18
L1: Course Overview & Introduction
Slides Activity #1 ⏰ 01/23 @ 2PM
Week 2 Jan 23
L2: SW Security Pillars
Slides HW1 ⏰ 02/07 @11:59PM
Jan 25
L3: Software Weaknesses (Deadly Sins of SW Security)
Slides Activity #2 ⏰ 01/30 @ 2PM
Week 3 Jan 30
L4: Weaknesses & OWASP Top 10 (Part 1)
Slides Activity #3 ⏰ 02/01 @ 2PM ⚙️ Course Project
Feb 01
L5: OWASP Top 10 (Part 2)
Slides Activity #4 ⏰ 02/06 @ 2PM
Week 4 Feb 06
L6: OWASP Top 10 (Part 3) & Intro to PyGoat
Slides
Feb 08
L7: PyGoat & Django Hands on
Slides Activity #5 ⏰ 02/13 @ 2PM HW2 ⏰ 2/21 @11:59PM
Week 5 Feb 13
L8: Django Hands on (Pt 2) & Secure Design Principles
Slides 📄 Seminar
Feb 15
L9: Sec Design Principles (Pt2), Sec. Requirements
Slides Activity #6 ⏰ 02/20 @ 2PM
Week 6 Feb 20
L10: Misuse/Abuse Cases & Threat Modeling-1
Slides
Feb 22
L11: Threat Modeling-2 & Static Analysis-1
Slides Activity #7 ⏰ 02/27 @11:59PM HW3 ⏰ 03/07 @11:59PM 🔎 Case Study
Week 7 Feb 27
L12: Static Analysis-2
Slides
Mar 01
L13: Static Analysis-3
Slides Activity #8 ⏰ 03/06 @11:59PM
Week 8 Mar 06
L14: Static Analysis-4
Slides
Mar 08
L15: Static Analysis-5
Slides HW4 ⏰ 03/28 @11:59PM
Week 9 Mar 13
No Class
Mar 15
No Class
Week 10 Mar 20
L16: Seminar Presentations - Day 1
Slides
Mar 22
L17: Seminar Presentations - Day 2
Slides
Week 11 Mar 27
L18: Seminar Presentations - Day 3
Slides
Mar 29
L19: Secure Coding (1)
Slides Activity #9 ⏰ 04/05 @ 2PM
Week 12 Apr 03
L20: Secure Coding (2)
Slides
Apr 05
L21: Secure Coding (3) & Dynamic Analysis (1)
Slides Activity #10 ⏰ 04/12 @ 2PM HW5 ⏰ 04/25 @11:59PM
Week 13 Apr 10
No Class
Apr 12
L22: Dynamic Analysis (2)
Slides Activity #11 ⏰ 04/17 @ 2PM
Week 14 Apr 17
L23: Dynamic Analysis (3)
Slides Activity #12 ⏰ 04/19 @ 2PM
Apr 19
L24: Security Testing - Part 1
Slides Activity #13 ⏰ 04/24 @ 2PM
Week 15 Apr 24
L25: Testing - Part 2
Slides
Apr 26
L26: Project Presentations-1
Slides HW6 ⏰ 05/03 @11:59PM
Week 16 May 01
L27: Project Presentations-2
Slides
May 03
L28: Project Presentations-3
Slides
Coursework:

This class includes the following graded components:

  • Case Study: An in-depth investigation of security challenges experienced by a real software product. While in class you will be learning about security tactics, common weaknesses, and secure coding practices, in the case study you will see investigate how those concepts are applied (or not at all). The outcome is a technical report.
  • Seminar Presentation: Every student will select (or be assigned) one paper on a course-related topic. The student is to gain a detailed understand of the paper, and present it to the class. The student should highlight the motivation of the work, its novel contributions, any surprising findings and possible applications of the work. This also includes a critique which contains at least three strengths of the paper and at least three weaknesses of the paper.
  • Course Project: In lieu of examinations, this class will have a course project in which the students would be working throughout the semester. You are expected to work on the course project individually. Each student is expected to write a research paper by the end of the semester. The topic is to be negotiated with the instructor. Examples include: building a tool to support secure software engineering practices, or a survey paper of a software security related topic (typically involves surveying several research papers), or empirical studies, etc. The final report (10 pages of context, +2 pages of reference, +5 pages for appendixes) should be submitted by the end of the semester. All project-related documents (i.e., project proposal and project report) should use the IEEE conference publication format. If the paper is deemed publishable, the instructor will work with the student to make appropriate changes to the final report and submit the paper for publication.
  • Homeworks: Each lecture cover a different practice or tool. The homeworks are intended for the student to apply the studied concepts in class. Most of these homeworks are individual (i.e., unless specified otherwise, the homeworks should be individual submissions).
  • Attendance & In-Class Participation: Attendance and participation is required. Classes may also include short hands-on activities/exercises that are submitted during class or by the next class section. These also may be used as points towards attendance.

Your final course grade is computed according to the following breakdown:

Component Points
Case Study 20%
Homeworks 20%
Course Project 30%
Seminar Presentation 20%
Attendance & In-Class Participation 10%
Grading:

Grades are assigned as follows:

Grade Points Grade Points
Grade Points A >=94 A- >=90 and <94
B+ >=87 and <90 B >=84 and <87 B- >=80 and <84
C+ >=77 and <80 C >=74 and <77 C- >=70 and <74
D >=64 and <70 F <64

Any re-grade request shall be made by the regrade request deadline on Gradescope (i.e., no more than 5 days after the grades are posted). All the re-grade requests shall be made through gradescope, unless specified otherwise in class, via e-mail, or on feedback notes.

In-Class Activities & Attendance:
Students are expected to come to class and actively participate on discussion, asking questions as well as helping peers when appropriate (see Honor Code Below). Classes may include short hands-on activities/exercises that are submitted during class. These may be used as points towards attendance. Missing several lectures without a justifiable reason will incur points deduction. Only the scenarios listed in Section 3.1 of the Academic Code are accepted as justifiable reason to miss a class session. Please notice that, per this academic code: "For absences planned in advance, the student must inform the instructor no less than one week prior to the planned absence; and for unplanned absences resulting from injury or illness, the student must provide the instructor appropriate verification from a health services provider, as described in section 3.1.3.5, no later than two business days after the period of absence concludes."
Late Policy:

Deadlines are strictly enforced. There is a penalty of 15% for submissions up to 12hrs past the deadline. Submissions made more than 12hrs past the deadline are not accepted (i.e., they will be assigned 0). Please plan ahead your assignments.

HOWEVER...
Life Happens. We all lead densely-layered lives; therefore, one of my core values is leading with grace. As a result, I institute a “Life Clause”. Should you need it, you may invoke the “Life Clause” on TWO homeworks, and get a 2-day extension, no explanation required. To invoke a life clause, please fill out this request form by 5PM on the day of the homework's deadline. The TA will process the request within one business day and add the extension on Gradescope.

Notice: the life clause is only for homeworks.

  • No extensions are given to activities because they are meant to be low-stakes assignments that can help you stay on track and follow the course content. Giving extensions would defeat the purpose of these activities.
  • The project, case study, and seminar has hard deadlines and no extension will be given to any student.

To maintain fairness, the professor DOES NOT grant extensions on a case-by-case basis (i.e., the rules laid out in here applies to all students -- without exceptions).

Honor Code:
Students are expected to abide by the principles of intellectual honesty and academic integrity.

It is cheating to copy, to allow another person to copy, all or part of an exam or an assignment, or to fake program output. It is also a violation of the Undergraduate Academic Code of Honor to observe and then fail to report academic dishonesty. You are responsible for the security and integrity of your own work.

For the individual assignments in this class, you may discuss with other students and consult printed and online resources. You may quote from books and online sources as long as you cite them properly. However, you may not look at another student's solution, and you may not copy any significant portions of other's solutions.

For the assignments made in groups, the same rules apply. The main difference is that you are allowed -- and expected -- to discuss specifics of the solution for your submission with your team members (i.e., students in your group). However, the group may not copy a solution from elsewhere (i.e., another team, book, tutorial, etc.).

Notice that since this class does not have an exam, and instead, has a large course project, any honor code violation to the project will be reported as a major violation.

The "Pencils Down" Rule: You may communicate about homework with your classmates at a high-level, give general advice, and chat about common problems. You may not communicate specific knowledge such as problem solutions or steps or planning documents. A good litmus test is if you would need to write it down to communicate or remember something, it is off limits. Seek homework help from the Professor or the TAs instead.

The following table summarizes how you may work with other students and use print/online sources:

Resources Solutions AI Assistant Tools (ex: ChatGPT, GitHub Copilot, etc)
Consulting Allowed Not Allowed ⚠️ Allowed only under specific conditions (see below)
Copying ⚠️ Cite Not Allowed

See the CSE Guide to the Honor Code for definitions of the above terms.

Policies on the Use of Text/Code Generation Tools (ex: ChatGPT, GitHub Copilot, etc.)

The use of text generation tools (ex: ChatGPT) or code generation tools (ex: GitHub Copilot) introduces authorship issues. As expressed above, this course expects that submitted assignments are a result of a student's individual effort (or group effort, for those assignments submitted in groups). Text generation tools can include not only factual errors but also may plagiarize other works. In light of these concerns, this class will follow similar guidelines from the ACL 2023 policy on AI writing assistance. Thus, these AI tools can only be only used under the conditions outlined below. Notice that the text in blue is from the ACL 2023 policy, whereas the text written in black is what has been tailored to our class setting.

  • ✅ Allowed Assistance purely with the language of the paper. When generative models are used for paraphrasing or polishing the author’s original content, rather than for suggesting new content - they are similar to tools like Grammarly, spell checkers, dictionary and synonym tools, which have all been perfectly acceptable for years. Thus, using these AI tools solely to assist with the writing is not an honor code violation.
  • ✅ Allowed Short-form input assistance. Even though predictive keyboards or tools like smart compose in Google Docs are also powered by generative language models, nobody objected to them, since hardly anyone would try to use them to generate a long, unique and coherent text: it would simply not be practical. Thus, using these AI tools solely to autocomplete small pieces of text/code (i.e., words, variable names, etc) is not an honor code violation.
  • ✅ Allowed but use with caution ⚠️ Literature search. Generative text models may be used as search assistants, e.g. to identify relevant literature. However, we expect the authors to read and discuss such references, just like the references identified by a regular search engine or a semantic literature recommendation tool. The usual requirements for citation accuracy and thoroughness of literature reviews apply; beware of the possible biases in suggested citations. That is, you can use AI assistant tools to help you find relevant related work, but you still need to manually vet them, and cite them accordingly.
  • ❌ Not AllowedLow-novelty text. Some authors may feel that describing widely known concepts is a waste of their time and can be automated. Since this is a class where the main goal is to learn, students must describe and cite widely known concepts on their own. This process should not be automated by writing assistants.
  • ❌ Not AllowedNew ideas. If the model outputs read to the authors as new research ideas, that would deserve co-authorship or acknowledgement from a human colleague, and that the authors then developed themselves (e.g., topics to discuss, framing of the problem), then the text/idea should not be used for any assignment in this class.
  • ❌ Not AllowedNew ideas + new text: a contributor of both ideas and their execution seems to us like the definition of a co-author, which the models cannot be. Therefore, it should not be used for this purpose in this class.
  • ✅ Allowed with disclosure ⚠️ Code Generation for "Common Code": If a code generation tool (GitHub Copilot) is used similarly to StackOverflow, i.e., to understand how to write "common code" in a specific programming language (ex: how to open a file in python), that is allowed. However, the submission must disclose this use by including a comment near the generated code indicating the use of GitHub Copilot (or other tool).

Per stated in Section 2.4.1 of the Undergraduate Academic Code of Honor "Faculty and anyone else responsible for teaching or assisting in a course will not tolerate academic dishonesty.". Therefore, if an instructor sees behavior that is academically dishonest, that professor is required to file either an Honor Code Violation Report (HCVR) or a formal report to the College of Engineering Honesty Committee.

This course will be recorded using Panopto. This system allows us to automatically record and distribute lectures in a secure environment. You can watch these recordings anytime, anywhere, on any device. In Canvas, look for the "Panopto" tool on the left hand side of the course. These recordings are jointly copyrighted by the University of Notre Dame and your instructor. Posting them to other websites (including YouTube, Facebook, SnapChat, etc.) or elsewhere without express, written permission may result in disciplinary action and possible civil prosecution.

Please notice that the lecture recording is intended to enhance the in-person experience rather than replacing it. Moreover, recordings may not always be reliable due to connectivity issues, etc. Thus, you are still required to attend the lectures in-person and attendance is one of the graded components). It is your responsibility to catch up with materials after missing the lectures.