CI/CD pipeline-a təhlükəsizliyi necə tikirsən

CI/CD təhlükəsizliyi nədir və niyə pipeline özü hədəfə çevrilir?

Bu iş iki hissədən ibarətdir: pipeline-ın buraxdığı kodu yoxlamaq və pipeline-ın özünü qorumaq. İkincisi çox vaxt unudulur. Halbuki build serverində bulud açarları, registry parolları və istehsal mühitinə deploy hüququ saxlanılır. Hücumçu üçün bu, tətbiqin özündən daha cəlbedici hədəfdir.

OWASP-ın CI/CD üçün Top 10 risk siyahısı bu mənzərəni yaxşı göstərir: axın nəzarətinin zəifliyi, asılılıq zəncirindən sui-istifadə, zəhərlənmiş pipeline icrası (poisoned pipeline execution), sirlərin pis idarəsi və artefakt bütövlüyünün yoxlanmaması. Yəni pipeline təhlükəsizliyi bir skaner quraşdırmaq deyil — bu, proqram təchizatı zəncirinin (supply chain) bütöv müdafiəsidir. Bu mənada o, müasir kibertəhlükəsizlik işinin ayrılmaz hissəsidir.

Təhlükəsizlik yoxlamalarını hansı ardıcıllıqla əlavə etmək lazımdır?

Ən çox yayılmış səhv bütün alətləri bir gündə qoşmaqdır. Yüzlərlə köhnə tapıntı birdən üzə çıxır, build qırmızıya çevrilir və komanda yoxlamanı söndürür. Pipeline təhlükəsizliyini dayanıqlı qurmağın yolu ucuz və dəqiq yoxlamalardan başlayıb mərhələ-mərhələ irəliləməkdir.

1. Secret scanning: repozitoriyaya düşən API açarlarını, tokenləri və parolları tapır. Ən ucuz və ən faydalı addımdır — həm commit-dən əvvəl (pre-commit hook), həm də pipeline-da işə salın.
2. Asılılıq təhlili (SCA): istifadə etdiyiniz kitabxanalarda məlum zəiflikləri (CVE) və lisenziya risklərini göstərir. Düzəliş çox vaxt sadəcə versiya yeniləməsidir.
3. SAST: öz kodunuzda SQL injection, təhlükəli deserializasiya kimi nümunələri axtarır. Səs-küyü daha çoxdur, ona görə qaydalar dəstini kiçik başlayıb tədricən genişləndirin.
4. Konteyner imici: minimal baza imic, root olmayan istifadəçi, imic skanı, SBOM və imza.
5. Kubernetes admission siyasətləri: klasterə yalnız qaydalara uyğun və imzalanmış iş yüklərinin düşməsinə icazə verir.

Burada vacib olan alət deyil, ardıcıllıqdır. Eyni məntiq GitLab CI, GitHub Actions və ya Jenkins-də eyni cür işləyir.

Konteyner imicini necə kiçiltmək və imzalamaq olar?

İmicdə nə qədər az paket varsa, skanerin tapacağı zəiflik də, hücumçunun istifadə edə biləcəyi alət də o qədər azdır. Multi-stage build ilə kompilyasiya alətlərini son imicdən çıxarın, minimal və ya distroless baza seçin, konteyneri root olmayan istifadəçi ilə işə salın. Baza imici tag ilə deyil, digest ilə bağlayın ki, eyni ad altında başqa məzmun gəlməsin.

İmza növbəti addımdır. Sigstore layihəsinin cosign aləti ilə imic build-dən sonra imzalanır, yanına SBOM və build mənşəyi (provenance) əlavə olunur. Nəticədə istehsal mühiti «bu imici həqiqətən bizim pipeline qurub?» sualına sübutla cavab verə bilir.

Kubernetes-də admission siyasətləri hansı riski bağlayır?

Admission controller Kubernetes API serverinə gələn sorğunu obyekt saxlanmazdan əvvəl yoxlayan mexanizmdir. Validating tipli yoxlama qaydaya uyğun olmayan sorğunu rədd edir, mutating tipli isə onu dəyişdirə bilir. Pipeline-da imzalanan imic məhz burada yoxlanılır.

• Yalnız öz registry-nizdən gələn və imzalanmış imiclərə icazə verin.
• Privileged rejimi, hostPath və host şəbəkəsini qadağan edin.
• Hər konteynerdə CPU və yaddaş limitlərini tələb edin.
• «latest» tag-ını rədd edin — yalnız konkret versiya və ya digest qəbul olunsun.

Siyasətləri birbaşa blok rejimində açmayın. Əvvəl audit rejimində işə salın, mövcud iş yüklərindən hansının qaydanı pozduğunu görün, onları düzəldin, sonra blok rejiminə keçin.

Tapıntıları necə triage etmək lazımdır ki, komanda yoxlamaları söndürməsin?

Pipeline təhlükəsizliyi çox vaxt texniki yox, təşkilati səbəbdən uğursuz olur. Hər build-i bloklayan, izahsız və yanlış müsbətlərlə dolu yoxlama tez bir zamanda söndürülür. Bu, kiber təhlükəsizlik komandası ilə developerlər arasında ən çox gərginlik yaradan məqamdır. Triage prosesi bunun qarşısını alır.

• Baseline yaradın: köhnə tapıntıları ayrıca backlog-a köçürün, bloku yalnız yeni əlavə olunan kritik və yüksək tapıntılara tətbiq edin.
• Hər tapıntı aydın olsun: hansı fayl, hansı sətir, niyə risklidir və necə düzəlir.
• Yanlış müsbəti (false positive) kodda səbəbi ilə qeyd etməyə imkan verin və bu qeydləri dövri yoxlayın.
• İstisnaların sahibi və bitmə tarixi olsun; vaxtı keçən istisna yenidən blok verir.
• Sızan sirr üçün qayda ayrıdır: onu koddan silmək kifayət deyil, açarı dərhal dəyişdirin (rotasiya).

SLSA və NIST SSDF bu işə necə çərçivə verir?

Alətlər dəyişir, çərçivə isə sabit qalır. SLSA (Supply-chain Levels for Software Artifacts) build prosesinin etibarlılığını səviyyələrlə təsvir edir. 1.0 versiyasında Build L1 build mənşəyi sənədinin mövcudluğunu, L2 onun hostlanan build platforması tərəfindən imzalanmasını, L3 isə build-in sərtləşdirilmiş və təcrid olunmuş mühitdə getməsini tələb edir.

NIST SP 800-218, yəni Təhlükəsiz Proqram Təminatı İnkişafı Çərçivəsi (SSDF), daha geniş baxır və təcrübələri dörd qrupa bölür: təşkilatın hazırlanması, proqram təminatının qorunması, təhlükəsiz proqram təminatının istehsalı və zəifliklərə reaksiya. Pipeline-dakı hər yoxlamanı bu qruplardan birinə bağlamaq auditdə «bu addım niyə var?» sualına hazır cavab verir.