DevSecOps nədir və necə öyrənilir?

DevSecOps nədir və DevOps-dan nə ilə fərqlənir?

DevOps proqramın daha tez yazılması, yığılması və yayımlanması üçün qurulmuş iş axınıdır. DevSecOps isə həmin axına nəzarət nöqtələri əlavə edir: hər dəyişiklik avtomatik olaraq zəiflik (vulnerability), sızdırılmış sirr və səhv konfiqurasiya baxımından yoxlanır. Sürət itmir, çünki yoxlamalar əl ilə deyil, boru kəmərinin öz addımları kimi işləyir.

Bu yanaşmanın adı təhlükəsizliyi sola sürüşdürmək prinsipidir. Məntiq sadədir: səhvi kod yazılarkən düzəltmək istehsal mühitində düzəltməkdən qat-qat asandır. NIST-in təhlükəsiz proqram hazırlama çərçivəsi (SSDF) və OWASP DevSecOps bələdçisi də eyni ardıcıllığı təklif edir — tələb, kod, build və buraxılış mərhələlərinin hər biri üçün ayrıca yoxlama.

DevSecOps mühəndisi gündəlik olaraq nə edir?

Rolun böyük hissəsi yeni alət quraşdırmaq deyil, mövcud boru kəmərini anlaşıqlı və dözülən hala gətirməkdir. Əgər hər commit-dən sonra uzun xəbərdarlıq siyahısı çıxırsa, komanda bir həftə sonra onlara baxmağı dayandırır. Ona görə DevSecOps mühəndisinin əsas məhsulu siqnalın keyfiyyətidir.

• CI/CD boru kəmərinə statik kod təhlili (SAST) və asılılıq təhlili (SCA) addımlarını inteqrasiya etmək və onların icra vaxtını optimallaşdırmaq.
• Gələn tapıntıları triage etmək: hansı real risk, hansı yanlış müsbət, hansı sonrakı sprintə qalır.
• Sirlərin idarəsi: repozitoriyadan açar və parolları təmizləmək, onları sirr saxlama sisteminə köçürmək, rotasiya qaydası yazmaq.
• Konteyner imiclərini minimallaşdırmaq, imic imzalanmasını tətbiq etmək və reyestrdə imzasız artefaktın işə düşməsini bağlamaq.
• Kubernetes tərəfində RBAC rollarını daraltmaq, şəbəkə siyasətləri yazmaq, qəbul nəzarəti qaydalarını sınaqdan keçirmək.
• Terraform kodunu yoxlamadan keçirmək: açıq portlar, geniş icazələr, şifrələnməmiş disklər.
• Developer komandası ilə danışmaq — tapıntını qadağa kimi deyil, konkret düzəliş təklifi kimi çatdırmaq.

CI/CD boru kəmərində təhlükəsizlik hansı mərhələlərdə yoxlanılır?

1. Kod yazılışı: developerin mühitində sadə qaydalar işləyir — təhlükəli funksiyalar və sərt kodlanmış dəyərlər dərhal görünür.
2. Commit və pull request: sirr axtarışı və sürətli SAST qaydaları işə düşür; açar repozitoriyaya düşərsə, birləşdirmə bloklanır.
3. Build: tam SAST skanı və SCA ilə asılılıq ağacı yoxlanır, məlum zəiflikləri olan kitabxana versiyaları işarələnir.
4. Konteyner: imic minimal baza üzərində yığılır, skan edilir, imzalanır və mənşə məlumatı artefaktla birlikdə saxlanır.
5. Deploy öncəsi: infrastrukturun kod kimi idarəsi (IaC) faylları — Terraform planı — siyasət qaydaları ilə qiymətləndirilir.
6. Klaster daxilində: qəbul nəzarəti siyasətə uyğun olmayan manifesti rədd edir, RBAC və şəbəkə siyasətləri əhatəni daraldır.
7. Runtime: davranış monitorinqi və konfiqurasiya sürüşməsinin aşkarlanması əl ilə edilən dəyişikliyi və anormal fəaliyyəti üzə çıxarır.

DevSecOps öyrənmək üçün hansı bilikləri əvvəlcədən bilmək lazımdır?

DevSecOps orta səviyyə istiqamətdir. Bu o deməkdir ki, siz təhlükəsizliyi öyrənməmişdən əvvəl sistemin özünü başa düşməlisiniz. Nəyin necə işlədiyini bilmədən skan nəticəsini oxumaq mümkün deyil — ekranda çıxan mətn sizin üçün sadəcə qırmızı sətir olaraq qalır.

• Linux: fayl icazələri, proseslər, servislər, jurnal (log) oxumaq, paket idarəsi.
• Şəbəkə əsasları: portlar, DNS, TLS, proksi məntiqi, daxili və xarici trafik fərqi.
• Git: branch, pull request, birləşdirmə, tarixçədən fayl təmizləmək.
• Bir skript dili: Bash mütləq, Python isə avtomatlaşdırma üçün çox işə yarayır.
• Konteyner məntiqi: imic nədir, layer nədir, konteyner hostdan nə ilə ayrılır.
• YAML və konfiqurasiya oxumaq bacarığı — boru kəmərinin dili budur.

IT təcrübəniz tamamilə yoxdursa, birbaşa DevSecOps-a girmək vaxt itkisidir. Əvvəlcə Linux administrasiyası və ya müdafiə komandası (Blue Team) istiqaməti ilə baza qurmaq daha sürətli nəticə verir.

DevSecOps necə öyrənilir — addım-addım yol xəritəsi necə olmalıdır?

1. Baza: Linux, Git və CI əsasları. Boru kəmərinin anatomiyasını öyrənin — mərhələlər, artefaktlar, mühit ayrılması. Nəticə: özünüz sadə bir CI işi qurmalısınız.
2. Kod və asılılıq təhlili. SAST, SCA və sirr axtarışını eyni boru kəmərinə əlavə edin. Nəticə: tapıntıları ciddiliyə görə çeşidləyib yanlış müsbətləri susdura bilməlisiniz.
3. Konteyner təhlükəsizliyi. İmic minimallaşdırma, imza, runtime siyasətləri. Nəticə: eyni tətbiqin iki imicini yığıb ölçü və zəiflik sayını müqayisə edin.
4. Kubernetes. RBAC, şəbəkə siyasətləri, qəbul nəzarəti və gizli məlumatların idarəsi. Nəticə: hər pod üçün ən az imtiyaz prinsipi tətbiq olunmuş kiçik klaster.
5. IaC və bulud konfiqurasiyası. Terraform yoxlamaları, konfiqurasiya sürüşməsi, icazələrin daraldılması. Nəticə: plan mərhələsində dayandırılan ən azı üç səhv konfiqurasiya.
6. Yekun layihə. Sıfırdan təhlükəsiz boru kəməri qurun və sonra onu audit edin — nəyi tapdınız, nəyi düzəltdiniz, nə qaldı.

• Hər mərhələdə bir işlək artefakt qalmalıdır: repozitoriya, konfiqurasiya faylı, hesabat.
• Mərhələləri qarışdırmayın — Kubernetes-ə konteyner məntiqini bilmədən keçmək ən çox yayılmış səhvdir.
• Hər modulun sonunda qısa qeyd yazın: nəyi bloklayırsınız, niyə, hansı istisna ilə.

DevSecOps-da hansı alətlərlə işləmək öyrənilir?

Alətlərin adları ildən-ilə dəyişir, kateqoriyalar isə qalır. Ona görə öyrənmənin düzgün ölçüsü “neçə alət bilirəm” deyil, “bu kateqoriyanın nəticəsini oxuya bilirəmmi” sualıdır. Bir SCA alətini dərindən anlayan adam ikincisinə bir günə keçir.

Laboratoriyada DevSecOps necə məşq olunur?

• Hər modul bir işlək mühitlə bitir — slayd deyil, konfiqurasiya və hesabat.
• Kiçik qrup formatı tapıntıların birlikdə triage edilməsinə imkan verir: eyni skan nəticəsini üç nəfər üç cür şərh edir, fərq müzakirə olunur.
• Yekun layihənin auditi iştirakçılar arasında çarpaz aparılır — bu, müsahibədə izah bacarığını da hazırlayır.
• Hər ay yeni qruplar başlayır; proqram sonunda Log Academy sertifikatı və beynəlxalq sertifikatlara hazırlıq verilir.

Portfolio üçün hansı DevSecOps layihəsini qurmaq olar?

• Skan mərhələləri olan boru kəməri: kiçik bir tətbiq üçün commit → SAST → SCA → imic skanı → deploy zənciri qurun və hər mərhələnin bloklama qaydasını sənədləşdirin.
• Minimal imic layihəsi: eyni tətbiqi standart və minimal baza imici üzərində yığın, zəiflik sayı və ölçü fərqini cədvəlləşdirin.
• Kubernetes siyasət dəsti: bir namespace üçün RBAC rolları, şəbəkə siyasətləri və qəbul nəzarəti qaydaları yazın, sonra qadağan olunmuş manifesti sınayın.
• Terraform yoxlama layihəsi: qəsdən səhv konfiqurasiyalı infrastruktur yazın və plan mərhələsində onu dayandıran qaydalar qurun.
• Sirlərin idarəsi nümunəsi: repozitoriyadan sirri çıxarın, sirr saxlama sisteminə köçürün, rotasiya prosedurunu yazın.

1. Layihəni ayrıca repozitoriyada saxlayın və README-də məqsədi bir abzasla yazın.
2. “Əvvəl / sonra” bölməsi əlavə edin: nə bloklanmırdı, indi nə bloklanır.
3. Hər qərarın səbəbini yazın — niyə bu qayda kritik, niyə digəri xəbərdarlıq səviyyəsində qaldı.
4. Yanlış müsbətləri necə idarə etdiyinizi göstərin; müsahibədə ən çox bu soruşulur.
5. Sonda məhdudiyyətləri etiraf edin: nə sınanmadı, növbəti addım nədir.

DevSecOps kimə uyğundur və kimə hələ tezdir?

Bu istiqamət orta səviyyə üçün nəzərdə tutulub və iştirak üçün minimum yaş 18-dir. Ən rahat keçid artıq kod yazan və ya infrastruktur idarə edən adamlardadır — çünki onlar boru kəmərini artıq içəridən görüblər.

DevSecOps öyrənərkən ən çox hansı səhvlər edilir?

• Alət kolleksiyaçılığı: on alət quraşdırmaq, heç birinin nəticəsini oxumamaq. Bir kateqoriyanı dərindən anlamaq daha dəyərlidir.
• Hər tapıntını “kritik” saymaq. Prioritetsiz siyahı komandanı yoxlamalardan tamamilə soyudur.
• Yanlış müsbətləri idarə etməmək. İstisna qaydası yazmaq və onu sənədləşdirmək işin bir hissəsidir, qaçış yolu deyil.
• Sirləri repozitoriyada saxlamaq. Tarixçədən silinməyən açar hələ də sızmış sayılır.
• Təhlükəsizliyi yalnız deploydan sonra yoxlamaq — bu, DevSecOps deyil, adi audit praktikasıdır.
• Boru kəmərinin özünü qorumamaq: geniş icazəli CI tokenləri və nəzarətsiz üçüncü tərəf addımları real hücum səthidir.
• Developer ilə danışmamaq. Qəbul edilməyən qayda bir həftə sonra söndürülür.

Bu səhvlərin ortaq kökü birdir: təhlükəsizliyi komandanın əleyhinə qurulmuş maneə kimi görmək. İşləyən model isə əksinədir — yoxlama developerin vaxtına qənaət etdikdə davamlı olur.