AI Destekli Yazılım Geliştirmede AST Tabanlı Değişiklik Denetimi

AI destekli yazılım geliştirmede metin diff’i neden yetersiz kalır?

Bir LLM aynı davranışı farklı sözdizimleriyle yazabilir: eval(userInput), bir yardımcı fonksiyon üzerinden çağrı veya dinamik import bunun tipik örnekleridir. Salt git diff incelemesi satır değişimini gösterir; ancak çağrının ifade ağacındaki yerini ve bağlamını sorgulamaz. Bu nedenle pull request tabanına karşı değişen dosyaları önce belirleyin:

BASE=$(git merge-base origin/main HEAD)
git diff --name-only --diff-filter=ACMR "$BASE" HEAD -- '*.ts' '*.tsx'

Bu listeyi AST taramasına girdi yapmak, modelin değiştirmediği eski borcu yeni bir PR’ın sonucu gibi raporlamayı azaltır.

Bu yaklaşım özellikle vibe coding eğitimi veya vibe coding kursu içinde öğretilmelidir: üretim hızının denetim yerine geçmediği somut olarak görülür. Örneğin TypeScript için ast-grep, boşluk ve satır sonu farklarını yok sayarak çağrı düğümünü eşler. Aşağıdaki kural, metinde geçen eval kelimesini değil, gerçekten çağrılan fonksiyonu hedefler:

id: forbid-eval
language: TypeScript
rule:
  pattern: eval($$ARGS)
message: "eval() yeni kodda kullanılamaz; doğrulanmış bir parser seçin."
severity: error

sg scan -r rules/no-eval.yml src/ komutu bu kuralı çalıştırır. İncelik şudur: yalnızca değişen satırları taramak, bir fonksiyonun çağrı sitesini değiştirmeden gövdesini riskli hale getiren PR’ları kaçırabilir; bu yüzden diff-kapsamlı hızlı taramayı, tam depo gece taramasından ayrı tutun.

Generative AI çıktısını Semgrep politikalarına dönüştürmek

Generative AI araçlarına “güvenli kod yaz” demek test edilebilir bir gereksinim değildir. Bunun yerine yasak API’leri, istisnaları ve önerilen alternatifi kural dosyasına koyun. Aşağıdaki Semgrep kuralı JavaScript/TypeScript’te doğrudan eval kullanımını CI hatasına çevirir:

rules:
  - id: typescript-no-eval
    languages: [javascript, typescript]
    severity: ERROR
    message: "eval yerine JSON.parse, zod veya tanımlı bir expression parser kullanın."
    patterns:
      - pattern: eval(...)

semgrep scan --config rules/ai-generated-code.yml packages/api çıktısında bulgu kimliği, dosya ve satır numarası bulunur; bu veriler review yorumuna veya SARIF dosyasına aktarılabilir.

Kuralı yazmak kadar yanlış pozitif sınırını belirlemek de önemlidir. Örneğin test fixture’ındaki kasıtlı eval çağrısını depo genelinde körlemesine hariç tutmak yerine, yalnızca test dizinini hariç bırakın:

paths:
  exclude:
    - "**/*.test.ts"
    - "**/fixtures/**"

Bu istisna üretim paketine yanlışlıkla taşınmış test kodunu yine yakalar. yapay zeka eğitimi ve llm eğitimi programlarında bu ayrım değerlidir: modelin ürettiği kural ile kuralın kabul ettiği dil, iki farklı teslimattır; ikincisi örnek kod ve negatif testlerle sürümlenmelidir.

Yazılım eğitimi için politika testlerini kod gibi sürümlemek

Semgrep kurallarını YAML yapılandırması olarak bırakmayın; semgrep test ile beklenen eşleşmeyi CI’da doğrulayın. Kural dosyanız rules/typescript-no-eval.yml ise yanına aşağıdaki fixture’ı ekleyin. ruleid yorumu bulgu beklenen satırı, ok ise kuralın susması gereken satırı belirtir:

// rules/typescript-no-eval.test.ts
function rejected(input: string) {
  // ruleid: typescript-no-eval
  return eval(input);
}
function accepted(input: string) {
  // ok: typescript-no-eval
  return JSON.parse(input);
}

semgrep test rules/typescript-no-eval.yml komutu, kuralın daha sonra gevşetilmesi veya aşırı genişletilmesi halinde build’i kırar.

Bu pratik, teknoloji eğitimi içeriğinde “prompt yazma”dan daha kalıcı bir beceri üretir: ekip, kabul edilmeyen kod biçimlerini makine tarafından çalıştırılan örneklere bağlar. Yaygın hata, sadece pozitif fixture yazmaktır. Her istisna için negatif fixture ekleyin; örneğin güvenilir bir parser sarmalayıcısının safeEvaluate(input) çağrısının yanlışlıkla eval kuralına takılmadığını gösterin. Kural güncellemesiyle birlikte fixture değişmiyorsa, PR’da bunun gerekçesini isteyin.

AI destekli yazılım geliştirmede CI kapısını SARIF ile kurmak

Yerel geliştirici taraması yeterli değildir; kod ajanının açtığı PR da aynı kontrolü çalıştırmalıdır. Aşağıdaki GitHub Actions adımı, önce kural testini, sonra yalnızca PR’da değişen TypeScript dosyalarının taramasını yürütür ve sonuçları SARIF olarak üretir:

- name: Install scanner
  run: python -m pip install --require-hashes -r tools/semgrep-requirements.txt
- name: Test policy rules
  run: semgrep test rules/
- name: Scan changed TypeScript files
  shell: bash
  run: |
    BASE=$(git merge-base origin/${{ github.base_ref }} HEAD)
    git diff --name-only --diff-filter=ACMR "$BASE" HEAD -- '*.ts' '*.tsx'       | xargs -r semgrep scan --config rules/ --sarif --output semgrep.sarif
- name: Upload findings
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: semgrep.sarif

--require-hashes ayrıntısı önemlidir: tarayıcı bağımlılığının beklenmedik bir pakete kaymasını engeller; yalnızca sürüm sabitlemek, transitive paketin dosya içeriğini doğrulamaz.

Bir yapay zeka kursu katılımcısı ya da üretimde çalışan ekip için kapı kuralı açık olmalıdır: ERROR bulgusu merge’i bloklar, WARNING bulgusu ise güvenlik şampiyonuna atanır. Ancak SARIF yalnızca bulguyu görünür kılar; GitHub branch protection tarafında ilgili workflow check’ini zorunlu durum kontrolü olarak seçmezseniz PR yine birleşebilir. Ayrıca fork PR’larında sırları olan workflow’ları çalıştırmayın: tarama için salt-okunur contents: read izni kullanın ve model tarafından üretilmiş script’i doğrudan bash ile çalıştırmayın.

Tarama süresini ölçmek: hızlı PR kontrolü ve tam gece taraması

Kural sayısı arttığında “CI yavaşladı” gözlemini ölçüme dönüştürün. Aynı, temiz bir runner’da tam depo taraması ile değişen dosya taramasını en az 10 kez çalıştırıp hyperfine ile medyan ve dağılımı kaydedin:

hyperfine --warmup 2 --runs 10   'semgrep scan --config rules/ packages/'   'git diff --name-only "$BASE" HEAD -- "*.ts" | xargs -r semgrep scan --config rules/'

Önce/sonra karşılaştırmasında yalnızca süreye bakmayın; iki komutun ürettiği bulgu kimliklerini de jq -r '.results[].check_id' report.json | sort -u ile karşılaştırın. Hızlı yol yeni dosyalardaki doğrudan ihlalleri yakalarken, dosyalar arası veri akışı bulgusunu kaçırıyorsa güvenlik eşdeğeri değildir.

Pratik yapılandırma iki katmanlıdır: PR’da değişen dosyalarda Semgrep çalışır; zamanlanmış workflow’da tam depo için CodeQL veya Semgrep’in tam taraması çalışır. Böylece PR geri bildirimini ölçülebilir biçimde kısa tutarken, yeniden adlandırma ya da ortak yardımcı fonksiyon değişikliği nedeniyle oluşan çapraz etkiyi gece taramasına bırakırsınız. ai destekli yazılım geliştirme süreçlerinde bu ayrım kritiktir; LLM’ler çok sayıda dosyaya benzer değişiklik yayabildiği için, yalnızca diff satırlarına dayalı bir kontrol kapsam yanılsaması yaratabilir.

Sık Sorulan Sorular

AI destekli yazılım geliştirmede Semgrep mi ast-grep mi kullanılmalı?

Yasak API, secret formatı ve çok dilli güvenlik kuralı için Semgrep ile başlayın; semgrep scan --config rules/ CI entegrasyonu ve SARIF çıktısı hazırdır. Belirli bir TypeScript AST dönüşümünü veya kesin kod biçimini eşlemek için ast-grep ekleyin: sg scan -r rules/no-eval.yml src/. Aynı politikayı iki araçta kopyalamak yerine, hangi aracın hangi riski sahiplenmesini README’de belirtin.

Vibe coding kursu projelerinde LLM tarafından üretilen kod nasıl test edilir?

Her politika için bir ihlal ve bir kabul fixture’ı yazın, ardından semgrep test rules/ komutunu PR zorunlu kontrolü yapın. Davranışsal riskler için de modelin değiştirdiği endpoint’e entegrasyon testi ekleyin; örneğin HTTP isteğini supertest ile gönderip yetkisiz kullanıcının 403 aldığını doğrulayın. Kodun derlenmesi tek başına yetki kontrolünün doğru olduğu anlamına gelmez.

Yapay zeka eğitimi ve LLM eğitimi içinde AST güvenlik kuralları hangi sırayla öğretilmeli?

İlk olarak git diff --name-only ile PR kapsamını çıkarın, ikinci adımda tek bir Semgrep kuralını çalıştırın, üçüncü adımda semgrep test fixture’ı ekleyin, son olarak SARIF yükleyen CI job’ını kurun. Öğrencinin teslimatı prompt değil; sürümlenmiş rules/ dizini, başarısız fixture ve branch protection ekranında zorunlu check olmalıdır.