SLA ve güvenlik politikaları

Güvenlik SLA’ları neden önemlidir?

SLA (Service Level Agreement), bir güvenlik açığının keşfedilmesinden çözüme ulaşmasına kadar geçen maksimum süreyi belirler.

Sınavda SLA bilgisi iki bağlamda çıkar:

1. Severity bazlı varsayılan SLA hedefleri
2. Security campaigns’deki deadline mekanizması

Severity bazlı SLA örneği

Severity	Tipik SLA hedef
Critical	24–48 saat
High	7 gün
Medium	30 gün
Low	90 gün (veya sonraki sprint)

Bu değerler standart değildir — her organizasyon kendi politikasını belirler. GitHub GHAS bu SLA’ları otomatik uygulamaz; security campaigns ve harici izleme araçlarıyla takip edilir.

SECURITY.md — güvenlik politikası dosyası

.github/SECURITY.md veya repo kökünde SECURITY.md dosyası, güvenlik açığı bildirimi için standart bir yer sağlar.

# Security Policy

## Supported Versions

| Version | Supported |
|---------|-----------|
| 2.x     | ✓         |
| 1.x     | ✗         |

## Reporting a Vulnerability

Bu repoda güvenlik açığı bulduysanız, lütfen
security@mycompany.com adresine e-posta gönderin.

Kamuya açıklamadan önce 90 gün içinde yanıt vereceğiz.

GitHub bu dosyayı repo’nun Security sekmesinde ayrıca gösterir.

Private vulnerability reporting

GitHub’ın private vulnerability reporting özelliği, harici araştırmacıların güvenlik açıklarını gizli olarak bildirmesini sağlar:

Repo → Security → Report a vulnerability (harici kullanıcı için)
Repo → Settings → Security → Private vulnerability reporting → Enable

Bildirilen açıklar Security Advisories olarak oluşturulur ve yalnızca repo güvenlik ekibi görür.

Security policy — enterprise düzeyi

Enterprise admin, tüm organizasyonlar için güvenlik gereksinimlerini policy olarak zorunlu kılabilir:

Enterprise → Policies → Code security → Require:
  - Secret scanning
  - Code scanning
  - Dependabot alerts
  - Push protection

Bu policy’ler, org owner’ların bu özellikleri devre dışı bırakmasını engeller.

Security campaigns ve SLA

Security campaigns, belirli alert türleri için deadline ve hedef belirler:

Org → Security → Campaigns → New campaign
  → Alert filter: severity=high, type=code-scanning
  → Target: tüm repoları 30 gün içinde temizle
  → Assign: ilgili takımlara bildirim

Campaign ilerleme görünümü, hangi repo’ların geride kaldığını gösterir.

Sıravda policy soruları

“Tüm repolarda push protection zorunlu olsun istiyoruz, individual org owner’lar kapatmasın.” → Enterprise policy → Require push protection.

“Geliştiricilere güvenlik açığı bildirimi için bir kanal sağlamak istiyoruz.” → SECURITY.md + private vulnerability reporting.

Sırada ne var?

Security overview dashboard — organizasyon genelinde güvenlik durumunu tek ekranda izlemek.