14.9-bob: Xavfsizlik auditi va yakuniy amaliyot

14-QISM — Web Xavfsizligi · 9-mavzu (yakuniy)

1. Kirish va motivatsiya

14-QISM davomida har xavfsizlik mavzusini alohida o'rgandik: OWASP Top 10 14.1-bob, XSS 14.2-bob, injection 14.3-bob, CSRF/SSRF 14.4-bob, auth 14.5-bob, token/secrets 14.6-bob, HTTPS/headers 14.7-bob, rate limiting 14.8-bob. Endi bularni birlashtiramiz va xavfsizlikni doimiy jarayonga aylantiramiz. Chunki xavfsizlik — bir martalik "qildim, tamom" emas (bugun xavfsiz ilova ertaga zaif bo'lishi mumkin — yangi zaiflik, yangi paket, yangi kod). Bu bob xavfsizlikni tizimli boshqarishni — audit (tekshirish), avtomatik vositalar, va xavfsiz ishlab chiqarish madaniyatini ko'rsatadi.

Xavfsizlik auditi — ilovani zaifliklar bo'yicha tizimli tekshirish (OWASP Top 10 checklist, avtomatik skanerlash, qo'lda tahlil). Avtomatik vositalar — npm audit (zaif paketlar — A06), SAST (kodni statik tahlil), DAST (ishlab turgan ilovani sinash), dependency scanning, secret scanning — bularning ko'pini CI/CD'ga qo'shib, har commit'da avtomatik tekshirsa bo'ladi. Va eng muhimi — madaniyat: xavfsizlik har bosqichda (dizayn, kod, review, deploy — shift left — 14.1: 2.5), har jamoa a'zosi mas'ul, va doimiy (yangilanishlar, monitoring). Bu bob 14-QISMni yakunlab, xavfsiz ilova qurish va saqlash usulini beradi.

Bu bob: xavfsizlik auditi (turlari, jarayon), avtomatik vositalar (npm audit, SAST, DAST, secret scanning), CI/CD'da xavfsizlik (avtomatik tekshiruv), dependency xavfsizligi (A06 — zaif paketlar), xavfsizlik madaniyati (shift left, mas'uliyat, javob rejasi), va yakuniy xavfsizlik checklisti (barcha 14-QISM), so'ngida esa to'liq xavfsizlik audit loyihasi ko'rib chiqiladi.

O'xshatish: Xavfsizlik auditi — bu uy tibbiy ko'rigi va doimiy parvarish. Bir marta shifokorga borib "sog'lomman" deb yurishni to'xtatmaysiz — muntazam tekshiruv (audit), avtomatik o'lchovlar (qon bosimi monitoringi — npm audit, skanerlash), va sog'lom turmush (madaniyat — har kun mashq, to'g'ri ovqat — xavfsiz kod yozish odati). Bitta tekshiruv "bugun sog'lom" deydi, lekin sog'liq — doimiy (yangi kasalliklar — yangi zaifliklar). Xavfsizlik ham shunday: bir marta audit qilish yetarli emas — muntazam (har release), avtomatik (CI/CD — har commit), va madaniyat (har dasturchi xavfsizlikni o'ylaydi). "Sog'lom ilova" — doimiy parvarish natijasi (bir martalik davolash emas).

Nega muhim?

• Bir martalik emas — xavfsizlik doimiy (yangi zaiflik, paket, kod — doimiy tekshiruv).
• Avtomatik — npm audit, SAST/DAST CI/CD'da (har commit — inson unutmasin).
• A06 (OWASP) — zaif paketlar eng keng (o'z kodimiz xavfsiz, lekin paket zaif).
• Madaniyat — xavfsizlik har bosqichda, har a'zo mas'ul (yagona "xavfsizlik xodimi" emas).

2. Nazariya — chuqur tushuntirish

2.1. Xavfsizlik auditi turlari

  XAVFSIZLIK AUDITI — ilovani zaifliklar bo'yicha tekshirish (turlari):

  1. CHECKLIST AUDIT (qo'lda — OWASP Top 10):
   har zaiflik bo'yicha tekshirish (14.1: Misol 5) — tizimli, lekin qo'lda

  2. AVTOMATIK SKANERLASH:
   SAST (Static — kodni tahlil, ishga tushirmasdan)
   DAST (Dynamic — ishlab turgan ilovani sinash — hujum simulyatsiya)
   SCA (Dependency — paketlardagi zaifliklar — npm audit)
   Secret scanning (kod/git'da secret)

  3. PENETRATION TEST (pentest — mutaxassis hujum qiladi):
   real hujumchi kabi ilovani sinash (qo'lda + vosita — chuqur)

  4. CODE REVIEW (xavfsizlik nuqtai nazaridan — 15-QISM):
   kod o'zgarishini xavfsizlik bo'yicha tekshirish (PR'da)

  5. BUG BOUNTY (tashqi tadqiqotchilar — zaiflik topib mukofot):
   ko'p ko'z (jamoadan tashqari) — real zaiflik topadi

   Audit turlari — checklist (qo'lda), avtomatik (SAST/DAST/SCA), pentest, review, bug bounty
   Qatlamli — avtomatik (tez, doimiy) + qo'lda (chuqur) + tashqi (pentest/bounty)

Xavfsizlik auditi turlari — ilovani zaifliklar bo'yicha tekshirishning usullari. Besh xil audit (qatlamli — har biri turli zaiflikni topadi): (1) checklist audit (qo'lda — OWASP Top 10): har zaiflik bo'yicha tizimli tekshirish (14.1: Misol 5 — A01-A10 ro'yxati) — tizimli, lekin qo'lda (vaqt talab); (2) avtomatik skanerlash — SAST (Static Application Security Testing — kodni statik tahlil, ishga tushirmasdan — masalan injection naqshlari, zaif funksiyalar — 2.2), DAST (Dynamic — ishlab turgan ilovani sinash — hujum simulyatsiya — XSS, injection — tashqaridan — 2.2), SCA (Software Composition Analysis — paketlardagi zaifliklar — npm audit — 2.4), secret scanning (kod/git'da secret — gitleaks — 14.6); (3) penetration test (pentest — xavfsizlik mutaxassisi real hujumchi kabi ilovani sinaydi — qo'lda + vosita — chuqur, lekin qimmat); (4) code review (xavfsizlik nuqtai nazaridan — 15-QISM — kod o'zgarishini PR'da xavfsizlik bo'yicha tekshirish); (5) bug bounty (tashqi tadqiqotchilar zaiflik topib mukofot oladi — ko'p ko'z — jamoadan tashqari — real, kutilmagan zaiflik). Ikki nuqta: (1) audit turlari — checklist (qo'lda — tizimli), avtomatik (SAST/DAST/SCA — tez, doimiy), pentest (chuqur, mutaxassis), review (PR'da), bug bounty (tashqi); (2) qatlamli — avtomatik (tez, doimiy — har commit) + qo'lda (chuqur — checklist, review) + tashqi (pentest/bounty — real hujumchi). Hech bir audit turi 100% emas (avtomatik — yuzaki, lekin tez; pentest — chuqur, lekin qimmat, kam) — shuning uchun kombinatsiya (avtomatik doimiy + qo'lda muntazam + tashqi davriy). Audit — xavfsizlikni o'lchovli qiladi (his emas — aniq tekshiruv). Bu — xavfsizlikni doimiy boshqarishning asosi (bir marta emas — muntazam, avtomatik, qatlamli).

Uch atamani chalkashtirmang (ko'p aralashtiriladi): (1) vulnerability assessment (zaiflik baholash) — ilovadagi ma'lum zaifliklarni ro'yxatlash (asosan avtomatik skanerlash — SAST/DAST/SCA); maqsad — "qanday zaifliklar bor?" (keng, lekin yuzaki — topilganlarni sanaydi, ekspluatatsiya qilmaydi); (2) penetration testing (pentest) — mutaxassis real hujumchi kabi zaiflikni ekspluatatsiya qiladi (zanjirlab — bir zaiflikdan ichkariga kirib, boshqasiga o'tadi); maqsad — "zaiflik haqiqatan qanchalik xavfli, hujumchi qayergacha yeta oladi?" (chuqur, lekin qimmat, tor qamrov — 2.8); (3) security code review — inson kodni o'qib xavfsizlik nuqtai nazaridan tekshiradi (mantiq xatolari — avtomatik vosita ilg'amaydigan biznes-mantiq zaifligi, masalan "narxni manfiy qilib chegirma olish"); maqsad — "kod xavfsiz yozilganmi?" (mantiqiy chuqurlik — 15-QISM). Farq: assessment sanaydi (nima bor), pentest isbotlaydi (haqiqatan buziladimi), review o'qiydi (mantiq to'g'rimi). Uchalasi bir-birini to'ldiradi (assessment keng+arzon pentest chuqur+qimmat review mantiqiy) — professional audit uchalasini birlashtiradi.

2.2. SAST va DAST

  SAST va DAST — avtomatik xavfsizlik testlari (ikki yondashuv):

  SAST (Static — kodni tahlil, ISHGA TUSHIRMASDAN):
   kodni o'qib zaiflik naqshlarini topadi (injection, XSS, zaif funksiya)
   CI'da (har commit), erta (kod yozish paytida — IDE)
   erta topadi (kod darajasida);  false positive (xato ogohlantirish) ko'p
  Vositalar: Semgrep, SonarQube, CodeQL (GitHub), ESLint security plugin

  DAST (Dynamic — ISHLAB TURGAN ilovani sinash):
   real hujum simulyatsiya (XSS, injection payload yuborish)
   ilova ishlab turganda (staging/test muhit)
   real zaiflik (ishlashda);  kech (ilova tayyor bo'lgach), qamrov cheklangan
  Vositalar: OWASP ZAP, Burp Suite

  IAST (Interactive — ikkalasi aralash) — ilg'or

   SAST — kod tahlil (erta, false positive); DAST — ishlab turgan ilova (real, kech)
   Ikkalasi birga (SAST erta kodda, DAST tayyor ilovada) — qatlamli avtomatik test

SAST va DAST — avtomatik xavfsizlik testining ikki asosiy yondashuvi. SAST (Static Application Security Testing) — kodni statik (ishga tushirmasdan) tahlil qiladi: kodni o'qib, zaiflik naqshlarini topadi (string birlashtirish bilan SQL — injection, dangerouslySetInnerHTML — XSS, eval — xavfli, zaif crypto). CI'da (har commit) yoki erta (IDE'da — kod yozish paytida). Afzalligi — erta topadi (kod darajasida — production'dan oldin); kamchiligi — false positive (xato ogohlantirish — kod xavfsiz bo'lsa ham "zaiflik" deyishi mumkin — shovqin). Vositalar: Semgrep, SonarQube, CodeQL (GitHub — bepul), ESLint security plugin. DAST (Dynamic) — ishlab turgan ilovani sinaydi: real hujum simulyatsiya (XSS, injection payload yuborib — javobni tekshiradi). Ilova ishlab turganda (staging/test muhit). Afzalligi — real zaiflik (ishlashda — haqiqiy hujum kabi); kamchiligi — kech (ilova tayyor bo'lgach), qamrov cheklangan (faqat sinalgan yo'llar). Vositalar: OWASP ZAP (bepul), Burp Suite. IAST (Interactive — ikkalasi aralash — ilg'or). Ikki nuqta: (1) SAST — kod tahlil (erta — kodda, lekin false positive ko'p); DAST — ishlab turgan ilova (real — haqiqiy hujum, lekin kech — tayyor ilova); (2) ikkalasi birga (SAST erta — kod yozilganda, DAST kech — ilova tayyor — qatlamli avtomatik test — har biri turli zaiflik topadi). SAST kod naqshlarini (potensial), DAST ishlashni (haqiqiy) tekshiradi — birga to'liqroq. Bu vositalar CI/CD'ga qo'shiladi (2.3 — har commit avtomatik) — inson har commit'ni qo'lda tekshirmaydi (avtomatik). SAST/DAST — avtomatik xavfsizlik testining asosi (tez, doimiy, takrorli — qo'lda audit'ni to'ldiradi).

2.3. CI/CD'da xavfsizlik

  CI/CD'DA XAVFSIZLIK — har commit'da avtomatik tekshiruv (shift left):

  PIPELINE'DA XAVFSIZLIK QADAMLARI:
  # .github/workflows/security.yml
  - npm audit              # zaif paketlar (SCA — A06)
  - secret scanning        # secret kod/git'da (gitleaks)
  - SAST                   # kod tahlil (Semgrep/CodeQL)
  - lint security          # ESLint security plugin
  - dependency review      # yangi paket zaifligi (PR'da)
  #  DAST (staging deploy'dan keyin — OWASP ZAP)

  NEGA CI/CD'DA:
   HAR commit avtomatik (inson unutmaydi)
   Erta (production'dan oldin — arzon tuzatish)
   Buzuq/zaif kod o'tmaydi (sifat darvozasi — 10.9)

  SHIFT LEFT (xavfsizlikni chapga — boshga surish — 14.1: 2.5):
  IDE (yozishda)  commit (pre-commit hook)  CI (har push)  deploy (DAST)  ishlab turish (monitoring)
   har bosqichda — erta topilgan zaiflik arzon (kech — qimmat)

   CI/CD'da xavfsizlik — npm audit + secret scan + SAST (har commit avtomatik)
   Shift left — xavfsizlik erta (IDEcommitCIdeploy) — erta topish arzon

CI/CD'da xavfsizlik — har commit'da avtomatik tekshiruv. Xavfsizlik vositalarini CI/CD pipeline'ga 10.9-bob qo'shib, har commit'da avtomatik tekshirsa bo'ladi. Pipeline'dagi xavfsizlik qadamlari (.github/workflows/security.yml): (1) npm audit (zaif paketlar — SCA — A06 — 2.4); (2) secret scanning (secret kod/git'da — gitleaks — 14.6); (3) SAST (kod tahlil — Semgrep/CodeQL — 2.2); (4) lint security (ESLint security plugin — xavfli naqshlar); (5) dependency review (yangi paket zaifligi — PR'da — GitHub avtomatik); (6) DAST (staging deploy'dan keyin — OWASP ZAP — ishlab turgan ilova). Nega CI/CD'da: (1) har commit avtomatik (inson unutmaydi — har push tekshiriladi); (2) erta (production'dan oldin — kod darajasida topilgan zaiflik arzon tuzatiladi); (3) buzuq/zaif kod o'tmaydi (sifat darvozasi — 10.9 — zaiflik topilsa pipeline to'xtaydi, merge bo'lmaydi). Shift left (xavfsizlikni "chapga" — jarayon boshiga — surish — 14.1: 2.5): IDE (yozishda — SAST plugin) commit (pre-commit hook — secret scan) CI (har push — npm audit, SAST) deploy (DAST) ishlab turish (monitoring — 13.10) — har bosqichda tekshiruv. Nega shift left: erta topilgan zaiflik arzon (kod yozishda — bir daqiqa tuzatish; production'da — falokat, ma'lumot sizishi, qimmat). Ikki nuqta: (1) CI/CD'da xavfsizlik — npm audit + secret scan + SAST (har commit avtomatik — inson unutmasin); (2) shift left — xavfsizlik erta (IDE commit CI deploy monitoring) — erta topish arzon, kech qimmat. Bu — xavfsizlikni avtomatlashtirish (qo'lda har commit tekshirib bo'lmaydi — vositalar qiladi). DevOps (10.9 CI/CD) + xavfsizlik = DevSecOps (xavfsizlik jarayonning qismi — alohida bosqich emas). Har production loyiha CI/CD'da xavfsizlik tekshiruvlari bilan bo'lishi kerak (npm audit minimal — har commit zaif paket tekshir).

2.4. Dependency xavfsizligi (A06)

  DEPENDENCY XAVFSIZLIGI — paketlardagi zaifliklar (A06 — keng):

  MUAMMO: o'z kodingiz xavfsiz, lekin PAKETLAR zaif:
   zamonaviy ilova yuzlab paket (node_modules — transitive — ming+)
   bir paketdagi zaiflik = sizning ilovangiz zaif (siz yozmasangiz ham)

  TEKSHIRISH:
  npm audit                # zaif paketlar ro'yxati (severity bilan)
  npm audit fix            # avtomatik yangilash (mos versiyaga)
  npm audit --production   # faqat production paketlar

  BOSHQARISH:
   Muntazam npm audit (CI'da — har commit — 2.3)
   Paketlarni yangilab tur (eski = zaif — Dependabot/Renovate avtomatik PR)
   Kam paket (har paket — xavf yuzasi; kerakmasini olib tashla)
   Ishonchli paket (mashhur, faol, audit qilingan — tasodifiy emas)
   Lock fayl (package-lock — aniq versiya, supply chain himoya)

   Dependency — paketlardagi zaiflik (A06); o'z kod xavfsiz, paket zaif bo'lishi mumkin
   npm audit (muntazam) + yangilab tur (Dependabot) + kam/ishonchli paket

Dependency xavfsizligi (A06) — paketlardagi zaifliklar. Muammo: o'z kodingiz xavfsiz bo'lsa ham, ishlatadigan paketlar zaif bo'lishi mumkin — zamonaviy ilova yuzlab paket ishlatadi (node_modules — to'g'ridan + transitive — paketlarning paketlari — ming+), va bir paketdagi zaiflik = sizning ilovangiz zaif (siz o'zingiz yozmasangiz ham — masalan mashhur paket zaif bo'lsa). Bu A06 (Vulnerable and Outdated Components) — eng keng zaifliklardan (chunki har ilova ko'p paket ishlatadi). Tekshirish: npm audit (zaif paketlar ro'yxati — severity — low/moderate/high/critical — bilan), npm audit fix (avtomatik yangilash — mos versiyaga — ko'pini hal qiladi), npm audit --production (faqat production paketlar — dev paketlar kam muhim). Boshqarish: (1) muntazam npm audit (CI'da — har commit — 2.3); (2) paketlarni yangilab tur (eski = zaif — Dependabot/Renovate — avtomatik PR yangi versiya bilan — GitHub); (3) kam paket (har paket — xavf yuzasi — 14.1: 2.5 — kerakmasini olib tashla — masalan kichik funksiya uchun katta paket emas); (4) ishonchli paket (mashhur, faol qo'llab-quvvatlanadigan, ko'p yuklab olingan — tasodifiy/yangi/kam ishlatilgan emas — supply chain xavfi); (5) lock fayl (package-lock.json — aniq versiya — supply chain himoyasi — npm ci lock'dan aniq o'rnatadi — kutilmagan yangilanish yo'q). Ikki nuqta: (1) dependency — paketlardagi zaiflik (A06 — o'z kod xavfsiz bo'lsa ham paket zaif bo'lishi mumkin — keng); (2) npm audit (muntazam — CI'da) + yangilab tur (Dependabot) + kam/ishonchli paket + lock fayl. Supply chain hujumi — hujumchi mashhur paketni buzadi (yoki o'xshash nomli yomon paket — typosquatting) — barcha ishlatuvchi zararlanadi (keng — bir paket, ming ilova). Himoya — ishonchli paket, lock fayl, audit, kam paket. npm auditdan tashqari vositalar (kengroq baza, qo'shimcha funksiya): Snyk (chuqurroq zaiflik bazasi, avtomatik fix PR, litsenziya tekshiruvi), Trivy (paket + Docker image + IaC skanerlash — bir vosita ko'p qatlam — 2.10), GitHub Dependabot (bepul, GitHub'ga integratsiya — 2.4). Bular SCA (Software Composition Analysis) — ilova tarkibidagi barcha uchinchi tomon komponentlarini zaifliklar bo'yicha tekshiradi (o'z kodingiz emas — kutubxonalar). Dependency xavfsizligi — zamonaviy ilovaning katta qismi (kod o'zimizniki emas — ko'p paket). npm audit (minimal) — har loyihada muntazam (CI'da avtomatik).

2.5. Xavfsizlik madaniyati va javob rejasi

  XAVFSIZLIK MADANIYATI — xavfsizlik HAR a'zo, HAR bosqich (yagona xodim emas):

  MADANIYAT PRINSIPLARI:
   Shift left (har bosqichda — dizayn, kod, review, deploy — 2.3, 14.1: 2.5)
   Har dasturchi mas'ul (xavfsizlik — "boshqa birovning ishi" emas)
   Xavfsizlik review (PR'da — xavfsizlik nuqtai nazaridan — 15-QISM)
   Threat modeling (yangi xususiyatga — 14.1: Misol 3)
   Xavfsizlik o'qitish (jamoa — yangi hujumlar, OWASP)
   Kamtarlik (hech kim 100% xavfsiz emas — doimiy o'rganish)

  INCIDENT RESPONSE (zaiflik/buzilish bo'lsa — javob rejasi):
  1. ANIQLASH (monitoring — 13.10 — hujum/sizish belgisi)
  2. CHEKLASH (zararni to'xtatish — sizgan kalit bekor, server izolyatsiya)
  3. YO'QOTISH (zaiflikni tuzatish — patch)
  4. TIKLASH (xizmatni qayta — toza holatda)
  5. O'RGANISH (post-mortem — nega bo'ldi, qanday oldini olish)

   Madaniyat — har a'zo mas'ul, har bosqich (shift left), doimiy o'rganish
   Incident response — aniqlashcheklashtuzatishtiklasho'rganish (reja oldindan)

Xavfsizlik madaniyati va javob rejasi — xavfsizlikni jamoa va jarayon darajasida. Xavfsizlik madaniyati — xavfsizlik har a'zo, har bosqich mas'uliyati (yagona "xavfsizlik xodimi" emas — hammaga tegishli). Madaniyat prinsiplari: (1) shift left (xavfsizlik har bosqichda — dizayn, kod, review, deploy — 2.3, 14.1: 2.5); (2) har dasturchi mas'ul (xavfsizlik "boshqa birovning ishi" emas — har kim o'z kodi xavfsizligiga javobgar); (3) xavfsizlik review (PR'da — kod o'zgarishi xavfsizlik nuqtai nazaridan — 15-QISM code review); (4) threat modeling (har yangi xususiyatga — "bu qanday buzilishi mumkin?" — 14.1: Misol 3); (5) xavfsizlik o'qitish (jamoa yangi hujumlar, OWASP, eng yaxshi amaliyotlarni o'rganadi — xavfsizlik rivojlanadi); (6) kamtarlik (hech kim 100% xavfsiz emas — doimiy o'rganish, xato qilishni tan olish, yaxshilanish). Incident response (zaiflik/buzilish bo'lsa — oldindan reja): (1) aniqlash (monitoring — 13.10 — hujum/sizish belgisi — ko'p 429, g'alati log); (2) cheklash (zararni darrov to'xtatish — sizgan kalitni bekor, buzilgan server izolyatsiya); (3) yo'qotish (zaiflikni tuzatish — patch); (4) tiklash (xizmatni qayta ishga tushirish — toza holatda); (5) o'rganish (post-mortem — nega bo'ldi, qanday oldini olish — kelajak uchun). Ikki nuqta: (1) madaniyat — har a'zo mas'ul, har bosqich (shift left), doimiy o'rganish (xavfsizlik — jarayon, bir martalik emas); (2) incident response — aniqlash cheklash tuzatish tiklash o'rganish (reja oldindan — buzilish paytida panika emas, reja bo'yicha). Madaniyat — eng muhim (vositalar — npm audit, SAST — yordam beradi, lekin xavfsizlikni odamlar (madaniyat) ta'minlaydi — agar jamoa xavfsizlikni o'ylamasa, vositalar yetmaydi). Incident response rejasi — buzilish muqarrar (hech bir tizim 100% xavfsiz) — qachon bo'lsa, tayyor bo'lish (reja bilan — tez, to'g'ri javob). Bu — xavfsizlikni tashkilot darajasida (kod + jarayon + odamlar + reja). Professional jamoa xavfsizlik madaniyati bilan (har kim mas'ul, doimiy, reja bilan).

2.6. Yakuniy xavfsizlik checklisti

  YAKUNIY XAVFSIZLIK CHECKLISTI (butun 14-QISM — production'dan oldin):

  A01 ACCESS CONTROL: egalik/rol har resursda (IDOR — 14.1); server'da ham 14.3-bob
  A02 CRYPTO: parol bcrypt 14.5-bob; HTTPS+HSTS 14.7-bob; secret env 14.6-bob
  A03 INJECTION: parametrlangan so'rov 14.3-bob; XSS escape/sanitizatsiya 14.2-bob; validatsiya
  A04 DESIGN: threat model 14.1-bob; xavfsiz arxitektura
  A05 MISCONFIG: xavfsizlik header 14.7-bob; default o'zgartir; CORS aniq origin
  A06 COMPONENTS: npm audit toza 14.9-bob; yangilab tur (Dependabot)
  A07 AUTH: kuchli parol+bcrypt 14.5-bob; rate limit 14.8-bob; 2FA; sessiya xavfsiz
  A08 INTEGRITY: imzo tekshir (webhook — 13.6); CI/CD xavfsizlik
  A09 LOGGING: monitoring 13.10-bob; xato yashir; hujum aniqlash
  A10 SSRF: URL validatsiya/allowlist 14.4-bob; bulut metama'lumot blok

  QO'SHIMCHA:
  CSRF: SameSite + token 14.4-bob | TOKEN: JWT xavfsiz 14.6-bob | RATE LIMIT (14.8)

   Yakuniy checklist — A01-A10 + CSRF/token/rate limit (har biri tekshirilgan)
   Production'dan oldin (13.10: 2.10 production checklist'ning xavfsizlik qismi)

Yakuniy xavfsizlik checklisti — butun 14-QISMni bir tekshiruv ro'yxatida. Bu — production'dan oldin (yoki muntazam audit'da) butun ilovani OWASP Top 10 + qo'shimcha himoyalar bo'yicha tekshirish (har 14-QISM bobini birlashtiradi): A01 Access Control — egalik/rol har resursda (IDOR — 14.1: Misol 1), server'da ham (faqat UI emas — 14.3, 13.9: 2.9); A02 Crypto — parol bcrypt 14.5-bob, HTTPS+HSTS 14.7-bob, secret env 14.6-bob; A03 Injection — parametrlangan so'rov 14.3-bob, XSS escape/sanitizatsiya 14.2-bob, validatsiya (Zod); A04 Design — threat model 14.1-bob, xavfsiz arxitektura; A05 Misconfig — xavfsizlik header 14.7-bob, default o'zgartir, CORS aniq origin; A06 Components — npm audit toza 14.9-bob, yangilab tur (Dependabot); A07 Auth — kuchli parol + bcrypt 14.5-bob, rate limit 14.8-bob, 2FA, sessiya xavfsiz; A08 Integrity — imzo tekshir (webhook — 13.6), CI/CD xavfsizlik; A09 Logging — monitoring 13.10-bob, xato yashir, hujum aniqlash; A10 SSRF — URL validatsiya/allowlist 14.4-bob, bulut metama'lumot blok. Qo'shimcha — CSRF (SameSite + token — 14.4), token (JWT xavfsiz — 14.6), rate limit 14.8-bob. Ikki nuqta: (1) yakuniy checklist — A01-A10 + CSRF/token/rate limit (har biri tekshirilgan — butun 14-QISM); (2) production'dan oldin (13.10: 2.10 production checklist'ning xavfsizlik qismi — deploy'dan oldin majburiy tekshiruv). Bu checklist — 14-QISMning amaliy yig'indisi (har bob — bir-ikki band). Har production deploy'dan oldin (yoki muntazam — har release) shu ro'yxat bo'yicha tekshirish (qo'lda + avtomatik vositalar — 2.2, 2.4). Bu — xavfsizlikni to'liq (bir mavzu emas — barcha) va tizimli (tasodifiy emas — ro'yxat) qiladi. 14.1: Misol 5 (OWASP audit) bu checklist'ning boshlanishi edi — bu uning to'liq, 14-QISM bo'ylab versiyasi. Xavfsiz ilova — bu checklist'ning har bandi bajarilgan ilova (bir himoya emas — hammasi — defense in depth). Sanoat standarti sifatida OWASP ASVS (Application Security Verification Standard) mavjud — u xavfsizlik talablarini uch darajaga (L1 — asosiy, L2 — ko'p ilovalar uchun tavsiya etilgan, L3 — yuqori xavf: bank, tibbiyot) va o'nlab bo'limga (V2 autentifikatsiya, V3 sessiya, V4 access control, V5 validatsiya/injection, V6 crypto, V7 xato/log, V9 aloqa, V14 konfiguratsiya) ajratadi. Bizning yakuniy checklist — ASVS L1/L2 ning amaliy, soddalashtirilgan ko'rinishi (ASVS — to'liq, rasmiy versiyasi — real audit uchun ASVS ro'yxatini asos qilib olish mumkin).

2.7. Threat modeling (STRIDE, DFD, attack tree)

  THREAT MODELING — zaiflikni KOD YOZISHDAN OLDIN o'ylash (dizayn bosqichi):

  SAVOL: "bu tizim qanday buzilishi mumkin?" (hujumchi ko'zi bilan)

  STRIDE (6 turdagi tahdid — har komponentga qo'llash):
  S poofing        — kimligini soxtalashtirish    auth 14.5-bob
  T ampering       — ma'lumotni o'zgartirish       imzo/integrity (14.4, 13.6)
  R epudiation     — "men qilmadim" (inkor)         audit log (A09, 2.5)
  I nfo disclosure — ma'lumot sizishi               crypto, access control
  D enial of svc   — xizmatni to'xtatish (DoS)      rate limit 14.8-bob
  E levation       — ruxsatni oshirish (useradmin) access control (A01)

  DFD (Data Flow Diagram) — ma'lumot oqimini chizish:
   tashqi entity  jarayon  ma'lumot ombori (har o'q — bo'lishi mumkin hujum)
   ISHONCH CHEGARASI (trust boundary): internet | server | DB — chegarada tekshir

  ATTACK TREE — maqsad  shoxlangan yo'llar:
  MAQSAD: admin hisobiga kirish
    ├─ parolni topish (brute force  rate limit 14.8)
    ├─ sessiya o'g'irlash (XSS  CSP 14.2 / token 14.6)
    └─ SQL injection  admin (parametrlash 14.3)

   Threat modeling — dizaynda "qanday buziladi?" (STRIDE 6 tur, DFD oqim, attack tree)
   Erta (kod yozishdan oldin) — eng arzon (shift left — dizayn bosqichi)

Threat modeling (tahdid modellashtirish) — zaiflikni kod yozishdan oldin, dizayn bosqichida o'ylash: "bu tizim qanday buzilishi mumkin?" (hujumchi ko'zi bilan). Bu — shift left ning eng chap nuqtasi (2.3 — dizaynda topilgan tahdid eng arzon — hali kod yo'q). Uch asosiy vosita: (1) STRIDE — tahdidlarni olti turga ajratuvchi ro'yxat (har komponentga "bu STRIDE ning qaysi turiga zaif?" deb qo'llanadi): Spoofing (kimligini soxtalashtirish — himoya: auth — 14.5), Tampering (ma'lumotni ruxsatsiz o'zgartirish — imzo/integrity — 14.4, webhook 13.6), Repudiation (foydalanuvchi "men qilmadim" deb inkor qilishi — audit log — A09, 2.5), Information disclosure (ma'lumot sizishi — crypto, access control), Denial of service (xizmatni to'xtatish — DoS — rate limit — 14.8), Elevation of privilege (ruxsatni ruxsatsiz oshirish — oddiy user admin — access control — A01); (2) DFD (Data Flow Diagram — ma'lumot oqimi diagrammasi) — tizimni tashqi entity jarayon ma'lumot ombori sifatida chizib, har o'q (ma'lumot harakati) uchun tahdidni ko'rish; eng muhimi — ishonch chegarasi (trust boundary): internet | server | DB o'rtasidagi chegara — chegarada ma'lumot ishonchsiz (validatsiya/auth shu yerda majburiy); (3) attack tree (hujum daraxti) — hujumchi maqsadini (masalan "admin hisobiga kirish") ildiz qilib, unga eltuvchi barcha yo'llarni shoxlab chizish (parol brute force rate limit; sessiya o'g'irlash CSP/token; SQL injection parametrlash) — har shox uchun himoya bormi tekshiriladi. Ikki nuqta: (1) threat modeling — dizaynda "qanday buziladi?" (STRIDE — 6 tur, DFD — oqim va ishonch chegarasi, attack tree — maqsaddan yo'llar); (2) erta (kod yozishdan oldin) — eng arzon, eng samarali (shift left cho'qqisi — 14.1: Misol 3). Bu — reaktiv emas, proaktiv xavfsizlik (zaiflik chiqishini kutmasdan, oldindan o'ylab, dizaynga himoya kiritish). Har yangi muhim xususiyat (login, to'lov, fayl yuklash) uchun qisqa threat modeling — professional amaliyot.

2.8. Penetration testing metodologiyasi

  PENTEST — mutaxassis REAL HUJUMCHI kabi (metodologiya bilan, tasodifiy emas):

  PTES / bosqichlar (izchil jarayon):
  1. RECONNAISSANCE (razvedka) — nishonni o'rganish (ochiq port, texnologiya, endpoint)
  2. SCANNING          — zaiflik qidirish (avtomatik + qo'lda)
  3. EXPLOITATION      — zaiflikni ishlatib kirish (haqiqatan buziladimi?)
  4. POST-EXPLOITATION — ichkarida qayergacha? (pivot, ruxsat oshirish)
  5. REPORTING         — hisobot (zaiflik + isbot + jiddiylik + tuzatish)

  QAMROV (scope) — OLDINDAN kelishilgan (faqat ruxsat etilgan tizim!):
   ruxsatsiz "test" = JINOYAT (o'z tizimingda yoki yozma ruxsat bilan)

  BUG BOUNTY — tashqi tadqiqotchilar (HackerOne/platforma) zaiflik topib mukofot
  RESPONSIBLE DISCLOSURE (mas'uliyatli oshkor qilish):
   zaiflik topilsa: AVVAL egaga xabar (yashirin)  tuzatishga vaqt  SO'NG ommaga
   darrov ommaga = hujumchiga qurol (0-day) — mas'uliyatsiz

   Pentest — metodologiya bilan (reconscanexploitpostreport), qamrov kelishilgan
   Ruxsatsiz test = jinoyat; responsible disclosure = avval egaga, keyin ommaga

Penetration testing metodologiyasi — pentest tasodifiy "urinib ko'rish" emas, izchil jarayon (metodologiya). Keng qo'llaniladigan asos — PTES (Penetration Testing Execution Standard) va shunga o'xshash bosqichlar: (1) reconnaissance (razvedka) — nishon haqida ma'lumot yig'ish (ochiq portlar, ishlatilgan texnologiyalar, endpoint'lar, subdomenlar — hujumdan oldin "yer o'rganish"); (2) scanning — zaifliklarni qidirish (avtomatik skanerlar — 2.2 DAST — + qo'lda tekshiruv); (3) exploitation — topilgan zaiflikni haqiqatan ishlatib kirish ("nazariy zaiflik" emas — isbot: buziladimi?); (4) post-exploitation — ichkariga kirgach, hujumchi qayergacha yeta oladi (pivot — bir tizimdan boshqasiga, ruxsatni oshirish, ma'lumotga yetish — ta'sirni baholash); (5) reporting — hisobot (har zaiflik: nima, qanday isbotlandi, jiddiyligi — CVSS bali, qanday tuzatiladi). Qamrov (scope) — pentest oldindan yozma kelishiladi (faqat ruxsat etilgan tizim, ruxsat etilgan usul) — ruxsatsiz "test" — jinoyat (birovning tizimini ruxsatsiz sinash — qonun buzilishi; faqat o'z tizimingizda yoki yozma ruxsat bilan). Bug bounty — kompaniya tashqi tadqiqotchilarni (HackerOne kabi platformalar orqali) zaiflik topishga taklif qiladi, topganga mukofot to'laydi (ko'p ko'z — jamoadan tashqari). Responsible disclosure (mas'uliyatli oshkor qilish) — zaiflik topilganda avval tizim egasiga (yashirin) xabar berish, tuzatishga vaqt berish, so'ngra ommaga e'lon qilish; darrov ommaga oshkor qilish — hujumchilarga tayyor qurol (0-day) berish (mas'uliyatsiz — himoyasiz foydalanuvchilar zarar ko'radi). Ikki nuqta: (1) pentest — metodologiya bilan (recon scan exploit post-exploit report), qamrov oldindan kelishilgan; (2) ruxsatsiz test — jinoyat; responsible disclosure — avval egaga, tuzatgach ommaga. Aksariyat dasturchilar pentest'ni buyurtma qiladi (tashqi mutaxassis/firma) — lekin metodologiyani bilish o'z ilovangizni tanqidiy ko'z bilan ko'rishga, va pentest hisobotini to'g'ri o'qishga yordam beradi.

2.9. Compliance va shaxsiy ma'lumot (GDPR, PCI-DSS, SOC 2, ISO 27001)

  COMPLIANCE — qonun/standart talablari (xavfsizlik + shaxsiy ma'lumot):

  GDPR (EI — shaxsiy ma'lumot): rozilik, o'chirish huquqi, sizish xabari (72 soat)
  PCI-DSS (karta to'lovi):  karta ma'lumotini O'ZING saqlama (Stripe kabi 13.6)
  SOC 2 (xizmat ishonchi):  audit — xavfsizlik nazoratlari isbotlangan
  ISO 27001 (axborot xavfsizligi boshqaruvi):  tizimli ISMS

  PII (Personally Identifiable Info) — shaxsni aniqlovchi (ism, email, IP, karta):
   MINIMIZATSIYA — faqat KERAK bo'lganini yig' (kam ma'lumot = kam xavf)
   Maqsad cheklovi — yig'ilgan sababdan boshqaga ishlatma
   Shifrlash (saqlashda + uzatishda), access control, saqlash muddati
   O'chirish huquqi (foydalanuvchi so'rasa — o'chir)

   Compliance — qonun/standart (GDPR shaxsiy ma'lumot, PCI karta, SOC2/ISO audit)
   PII — minimizatsiya (kam yig'), maqsad cheklovi, shifrlash, o'chirish huquqi

Compliance (muvofiqlik) — xavfsizlik faqat texnik emas, ko'p holatda qonun va standart talabi. Asosiylari: (1) GDPR (Yevropa Ittifoqi — shaxsiy ma'lumot himoyasi) — foydalanuvchi ma'lumotini yig'ish uchun rozilik, ma'lumotga kirish/tuzatish/o'chirish huquqi ("unutilish huquqi"), ma'lumot sizishini 72 soat ichida xabar berish majburiyati; buzilsa — katta jarima (jahon aylanmasining foizi); (2) PCI-DSS (to'lov kartasi sanoati) — karta ma'lumotlarini himoyalash; amaliy xulosa — karta raqamini o'zingiz saqlamang, Stripe kabi PCI-mos provayderga ishoning (13.6 — token oling, karta ularda); (3) SOC 2 — xizmat kompaniyasining xavfsizlik nazoratlari mustaqil audit bilan isbotlanishi (korporativ mijozlar talab qiladi); (4) ISO 27001 — axborot xavfsizligini boshqarish tizimi (ISMS) uchun xalqaro standart (tizimli, hujjatlashtirilgan jarayon). PII (Personally Identifiable Information — shaxsni aniqlovchi ma'lumot: ism, email, telefon, IP, karta, lokatsiya) bilan ishlashning asosiy tamoyillari: (1) ma'lumot minimizatsiyasi — faqat haqiqatan kerak bo'lganini yig'ing (kam ma'lumot = kam xavf, sizsa kam zarar — "har ehtimolga qarshi yig'ib qo'yish" xavfli); (2) maqsad cheklovi — ma'lumotni yig'ilgan sababdan boshqasiga ishlatmang; (3) shifrlash (saqlashda va uzatishda — 14.7), access control (kim ko'ra oladi — A01), saqlash muddati (kerak bo'lmaganda o'chirish); (4) foydalanuvchining o'chirish huquqi (so'rasa — ma'lumotini o'chirish). Ikki nuqta: (1) compliance — qonun/standart talabi (GDPR — shaxsiy ma'lumot huquqlari, PCI — karta, SOC 2/ISO 27001 — tashkiliy audit); (2) PII — minimizatsiya (kam yig'), maqsad cheklovi, shifrlash, o'chirish huquqi. Dasturchi sifatida siz huquqshunos bo'lishingiz shart emas, lekin ma'lumot minimizatsiyasi va PII ni shifrlash/himoyalash — sizning bevosita mas'uliyatingiz (dizayndan boshlab — 2.7 threat modeling: "qaysi PII yig'iladi, qanday himoyalanadi?").

2.10. Konteyner va infratuzilma xavfsizligi

  KONTEYNER/INFRA XAVFSIZLIGI — kod + paket + IMAGE + platforma:

  DOCKER IMAGE:
   Kichik/rasmiy asos image (alpine, distroless — kam yuza, kam zaiflik)
   Image skanerlash (Trivy — image ichidagi zaif paket — 2.4)
   root emas foydalanuvchi (USER node — konteynerda root bo'lma)
   Secret image ichiga QO'YMA (env/secret manager — 14.6, build arg emas)

  KUBERNETES / PLATFORMA:
   Eng kam imtiyoz (RBAC — pod faqat kerak ruxsat)
   Network policy (podlar orasida faqat kerak aloqa)
   Read-only fayl tizim, resource limit (DoS himoya)

   Konteyner xavfsizligi — kichik/rasmiy image, skanerlash, root emas, secret tashqarida
   Platforma — eng kam imtiyoz (RBAC), network policy, resource limit

Konteyner va infratuzilma xavfsizligi — zamonaviy ilova konteynerda (Docker) va platformada (Kubernetes/bulut) ishlaydi — xavfsizlik faqat kod emas, image va platforma ni ham qamraydi. Docker image: (1) kichik/rasmiy asos image — alpine yoki distroless (kam komponent = kam hujum yuzasi = kam zaiflik; "to'liq OS" image'da minglab keraksiz paket); (2) image skanerlash — Trivy 2.4-bob image ichidagi zaif paketlarni topadi (o'z kodingiz toza bo'lsa ham asos image'dagi OS paketi zaif bo'lishi mumkin — CI'da skanerlang); (3) root emas foydalanuvchi — USER node (konteynerda root bo'lib ishlash — konteyner buzilsa hujumchi root; oddiy foydalanuvchi bilan cheklang); (4) secret'ni image ichiga qo'ymang (14.6 — image qatlamlarida qoladi, docker history bilan ko'rinadi; env yoki secret manager orqali runtime'da bering — build arg emas). Kubernetes/platforma: (1) eng kam imtiyoz (RBAC — Role-Based Access Control — har pod/xizmat faqat kerakli ruxsatga ega — A01 tamoyili infra darajasida); (2) network policy (podlar orasida faqat kerakli aloqaga ruxsat — buzilgan pod hamma joyga yeta olmasin — segmentatsiya); (3) read-only fayl tizim (konteyner o'ziga yoza olmasin — ko'p hujum yozish talab qiladi), resource limit (CPU/xotira — bir pod hammasini yeb DoS qilmasin). Ikki nuqta: (1) konteyner — kichik/rasmiy image, skanerlash (Trivy), root emas foydalanuvchi, secret tashqarida; (2) platforma — eng kam imtiyoz (RBAC), network policy (segmentatsiya), resource limit. Bularning ko'pi CI/CD'da avtomatlashtiriladi (2.3 — image build'dan keyin Trivy skanerlash — sifat darvozasi: kritik zaifli image deploy bo'lmaydi). Konteyner/infra xavfsizligi — DevSecOps ning ilova kodidan tashqaridagi qatlami (defense in depth — kod + paket + image + platforma).

3. Sintaksis — xavfsizlik vositalari

DEPENDENCY 2.4-bob: npm audit | npm audit fix | Dependabot | Snyk | Trivy
SECRET SCAN 2.3-bob:gitleaks | trufflehog | git-secrets (pre-commit hook)
SAST 2.2-bob:       Semgrep | CodeQL (GitHub) | SonarQube | ESLint security
DAST 2.2-bob:       OWASP ZAP | Burp Suite (ishlab turgan ilova)
IMAGE SCAN 2.10-bob:Trivy | Docker Scout (Docker image zaifligi)
CI/CD 2.3-bob:      .github/workflows — npm audit + secret scan + SAST (har commit)
THREAT MODEL2.7-bob:STRIDE | DFD (ma'lumot oqimi) | attack tree
CHECKLIST 2.6-bob:  OWASP Top 10 (A01-A10) + OWASP ASVS + CSRF/token/rate limit

4. Batafsil misollar

Har misol: Maqsad + izohli kod/tahlil + "Bu nima qiladi".

Misol 1 — CI/CD xavfsizlik pipeline (2.3)

Maqsad: Har commit'da avtomatik xavfsizlik tekshiruvini sozlash — npm audit, secret scan, SAST. Bu zaiflikni production'dan oldin avtomatik topadi.

# .github/workflows/security.yml — xavfsizlik pipeline
name: Security
on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 1. Dependency zaifliklar (A06 — 2.4):
      - name: npm audit
        run: npm audit --audit-level=high   # high/critical bo'lsa pipeline yiqiladi

      # 2. Secret scanning (kod/git'da secret — 14.6):
      - name: Gitleaks
        uses: gitleaks/gitleaks-action@v2

      # 3. SAST (kod tahlil — 2.2):
      - name: Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: "p/owasp-top-ten"   # OWASP qoidalari

      # 4. CodeQL (GitHub — chuqur SAST):
      - uses: github/codeql-action/analyze@v3

Bu nima qiladi: Bu — CI/CD xavfsizlik pipeline (har commit avtomatik tekshiruv — 2.3). .github/workflows/security.yml — GitHub Actions 10.9-bob, har push/PR'da ishlaydi (on: [push, pull_request]). To'rt xavfsizlik qadami: (1) npm audit --audit-level=high — dependency zaifliklar (A06 — 2.4); --audit-level=high — agar high/critical zaiflik bo'lsa pipeline yiqiladi (sifat darvozasi — zaif paket bilan kod merge bo'lmaydi — low/moderate ogohlantirish, lekin to'xtatmaydi); (2) Gitleaks (secret scanning — 14.6) — kod yoki git tarixida secret (API kalit, parol) bormi tekshiradi — topilsa pipeline yiqiladi (secret git'ga ketishini oldini oladi — 14.6: Misol 3); (3) Semgrep (SAST — 2.2) — kodni tahlil qiladi (p/owasp-top-ten — OWASP qoidalari — injection, XSS naqshlari); (4) CodeQL (GitHub — chuqur SAST — bepul). Bu pipeline har commit'da avtomatik ishlaydi (inson har commit'ni qo'lda tekshirmaydi — vositalar qiladi — 2.3). Agar biror tekshiruv yiqilsa (zaif paket, secret, kod zaifligi) — pipeline to'xtaydi, merge bo'lmaydi (zaiflik production'ga bormaydi — erta to'siladi — shift left — 2.3). Nega muhim: qo'lda xavfsizlik tekshiruvi (audit) muntazam emas (unutiladi, vaqt yo'q) — CI/CD avtomatik (har commit — izchil, unutilmaydi). Bu DevSecOps (xavfsizlik CI/CD'ning qismi — alohida bosqich emas). Har production loyiha shunday pipeline bilan bo'lishi kerak (minimal npm audit + secret scan). Bu — xavfsizlikni avtomatlashtirish (doimiy, izchil, erta) — qo'lda audit'ni (2.6 checklist) to'ldiradi (avtomatik tez + qo'lda chuqur). Erta topilgan zaiflik arzon (CI'da — bir daqiqa; production'da — falokat).

Misol 2 — npm audit va dependency boshqaruvi (2.4)

Maqsad: Paket zaifliklarini topish va boshqarish — npm audit, fix, Dependabot. Bu A06 (eng keng zaiflik) himoyasi.

# 1. ZAIFLIKLARNI KO'RISH:
npm audit
# Natija:
# │ High  │ Prototype Pollution in lodash                       │
# │ Paket │ lodash  │ Zaif: <4.17.21  │ Yo'l: app > lib > lodash │
# │ Fix   │ npm audit fix (4.17.21'ga yangilash)                │

# 2. AVTOMATIK TUZATISH (mos versiyaga):
npm audit fix
# npm audit fix --force   # major version (ehtiyot — buzishi mumkin)

# 3. FAQAT PRODUCTION:
npm audit --production --audit-level=high

# 4. ANIQ paket yangilash:
npm update lodash
npm install lodash@latest

# DEPENDABOT (avtomatik — .github/dependabot.yml):
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule: { interval: "weekly" }   # har hafta zaif/eski paket  avtomatik PR
#  Dependabot har hafta tekshiradi, yangi versiya bilan PR ochadi (siz review + merge)

Bu nima qiladi: Bu — paket zaifliklarini boshqarish (A06 — eng keng zaiflik — 2.4). npm audit — ilovadagi barcha paketni (to'g'ridan + transitive) zaifliklar bazasi (npm advisory) bilan solishtiradi va zaif paketlarni ko'rsatadi: severity (High/Critical/Moderate/Low), qaysi paket (lodash), zaif versiya (<4.17.21), yo'l (app > lib > lodash — qaysi paket orqali keldi — ko'pincha transitive — sizning to'g'ridan ishlatmaganingiz), va fix (yangilash). npm audit fix — zaifliklarni avtomatik tuzatadi (mos versiyaga yangilaydi — semver ichida — buzmaydi); --force (major version — ehtiyot — buzishi mumkin — test kerak). npm audit --production — faqat production paketlar (dev paketlar — build, test — kam muhim, production'da yo'q). Aniq yangilash — npm update lodash yoki npm install lodash@latest. Dependabot (.github/dependabot.yml) — GitHub'ning avtomatik vositasi: har hafta (interval: weekly) paketlarni tekshiradi, zaif/eski paket uchun avtomatik PR ochadi (yangi versiya bilan — siz review qilib, test o'tsa merge — yangilanish avtomatlashtirilgan). Nega muhim: paketlardagi zaifliklar (A06) eng keng (har ilova yuzlab paket — bir paket zaif = ilova zaif), va ular doimiy chiqadi (yangi zaiflik topiladi) — shuning uchun muntazam npm audit (CI'da — Misol 1 — har commit) va avtomatik yangilash (Dependabot — eski paket = zaif). Qo'lda har paketni kuzatish mumkin emas (yuzlab) — vositalar (npm audit, Dependabot) qiladi. Eng keng xato — paketlarni yillar yangilamaslik (eski = ma'lum zaifliklar — hujumchi biladi). To'g'ri — muntazam audit + yangilash (Dependabot avtomatik). Bu — dependency xavfsizligining amaliy boshqaruvi (A06 — zamonaviy ilovaning katta qismi — paket xavfsizligi).

Misol 3 — Pre-commit secret scanning (2.3, 14.6)

Maqsad: Secret commit'ni avtomatik to'sish — pre-commit hook bilan. Bu secret git'ga ketishini boshidan oldini oladi.

# gitleaks o'rnatish + pre-commit hook (Husky — 15-QISM):
npm install -D husky
npx husky init

# .husky/pre-commit — har commit'dan OLDIN secret tekshir:
# (fayl ichi):
gitleaks protect --staged --verbose
#  agar staged o'zgarishlarda secret (API kalit, parol) bo'lsa  commit TO'XTAYDI

GITLEAKS TOPADIGAN NAQSHLAR:
 AWS kalit (AKIA...), Stripe (sk_live_...), GitHub token (ghp_...)
 Private key (-----BEGIN PRIVATE KEY-----)
 Yuqori entropiyali satrlar (tasodifiy — token kabi)
 Parol naqshlari (password = "...")

NATIJA:
$ git commit -m "yangi xususiyat"
   gitleaks: STRIPE_SECRET_KEY topildi (config.ts:12)
   Commit to'xtatildi (secret'ni env'ga ko'chiring — 14.6)

 secret git'ga UMUMAN ketmaydi (boshidan to'silgan — 14.6: Misol 3)

Bu nima qiladi: Bu — pre-commit secret scanning (secret git'ga ketishini boshidan oldini olish — 2.3, 14.6). 14.6: Misol 3'da ko'rdik — git'ga ketgan secret git tarixida qoladi (o'chirish yetarli emas — bekor qilish kerak). Eng yaxshi — secret git'ga umuman ketmasligi (boshidan to'sish). Pre-commit hook (Husky — 15-QISM — git hook'lari) — har commit'dan oldin avtomatik ishlaydigan tekshiruv. gitleaks protect --staged — commit qilinayotgan (staged) o'zgarishlarda secret (naqshlar bo'yicha) bormi tekshiradi. Gitleaks topadigan naqshlar: AWS kalit (AKIA...), Stripe (sk_live_...), GitHub token (ghp_...), private key (-----BEGIN PRIVATE KEY-----), yuqori entropiyali satrlar (tasodifiy — token kabi — entropiya bilan aniqlanadi), parol naqshlari. Natija: agar dasturchi tasodifan secret'ni kodga yozib commit qilmoqchi bo'lsa (STRIPE_SECRET_KEY = "sk_live_..."), pre-commit hook commit'ni to'xtatadi ( Commit to'xtatildi — secret'ni env'ga ko'chiring) — secret git'ga umuman ketmaydi (boshidan to'silgan). Bu CI'dagi secret scan (Misol 1)dan ham erta (commit'dan oldin — local'da — git'ga umuman bormaydi; CI — git'ga ketgandan keyin push'da — kechroq, lekin baribir merge'dan oldin). Shift left 2.3-bob — eng erta (commit paytida) to'sish (eng arzon — secret git'ga umuman ketmaydi). Husky + gitleaks (yoki git-secrets) — har dasturchi mashinasida (pre-commit) + CI'da (Misol 1 — qo'shimcha qatlam — agar local hook o'tkazib yuborilsa). Nega muhim: secret git'ga ketishi — eng keng, eng oson oldini olinadigan xavfsizlik xatosi (14.6: 2.5 — GitHub'da minglab secret sizadi); pre-commit hook buni avtomatik, boshidan to'sadi (dasturchi unutsa ham — hook tekshiradi). Bu — secret xavfsizligining 14.6-bob eng yaxshi amaliyoti (boshidan to'sish — keyin bekor qilishdan yaxshiroq). Defense in depth — pre-commit (local) + CI secret scan (Misol 1) — ikki qatlam.

Misol 4 — Xavfsizlik logging va monitoring (2.5, A09)

Maqsad: Xavfsizlik hodisalarini loglash va kuzatish — hujum aniqlash uchun. Bu A09 (Logging Failures) himoyasi va incident response asosi.

// Xavfsizlik hodisalarini loglash (A09 — hujum aniqlash):
import { logger } from "@/lib/logger";

// LOGLASH KERAK (xavfsizlik hodisalari):
async function login(email: string, password: string, ip: string) {
  const user = await db.user.findUnique({ where: { email } });
  const valid = user && (await bcrypt.compare(password, user.passwordHash));

  if (!valid) {
    //  Muvaffaqiyatsiz login — log (brute force aniqlash):
    logger.warn("login_failed", { email, ip, timestamp: Date.now() });
    return null;
  }
  logger.info("login_success", { userId: user.id, ip });
  return user;
}

// LOGLAMASLIK KERAK (maxfiy — ma'lumot sizishi):
//  logger.info("login", { password });   // PAROL logda — YO'Q!
//  logger.info("token", { jwt: token });  // token logda — YO'Q!

// MONITORING (anomaliya aniqlash — alert):
//  ko'p login_failed bir IP/email  brute force alert (13.10 — Sentry/alert)
//  g'alati so'rov naqshlari  hujum alert

XAVFSIZLIK LOGLASH PRINSIPLARI (A09):
 Xavfsizlik hodisalari (login fail/success, ruxsat rad, rate limit) — LOGLA
 Maxfiy ma'lumot (parol, token, karta) — LOGLAMA (sizadi)
 Yetarli kontekst (kim, qachon, qaerdan, nima) — tergov uchun
 Markaziy log (barcha server — bir joy — qidiriladigan)
 Monitoring/alert (anomaliya — hujum belgisi — 13.10)
 Log saqlash (audit — keyin tahlil)

Bu nima qiladi: Bu — xavfsizlik logging va monitoring (A09 — Logging Failures — hujum aniqlash — 2.5, incident response asosi). Loglash kerak (xavfsizlik hodisalari): login_failed (muvaffaqiyatsiz login — email, IP, vaqt — brute force aniqlash — ko'p login_failed bir IP/email'dan = hujum), login_success, ruxsat rad, rate limit oshishi (14.8: Misol 5) — bular hujum belgilarini beradi. Loglamaslik kerak (maxfiy ma'lumot): parol, token, karta raqami — bularni hech qachon loglama (log fayllar sizsa — maxfiy ma'lumot ochiq — log ham ma'lumot sizish manbai). Monitoring (anomaliya aniqlash — alert): ko'p login_failed bir IP/email brute force alert (13.10 — Sentry/PagerDuty — darrov xabar), g'alati so'rov naqshlari hujum alert. Xavfsizlik loglash prinsiplari (A09): (1) xavfsizlik hodisalari (login, ruxsat, rate limit) — logla (tergov, aniqlash); (2) maxfiy ma'lumot (parol, token) — loglama (sizadi); (3) yetarli kontekst (kim, qachon, qaerdan, nima — tergov uchun — masalan "user123 IP 1.2.3.4'dan 02:00'da ruxsat rad"); (4) markaziy log (barcha server bir joy — qidiriladigan — ELK, Datadog); (5) monitoring/alert (anomaliya — hujum belgisi — 13.10); (6) log saqlash (audit — keyin tahlil — buzilish bo'lsa tergov). Nega A09: log/monitoring yo'q bo'lsa — hujum sezilmaydi (hujumchi ma'lumot o'g'irlaydi, siz bilmaysiz — oylab — ko'p buzilish kech aniqlanadi). Log/monitoring bilan — hujum darrov aniqlanadi (incident response — 2.5 — aniqlash bosqichi), va tergov mumkin (nima bo'ldi — log'dan). Eng keng xato — log yo'q (hujum sezilmaydi) yoki maxfiy ma'lumot logda (log sizsa — falokat). To'g'ri — xavfsizlik hodisalari loglanadi (maxfiysiz), monitoring (alert), saqlanadi (tergov). Bu A09 (Logging Failures) himoyasi — hujum aniqlash va incident response 2.5-bobning asosi. Monitoring 13.10-bob + xavfsizlik logging = hujumni ko'rish (ko'r ilova emas).

Misol 5 — To'liq xavfsizlik audit hisoboti (2.6)

Maqsad: Ilovani butun 14-QISM bo'yicha audit qilib, hisobot tuzish. Bu xavfsizlik holatini o'lchovli, harakatli qiladi.

═══════════════════════════════════════════════════════════
  XAVFSIZLIK AUDIT HISOBOTI — MyShop ilovasi (2026-06-23)
═══════════════════════════════════════════════════════════

OWASP TOP 10:
  A01 Access Control   IDOR yo'q (egalik tekshir), rol server'da
  A02 Crypto           bcrypt(12), HTTPS+HSTS, secret env
  A03 Injection        1 ta raw SQL topildi (admin/report.ts:34)  PARAMETRLA
  A04 Design           threat model (login, to'lov)
  A05 Misconfig        CSP yo'q  QO'SH (header)
  A06 Components       lodash zaif (High)  npm audit fix
  A07 Auth             rate limit, bcrypt;  2FA yo'q  QO'SH (tavsiya)
  A08 Integrity        webhook imzo tekshir
  A09 Logging          monitoring yo'q  Sentry QO'SH
  A10 SSRF             avatar URL allowlist

QO'SHIMCHA:
  CSRF   SameSite + Server Actions
  Token  JWT algoritm qat'iy, HttpOnly
  Rate limit  login + API (Upstash)

AVTOMATIK:
  npm audit: 1 High (lodash) | Gitleaks: toza | SAST: 2 ogohlantirish

═══ XULOSA: 3 muhim (A03 raw SQL, A06 lodash, A05 CSP)  DARROV tuzat ═══
═══          2 tavsiya (2FA, monitoring)  rejaga ═══

Bu nima qiladi: Bu — to'liq xavfsizlik audit hisoboti (butun 14-QISMni amalda — 2.6). Real audit — ilovani checklist 2.6-bob bo'yicha tekshirib, hisobot tuzish (topilgan zaifliklar + holat + harakat). Hisobot strukturasi: (1) OWASP Top 10 (A01-A10) — har biri uchun holat: (yaxshi — masalan A01 IDOR yo'q, A02 bcrypt/HTTPS), (e'tibor — masalan A03 bitta raw SQL topildi — parametrlash kerak, A05 CSP yo'q, A07 2FA yo'q, A09 monitoring yo'q), (jiddiy — A06 lodash zaif — High — darrov tuzatish); (2) qo'shimcha (CSRF, token, rate limit — 14-QISM qolgan boblar — ); (3) avtomatik (npm audit, Gitleaks, SAST natijalari); (4) xulosa — ustuvorlik bo'yicha: muhim (darrov tuzatish — raw SQL, zaif paket, CSP) + tavsiya (rejaga — 2FA, monitoring). Nega hisobot: audit faqat tekshirish emas — harakatli natija (qaysi zaiflik, qancha jiddiy, nima qilish — ustuvorlik bilan). Hisobot xavfsizlikni o'lchovli qiladi (his "ilova xavfsizmi?" emas — aniq "3 muhim, 2 tavsiya"), va harakatli (har band — aniq vazifa: parametrla, npm audit fix, CSP qo'sh). Jiddiylik bo'yicha ustuvorlik ( darrov, rejaga — vaqt/resurs cheklangan, eng muhimdan boshlash). Bu — 14.1: Misol 5 (audit ro'yxati boshlanishi)ning yakuniy, to'liq versiyasi (butun 14-QISM + hisobot + harakat). Professional audit shunday (tekshir hujjatlashtir ustuvorlik tuzat qayta tekshir). Audit muntazam (har release yoki chorak) — xavfsizlik doimiy (1.1 — bir martalik emas). Bu hisobot — 14-QISMning amaliy cho'qqisi (barcha bilim bir audit'da — checklist, vositalar, ustuvorlik). Xavfsiz ilova — muntazam audit qilingan, topilgan zaifliklar tuzatilgan ilova (hujjatlashtirilgan jarayon).

5. To'g'ri va noto'g'ri holatlar

1) Xavfsizlik

 bir martalik (deploy'dan oldin bir marta)
 doimiy (CI/CD avtomatik + muntazam audit — 1.1, 2.3)

2) Paketlar

 yillar yangilamaslik (eski = zaif — A06)
 npm audit + Dependabot (Misol 2)

3) Secret

 commit'dan keyin topish (git'da qoladi)
 pre-commit hook (boshidan to'sish — Misol 3)

4) Log

 log yo'q (hujum sezilmaydi — A09) yoki parol logda
 xavfsizlik hodisalari (maxfiysiz) + monitoring (Misol 4)

5) Mas'uliyat

 "xavfsizlik — boshqa birovning ishi"
 har dasturchi mas'ul (madaniyat — 2.5)

6) Audit

 his ("xavfsiz ko'rinadi")
 o'lchovli (checklist + vositalar + hisobot — Misol 5)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Xavfsizlik bir martalik

Sababi: "qildim, tamom" 1.1-bob. Yechimi: doimiy (CI/CD + muntazam audit).

Xato 2 — Paketlar eski (A06)

Sababi: yangilamaslik. Yechimi: npm audit + Dependabot (Misol 2).

Xato 3 — Secret git'ga ketgan

Sababi: pre-commit hook yo'q 2.3-bob. Yechimi: gitleaks pre-commit (Misol 3).

Xato 4 — Hujum sezilmaydi (A09)

Sababi: log/monitoring yo'q. Yechimi: xavfsizlik logging + alert (Misol 4).

Xato 5 — Parol/token logda

Sababi: maxfiy ma'lumot loglandi. Yechimi: maxfiysiz log (Misol 4).

Xato 6 — Audit qo'lda, muntazam emas

Sababi: unutiladi. Yechimi: CI/CD avtomatik (Misol 1) + muntazam checklist.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

• Butun 14-QISM: audit barcha himoyani birlashtiradi (OWASP, XSS, injection...).
• CI/CD 10.9-bob: xavfsizlik pipeline (npm audit, SAST).
• DevOps (10-QISM): monitoring, secret boshqaruv.
• Code review (15-QISM): xavfsizlik review, Husky (pre-commit).
• Deploy 13.10-bob: production checklist (xavfsizlik qismi).
• Monitoring 13.10-bob: xavfsizlik logging, alert (A09).
• OWASP 14.1-bob: A06 (components), A09 (logging) — audit.

8. Eng yaxshi amaliyotlar (best practices)

• Doimiy xavfsizlik (CI/CD + muntazam audit — bir martalik emas — 1.1).
• CI/CD pipeline (npm audit + secret + SAST — har commit — Misol 1).
• npm audit + Dependabot (A06 — paket yangilash — Misol 2).
• Pre-commit secret scan (gitleaks — boshidan — Misol 3).
• Xavfsizlik logging (maxfiysiz + monitoring — Misol 4).
• Shift left (xavfsizlik erta — IDECIdeploy — 2.3).
• Har a'zo mas'ul (madaniyat — 2.5).
• Incident response rejasi (buzilishga tayyor — 2.5).
• Yakuniy checklist (A01-A10 + qo'shimcha — Misol 5).
• Audit hisoboti (o'lchovli, harakatli — Misol 5).

9. Yakuniy loyiha: "To'liq Xavfsizlik Auditi"

14-QISMning barcha bilimini bitta auditda birlashtirish.

Maqsad

Ilovani (13.11 capstone yoki boshqa) butun 14-QISM bo'yicha audit qiling, zaifliklarni tuzating, doimiy xavfsizlik o'rnating.

Talablar (requirements)

1. OWASP audit: A01-A10 checklist (Misol 5, 2.6).
2. Avtomatik: npm audit + SAST + secret scan (Misol 1, 2).
3. CI/CD: xavfsizlik pipeline (Misol 1).
4. Pre-commit: secret scan (Misol 3).
5. Logging: xavfsizlik hodisalari + monitoring (Misol 4).
6. Har himoya: XSS, injection, CSRF, auth, token, headers, rate limit (14.2-14.8).
7. Hisobot: topilgan zaifliklar + ustuvorlik (Misol 5).
8. Tuzatish: muhim zaifliklarni tuzat.
9. Dependency: npm audit toza + Dependabot (Misol 2).
10. Madaniyat: incident response rejasi 2.5-bob.

Bosqichma-bosqich: o'z ilovangizni audit qilish

Bu loyiha — o'z ilovangizni haqiqiy audit qilish jarayoni. Quyidagi tartibda yuring (har bosqich — audit hisobotiga (Misol 5) bir band):

1. Doira belgilash (scope) — nimani audit qilasiz? (butun ilova yoki auth + to'lov kabi kritik qism). DFD chizing 2.7-bob: tashqi kirish server DB — ishonch chegaralarini belgilang.
2. Avtomatik skanerlash (tez, birinchi) — npm audit --audit-level=high (SCA — A06), gitleaks detect (secret — git tarixi bo'ylab), Semgrep p/owasp-top-ten (SAST). Natijalarni yozib oling.
3. OWASP Top 10 checklist (qo'lda, chuqur) — A01 dan A10 gacha (2.6, Misol 5): har biriga // qo'ying, dalil bilan ("A03: report.ts:34 da raw SQL" kabi aniq joy).
4. Threat modeling (kritik oqimlarga) — login/to'lov uchun STRIDE 2.7-bob: har tur bo'yicha "himoya bormi?" tekshiring.
5. Xavfsizlik header va konfiguratsiya — 14.7 (CSP, HSTS), CORS aniq origin, default parol/kalit o'zgartirilganmi, xato xabari maxfiyat sizdirmaydimi (stack trace ochiq emasmi).
6. Logging/monitoring — xavfsizlik hodisalari loglanadimi (maxfiysiz — Misol 4), monitoring/alert bormi (A09).
7. Hisobot va ustuvorlik — topilganni Misol 5 formatida yozing, jiddiylik bo'yicha saralang ( darrov, rejaga).
8. Tuzatish va qayta tekshirish — muhimlarini tuzating, so'ng skanerlashni qayta yuriting (regression — tuzatish yangi muammo keltirmadimi).
9. Doimiy qilish — CI/CD pipeline (Misol 1) + pre-commit (Misol 3) + Dependabot (Misol 2) o'rnating — audit bir martalik emas 1.1-bob.
10. Incident response rejasi — qisqa yozing (aniqlash cheklash tuzatish tiklash o'rganish — 2.5): "sizish bo'lsa, birinchi 30 daqiqada nima qilamiz?".

Maslahatlar (hint)

• Checklist (A01-A10 — Misol 5).
• Avtomatik CI/CD (Misol 1).
• Pre-commit secret (Misol 3).
• Logging (maxfiysiz — Misol 4).
• Ustuvorlik (muhim darrov — Misol 5).

"Tayyor" mezonlari (acceptance criteria)

• OWASP Top 10 audit (har biri).
• Avtomatik tekshiruv (CI/CD).
• npm audit toza.
• Secret scan (pre-commit + CI).
• Xavfsizlik logging + monitoring.
• Audit hisoboti + tuzatish.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring. Yo'nalish kerak bo'lsa, «[mavzu] qanday audit qilinadi?» deb so'rang.

10. Xulosa va keyingi qismga ko'prik

Bu bob bilan 14-QISM (Web Xavfsizligi) yakunlandi. Biz:

• Audit turlari 2.1-bob; SAST/DAST 2.2-bob; CI/CD xavfsizlik 2.3-bob; dependency (A06 — 2.4); madaniyat/incident response 2.5-bob; yakuniy checklist 2.6-bob.

Endi siz xavfsizlikni doimiy jarayonga aylantirasiz: avtomatik vositalar (npm audit, SAST, secret scan — CI/CD'da), audit (checklist + hisobot), va madaniyat (har a'zo mas'ul, shift left, incident response).

14-QISM (Web Xavfsizligi) TUGADI! Siz endi xavfsiz ilova qura olasiz: OWASP Top 10, XSS, injection, CSRF/SSRF, auth, token/secrets, HTTPS/headers, rate limiting, va doimiy audit. Xavfsizlik — har professional dasturchining majburiy ko'nikmasi.

Keyingi — 15-QISM: Kasbiy ko'nikmalar. Texnik mahoratni bildik; endi professional ko'nikmalarni o'rganamiz: toza kod va refactoring, code review madaniyati, ESLint/Prettier/Husky, monorepo, debugging metodologiyasi, hujjat o'qish, system design intervyu, va portfolio/open source. Bu — sizni texnik jihatdan kuchli dasturchidan professional, ishga tayyor dasturchiga aylantiradi.

Foydalanilgan rasmiy/ishonchli manbalar

• OWASP — "Vulnerability Scanning Tools", "DevSecOps", "Web Security Testing Guide (WSTG)"
• OWASP ASVS (Application Security Verification Standard) — xavfsizlik talablari darajalari
• OWASP — "Threat Modeling", STRIDE metodologiyasi; OWASP Top 10 (A01–A10)
• npm audit, Dependabot, Snyk, Trivy, Gitleaks, trufflehog, Semgrep, SonarQube, CodeQL, OWASP ZAP hujjatlari
• OWASP — A06 (Vulnerable Components), A09 (Logging Failures); NIST — Incident Response Guide (SP 800-61)
• PTES (Penetration Testing Execution Standard); responsible disclosure amaliyoti
• GDPR, PCI-DSS, SOC 2, ISO 27001 — compliance va shaxsiy ma'lumot (PII) himoyasi asoslari
• Docker/Kubernetes xavfsizlik hujjatlari (image skanerlash, RBAC, network policy)
• OWASP SAMM (Software Assurance Maturity Model) — xavfsizlik madaniyati