Pāriet uz saturu
Atpakaļ uz blogu
Backend8 min lasīšanaVexilian2026. gada 16. marts

CI/CD drošība: cauruļvada aizsardzība

DevSecOps praksēs CI/CD cauruļvadā — noslēpumu pārvaldība, piegādes ķēdes drošība un automatizēta skenēšana.

CI/CD cauruļvads ir viens no augstākā riska punktiem uzņēmuma infrastruktūrā — caur to plūst pirmkods, noslēpumi, piekļuves atslēgas un deployment tokeni. Kompromitēts cauruļvads = kompromitēta produkcija. DevSecOps integrē drošību katrā izstrādes un deployment solī.

Noslēpumu pārvaldība — nulles tolerance

Nekad kodā — nekad

API atslēgas, datubāzes paroles, tokeni un privātās atslēgas nedrīkst atrasties versiju kontrolē nekādā formā:

  • Ne `.env` failā, kas "nejauši" tiek commitots (biežākais incidents)
  • Ne komentāros vai "pagaidu" hardcoded vērtībās
  • Ne Docker failos vai CI konfigurācijā
  • Ne test failos ar "test" credentials, kas patiesībā ir reāli

Rīki prevencijai: git-secrets (pre-commit hook, kas bloķē AWS atslēgas un līdzīgus patterns), truffleHog (skenē visu git vēsturi un atrod noplūdušus noslēpumus), GitGuardian (reāllaika monitorings GitHub/GitLab repos)

Noslēpumu glabātuves

  • GitHub Actions Secrets — šifrēti, pieejami tikai workflow laikā, nav redzami logos. Organizācijas un repo līmeņa noslēpumi
  • HashiCorp Vault — uzņēmuma līmeņa noslēpumu pārvaldība ar dinamiskām credentials, automātisku rotāciju, detalizētu auditu un piekļuves kontroli
  • AWS Secrets Manager / GCP Secret Manager — mākoņa natīvi risinājumi ar IAM integrāciju un automātisku rotāciju
  • Doppler — moderna SaaS noslēpumu pārvaldība ar vides sincronizāciju starp development, staging un production

Automātiska rotācija

Noslēpumus rotē regulāri (vismaz ik 90 dienas), nevis tikai pēc incidenta. Labākā prakse:

  • Datubāzes paroles — automātiska rotācija ar Vault vai cloud provider
  • API atslēgas — rotējiet un pārbaudiet, vai vecā atslēga tiek deaktivēta
  • Deploy tokeni — īss derīguma termiņš (1h–24h), ģenerēti katram deployment

Piegādes ķēdes drošība (Supply Chain Security)

Atkarību skenēšana

  • npm audit — iebūvēts Node.js rīks, kas pārbauda zināmās ievainojamības. `npm audit --production` skenē tikai production atkarības
  • Snyk — komercials rīks ar precīzāku ievainojamību datubāzi, fix PR automātisku ģenerēšanu un konteineru skenēšanu
  • Dependabot — GitHub natīvs serviss, kas automātiski izveido PR ar atkarību atjauninājumiem un ievainojamību labojumiem
  • Socket.dev — analizē pakotņu uzvedību (ne tikai zināmās CVE), identificē supply chain uzbrukumus un aizdomīgas izmaiņas

Lockfile integritāte

`package-lock.json` jābūt versiju kontrolē un jāpārbauda integritāte:

  • `npm ci` (nevis `npm install`) — strikti ievēro lockfile, nemodificē to, nodrošina reproducējamas builds
  • Lockfile lint — pārbauda, vai lockfile nav manipulēts (registry URL izmaiņas, integrity hash nesaderība)
  • Pinned versions — lock precīzas versijas, nevis ranges (`^1.2.3` → `1.2.3`)

Typosquatting un malicious packages

npm ekosistēmā regulāri parādās ļaunprātīgas pakotnes ar līdzīgiem nosaukumiem (lodash → 1odash). Aizsardzība:

  • npm provenance — verificē, ka pakotne tika veidota no publiskā avota koda
  • Privāts npm registry (Verdaccio, JFrog, GitHub Packages) — kontrolē, kuras pakotnes pieejamas komandai
  • Regulāra atkarību audita meeting — pārskatiet jaunas atkarības pirms pievienošanas

Automatizēta drošības testēšana CI cauruļvadā

SAST (Static Application Security Testing)

Analizē pirmkodu bez izpildes:

  • ESLint security plugins — eslint-plugin-security identificē eval(), child_process, regex DoS un citas bīstamas patterns
  • Semgrep — daudzvalodu SAST ar custom rules. Var rakstīt uzņēmuma-specifiskus noteikumus (piemēram: "nedrīkst izmantot localStorage sensitīviem datiem")
  • SonarQube — pilnvērtīga koda kvalitātes un drošības platforma ar dashboard, trends un quality gates
  • CodeQL — GitHub natīvs SAST, kas izprot datu plūsmu (no user input līdz datubāzei) un atrod injekciju ceļus

DAST (Dynamic Application Security Testing)

Testē darbojošos aplikāciju:

  • OWASP ZAP — bezmaksas, open-source. Automātiskais un manuālais režīms. Spider skenē visas lapas un testē injekcijas, XSS, CSRF
  • Nuclei — ātra, template-based ievainojamību skenēšana. 6000+ templates kopienas uzturēti

Konteineru drošība

  • Trivy — Docker attēlu un failu sistēmu skenēšana. Integrējas CI GitHub Actions, GitLab CI, vai lokāli
  • Snyk Container — OS paku un aplikācijas atkarību skenēšana Docker attēlā
  • Distroless/Alpine bāzes attēli — minimāla OS = minimāla uzbrukuma virsma
  • Multi-stage builds — production attēlā iekļauti tikai runtime faili, ne build rīki

SCA (Software Composition Analysis)

Apvieno atkarību skenēšanu ar licenču atbilstību. Nodrošina, ka neizmantojat GPL bibliotēkas komerciālā produktā bez atbilstības.

Piekļuves kontrole un pipeline hardening

Mazāko privilēģiju princips

  • CI/CD servisa konti (GitHub App, deploy keys) ar minimālām tiesībām — tikai tas, kas nepieciešams konkrētajam uzdevumam
  • Atsevišķi tokeni katrai videi (development, staging, production)
  • Production deployment pilnvaras — tikai CI/CD, nevis individuāliem izstrādātājiem

Branch aizsardzība

  • Protected branches — main/production branši prasa PR un apstiprināšanu
  • Required reviews — vismaz 1 (ieteicami 2) codeowner apstiprināšanas
  • Status checks — visi CI testi un drošības skenēšanas jāizpildās veiksmīgi pirms merge
  • Signed commits — GPG parakstīti commit novērš viltotus commit (commit spoofing)

OIDC autentifikācija

GitHub Actions OIDC token aizstāj ilgtermiņa static credentials. Workflow ģenerē īslaicīgu tokenu, kas pieprasa piekļuvi AWS/GCP/Azure tieši — bez glabātiem noslēpumiem.

Audita liecības un monitorings

Visi CI/CD notikumi jāreģistrē nemaināmā žurnālā:

  • Kas iniciēja deployment (lietotājs, automatizēts trigger)
  • Ko — kuru commit, kuru branch, kuru vidi
  • Kad — precīzs laiks ar timezone
  • Rezultāts — veiksmīgs/neveiksmīgs, kļūdu detaļas
  • Kas mainījās — CI konfigurācijas izmaiņas, jauni noslēpumi, piekļuves izmaiņas

Integrējiet ar SIEM (Splunk, DataDog, ELK) lai monitorētu anomālijas: neparasti deployment laiki, neautorizēti branši, masveidīgas konfigurācijas izmaiņas.

Biežāk uzdotie jautājumi

Kas ir DevSecOps?

Drošības integrēšana katrā izstrādes un operāciju solī — plānošanā, kodēšanā, testēšanā, deployment un monitoringā. Drošība nav atsevišķs posms beigās, bet nepārtraukts process. Praksē: SAST/DAST CI cauruļvadā, automātiska atkarību skenēšana, noslēpumu pārvaldība, infrastructure as code drošība.

Vai GitHub Secrets ir droši?

Jā, tie ir šifrēti ar libsodium, nav redzami logos un pieejami tikai workflow izpildes laikā. Bet: 1) regulāri rotējiet, 2) izmantojiet organization secrets kopīgiem noslēpumiem, 3) ierobežojiet ar environment protection rules, 4) neekspozējiet caur echo vai outputs.

Cik bieži jāskenē atkarības?

Katrā CI izpildē (npm audit) + Dependabot/Snyk automātiskas pārbaudes ik dienu. Kritiskās ievainojamības — nekavējoties labojiet. High severity — 48h ietvaros. Medium — nākamā sprinta laikā. Pinned versions + lockfile = papildu drošības slānis.

Kā aizsargāties pret supply chain uzbrukumiem?

1) npm audit + Snyk + Socket.dev katram CI build. 2) Lockfile stingri ievērots ar npm ci. 3) Privāts registry iespēja. 4) npm provenance verificēšana. 5) Regulāra atkarību audita meeting. 6) Minimāls atkarību skaits — katrai jaunai pakotne jautājiet: vai mums tiešām vajag?

Vai SAST pietiek, vai vajag arī DAST?

Abi nepieciešami. SAST analizē kodu statili (atrod injekcijas, nedrošas patterns) — ātrs, CI-friendly. DAST testē darbojošos aplikāciju (atrod XSS, CSRF, autentifikācijas problēmas) — precīzāks, bet lēnāks. SAST katram PR, DAST staging vidē pirms production deployment.

CI/CDsecuritypipelineDevSecOps

Gatavi sakārtot sava uzņēmuma digitālo klātbūtni?

Pieteiciet bezmaksas konsultāciju un kopā atradīsim piemērotāko risinājumu jūsu uzņēmumam.