Fri Oct 16 2026
Hazırsan başlayalım; birkaç adımda güvenli erişimi nasıl hayata geçirebileceğimizi konuşacağız.
Neden otomasyon?
🛠 Kullanacağımız araçlar
Şimdi, basit bir GitHub Actions pipeline'ı üzerinde pratik yapalım. Aşağıda .github/workflows/security-scan.yml dosyasını görüyoruz:
name: Depolama Güvenlik Taraması
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
schedule:
- cron: '0 2 * * 1' # Haftada bir, pazartesi günü gece 02:00
jobs:
trivy-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Docker imajını oluştur
run: |
docker build -t myapp:${{ github.sha }} .
- name: Trivy ile güvenlik açığını tara
uses: aquasecurity/trivy-action@master
with:
image-ref: 'myapp:${{ github.sha }}'
format: 'sarif'
output: 'trivy-results.sarif'
- name: OpenJDK ile sonuçları yükler
if: always()
uses: github/codeql-action/upload-sarif@v2
with:
sarif_file: 'trivy-results.sarif'
Bu sayede ne oluyor?
🔁 Depolama alanındaki ek adımlar
pre-commit kuralını kullanarak *.env gibi gizli bilgileri commit etmeyi engelle.pre-commit, post-checkout) ile node_modules/ gibi dökümanları depoda tutmayı engelle.✅ Basit adımla güvenlik onayını nasıl takip edebiliriz?
security-scan.yml dosyasını repoya ekle..pre-commit-config.yaml dosyası ile pre-commit ve trivy araçlarını kur.post-checkout kancasını kur, örneğin bir depolama alanı temizleme komutu ile.🎯 Sizin için temel sonuç
❗️ Unutmayın
📦 Tamam, hemen başlayalım.
.github/workflows/security-scan.yml dosyasını oluşturun, komutları kopyalayın ve depoda bir commit oluşturun. İşte bu kadar.Hadi hemen başlayalım, sen de bir kanalla güvenli bir repo kullanmaya başlayabilirsin! 🚀
Hadi başlayalım! 🛠️ Güvenlik ile hijyen süreçlerini manuel olarak yönetmek, kulağa basit gelebilir, ama aslında hızlı bir şekilde geri dönülemez hatalara yol açabilir. Konuya bir örnek üzerinden girelim ve otomasyonun neden bir kurtarıcı olduğunu görelim.
Bir geliştirici bir dosya işleme aracı eklemek istediğini varsayalım. Yeni içerik için bir dizin eklemesi gerekirken yanlışlıkla kod deposuna bir yabancı dizin ekliyor.
# .env
APP_HOME=/opt/myapp
# YABANCI DİZİN (karışıklık yaratıyor!)
UNEXPECTED_DIR=/etc/cron.d/bad_script
❗️ Ne oluyor burada? Yazılım geliştiriciler yanlışlıkla hassas bir dizin için yazılmış
.envdosyasına bir değer ekleyebilir. Kaydedildiğinde, sistem artık dış kaynaklara (örneğin/etc/cron.d/bad_script) erişmeye çalışır ve bu da yetkilendirme hatası ile yetkisiz komut yürütmelerine neden olur.
#!/usr/bin/env bash
set -euo pipefail
# Hassas dizinleri /etc ve /var gibi dışe taşımak için tarama yap
if [[ "$APP_HOME" == /* && ! "$APP_HOME" =~ ^/opt ]]; then
echo "⚠️ Dış dizine erişim riski tespit edildi: $APP_HOME"
exit 1
fi
# .env dosyasındaki tüm değişkenleri tarama
if grep -Riq '^[A-Z_]+=[^ ]+$' .env 2>/dev/null; then
:
fi
# Secret Scanner'ı çalıştırma
npm run secret-scan || true
echo "✅ Güvenlik kontrolü tamamlandı"
Nasıl çalışıyor? Script, otomatik bir tarama, config validation, ve secret scanner çalıştırarak dosya kaydedilmeden önce yanlışlıkla eklenmiş dizinleri erken bir aşamada yakalar. Geliştirici hemen geri bildirim alır ve bu da manuel denetimleri önler.
Bu yüzden, güvenlik otomasyonunu ayağınıza getiren birkaç script çiftinden daha iyi bir yatırım yapamazsınız; bu, aynı zamanda organizasyonunuzu istenen maliyetlerden ve stres anlarından koruyan sürekli çalışan bir güvenlik ekibidir. 🚀
Hazırsan başlayalım! 🎯 Bir kurumsal hesap için GitHub App oluşturup izinlerini nasıl ayarlayacağımıza göz atalım. Bunu, GitHub Actions'ta kullanılabilecek güvenli bir token ile yapacağız.
name: Kurumsal Erişim Uygulaması
description: Depolara güvenli erişim sağlayan bir yardımcı uygulama.
url: https://github.com/your-org/corporate-access-app
environments:
- node_id: "ORGID" # Kurumsal node ID'niz
repo_sizes:
- access: limited
repositories:
- repo-owner/repo-name
- repo-owner/another-repo
permissions:
contents: read
issues: write
pull_requests: write
metadata: read
events:
- push
- issues
- pull_request
Nasıl çalışıyor? name, description ve url temel bilgiler.
environments→ kurulu bir kurumsal kimlik.repo_sizes.access: limitedverepositoriesbir listesi, izin verdiğimiz spesifik depoları tanımlar.permissionsblokundacontents: readvs. gibi key: value çiftleri ile hangi izinlerin verileceği belirlenir.events→ uygulamanın uyarılmak istediği GitHub aktiviteleri.
Aşağıda, depolardan birine erişen ve bu erişimi github-app-token aracılığıyla sağlamaya çalışan basit bir workflow.yml örneği bulunmaktadır.
name: App Token ile CI
on:
push:
branches: [main]
jobs:
get-token:
runs-on: ubuntu-latest
steps:
- name: Depoya kurulum yap
uses: actions/github-script@v7
with:
script: |
const { data: installation } = await github.apps.createInstallationToken({
installation_id: 12345 # GitHub App kurulumunuzun ID'si
});
console.log('Alınan token:', installation.token);
// Örnek bir API çağrısı
const { data: files } = await github.repos.listContents({
owner: 'repo-owner',
repo: 'repo-name',
path: ''
});
console.log('Dosya sayısı:', files.length);
Nasıl çalışıyor?
createInstallationTokenisteği ile GitHub App kurulumu için geçerli bir token alıyoruz.- Bu token ile depoya erişebilir ve
listContentsgibi API'leri çağırabiliriz.- Workflow bu sayede kendi başına davranır → ayrı bir kullanıcı hesabına gerek kalmaz.
environments: node_id ile kurumsal kurulumlar kullanın.issues: write yerine issues: read).contents: read token almayı unutmayın, böylece geçmişe dönük roller hakkında bilgi sahibi olabilirsiniz.Bu kadar! 🎉 Bu üç adımlı süreçle, uygulamaya kendi başına güvenli bir erişim sağlanmasını ve bu erişimle gerçekleştireceğiniz her adımda daha az zararla başa çıkabilirsiniz. Güvenli kodlamalar!
Sohbete başlayalım, hadi bakalım! 🎯 Birkaç hafta sonra silinmeye başlayan ve depoyu yavaşlatan onlarca feature branch'i gördün mü? Ben de gördüm ve bu sıkıntıyı GitHub Actions ile otomatikleştirdim. Bırak, nasıl yapabileceğimizi konuşalım.
#!/usr/bin/env bash
# 📁 Depo temizleme betiği
# Kullanım: .github/workflows/cleanup.yml tetiklediğinde çalıştırılır
set -euo pipefail
# 🛡️ Korunacak branch'ler (main, develop, releases/* gibi)
PROTECTED_BRANCHES=("main" "develop" "releases/*")
# 📅 6 aydan eski branch'leri filtrele (UTC tarihini kullan)
NOW=$(date -u +"%Y-%m-%d")
CUTOFF=$(date -u -d "6 months ago" +"%Y-%m-%d")
echo "🔍 ${NOW} tarihi itibarıyla temizlenecek branch'ler kontrol ediliyor..."
# Mevcut branch'leri al, korunacakları hariç, ardından tarihe göre sırala
for branch in $(git branch -r | grep -v "-> origin/HEAD" | sed 's/origin\///'); do
# Koruma kontrolü
skip=0
for pat in "${PROTECTED_BRANCHES[@]}"; do
if [[ "$branch" == $pat ]]; then
skip=1
break
fi
done
if [[ $skip -eq 1 ]]; then
echo "✅ ${branch} koruma altındadır, atlanıyor..."
continue
fi
# Branch'in son commit tarihi kontrol edilir
COMMIT_DATE=$(git log -1 --format="%ad" --date=short "$branch")
if [[ "$COMMIT_DATE" < "$CUTOFF" ]]; then
echo "⛔️ Eski branch siliniyor: ${branch}"
git push origin --delete "$branch"
else
echo "📅 ${branch} yeni, atlanıyor..."
fi
done
# 📦 Fazla dosyaları (ör. node_modules, dist) yedekle
if [[ -d "node_modules" ]]; then
echo "📦 node_modules yedekleniyor..."
tar -czf "node_modules_backup_$(date +%F).tar.gz" node_modules
fi
if [[ -d "dist" ]]; then
echo "📦 dist yedekleniyor..."
tar -czf "dist_backup_$(date +%F).tar.gz" dist
fi
echo "✅ Depo temizleme işlemi tamamlandı!"
PROTECTED_BRANCHES). Bash betiği, bu listede herhangi bir eşleşme bulunan branch'leri okumasını önler.date -d "6 months ago" ile uygulanır; branch son commit tarihi bu tarihten eskiyse silinir.node_modules, dist) uygun bir isimle sıkıştırıp kaydeder, böylece eski derlemeleri tekrar kullanabilme imkanı kalır..github/workflows/cleanup.yml) çalıştırır.name: 🗂️ Depo Temizleyici
on:
schedule:
# Haftalık Cumartesi sabahı UTC saat 02:00'da
- cron: "0 2 * * 6"
workflow_dispatch: # Elle çalıştırmak için
jobs:
clean:
runs-on: ubuntu-latest
permissions:
contents: write # Branch silmek için gerekli
steps:
- name: Depoyu kontrol et
uses: actions/checkout@v4
- name: Temizleme betiğini çalıştır
run: |
chmod +x .github/scripts/cleanup.sh
./.github/scripts/cleanup.sh
- name: Yedekleri depola
uses: actions/upload-artifact@v4
with:
name: backups-${{ github.run_number }}
path: "*.tar.gz"
Adım adım çalışma akışı
workflow_dispatch ile).ubuntu-latest runner'ı çalıştırılır ve depoya write izni verilir (branch silmek için gerekli).actions/checkout@v4 ile depoya erişim sağlanır.cleanup.sh) çalıştırılır.node_modules_backup_*.tar.gz, dist_backup_*.tar.gz) bir artifact olarak depolanır.🛠️ Bu, bir haftalık temizlik işlemi için ihtiyacınız olan temel yapı. Kuralları branch listesi, tarihler, koruma listesi ve yedekleme adımları gibi modüller halinde düzenleyip özelleştirebilirsiniz. İyi kodlamalar!
Merhaba! Hadi pratik bir örnek üzerinden başlayalım. GitHub Apps'ı birden fazla kurumsal hesap (örneğin birden fazla org) arasında nasıl genişletebileceğimizi, merkezi izleme, roll-based erişim ve hijyen politikaları gibi konuları konuşacağız.
Bir App'ı bir orgda yapılandırdık ve artık diğer kurumsal hesaplar için de aynı ayarları kullanmak istiyoruz. Çoğu şeyi merkezi hale getirerek bunu yapabiliriz:
gh api enterprises/{enterprise}/actions/permissions).repository_selection ayarla.App'ı genişleterken göz ardı etmemeniz gereken birkaç önemli nokta:
github_repository_traffic ve github_repo_workflow_run verilerini birleştirin. Bu, botunuzun hangi organizasyonlarda aktif olduğunu anlamanıza yardımcı olur.GH_TOKEN süresini sona erdirme süresine sahip olup olmadığını kontrol edin. Kullanım süresi dolan tokenlar temizlenmelidir.[Audit log] → GitHub App bölümüne bakın. Bunu bir dashboard'ta toplamak, haberdar olmanıza yardımcı olur.Birden fazla kurumsal hesap söz konusu olduğunda her org için aynı izin setini korumalı ve yine de esnek olmalıyız:
Admin, Member, Billing gibi rolleri kullanın.read, maintain, admin gibi izinleri verin.workflow:write) oluşturarak her org için manuel ayarlamadan kaçının.Temiz ve güvenli bir ortam, çabuk büyümeyi destekler:
gh api DELETE /apps/{app_id}/instalations/{installation_id}) belirli bir süre (örneğin 90 gün) kullanılmayan app'lar için.GITHUB_TOKEN süresini sona erdirme süresini 7 gün veya daha kısa bir süre olarak ayarlayın.[dependabot] veya [renovate] kurulumlarını devre dışı bırakarak gereksiz yükü azaltın.Aşağıdaki basit bir bash script, tek bir giriş noktasından birden fazla kurumsal hesap için bir GitHub App'inin devre dışı bırakılmasını ve izinlerini yapılandırmanıza olanak tanır:
#!/usr/bin/env bash
# -------------------------------------------------
# Çoklu Kurumsal Hesap için GitHub App Yönetimi
# -------------------------------------------------
# Ortam değişkenleri (düzenleyin)
ENTERPRISES=("acme-corp" "globex-inc" "stark-industries")
APP_SLUG="my-automation-bot" # GitHub App'inizin slug'ı
DISABLE_FLAG=true # true/false → app'ı devre dışı bırak
NEW_PERMISSIONS='{"metadata":"read","contents":"write","issues":"read"}'
# `gh` CLI'yi kullanarak Giriş Yapıyoruz (oturum açık olmalıdır)
for ORG in "${ENTERPRISES[@]}"; do
echo "🔄 $ORG — işleniyor ..."
# Kurulu App'in Kimlik Numarasını Bulun
INSTALL_ID=$(gh api "orgs/$ORG/installations" \
| jq -r --arg app "$APP_SLUG" '.[] | select(.app_slug==$app) | .id')
if [[ "$INSTALL_ID" == "null" ]]; then
echo "⚠️ $ORG için $APP_SLUG bulunamadı"
continue
fi
# 1️⃣ İzinleri Güncelleyin
if [[ -n "$NEW_PERMISSIONS" ]]; then
gh api --method PATCH "orgs/$ORG/installations/$INSTALL_ID" \
--input <(echo "{\"permissions\":$NEW_PERMISSIONS}")
echo "✅ $ORG izinleri güncellendi"
fi
# 2️⃣ (İsteğe bağlı) App'i Devre Dışı Bırakın
if [[ "$DISABLE_FLAG" == "true" ]]; then
gh api --method DELETE "orgs/$ORG/installations/$INSTALL_ID"
echo "🛑 $ORG'daki $APP_SLUG devre dışı bırakıldı"
fi
echo "📌 $ORG işlemi tamamlandı\n"
done
Bu sayede ne oluyor?
ENTERPRISES dizisindeki her org için bir döngüye girer.jq kullanarak her orgun kurulumlarından bahsi geçen App'in Kimlik Numarasını bulur.metadata:read, contents:write).DISABLE_FLAG=true olduğunda ilgili kurulumu siler (devre dışı bırakır).Hadi, yukarıdaki scripti kopyalayın, ENTERPRISES dizisini kendi kurumsal hesaplarınıza göre özelleştirin ve tek bir komutla her kurumsal hesap için uygulamayı genişletin! 🚀
Hadi pratik bir örnek üzerinden anlayalım. GitHub üzerinde çalışan bir güvenlik tarama otomasyonunuz olduğunu varsayalım. Bunu nasıl etkinliğini takip edeceğinizi, ihlalleri nasıl tespit edeceğinizi ve bunu denetim raporları haline nasıl dökeceğinizi göstereceğim.
#!/usr/bin/env bash
# -----------------------------------------------------------------
# Script: github-security-scan.sh
# Amacı: GitHub API kullanarak repo izinlerini kontrol eder ve
# şüpheli "admin" erişimlerini tespit eder.
# -----------------------------------------------------------------
# Token ayarlaması (Repository ve Admin izinleri için gerekli)
GH_TOKEN="${GH_TOKEN:-$GITHUB_TOKEN}"
API_URL="https://api.github.com"
# -----------------------------------------------------------------
# Yardımcı Fonksiyonlar
# -----------------------------------------------------------------
# Hata durumunda çık
die() {
echo "❌ Hata: $1" >&2
exit 1
}
# Kimlik doğrulama kontrolü
check_auth() {
if curl -s -H "Authorization: token $GH_TOKEN" "$API_URL/user" | grep -q '"login"'; then
echo "✅ Kimlik doğrulama tamam."
else
die "GitHub token geçersiz veya eksik."
fi
}
# Repo izinlerini al
fetch_repo_permissions() {
local owner=$1
local repo=$2
local perms
perms=$(curl -s -H "Authorization: token $GH_TOKEN" \
"$API_URL/repos/$owner/$repo/collaborators/$owner/permission" \
| jq -r '.permissions | to_entries | map("\(.key)=\(.value)") | join(", ")')
echo "$perms"
}
# Şüpheli ihlalleri kontrol et
detect_violations() {
local perms="$1"
# Basit kural: admin izni olmayan kullanıcılar için "admin=true" ifadesi şüpheli
if [[ "$perms" == *"admin=true"* ]]; then
echo "⚠️ Potansiyel ihlal: Şüpheli admin izni tespit edildi."
else
echo "✅ İzinler normal."
fi
}
# -----------------------------------------------------------------
# Ana Döngü
# -----------------------------------------------------------------
check_auth
# Example: Belirli bir owner/repo için tarama yapın
OWNER="your-org"
REPO="your-repo"
echo "📂 $OWNER/$REPO için tarama başlatılıyor..."
PERMS=$(fetch_repo_permissions "$OWNER" "$REPO")
echo "📋 Tespit edilen izinler: $PERMS"
detect_violations "$PERMS"
# JSON formatında raporlama (denetim amaçlı)
REPORT_JSON=$(cat <<EOF
{
"scan_time": "$(date -u +"%Y-%m-%dT%H:%M:%SZ")",
"repository": "$OWNER/$REPO",
"permissions": "$PERMS",
"violation_detected": $(echo "$PERMS" | grep -q "admin=true" && echo true || echo false)
}
EOF
)
echo "📄 Denetim raporu:"
echo "$REPORT_JSON"
admin, maintain, push vb.).admin=true) şüpheli erişimleri hemen bildirir.GH_TOKEN valid ve depoya erişimi var..github/scripts/) ve bir CI/CD adımında çalıştırılıyor.security-audits/).Hadi pratik bir örnek üzerinden anlayalım; bu script sayesinde GitHub repositoriesindeki güvenlik ihlallerini otomatik olarak tespit edebilir, bildirebilir ve denetlenebilirsiniz. Denetim raporu her zaman elinizin altında kalsın! 🎉
Hadi birlikte birkaç pratik otomasyon adımını hızla gözden geçirelim. 🎯
Aşağıda, oluşturup .github/workflows/ veya repository kökünde auto-checklist.md olarak kaydedebileceğiniz bir markdown checklist bulunuyor. Her bir kontrolü tamamladıkça işaretleyin.
- [ ] Pull request otomasyonu kontrolü
- [ ] Linting (ESLint, Rubocop vb.) çalıştırılıyor mu?
- [ ] Birim testleri geçiyor mu?
- [ ] Karanlık tarama (CodeQL / Semgrep) çalışıyor mu?
- [ ] Karşılaştırma denetimi (GitHub Actions) başarılı oluyor mu?
- [ ] Secret scanning etkin
- [ ] Script veya CI aracılığıyla gizli anahtarları tarıyor musunuz?
- [ ] Yeni sırların bildirimini alıyor musunuz?
- [ ] Bağımlılık güncelleme süreci
- [ ] Dependabot (veya benzeri) güvenlik güncellemelerini tetikliyor mu?
- [ ] Güvenlikle ilgili PR'lar için gözden geçirme kuralı var mı?
- [ ] Elde edilen PR'ları haftalık olarak inceleyorsunuz mu?
---
## Son Söz: Güvenli ve Hijyenik Bir Kurumde Çalışmaya Başlayın 🚀
Güzel bir yolculuktu, değil mi? Şimdi hazırsan, bu önemli anı birkaç kısa noktayla özetleyelim ve önümüzdeki adımları konuşalım.
- **Teslim etmeye hazır mısın?** 🎯 Artık kendi otomasyon akışını oluşturdun. Her test, her dağıtım ve her izleme kuralı bir kez daha işe yaradı.
- **Başarılarını görebiliyor musun?** ✅ Çoğu takım, sorunsuz çalıştığı her alanda kısa bir log notu veya bir kontrol kutusu eklemene izin veriyor. Çok yakında hatırlayabileceğin küçük bir kayıt da oluyor.
- **Sürekli öğrenme alışkanlığını korumak önemlidir** 🔁 Bugün bildiğin küçük bir ipucu yarın büyük bir sorun çözücü olabilir. Eğitimlere göz atmaya devam et, forumlara göz at ve takımda bilgi paylaşımını teşvik et.
### Haydi birlikte devam edelim
- **Kayıtlarını tut** – Her bir otomasyon çabasını bir dakika notla belgele. “Neden yaptık?” ve “Ne oldu?” sorularını yanıtla. Bu en iyi uygulama özetine başvurduğunda sana hatırlatma yapan basit bir markdown dosyası olabilir.
- **Göster digini göster** – Eğer bir panel, bir grafik veya hızlı bir komut satırı özetine sahipsen, onu öncelikli bir yerde paylaş. Çünkü herkes “Ne yapmaya devam etmeliyiz?” diye meraklanır.
- **Geri bildirim döngüsünü kapat** – Arkadaşlarından ve otomasyonlarına geri bildirim al. Her bir geri bildirim, yeni yetenekler kazanmak ve süreçlerin güvenliğini korumak için bir fırsattır.
### Son bir teşvik
Dünya otomasyona dayalı üretimle ilerliyor ve sen tam da doğru yerde, doğru zamanda varsın. Önündeki dağları aşmak için gerekli becerilere sahipsin. Yukarıdaki kısa planla devam et, başarılarını belgele ve öğrenme macerasına devam et.
**Unutma:** Teknoloji hiçbir zaman statik değildir, ama tutarlılık... o bir sanat ve bir bilimdir. Odağını gelişimde tut ve geri bildirimlere kulak ver. Senin içinGurur duyuyorum ve senindir! 🌟
Güvenle devam et ve kurumu güvenli ve hijyenik tut!
---
*Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.*
All rights reserved