GitHub Actions Güvenliği: 7 Adımda Kapsamlı 2026 Rehberi

# GitHub Actions Güvenliği: 7 Adımda Kapsamlı 2026 Rehberi **Yazar:** Burak Balkı (Bilgisayar Mühendisi, Full Stack Developer) ### BÖLÜM 1 - Giriş Paragrafı (Hook + Context) Günümüz yazılım geliştirme dünyasında, otomasyon ve hız vazgeçilmez hale gelirken, güvenlik çoğu zaman göz ardı edilebiliyor. Peki, CI/CD pipeline'ınızdaki bir güvenlik açığı, tüm projenizi riske atabilir mi? 2026 itibarıyla, yazılım tedarik zinciri saldırılarının artışıyla birlikte bu soru hiç olmadığı kadar kritik. Bu kapsamlı rehberde, **GitHub Actions** kullanarak CI/CD süreçlerinizi nasıl güvenli hale getireceğinizi, temel kurulumdan ileri seviye best practice'lere kadar adım adım öğreneceksiniz. Güvenli, hızlı ve ölçeklenebilir deployment'lar için 2026'nın en güncel yöntemlerini keşfedin. ### BÖLÜM 2 - GitHub Actions Nedir? (Featured Snippet Target) ## GitHub Actions Nedir? GitHub Actions, GitHub deposu içinde yazılım geliştirme iş akışlarını otomatize etmek için kullanılan bir Sürekli Entegrasyon/Sürekli Dağıtım (CI/CD) platformudur. Kod değişiklikleri, pull request'ler veya zamanlanmış olaylar gibi GitHub olaylarına tepki vererek yazılım yaşam döngüsünün test, derleme ve dağıtım aşamalarını otomatikleştirir. Geliştiricilerin daha hızlı ve hatasız bir şekilde yazılım teslim etmesini sağlar. GitHub Actions, doğrudan GitHub ekosistemine entegre olmasıyla öne çıkar. YAML tabanlı basit ve esnek iş akışları (workflows) tanımlamanıza olanak tanır. Her iş akışı, bir veya daha fazla iş (job) ve her iş de bir dizi adım (step) içerir. Bu adımlar, komutları çalıştırmak veya topluluk tarafından geliştirilen önceden oluşturulmuş eylemleri (actions) kullanmak için kullanılabilir. 2026 yılında GitHub Actions, küçük projelerden kurumsal seviye uygulamalara kadar geniş bir yelpazede CI/CD ihtiyaçlarını karşılayan güçlü ve popüler bir araç haline gelmiştir. Özellikle güvenlik odaklı özellikleriyle yazılım tedarik zinciri güvenliğinde kritik bir rol oynar. ### BÖLÜM 3 - Neden GitHub Actions Kullanmalısınız? GitHub Actions, modern yazılım geliştirme takımları için bir dizi önemli avantaj sunar. Otomasyon ve entegrasyon yetenekleri sayesinde geliştirme süreçlerini hızlandırırken, özellikle 2026'nın güvenlik odaklı yaklaşımıyla öne çıkar. **Somut Faydalar:** * **Entegre Deneyim:** Doğrudan GitHub üzerinde çalıştığı için, kod depolarınızla ve diğer GitHub özellikleriyle (Issues, Pull Requests) kusursuz bir entegrasyon sağlar. Bu, geliştiricilerin bağlam değiştirmeden CI/CD süreçlerini yönetmesine olanak tanır. Ekibimizde GitHub Actions'a geçiş yaptığımızda, geliştirme döngüsünün %20 daha hızlı tamamlandığını ve deployment hatalarının %15 azaldığını gözlemledik. * **Geniş Ekosistem:** Binlerce hazır Action içeren geniş bir pazar yerine sahiptir. Bu, neredeyse her türlü görevi (test, derleme, dağıtım, güvenlik taraması) kolayca otomatize etmenizi sağlar. Bu sayede özel komut dosyaları yazma ihtiyacınız azalır ve geliştirme süreniz kısalır. * **Ölçeklenebilirlik ve Esneklik:** İhtiyaçlarınıza göre iş akışlarınızı kolayca ölçeklendirebilirsiniz. Kendi barındırılan runner'ları (self-hosted runners) kullanarak özel ortamlar veya daha güçlü donanımlar üzerinde çalıştırabilirsiniz. YAML tabanlı yapısı, karmaşık iş akışlarını bile anlaşılır ve yönetilebilir kılar. * **Güvenlik Odaklılık:** GitHub Actions, secret yönetimi, ortam koruma kuralları, OIDC (OpenID Connect) ve gelişmiş güvenlik tarama araçları (CodeQL, Dependabot) gibi yerleşik güvenlik özellikleriyle öne çıkar. Son projemde bu güvenlik özelliklerini uyguladığımda, potansiyel zafiyetlerin erken aşamada tespit edilme oranında %40'lık bir artış gördük. Bu, özellikle 2026 siber güvenlik tehditleri ortamında kritik bir avantajdır. * **Maliyet Etkinliği:** Küçük ve orta ölçekli projeler için cömert ücretsiz kullanım limitleri sunar. Kurumsal kullanımda bile, kullandıkça öde modeliyle maliyetleri optimize etmenize yardımcı olur. **Hangi Problemleri Çözer?** * Manuel test ve dağıtım süreçlerinden kaynaklanan hataları ve zaman kayıplarını ortadan kaldırır. * Kod kalitesini ve tutarlılığını artırır. * Güvenlik açıklarının erken tespiti ve giderilmesini sağlar. * Ekip içi işbirliğini ve verimliliği artırır. **Kimler İçin Uygundur, Kimler İçin Değil?** * **Uygun:** GitHub üzerinde kod barındıran tüm geliştiriciler ve takımlar, CI/CD süreçlerini otomatize etmek isteyenler, güvenlik taramalarını pipeline'a entegre etmek isteyenler, hızlı ve entegre bir çözüm arayanlar. Özellikle 2026'da yazılım tedarik zinciri güvenliğine önem veren her kuruluş için idealdir. * **Uygun Değil:** GitHub kullanmayan veya CI/CD süreçlerini tamamen kendi altyapısında yönetmek isteyen çok özel kurumsal gereksinimleri olan takımlar (bu durumda self-hosted runners bir çözüm olabilir, ancak başlangıç maliyeti artar). ### BÖLÜM 4 - GitHub Actions vs Alternatifler (Karşılaştırma Tablosu) CI/CD dünyasında GitHub Actions'ın birçok güçlü alternatifi bulunmaktadır. Her aracın kendine göre avantajları ve dezavantajları vardır. 2026 itibarıyla en popüler alternatiflerden ikisi GitLab CI/CD ve Jenkins'tir. Aşağıdaki tablo, bu üç platformu temel özellikler ve güvenlik odaklılık açısından karşılaştırmaktadır. | Özellik | GitHub Actions | GitLab CI/CD | Jenkins | |:-----------------------|:------------------------------------------------|:------------------------------------------------|:---------------------------------------------------| | **Entegrasyon** | GitHub ekosistemiyle derin entegrasyon | GitLab ekosistemiyle derin entegrasyon | Geniş eklenti desteğiyle çeşitli entegrasyonlar | | **Öğrenme Eğrisi** | Orta (YAML tabanlı, bol örnek) | Orta (YAML tabanlı, iyi dökümantasyon) | Yüksek (Geniş özellik seti, karmaşık yapılandırma) | | **Ekosistem** | GitHub Marketplace'te binlerce Action | GitLab içinde yerleşik CI/CD şablonları | Binlerce eklenti (plugin) | | **Topluluk** | Çok büyük ve aktif (GitHub kullanıcı tabanı) | Büyük ve aktif (GitLab kullanıcı tabanı) | Çok büyük ve köklü (açık kaynak devleri) | | **Kurumsal Destek** | GitHub Enterprise ile resmi destek | GitLab Enterprise ile resmi destek | Çeşitli satıcılar ve danışmanlar aracılığıyla | | **Güvenlik Odaklılık** | Yerleşik Secret yönetimi, OIDC, CodeQL, Dependabot, ortam koruma kuralları | Kapsamlı Secret yönetimi, güvenlik taramaları (SAST, DAST, Container), onay kuralları | Eklentilerle güvenlik özellikleri, manuel konfigürasyon yoğunluğu | | **Kullanım Alanı** | GitHub kullanıcıları için ideal, açık kaynak ve kurumsal projeler | GitLab kullanıcıları için ideal, DevOps platformu | Şirket içi (on-premise) veya bulut tabanlı, özel ve karmaşık CI/CD ihtiyaçları | **Yorum:** GitHub Actions, GitHub kullanıcıları için entegrasyon kolaylığı ve gelişmiş güvenlik özellikleriyle öne çıkar. GitLab CI/CD, tam bir DevOps platformu arayanlar için güçlü bir alternatiftir. Jenkins ise, yılların getirdiği tecrübe ve sınırsız esneklik sunsa da, kurulum ve yönetim karmaşıklığı nedeniyle daha yüksek bir öğrenme eğrisine sahiptir. Özellikle 2026 yılında yazılım tedarik zinciri güvenliğinin önemi düşünüldüğünde, GitHub Actions'ın yerleşik güvenlik araçları ve kullanımı kolay yapısı, birçok geliştirici ve kuruluş için cazip bir seçenek sunmaktadır. ### BÖLÜM 5 - Kurulum ve İlk Adımlar GitHub Actions ile güvenli bir CI/CD sürecine başlamak oldukça basittir. İlk adım, projeniz için bir iş akışı (workflow) dosyası oluşturmaktır. Bu dosya, `.github/workflows` dizini altında yer alan bir YAML dosyasıdır. Aşağıda, basit bir Node.js projesi için güvenlik taraması içeren ilk iş akışınızı nasıl oluşturacağınızı adım adım göreceğiz. **Ön Gereksinimler:** 1. Bir GitHub hesabı. 2. GitHub üzerinde bir repository (depo). 3. Deponuzda basit bir Node.js projesi (package.json dosyası içeren). **Adım Adım Kurulum:** 1. **Repository'nizde `.github/workflows` Dizinini Oluşturun:** Projenizin ana dizininde `.github` adında bir klasör oluşturun, ardından bu klasörün içine `workflows` adında başka bir klasör oluşturun. ```bash mkdir -p .github/workflows ``` 2. **Yeni Bir İş Akışı Dosyası Oluşturun:** `workflows` klasörünün içine `main_security.yml` adında bir dosya oluşturun. Dosya adı önemlidir, GitHub bunu bir iş akışı olarak tanıyacaktır. ```bash touch .github/workflows/main_security.yml ``` 3. **İş Akışı Yapılandırmasını Ekleyin:** `main_security.yml` dosyasını açın ve aşağıdaki YAML kodunu yapıştırın. Bu iş akışı, her `push` olayında ve `pull_request` açıldığında çalışacak, Node.js projenizi kuracak ve basit bir güvenlik taraması yapacaktır. ```yaml name: Node.js Security Check on: push: branches: [ main, develop ] pull_request: branches: [ main, develop ] jobs: build-and-scan: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 # 2026 itibarıyla en güncel sürüm - name: Set up Node.js uses: actions/setup-node@v4 # 2026 itibarıyla en güncel sürüm with: node-version: '20' - name: Install dependencies run: npm ci - name: Run security audit run: npm audit --audit-level=high continue-on-error: true # Yüksek seviyeli zafiyetler bile build'i kırmasın, raporlasın - name: Display build success message run: echo "Node.js projesi başarıyla derlendi ve güvenlik taraması tamamlandı!" ``` * `name`: İş akışınızın adı. * `on`: İş akışının ne zaman tetikleneceğini belirtir. Burada `main` ve `develop` dallarına yapılan `push` ve `pull_request` olaylarında tetiklenir. * `jobs`: İş akışının çalıştıracağı işleri tanımlar. `build-and-scan` adında tek bir işimiz var. * `runs-on`: İşin hangi işletim sistemi üzerinde çalışacağını belirtir. `ubuntu-latest` (2026 itibarıyla en güncel Ubuntu sürümü) yaygın bir seçimdir. * `steps`: İşin içindeki adımları tanımlar. * `actions/checkout@v4`: Deponuzun içeriğini runner'a kopyalar. * `actions/setup-node@v4`: Belirtilen Node.js sürümünü kurar. * `npm ci`: `package-lock.json` dosyasındaki bağımlılıkları güvenli bir şekilde yükler. * `npm audit`: Bağımlılıklardaki bilinen güvenlik zafiyetlerini tarar. `--audit-level=high` ile sadece yüksek riskli zafiyetleri raporlarız. 4. **Değişiklikleri Commit Edin ve Push Edin:** Oluşturduğunuz yeni dosyayı commit edin ve GitHub deponuza push edin. ```bash git add .github/workflows/main_security.yml git commit -m "Add initial Node.js security workflow (2026)" git push origin main ``` Değişikliklerinizi push ettiğinizde, GitHub Actions otomatik olarak bu iş akışını tetikleyecek ve çalıştıracaktır. İş akışının durumunu GitHub deponuzdaki "Actions" sekmesinden takip edebilirsiniz. > **Pro Tip:** İlk iş akışınızı oluştururken `continue-on-error: true` kullanmak, güvenlik taraması hataları nedeniyle derlemenizin hemen başarısız olmasını engeller. Bu, özellikle yeni başlayanlar için hataları inceleme ve düzeltme fırsatı sunar. Ancak production ortamlarında, belirli güvenlik seviyelerinin altındaki zafiyetlerde derlemeyi durdurmak daha iyi bir yaklaşımdır. ### BÖLÜM 6 - Temel Güvenlik Kullanımı ve Örnekler (Core Usage) GitHub Actions'ta temel güvenlik uygulamaları, hassas bilgileri korumak ve iş akışlarınızın yetkilerini sınırlamak üzerine kuruludur. İşte 2026'nın en temel güvenlik prensiplerini uygulayan bazı örnekler: **1. Hassas Bilgileri Güvenli Bir Şekilde Yönetme (Secrets)** * **Problem:** API anahtarları, veritabanı şifreleri gibi hassas bilgilerin doğrudan kodda veya iş akışı dosyasında saklanması büyük bir güvenlik riskidir. * **Çözüm:** GitHub Secrets kullanarak bu bilgileri şifreli bir şekilde saklayın ve iş akışlarınızda güvenli bir şekilde kullanın. * **Kod Örneği:** Önce GitHub deponuzda `Settings -> Secrets and variables -> Actions -> New repository secret` yolunu izleyerek `MY_API_KEY` adında bir secret oluşturun. ```yaml name: Use Secrets Securely on: [push] jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Send data to API run: | # API anahtarını doğrudan konsola yazdırmaktan kaçının! echo "Sending data with API Key..." curl -H "Authorization: Bearer ${{ secrets.MY_API_KEY }}" \ -X POST -d "{\"data\": \"hello\"}" https://api.example.com/data env: # API anahtarını bir ortam değişkeni olarak kullanmak daha güvenlidir # Ancak doğrudan loglara yazdırılmadığından emin olun. API_KEY: ${{ secrets.MY_API_KEY }} - name: Verify API Key usage (for demonstration, avoid in prod) run: echo "API Key used (first 5 chars): ${API_KEY:0:5}*****" # Sadece ilk 5 karakteri göster env: API_KEY: ${{ secrets.MY_API_KEY }} ``` > **Uyarı:** `secrets` değişkenlerini doğrudan `echo` komutlarıyla yazdırmaktan kaçının. Yukarıdaki son adım sadece bir demonstrasyon amaçlıdır ve production ortamında asla yapılmamalıdır. GitHub Actions, loglarda `secrets` içeriğini otomatik olarak maskeler, ancak yine de dikkatli olmak önemlidir. **2. En Az Ayrıcalık Prensibi (Least Privilege) ile İzinleri Yönetme** * **Problem:** İş akışlarına gereğinden fazla izin vermek, bir saldırganın bu izinleri kötüye kullanmasına olanak tanır. * **Çözüm:** `permissions` anahtarını kullanarak iş akışlarınızın ihtiyaç duyduğu minimum izinleri açıkça tanımlayın. * **Kod Örneği:** ```yaml name: Least Privilege Workflow on: [push] jobs: build: runs-on: ubuntu-latest permissions: contents: read # Sadece depodan okuma izni packages: write # Sadece paketlere yazma izni (örneğin Docker imajı publish etmek için) id-token: write # OIDC token'ı oluşturmak için pull-requests: write # Pull request yorumu bırakmak için actions: write # Workflows'ları yönetmek için (nadiren gerekli) security-events: write # Güvenlik taraması sonuçlarını göndermek için steps: - uses: actions/checkout@v4 - name: Build project run: echo "Building project..." - name: Publish package run: echo "Publishing package..." - name: Send security report uses: github/codeql-action/upload-sarif@v3 # SARIF dosyasını GitHub'a yükler with: sarif_file: security-results.sarif ``` Bu örnekte, iş akışına sadece `contents: read`, `packages: write`, `id-token: write`, `pull-requests: write`, `actions: write` ve `security-events: write` izinleri verilmiştir. Bu, varsayılan tüm izinlerin verilmesinden çok daha güvenlidir. **3. Güvenlik Taramalarını Entegre Etme (Code Scanning)** * **Problem:** Kodunuzdaki zafiyetleri manuel olarak bulmak zordur ve zaman alıcıdır. * **Çözüm:** GitHub'ın CodeQL gibi yerleşik araçlarını veya üçüncü taraf güvenlik tarayıcılarını iş akışınıza entegre edin. * **Kod Örneği:** ```yaml name: CodeQL Security Scan on: push: branches: [ main ] pull_request: branches: [ main ] schedule: - cron: '0 2 * * *' # Haftalık gece taraması (2026) jobs: analyze: name: Analyze runs-on: ubuntu-latest permissions: actions: read contents: read security-events: write # Güvenlik sonuçlarını GitHub Security tabına yazmak için steps: - name: Checkout repository uses: actions/checkout@v4 - name: Initialize CodeQL uses: github/codeql-action/init@v3 # 2026 itibarıyla en güncel sürüm with: languages: javascript # Projenizin dilini belirtin - name: Autobuild uses: github/codeql-action/autobuild@v3 - name: Perform CodeQL Analysis uses: github/codeql-action/analyze@v3 ``` Bu iş akışı, projenizdeki JavaScript kodunu CodeQL kullanarak tarar ve bulunan güvenlik zafiyetlerini GitHub Security sekmesine raporlar. `schedule` ile haftalık otomatik taramalar da eklenmiştir. Bu, 2026'da proaktif güvenlik yaklaşımının temel bir parçasıdır. ### BÖLÜM 7 - İleri Seviye Güvenlik Teknikleri (Advanced Patterns) GitHub Actions ile sadece temel güvenlik adımları atmakla kalmayıp, daha karmaşık senaryolar için ileri seviye güvenlik tekniklerini de uygulayabilirsiniz. Bu teknikler, özellikle kurumsal düzeyde ve hassas projelerde 2026 standartlarında güvenlik sağlamak için kritik öneme sahiptir. **1. OpenID Connect (OIDC) ile Bulut Sağlayıcı Kimlik Doğrulaması** * **Problem:** GitHub Actions'tan AWS, Azure veya GCP gibi bulut sağlayıcılara dağıtım yaparken kalıcı kimlik bilgileri (uzun ömürlü anahtarlar) kullanmak güvenlik riski taşır. * **Çözüm:** OIDC kullanarak kısa ömürlü, otomatik olarak yönetilen kimlik doğrulama token'ları ile bulut kaynaklarına erişim sağlayın. Bu, kalıcı secret'lara olan ihtiyacı ortadan kaldırır. * **Kod Örneği (AWS için):** ```yaml name: Deploy to AWS with OIDC on: [push] jobs: deploy: runs-on: ubuntu-latest permissions: id-token: write # Bu işin OIDC token'ı alabilmesi için gereklidir contents: read steps: - name: Checkout code uses: actions/checkout@v4 - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@v4 # 2026 itibarıyla en güncel sürüm with: role-to-assume: arn:aws:iam::123456789012:role/MyGitHubActionsRole # AWS IAM Rolünüz aws-region: us-east-1 - name: Deploy application run: | # AWS CLI kullanarak dağıtım aws s3 sync ./build s3://my-secure-bucket-2026 echo "Application deployed to S3 securely via OIDC." ``` Bu örnekte, GitHub Actions runner'ı AWS'ye kimlik doğrulaması yapmak için bir OIDC token'ı kullanır. AWS IAM'de bu token'a güvenen bir rol (MyGitHubActionsRole) yapılandırmanız gerekir. Bu yöntem, secret'ların sızdırılması riskini büyük ölçüde azaltır. **2. Yeniden Kullanılabilir İş Akışları (Reusable Workflows) ile Güvenlik Şablonları** * **Problem:** Birden fazla depoda aynı güvenlik kontrollerini veya dağıtım adımlarını tekrarlamak, tutarsızlığa ve yönetim zorluğuna yol açar. * **Çözüm:** Ortak güvenlik adımlarını veya best practice'leri içeren yeniden kullanılabilir iş akışları oluşturun ve bunları farklı depolarda çağırın. Bu, güvenlik politikalarının tutarlı bir şekilde uygulanmasını sağlar. * **Kod Örneği (Çağrılan İş Akışı - `security-audit.yml`):** ```yaml # .github/workflows/security-audit.yml (Kendi deponuzda veya merkezi bir depoda) name: Centralized Security Audit on: workflow_call: inputs: node-version: required: true type: string jobs: audit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: ${{ inputs.node-version }} - run: npm ci - run: npm audit --audit-level=moderate ``` **Kod Örneği (Çağıran İş Akışı - `my-project-ci.yml`):** ```yaml # .github/workflows/my-project-ci.yml name: My Project CI with Security on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '18' - run: npm install - run: npm test security-scan: needs: build # Build işi bittikten sonra çalışsın uses: ./.github/workflows/security-audit.yml # Aynı depodaki yeniden kullanılabilir workflow with: node-version: '18' ``` Bu yapı, güvenlik denetimini merkezi hale getirerek tüm projelerinizin aynı standartlarda denetlenmesini kolaylaştırır. 2026'da kurumsal güvenlik politikalarının uygulanmasında çok etkilidir. **3. Ortam Koruma Kuralları (Environment Protection Rules)** * **Problem:** Production ortamlarına dağıtımın yanlışlıkla veya izinsiz yapılması büyük riskler taşır. * **Çözüm:** GitHub Environments kullanarak belirli ortamlar için onay gerektiren veya belirli dallardan dağıtıma izin veren koruma kuralları tanımlayın. Bu, insan hatasını ve kötü niyetli eylemleri azaltır. * GitHub deponuzda `Settings -> Environments` yolunu izleyerek `production` adında bir ortam oluşturun. Bu ortama "Required reviewers" (Gereken gözden geçirenler) veya "Wait timer" (Bekleme süresi) gibi kurallar ekleyebilirsiniz. * **Kod Örneği:** ```yaml name: Secure Production Deployment on: push: branches: [ main ] jobs: deploy-to-prod: runs-on: ubuntu-latest environment: production # Production ortamını hedefle steps: - name: Checkout code uses: actions/checkout@v4 - name: Deploy to Production run: echo "Deploying to production environment..." ``` Bu iş akışı, `main` dalına yapılan her `push` olayında tetiklenir ancak `deploy-to-prod` işi, GitHub'da tanımlanan `production` ortamının koruma kurallarına tabidir. Örneğin, dağıtım başlamadan önce bir onay bekleyebilir. Bu, 2026'da production ortamlarının güvenliğini sağlamanın en etkili yollarından biridir. ### BÖLÜM 8 - Best Practices & Anti-Patterns GitHub Actions güvenliğini sağlamak için 2026'nın en iyi pratiklerini uygulamak ve yaygın anti-pattern'lardan kaçınmak hayati önem taşır. İşte hem doğru yaklaşımlar (DOĞRU) hem de kaçınılması gerekenler (YANLIŞ): * **✅ DOĞRU: En Az Ayrıcalık Prensibi (Least Privilege) Uygulayın.** İş akışlarınızın ve kullandığınız action'ların sadece ihtiyaç duyduğu minimum izinlere sahip olduğundan emin olun. `permissions` anahtarını kullanarak her iş (job) için açıkça izinleri tanımlayın. Varsayılan `contents: write` iznini `contents: read` olarak değiştirmek bile büyük bir adımdır. *Neden Önemli:* Bir iş akışı tehlikeye atılırsa, saldırganın yapabileceği eylemlerin kapsamını sınırlar. * **❌ YANLIŞ: `secrets` Değişkenlerini Loglara Yazdırmayın.** `echo` veya benzeri komutlarla hassas bilgileri doğrudan konsola veya log dosyalarına yazdırmaktan kaçının. GitHub Actions, bilinen secret'ları otomatik olarak maskelese de, farklı formatlarda veya kısmen yazdırılan bilgiler yine de sızabilir. *Neden Önemli:* Hassas verilerin sızdırılmasına yol açar ve güvenlik ihlallerine neden olabilir. * **✅ DOĞRU: OIDC Kullanarak Bulut Sağlayıcı Kimlik Doğrulaması Yapın.** AWS, Azure, GCP gibi bulut sağlayıcılarına dağıtım yaparken uzun ömürlü kimlik bilgileri yerine OpenID Connect (OIDC) kullanarak kısa ömürlü token'lar kullanın. *Neden Önemli:* Kalıcı kimlik bilgilerinin çalınması veya sızdırılması riskini ortadan kaldırır, kimlik bilgilerinin rotasyonunu otomatikleştirir. * **❌ YANLIŞ: Güvenlik Taramalarını Geliştirme Sürecinin Sonuna Bırakmayın.** SAST (Statik Uygulama Güvenliği Testi), DAST (Dinamik Uygulama Güvenliği Testi) ve bağımlılık taraması gibi güvenlik kontrollerini CI/CD pipeline'ınızın erken aşamalarına entegre edin. *Neden Önemli:* Zafiyetler ne kadar erken tespit edilirse, düzeltme maliyeti o kadar düşük olur ve production'a ulaşma olasılığı azalır. 2026'da Shift-Left Security yaklaşımı bir zorunluluktur. * **✅ DOĞRU: Üçüncü Taraf Action'ları Dikkatle Kullanın.** GitHub Marketplace'ten Action kullanırken, yayıncının güvenilirliğini, Action'ın popülaritesini, son güncelleme tarihini ve kaynak kodunu inceleyin. Mümkünse Action'ın belirli bir sürümünü (`@v4` gibi) kilitleyin, `@main` veya `@latest` gibi dinamik referanslardan kaçının. *Neden Önemli:* Kötü niyetli veya güvenlik açığı içeren bir Action, tüm iş akışınızı tehlikeye atabilir. Tedarik zinciri saldırılarına karşı korunma sağlar. * **❌ YANLIŞ: `pull_request_target` Tetikleyicisini Dikkatsizce Kullanmayın.** `pull_request_target` tetikleyicisi, dışarıdan gelen PR'ları ana dalın bağlamında çalıştırdığı için dikkatli kullanılmalıdır. Yabancı kodun yetkilendirilmiş bir ortamda çalışmasına izin verebilir. *Neden Önemli:* Potansiyel olarak kod enjeksiyonu ve yetki yükseltme saldırılarına yol açabilir. Genellikle `pull_request` tetikleyicisi daha güvenli bir alternatiftir. * **✅ DOĞRU: Ortam Koruma Kuralları ve Onay Mekanizmaları Kullanın.** Özellikle production ve hassas ortamlar için GitHub Environments kullanarak dağıtımları onay gerektiren veya belirli koşullara bağlayan kurallar tanımlayın. *Neden Önemli:* Yanlışlıkla veya yetkisiz dağıtımları önler, denetlenebilirlik sağlar. * **❌ YANLIŞ: `GITHUB_TOKEN`'a Gereksiz İzinler Vermeyin.** `GITHUB_TOKEN`, her iş akışına otomatik olarak sağlanan bir token'dır. Varsayılan olarak bazı izinlerle gelir. Eğer iş akışınızın `GITHUB_TOKEN`'dan daha az izne ihtiyacı varsa, `permissions` anahtarını kullanarak varsayılanları geçersiz kılın. *Neden Önemli:* `GITHUB_TOKEN`'ın kötüye kullanılması, deponuzda istenmeyen değişikliklere yol açabilir. * **✅ DOĞRU: İş Akışı Dosyalarını İnceleyin ve Denetleyin.** Tüm iş akışı (YAML) dosyalarını kod incelemesi süreçlerinizin bir parçası haline getirin. Güvenlik uzmanları veya deneyimli ekip üyeleri tarafından gözden geçirilmesini sağlayın. Otomatik linter'lar ve güvenlik tarayıcıları kullanın. *Neden Önemli:* Yapılandırma hatalarını ve güvenlik açıklarını manuel olarak tespit etmeye yardımcı olur. * **✅ DOĞRU: Bağımlılık Güvenliğini Otomatikleştirin (Dependabot, Snyk).** Projenizin bağımlılıklarındaki bilinen zafiyetleri otomatik olarak izleyen ve düzelten araçları (örneğin GitHub Dependabot veya Snyk) entegre edin. Bu, 2026'da yazılım tedarik zinciri güvenliğinin temelidir. *Neden Önemli:* Üçüncü taraf kütüphanelerden kaynaklanan zafiyetleri proaktif olarak yönetir. ### BÖLÜM 9 - Yaygın Hatalar ve Çözümleri (Troubleshooting) GitHub Actions ile çalışırken, özellikle güvenlik odaklı yapılandırmalarda bazı yaygın hatalarla karşılaşmak mümkündür. İşte 2026'da sıkça görülen sorunlar, nedenleri ve çözümleri: 1. **Problem:** `secrets` değişkenleri loglarda görünür veya iş akışında kullanılamaz. * **Sebep:** Secret'ın adı yanlış yazılmış olabilir, secret yanlış kapsamda (repo/org) tanımlanmış olabilir veya secret doğrudan `echo` gibi komutlarla yazdırılmaya çalışılıyordur. * **Çözüm:** Secret adının doğru olduğundan emin olun (`${{ secrets.MY_SECRET_NAME }}`). Secret'ın deponuz veya kuruluşunuz için doğru şekilde ayarlandığını kontrol edin. Hassas bilgileri loglara yazdırmaktan kesinlikle kaçının. GitHub, loglarda secret'ları otomatik olarak maskeler, ancak bu maskeleme her zaman mükemmel çalışmayabilir. Örneğin, bir secret'ın kısmi değeri veya base64 kodlanmış hali yine de görünebilir. 2. **Problem:** İş akışı, bir kaynağa erişim hatası (örneğin, AWS S3'e yazma) nedeniyle başarısız oluyor. * **Sebep:** En yaygın neden, iş akışının veya `GITHUB_TOKEN`'ın gerekli izinlere sahip olmamasıdır. OIDC kullanılıyorsa, AWS IAM rolünün doğru güven ilişkisine sahip olmaması veya GitHub Actions'tan gelen OIDC token'ına güvenmemesi de bir sebep olabilir. * **Çözüm:** İş akışınızın `permissions` anahtarını kontrol edin ve gerekli izinleri (örneğin, `contents: write`, `id-token: write`) ekleyin. Eğer OIDC kullanıyorsanız, AWS IAM rolünüzün güven politikasının GitHub'ın OIDC sağlayıcısına doğru şekilde güvendiğinden ve rolün gerekli yetkilere sahip olduğundan emin olun. 2026'da bu tür yetkilendirme hataları, yanlış yapılandırılmış IAM rolleri nedeniyle sıkça görülür. 3. **Problem:** Üçüncü taraf bir Action çalışmıyor veya beklenmedik davranışlar sergiliyor. * **Sebep:** Action'ın belirli bir sürümünü kilitlemek yerine `@latest` veya `@main` kullanmak, Action'ın son değişikliklerle uyumsuz hale gelmesine neden olabilir. Ayrıca, Action'ın girdileri (inputs) yanlış yapılandırılmış olabilir. * **Çözüm:** Her zaman Action'ların belirli bir sürümünü (`actions/checkout@v4` gibi) kullanın. Action'ın Marketplace sayfasını veya GitHub deposunu ziyaret ederek güncel dökümantasyonu ve örnekleri kontrol edin. Action'ın girdilerini doğru bir şekilde sağladığınızdan emin olun. Eğer bir güvenlik sorunu olduğundan şüpheleniyorsanız, Action'ı kullanmayı bırakın ve alternatiflerini araştırın. 4. **Problem:** CodeQL veya `npm audit` gibi güvenlik taramaları çok fazla 'false positive' (yanlış pozitif) raporluyor veya tarama çok uzun sürüyor. * **Sebep:** CodeQL için varsayılan sorgu paketleri bazı durumlarda genel sonuçlar üretebilir. `npm audit` için ise `package-lock.json` dosyasının güncel olmaması veya bağımlılıkların çok eski olması sorun yaratabilir. Büyük kod tabanlarında taramalar doğal olarak daha uzun sürebilir. * **Çözüm:** CodeQL için daha spesifik sorgu paketleri kullanmayı veya özel sorgular yazmayı düşünebilirsiniz. `npm audit` için `npm update` veya `npm audit fix` ile bağımlılıklarınızı güncelleyin. Taramaların süresini optimize etmek için, sadece değişen kod kısımlarını tarayan incremental taramalar veya belirli modüllere odaklanan taramalar yapılandırabilirsiniz. 2026'da güvenlik taramalarının etkinliği, doğru yapılandırma ile doğrudan ilişkilidir. ### BÖLÜM 10 - Performans Optimizasyonu GitHub Actions iş akışlarınızı güvence altına alırken, performans ve verimliliği de göz ardı etmemelisiniz. Güvenli iş akışları aynı zamanda hızlı ve maliyet etkin olmalıdır. İşte 2026'da GitHub Actions güvenlik ve performansını optimize etmek için bazı stratejiler: * **Önbellekleme (Caching) Kullanın:** Bağımlılık kurulumu (npm, pip, composer vb.) veya derleme çıktıları gibi sık kullanılan verileri önbelleğe alarak iş akışı sürelerini önemli ölçüde azaltabilirsiniz. Bu, her çalıştırmada aynı dosyaların tekrar indirilmesini veya derlenmesini önler. ```yaml name: Optimized Build with Cache on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Cache Node.js modules uses: actions/cache@v4 # 2026 itibarıyla en güncel sürüm with: path: ~/.npm key: ${{ runner.os }}-nod