Software Security, Autumn 2022

This course is taught by Erik Poll with the help of Seyed Benham Andarzian and Cristian Daniele.

Make sure you are registered in Osiris, which will then also register you in Brightspace. If you don't log in to Brightspace often, configure your Brightspace account to have announcements forwarded to you by email, as you are expected to check these announcements on a regular/daily basis.


Basic programming skills, incl. familiarity with C and some standard OO language like Java or C#. In more detail:


Software is the most important root cause behind most IT security problems: things can get hacked because they contain software! This course addresses two questions: Techniques to prevent or detect problems include threat modeling, checklists and coding standards, code reviews, "safe" programming languages, LangSec (language-theoretic security) and more generally organising input and output handliing in a structured way, fuzzing and other forms of security testing (aka DAST), static analysis tools and source code analyzers (aka SAST), information flow analysis (incl. tainting), and program verification as the most extreme form of static analysis.

The focus of this course is not on pen-testing or hacking to find vulnerabilities, as in the bachelor courses 'Hacking in C' and 'Web Security'. Instead the focus is on (addressing) the underlying causes and general techniques to improve software security.

Lectures & obligatory reading material

Lectures: Fridays 10:30-12:15 in MM 00.035 (Maria Montessori building), starting in November in LIN 4.

The description below will be updated as we go along, with slides and pointers to papers. The obligatory reading material and exam material for the course includes the slides, some academic research papers listed below, and the following textbook material:

plus the additional scientific papers listed below.

day slides Mandatory reading & mini-assignments
Sept 9
  • To read: page 1-10 & 27-30 of Secure Software Lifecycle, CyBok chapter by Williams, 2019.
    Page 6-10 are about Microsoft SDL (Security Development Lifecycle): Microsoft's website about SLD also provides a summary of the 12 practices of SDL with pointers to much more information. Page 11-26 discuss other approaches, but the basic ingredients are always the same.
  • To do: have a look at the latest US-CERT Bulletin and the CVE Twitter feed to get a feel for the scale of software security problems.
  • To do: search the CVE list or NIST's Vulnerability Database for flaws in the browser you are using to view this webpage and for the PDF viewer you are using to look at the slides. (These use the same list of vulnerabilities, but NIST's webpage has better search options.) For some of the vulnerabilities, check how the CVSS score was determined. You can also search for known flaws in the other applications or operating systems that you commonly use, and maybe double-check that these are automatically patched.
Sept 15
Sept 16
Sept 23

1st assignment: Static analysis with PREfast

      Feedback on PREfast solutions
Sept 30
Group fuzzing project     Deadline for making group and picking project: ASAP, ideally Oct 6.
    Deadline for the final report: Nov 30
Oct 7
Oct 7
  • Guest lecture: Technical Penetration Testing by Francisco Dominguez of Hunt and Hacket, 13:30-15:15 in LIN 4
      (slides in Brightspace)
Oct 14
Oct 21
Oct 21
  • Guest lecture: Automated Vulnerability testing by Frans van Buul of Microfocus, 13:30-15:15 in LIN 4
      (slides in Brightspace)
Oct 28 & Nov 4: no lectures (midterm break/exam period) The lecture-free period is a good time to read the CyBok chapter on Software Security, also listed at mandatory reading material.
Nov 11
Nov 18
Nov 25 Secure input handling (2):
Dec 2
Dec 9
Dec 16
Dec 23
  • no lecture
Jan ??
  • Exam
The exam is closed book, and covers the material treated in class (and in the slides), the course lecture notes, the papers listed above, and the projects.
Mock exam


The course will be graded based on a written exam. The group project work can earn you a bonus point. The other exercises, to be done individually or in pairs, are not graded but are mandatory. You MUST seriously participate in the project and do all the other exercises to take the exam, and there are not options to resit these.

The exam will cover the material presented in the lectures, the obligatory literature listed below, and the project work. The exam is closed book, ie. you cannot bring copies of slides, papers etc to the exam. You're not expected to be able to reproduce technical details from the papers, but you should be able to explain the core ideas. I will only ask about technical details from the papers that have been discussed in the lectures (and are covered by the slides). You are expected to be able to spot simple buffer overflow problems given some hints, but are not expected to spot tricky ones even with hints.

Optional background reading

For additional background info I can recommend: