Secure Software Architecture
- Code: LTAT.05.044 (6 EAP)
- Language: English
- Lectures: Fridays 12:15-14:00, Narva mnt 18 - 1021
- Practical sessions: Fridays 14:15-16:00, Narva mnt 18 - 2045
- Lecturers: Eduardo Ribas Brito, Margus Freudenthal, Andres Ojamaa, Mart Oruaas, Ahto Truu
Secure Software Architecture teaches software architecture with an explicit focus on security. The course is about architectural decision-making, documentation, trade-off analysis, and security reasoning for modern distributed software systems.
Students work in teams on a semester-long architecture project. The goal is not to implement production code. The goal is to produce a coherent architecture package that could guide an implementation team: diagrams, decision records, interface specifications, risk analysis, threat modeling, and deployment/operations reasoning.
Learning outcomes
After completing the course, students should be able to:
- identify architectural drivers, quality attributes, constraints, and security goals;
- produce architecture documentation using appropriate views, including C4-style diagrams;
- design identity, authentication, authorization, and access-control mechanisms for distributed systems;
- reason about distributed systems trade-offs involving consistency, availability, fault tolerance, and security;
- design stable and evolvable APIs or event interfaces;
- apply security requirements, threat modeling, and architectural risk analysis to architecture work;
- relate architecture to deployment, observability, recovery, and incident response concerns;
- explain and defend architecture decisions and trade-offs.
Course format
- Weekly lecture.
- Weekly practical project session.
- Project checkpoint presentations.
- Final architecture package.
- Oral exam.
Practical sessions are working sessions where students apply the lecture topic to their team project and receive instructor feedback.
Project
The course project is the architecture of a security-critical distributed software system.
The default scenario is a Citizen Services Portal: a single digital entry point for residents to access government services. The system integrates multiple agencies and registries, supports strong digital identity, and must be highly available, auditable, privacy-preserving, and evolvable.
Teams produce architecture and design documentation. No production implementation is required.
Main final artifacts:
- architecture description;
- C4 context, container, and selected component views;
- key architectural mechanisms;
- API specifications for important interfaces;
- architecture decision records;
- risk register;
- security goals, trust boundaries, and threat model;
- deployment and observability plan.
Grading
| Component | Weight |
|---|---|
| Project final documentation | 50% |
| Project presentations | 15% |
| Oral exam | 35% |
Weekly schedule
Lectures take place on Fridays 12:15-14:00 in Narva mnt 18 - 1021. Practical sessions take place on Fridays 14:15-16:00 in Narva mnt 18 - 2045.
| Week | Date | Lecture focus | Practical session focus |
|---|---|---|---|
| 1 | 04.09 | Course introduction, software architecture, architectural drivers | Team formation, GitHub fork setup, initial discovery |
| 2 | 11.09 | Architecture in the process, risk-based development, Conway's law, microservices | Initial risk register and iteration plan |
| 3 | 18.09 | Architectural requirements, quality attributes, security goals | Business goals, NFRs, quality attribute scenarios |
| 4 | 25.09 | Describing architecture, viewpoints, C4, documentation quality | C4 context and container diagrams, documentation skeleton |
| 5 | 02.10 | Distributed systems I: scaling, consistency, transactions | Data ownership, consistency model, failure modes |
| 6 | 09.10 | Identity and naming in distributed systems | Identity model, identifiers, entity lifecycle |
| 7 | 16.10 | Authentication, authorization, access control, delegation | AuthN/AuthZ architecture, access-control matrix, threat sketches |
| 8 | 23.10 | Distributed systems II: distributed security and feature interaction | Threat modeling distributed features and invariants |
| 9 | 30.10 | Interface design I: API principles, leaky abstractions, HTTP contracts | Key API specs and event contracts |
| 10 | 06.11 | Interface design II: evolvability and API security | Interface change request with compatibility constraints |
| 11 | 13.11 | Security process, touchpoints, architectural risk analysis | ARA practice, mitigations, roadmap |
| 12 | 20.11 | Systems architecture I: deployment, environments, cloud | Deployment model, trust boundaries, SLO drafts |
| 13 | 27.11 | Systems architecture II: observability, backups, recovery | Metrics, logs, traces, backup and restore, incident playbook |
| 14 | 04.12 | Systems evolution: technical debt, migrations, deprecation | Debt register, evolution plan, risk reassessment |
| 15 | 11.12 | Guest lecture: supply chain security / SBOM / attestations | Apply guest topic to the project |
| 16 | 18.12 | Final presentations and oral exam preparation | Final package submission and cross-team review |
Contact
For course content and organizational questions, contact the course lecturers.
For technical problems with the Courses environment, contact the Courses support channel.