Projenin amacı

Bu projede, seçtiğiniz bir uygulamayı sertifikasyon sürecinden geçiyormuş gibi tasarlayıp
geliştireceksiniz:

• bir C++ konsol uygulaması
• onun güvenliğini sağlayan bir dinamik kütüphane (DLL/.so)

Amaç: dönem boyunca öğrendiğiniz güvenlik yöntemlerini tek bir üründe birleştirmek ve hepsini bir
güvenlik kılavuzuyla (S0–S17) belgelemek.

Kontrol noktaları

2. Değerlendirme yapısı — ağırlıklar

• Vize = 0,6·RAP1 + 0,4·Quiz-1
• Final = 0,7·RAP2 + 0,3·Quiz-2
• Başarı notu = 0,4·Vize + 0,6·Final

RAP1 (7. hafta): ürünün ilk yarısı (S2–S5 + temel korumalar)
RAP2 (15. hafta): tam ürün + S16 sonuçları

Şablon deposu

Şablon: ucoruh/cpp-cmake-ctest-template

• Fork etmeyin: herkese açık bir deponun fork'u özel yapılamaz
• Şablon sayfasında Use this template → Create a new repository; depo adı cen429-2026-2027-NNN-ad-soyad-cpp, Private
• Ders sorumlusunu (ucoruh) ve varsa takım arkadaşınızı işbirlikçi (collaborator) olarak ekleyin

!!! tip "Şablonu tam kullanın"
Şablon; derleme, CTest ile birim testi, dokümantasyon üretimi, test/dokümantasyon kapsamı ölçümü ve
paketlemeyi sağlar. Şablon standartlarına uymayan teslimler kabul edilmez. Sürüm (release) üretin; sürüm
kimliği ve özet değerlerini kaydedin.

Projenizi yerelde gösterme

GitHub Free'de özel (private) bir depoda GitHub Pages sitesi açılmaz. Her şeyi kendi bilgisayarınızda gösterirsiniz:

• 7-build-all-windows.bat (Linux/WSL: 7-build-all-linux.sh) derler, test eder, bütün raporları üretir
• 9-open-site-windows.bat (Linux: 9-open-site-linux.sh) tam siteyi http://localhost adresinde açar: bütün raporlar (testler, kod kapsamı, dokümantasyon kapsamı; Windows ve Linux) ve API belgeleri
• release/ bütün çıktıları tutar: uygulama/exe, kütüphane, raporlar, API belgeleri, site.zip, kaynak kod, ASSETS.md, SHA256SUMS.txt
• 10-release-windows.bat (Linux: 10-release-linux.sh) GitHub Release'i oluşturur; sürümler özel depolarda da çalışır

Gösterim kontrol listesi

Gösterimde sırayla neyi açıp göstereceğiniz:

1. Yerel sitenin ana sayfası (9-open-site-..., http://localhost adresinde).
2. Her rapor sayfası: testler, kod kapsamı, dokümantasyon kapsamı (Windows ve Linux).
3. API belgeleri.
4. release/ klasörünün içeriği.
5. Uygulamayı release arşivinden çalıştırma.
6. Özel deponuzun GitHub Release sayfası (ders sorumlusu collaborator olarak ekli).

Proje düzeni

• lib/ — güvenlik kütüphanesi (DLL/.so): kriptografi, RASP, kod gizleme, veri koruma fonksiyonları
• app/ — konsol uygulaması: kütüphaneyi kullanan kullanıcı arayüzü
• test/ — CTest birim testleri (kripto ve koruma fonksiyonları)

Geliştirme ortamı kurulumu ve ön bilgi için bkz. Ön gereksinimler sayfası.

4. Konu seçimi

Proje konuları rehber sayfasının sonundaki Ek — Proje konuları listesi bölümündedir (100 konu).

Her konu kutusunda:

• Uygulamanın kısa tanımı
• Temel özellikleri
• Korunacak varlıklar
• O konuda öne çıkan güvenlik gereksinimleri

Nasıl seçilir?

1. Rehber sayfasının sonundaki listeyi inceleyin ve bir konu seçin
2. Seçiminizi paylaşılan takım ve konu listesine yazın (bağlantı Teams duyurusunda) — bir konuyu yalnız bir takım
   alabilir, tabloya ilk yazan takım alır
3. Proje planınızla birlikte ders sorumlusuna onaylatın; onaydan sonra konu değiştirilmez

Konu seçiminde kurallar

• 5. bölümdeki 15 gereksinimin hepsi her projede geçerlidir; konu kutusundaki "öne çıkan
     gereksinimler" o konuda en doğal ve en çok puan getiren uygulama yerlerini gösterir
• Listede olmayan bir fikriniz varsa, ders sorumlusunun onayıyla seçebilirsiniz
• Bu dersi tekrar alıyorsanız önceki projenizden farklı bir konu seçin

5.1 Vize kapsamı (RAP1)

4.1 Geliştirme ortamı güvenliği

Hafta 1, 12 · S13

• Yazılım geliştirme akışı ve değişiklik yönetimi (temel çizgi → talep → sınıflandırma → onay →
  yayın → doğrulama)
• Git ile sürüm kontrolü; erişim kaydı; imzalı sürüm
• Geliştirme bilgisayarı/sunucu güvenliği (kısa politika)

4.2 Kullanımdaki veri güvenliği

Hafta 3, 6 · S7

• Bellekteki hassas veri kullanımdan sonra güvenli silinir (memset_s benzeri)
• Çalışma zamanı veri koruması (gölge kopya/bütünlük — 6. hafta)

4.3 Aktarımdaki veri güvenliği

Hafta 3, 10 · S6, S11

• TLS 1.3; sertifika zinciri + SAN doğrulaması; sabitleme (pinning) + yedek pin
• Şifrelenmiş oturum anahtarı; cihaz/sürüm bağlama; bütünlük + kimlik doğrulama; sunucu
  doğrulama kodu

4.4 Beklemedeki veri güvenliği

Hafta 3, 10, 11 · S8

• Dosya/DB şifreleme AEAD (AES-GCM); nonce tekrarsız
• Hassas anahtarlar için whitebox ya da SoftHSM/PKCS#11; kararın gerekçesi (11. hafta)

4.8 Arayüz tanımları ve korunması

Hafta 1, 4 · S3, S6

• Tüm arayüzler erişim kontrolü + kimlik doğrulama ile korunur
• Girdi güven sınırında doğrulanır

4.9 Kod sağlamlaştırma

Hafta 4, 9, 14 · S9

• Opak döngü/yüklem, ad/dosya/dize/aritmetik gizleme, opak boolean, sahte işlem/ölü dal
• Kontrol akışı düzleştirme + rastgele çıkış, sürümde log kapalı
• Maliyeti ölçün (9/14. hafta demoları)

4.10 RASP

Hafta 6 · S10

• Checksum bütünlük denetimi, çağıran uygulama hash/imza doğrulaması
• Kök/emülatör tespiti, hook/anti-debug
• Kurcalama (tamper) tespiti + yanıt, kontrol akışı sayacı

4.11 Bellek koruması

Hafta 4 · S9

• Derleyici/OS korumaları (yığın koruyucu, PIE, RELRO, NX, CFI)
• Hassas veri kullanım sonrası temizlenir

5.2 Final kapsamı (RAP2)

4.5 Statik varlıkların korunması

Hafta 1, 4, 9 · S5, S9

Gizli anahtarlar, özet değerleri, kaynak kodu, kaynaklar: şifreleme + erişim kontrolü + gizleme

4.6 Dinamik varlıkların korunması

Hafta 3, 6 · S5, S8

Cihaz/uygulama parmak izleri, oturum verileri, dinamik anahtarlar şifrelenir

4.7 Varlık yönetimi

Hafta 1, 3, 13 · S5

Her varlık için: ad, açıklama, konum (tablo/sütun), kaynak, boyut, oluşturma/silme zamanı, varsayılan,
koruma şeması (C/I/I+)

4.12 Kriptografi ve sertifikalar

Hafta 3, 10 · S8, S11

• Doğru algoritma/kip/dolgu
• İmza doğrulaması (==1, sürüm kapsamı)
• SSL/TLS + pinning + karşılıklı kimlik doğrulama

4.13 Sertifikasyon ve sızma testi planı

Hafta 12, 13 · S16, S14, S17

• Standart eşlemesi (ETSI/EMVCo/GSMA/PCI/MASVS)
• Sızma testi planı (kapsam, kurallar, yöntem, test kartı) ve sonuçları
• Saldırı potansiyeli + CVSS

4.14 Binary uygulama koruması

Hafta 6, 9, 11, 14 · S9, S10, S15

• Tespit (checksum, anti-debug, emülatör)
• Savunma (gizleme, dize/kaynak şifreleme, çağrı gizleme)
• Caydırma (yanıt/kapanma politikası)

4.15 OWASP ve derleme/dağıtım hattı

Hafta 5, 14 · S13, S15

• OWASP MASVS/ASVS ilkeleri
• SBOM (CycloneDX) + bağımlılık taraması
• Gizleme + imzalama içeren derleme hattı

5.3 Her iki kontrolde ortak kurallar

• Değerler sentetik olmalı; depoda gerçek sır, anahtar ya da kişisel veri bulunmaz
• Her gereksinim maddesi kod içinde görülebilir olmalı ve güvenlik kılavuzunun ilgili S bölümünde
  belgelenmelidir; belgelenmeyen bir uygulama karşılanmamış sayılır
• Bir gereksinim karşılanamıyorsa gerekçesiyle S14'e yazılır; sessizce atlanamaz
• Uygulama yalnız kendi bilgisayarınızda (localhost) çalışır; başka bir sisteme veya veriye zarar vermez

Tek ZIP arşivi yapısı

cen429-2026-2027-NNN-midterm.zip                  # final: cen429-2026-2027-NNN-final.zip
└── cen429-2026-2027-NNN-ad-soyad-cpp/            # GitHub deposunun klonu
    ├── lib/                              # güvenlik kütüphanesi (DLL/.so)
    ├── app/                              # konsol uygulaması
    ├── test/                             # CTest birim testleri
    ├── docs/                             # Doxygen çıktısı
    ├── security-guide/                   # S0–S17 güvenlik kılavuzu
    ├── sbom/                             # CycloneDX SBOM (final)
    ├── test-coverage/                    # CTest kapsam raporu
    └── README.md

Adlandırma

• Depo: cen429-2026-2027-NNN-ad-soyad-cpp
• Arşiv: cen429-2026-2027-NNN-midterm.zip / cen429-2026-2027-NNN-final.zip
• Güvenlik kılavuzu dosyası: cen429-2026-2027-NNN-security-guide.docx

Rapor/kılavuzun kapak sayfasında GitHub deposu bağlantısı bulunur.

7. Takım çalışması (1/2)

• GitHub Flow: main dalı korumalıdır, doğrudan commit yapılmaz; her iş için ayrı bir özellik dalı
  (feature branch) açılır, birleştirme çekme isteği (pull request) ile yapılır
• Commit mesajı kuralı: Conventional Commits, ör.
  feat(crypto): add AES-GCM wrapper, fix(rasp): correct debugger detection

7. Takım çalışması (2/2)

• Çekme isteği + inceleme: her PR en az bir takım arkadaşınca incelenir (code review)
• Issues + Projects panosu: Backlog → In Progress → In Review → Done
• CI yeşil olmadan birleştirme yok
• Sürüm etiketleri: vize midterm-v1.0, final final-v1.0
• "Bitti" tanımı: derleniyor · birim testi var · kapsam düşmedi · PR onaylandı · CI yeşil · kılavuz
  güncellendi

8.1 Başarı düzeyleri

9. Kabul koşulları

Teslim kabul edilmez, eğer…

• GitHub deposu yoksa, özel (private) değilse ya da takım üyelerinin commit'i görünmüyorsa
• gereksinimlerin karşılanma oranı asgari eşiğin altındaysa
• depoda ya da arşivde binary dosyalar (derlenmiş .exe/.dll/.so) varsa
• sürüm (release) üretilmemişse, uygulama Windows ya da WSL/Linux'ta derlenmiyor/çalışmıyorsa
• depoda gerçek sır, anahtar ya da kişisel veri varsa, intihal tespit edilmişse

10. Gösterimde sorulacaklar (1/2)

• Git/GitHub: Depoyu şablondan doğru adla oluşturdunuz mu? Depo özel mi, ders sorumlusu işbirlikçi mi? Her
  iki üyenin de commit'i var mı?
• Kurulum-derleme: Uygulamayı ve kütüphaneyi Windows'ta ve WSL/Linux'ta derleyin; lib/app/test
  ayrımını gösterin

10. Gösterimde sorulacaklar (2/2)

• Konu (satır satır): Seçtiğiniz güvenlik gereksinimini kodda satır satır açıklayın
• Test ve belge: Birim testlerini ve kapsam raporunu açın; kılavuzun ilgili S bölümünü gösterin
• Dosya/veri işlemleri: Bir kayıt ekleyin, programı kapatıp yeniden açın, verinin şifreli geldiğini
  gösterin
• Programlama: Bellek yönetimi, işaretçiler, derleyici/OS korumaları, hata ayıklayıcıda inceleme

11. Mesleki sorumluluk ve akademik dürüstlük

• Teslim ettiğiniz her satırı açıklayabilmelisiniz
• Başkasının kodunu/metnini kullandıysanız kaynağını belirtin
• Bütün örnekler ve değerler sentetik olmalıdır
• İntihal ve izinsiz kopyalama başarısızlık nedenidir
• Hayalet commit (başkası adına commit atmak) intihal sayılır

Güvenli ve yasal çerçeve

Sızma testi yalnız kendi projeniz üzerinde yapılır.

Örnekler ve değerler sentetik olmalı; hiçbir gerçek sır, anahtar ya da kişisel veri depoya girmemeli.

Uygulamanız başkasının sistemine/verisine zarar vermemeli.

12. Sık sorulan sorular (1/2)

Takımı tek başıma kurabilir miyim?
Evet. Takım en çok 5 kişidir; takımlar 3. haftanın sonunda (04.10.2026) kesinleşir.

Konumu onaydan sonra değiştirebilir miyim?
Hayır. Onaydan sonra konu değişmez.

12. Sık sorulan sorular (2/2)

Bir gereksinimi tam karşılayamazsam ne olur?
S14'e gerekçenizi yazarak devredebilir ya da kapsam dışı bırakabilirsiniz.

RAP1'de eksik kalan bir gereksinim RAP2'de tamamlanabilir mi?
Evet, ama RAP1 puanı gösterim anındaki duruma göre verilir ve güncellenmez.

Geç teslim kabul edilir mi?
Hayır — izlencedeki kurallar geçerlidir.

Örnek konu — 01

Çevrimdışı Ödeme Cüzdanı

Kullanıcının internet olmadan küçük ödemeler yapabildiği bir cüzdan. Bakiye ve tek kullanımlık ödeme
anahtarları cihazda durur; bağlantı gelince işlemler sunucuyla eşleşir.

Öne çıkan gereksinimler: 4.4 Beklemedeki veri (AES-GCM + SoftHSM), 4.3 Aktarımdaki veri (TLS 1.3 +
sabitleme), 4.10 RASP (hata ayıklayıcı algılanınca anahtar silinir)

Örnek konu — 26

Kişisel Sağlık Kaydı Kasası

Kullanıcının sentetik tanı, ilaç ve alerji kayıtlarını yerel bir kasada tuttuğu uygulama. Saldırgan,
cihazı ele geçiren ya da kaybolan cihazı bulan kişidir.

Öne çıkan gereksinimler: 4.4 Beklemedeki veri (SQLite + AES-GCM + SoftHSM), 4.2 Kullanımdaki veri
(sınırlı süre bellekte açık), 4.11 Bellek koruması (görüntülenen kayıt kapatılınca silinir)

Tam liste nerede?

Kalan 98 konu, her biri aynı biçimde (kısa tanım, temel özellikler, korunacak varlıklar, öne çıkan
gereksinimler) Proje Rehberi sayfasının sonundaki Ek — Proje konuları listesi bölümündedir.

ucoruh.github.io/cen429-secure-programming/project-guide/