EDUCATION, SECURE, DEVELOPMENT

🔐 Droša programmatūras izstrāde

Sešas tēmas par to, kā izstrādāt drošu programmatūru - no Secure by Design principiem līdz CI/CD drošības vārtiem un piegādes ķēdes integritātei - pēc starptautiskās prakses (CISA, NIST SSDF, OWASP, SLSA). Piemēri ir vispārīgi, paredzēti apmācībām.

Drošība kā projektēšanas prasība

Secure by Design un Secure by Default

Trūkuma novēršanas izmaksas pa dzīves cikla fāzēm Stabiņu diagramma - jo vēlāk fāzē (prasības → projektēšana → izstrāde → testēšana → ražošana) atrod trūkumu, jo augstākas relatīvās novēršanas izmaksas. Drošība iebūvēta, ne uzlīmēta Jo vēlāk atrod trūkumu, jo dārgāk to novērst (relatīvās izmaksas, ilustratīvi) Shift-left: atrodi un novērsi pēc iespējas agrāk ×1 Prasības ×5 Projektēšana ×10 Izstrāde ×15 Testēšana ×30+ Ražošana CISA Secure by Design (2023), NIST SSDF SP 800-218, Saltzer & Schroeder principi

Secure by Design nozīmē drošību kā prasību no pirmās dienas; Secure by Default nozīmē drošus noklusējumus (piem. MFA ieslēgts, porti slēgti), lai lietotājam nekas nav jāaktivizē manuāli.

Praksē

Drošība ir biznesa prasība, ne papildu funkcija. Galvenie principi: minimāla uzbrukuma virsma, mazākās privilēģijas, daudzslāņu aizsardzība, droša atteice (fail securely) un droši noklusējumi.

Atsauce

CISA "Secure by Design" (2023), NIST SSDF (SP 800-218), OWASP, Saltzer & Schroeder (1975) drošības projektēšanas principi.

Drošības piezīme

Atbildība par drošību pieder ražotājam, ne lietotājam. Drošība, kas jāieslēdz manuāli, praksē paliek izslēgta - tāpēc noklusējumam jābūt drošam.

Drošs izstrādes dzīves cikls (SSDLC)

Drošības darbība katrā fāzē

Droša izstrādes dzīves cikla fāzes Sešas fāzes ar iebūvētu drošības darbību - prasības, projektēšana, izstrāde, testēšana, izvietošana, uzturēšana. Drošs izstrādes dzīves cikls Drošība nav atsevišķs posms beigās - tā caurvij visu ciklu 1. Prasības - Drošības prasības - Ļaunprātīgas lietošanas gadījumi - Atbilstības prasības 2. Projektēšana - Draudu modelēšana (STRIDE) - Drošības arhitektūra - Uzbrukuma virsmas analīze 3. Izstrāde - Drošs kods + koda pārskats - SAST (statiskā analīze) - SCA (atkarību pārbaude) 4. Testēšana - DAST (dinamiskā analīze) - Ielaušanās tests - Fuzzing 5. Izvietošana - Droša konfigurācija - Noslēpumu pārvaldība - SBOM + parakstīšana 6. Uzturēšana - Ielāpu pārvaldība - Monitorings un žurnāli - Incidentu reaģēšana Cikls atkārtojas - atziņas no uzturēšanas kļūst par jaunām prasībām Microsoft SDL, NIST SSDF SP 800-218, OWASP SAMM, BSIMM, ISO/IEC 27034

Praksē

Katrai fāzei sava drošības darbība un atbildīgais. Kartējams uz atzītiem ietvariem - Microsoft SDL, NIST SSDF praksēm (PO, PS, PW, RV) un OWASP SAMM brieduma domēniem.

Atsauce

NIST SSDF SP 800-218, Microsoft Security Development Lifecycle, OWASP SAMM, BSIMM, ISO/IEC 27034 (aplikāciju drošība).

Drošības piezīme

Draudu modelēšana projektēšanas fāzē atrod arhitektūras trūkumus, ko neviens koda skeneris neredz - tie ir visdārgākie labot vēlāk.

Drošas kodēšanas prakse

Izplatītākie riski (OWASP Top 10) un aizsardzība

OWASP Top 10 riski un to aizsardzība Tabula ar izplatītākajiem tīmekļa lietojumu riskiem kreisajā pusē un attiecīgo drošas kodēšanas aizsardzību labajā pusē. Risks → aizsardzība Drošs kods novērš izplatītākos vājumus jau rakstīšanas laikā RISKS (OWASP Top 10) AIZSARDZĪBA Bojāta piekļuves kontrole Autorizācija servera pusē katram pieprasījumam Kriptogrāfijas kļūdas TLS 1.3, pārbaudīta kriptogrāfija Injekcija (SQL/komandu) Parametrizēti vaicājumi, ievades validācija, izvades kodēšana Nedrošs dizains Draudu modelēšana, drošības prasības projektā Nedroša konfigurācija Droši noklusējumi, hardening, minimāla virsma Novecojušas komponentes SCA, regulāra atkarību atjaunināšana Autentifikācijas kļūdas MFA, droša sesiju pārvaldība, rate-limit Datu integritātes kļūdas Parakstīti artefakti, uzticami atkarību avoti Nepietiekama žurnalēšana Drošības notikumu reģistrēšana un brīdinājumi OWASP Top 10:2021, OWASP ASVS, OWASP Cheat Sheets, CWE Top 25, SEI CERT

Praksē

Praktisks kontrolsaraksts izstrādātājam un koda pārskatam. OWASP ASVS dod pārbaudāmas prasības trīs līmeņos (L1-L3) atkarībā no lietotnes kritiskuma.

Atsauce

OWASP Top 10:2021, OWASP Application Security Verification Standard (ASVS) 5.0 (2025), OWASP Cheat Sheet Series, CWE Top 25, SEI CERT Coding Standards.

Drošības piezīme

Nekad neuzticies ievadei un neraksti pats savu kriptogrāfiju. Validē ievadi serverī (ne tikai pārlūkā) un lieto pārbaudītas bibliotēkas.

DevSecOps - drošība konveijerā

Automatizēti drošības vārti katrā posmā

CI/CD konveijers ar drošības vārtiem Seši konveijera posmi no pirms-commit līdz izpildlaikam, katrs ar automatizētu drošības vārtu; shift-left bulta norāda drošību pēc iespējas agrāk. CI/CD konveijers ar drošības vārtiem Katrs vārts automatizēts un bloķējošs - drošība neatkarīga no cilvēka atmiņas Shift-left: drošība pēc iespējas agrāk Pirms-commit Commit / PR Būve Tests Izvietošana Izpildlaiks noslēpumu skenēšana lint SAST, SCA koda pārskats SBOM parakstīšana DAST, IAST integrācijas testi IaC skenēšana konfig audits monitorings WAF / RASP Vārts, kas neizdodas → konveijers apstājas (build fails) OWASP Top 10 CI/CD Security Risks, NIST SSDF, SLSA, DevSecOps prakse

Izmaiņa konveijerā soli pa solim

Kur automātiskie vārti var apturēt izmaiņu. Zaļā piezīme rāda, kad vārti to aptur.

Viena izmaiņa ceļā uz produkciju

  1. 1
    IzstrādātājsPirms commit: noslēpumu skenēšana lokāli

    Atslēga, kas nonāk git vēsturē, ir jāmaina - dzēšana no vēstures nepalīdz.

  2. 2
    Izstrādātājs → CIpull request

    Vārti aptur, ja: kodā atrasts noslēpums vai SAST atrod kritisku kļūdu

    Konveijers sāk automātiskās pārbaudes. Ja vārti krīt, izmaiņa tālāk netiek.

  3. 3
    CISAST kodam, SCA atkarībām, otrs cilvēks pārskata

    Rīki atrod zināmus paraugus, cilvēks - loģikas kļūdas, ko rīki neredz.

  4. 4
    CIBūvē attēlu → skenē → SBOM → paraksta

    SBOM ir sastāvdaļu saraksts. Paraksts pierāda, ka attēls nāk tieši no šī konveijera.

  5. 5
    CI → Videparakstīts attēls + SBOM

    Vārti aptur, ja: paraksts neatbilst vai attēlā ir kritiska ievainojamība

    Vide pieņem tikai parakstītus attēlus - ar roku uzbūvēts attēls netiek palaists.

  6. 6
    VideDAST testa vidē: pārbauda strādājošu lietotni no ārpuses

    Atrod to, kas redzams tikai darbībā: konfigurāciju, galvenes, autentifikāciju.

  7. 7
    VideIzlaišana produkcijā ar iespēju atgriezties pie iepriekšējās versijas

    Ja kaut kas noiet greizi, atgriešanās ir viens solis, ne jauna būve.

  8. 8
    PiezīmePats konveijers ir mērķis: minimālas tiesības, noslēpumi ārpus koda, pārbaudītas trešo pušu darbības

    Kas pārņem konveijeru, tas var piegādāt savu kodu visiem lietotājiem.

Praksē

Katrs drošības rīks kļūst par automātisku konveijera vārtu. Tā drošība mērogojas ar izstrādi, nevis paļaujas uz manuālu pārbaudi termiņa spiedienā.

Atsauce

OWASP Top 10 CI/CD Security Risks, NIST SSDF SP 800-218, SLSA, DevSecOps (kultūra + automatizācija).

Drošības piezīme

Pats konveijers ir mērķis - aizsargā būves noslēpumus, ierobežo konveijera darbu atļaujas un pārbaudi trešo pušu darbības (GitHub Actions u.c.), lai konveijeru nevarētu kompromitēt.

Automatizētā drošības testēšana

SAST, SCA, DAST, IAST - kurš ko atrod

Drošības testēšanas metožu salīdzinājums Sešas automatizētas drošības testēšanas metodes ar to, ko katra analizē un kad konveijerā tā darbojas. Testēšanas metodes salīdzinājums Neviena metode viena pati neatrod visu - tās papildina cita citu SAST Statiskā pirmkoda analīze Kad: commit / būve Baltā kaste (white-box) Daudz viltus-pozitīvu SCA Atkarības un bibliotēkas Kad: commit / būve Zināmās CVE + licences Balstās uz SBOM Noslēpumu skenēšana Noslēpumi kodā un vēsturē Kad: pirms-commit API atslēgas, paroles Novērš noplūdi git vēsturē DAST Darbojošos lietotni Kad: tests / staging Melnā kaste (black-box) Izpildlaika vājības IAST Instrumentēts izpildlaiks Kad: funkcionālie testi Pelēkā kaste (grey-box) Precīzāk, mazāk viltus Konteineru / IaC Attēli + infrastruktūras kods Kad: būve / izvietošana Nedroši attēli, konfig CIS benchmarks OWASP, NIST SSDF SP 800-218 (RV grupa), fuzzing (OSS-Fuzz) papildina dinamisko testēšanu

Praksē

Kombinē metodes atbilstoši konveijera posmam: statiskās (SAST/SCA/secret) agri, dinamiskās (DAST/IAST) testos, infrastruktūras skenēšana pirms izvietošanas.

Atsauce

OWASP (testēšanas rīki - ZAP, Dependency-Check), NIST SSDF SP 800-218, CIS Benchmarks, OSS-Fuzz (nepārtraukta fuzzing).

Drošības piezīme

Rīki atrod zināmos šablonus, ne biznesa loģikas kļūdas. Automatizētā testēšana nepārbauda, vai piekļuves kontrole ir loģiski pareiza - to atrod manuāls pārskats un ielaušanās tests.

Programmatūras piegādes ķēdes integritāte

SBOM, parakstīšana un SLSA līmeņi

Piegādes ķēdes integritātes kontroles un SLSA līmeņi Augšā piegādes ķēdes plūsma no avota līdz izvietošanai ar integritātes kontroli katrā solī; zem tās SLSA būves līmeņi no L0 līdz L3. Piegādes ķēde: integritāte no avota līdz izvietošanai Pierādi, KO tu palaid un NO KURIENES tas nāk Avots versiju kontrole 2-personu pārskats Būve (build) izolēta, atkārtojama izcelsme (provenance) Artefakts SBOM (CycloneDX/SPDX) paraksts (Sigstore) Izvietošana verificē parakstu pārbauda izcelsmi SLSA būves līmeņi - pieaugoša būves integritāte L0 Nav garantiju nav izcelsmes pieraksta sākumpunkts L1 Izcelsme (provenance) pieejama un dokumentēta automatizēta būve L2 Parakstīta izcelsme pārvaldīta būves platforma grūtāk viltot L3 Neviltojama izolēta būve augstākā garantija SLSA v1.0, NIST SSDF SP 800-218, US EO 14028, EU CRA, in-toto attestations SBOM = sastāvdaļas, izcelsme (provenance) = kā tas uzbūvēts, paraksts = kas to izlaida

Praksē

SBOM ļauj ātri atbildēt "vai mūs skar šī CVE?"; izcelsme (provenance) un paraksts pierāda, ka artefakts (būves gala fails) nāk no uzticama, neviltota būves procesa. Kopā tie aizsargā piegādes ķēdi.

Atsauce

SLSA v1.0, NIST SSDF SP 800-218, SPDX / CycloneDX (SBOM formāti), Sigstore/cosign, in-toto, US EO 14028, EU Cyber Resilience Act (Regula (ES) 2024/2847): ziņošana par aktīvi izmantotām ievainojamībām no 2026. gada 11. septembra, pilnas prasības no 2027. gada 11. decembra.

Drošības piezīme

Lielākā daļa koda ir trešo pušu atkarības. SolarWinds un līdzīgi incidenti rāda - kompromitēta būve vai atkarība apiet visu pārējo aizsardzību. Verificē pirms palaišanas.

Saīsinājumi

Visu ceļvedī lietoto saīsinājumu atšifrējumi (oriģināls un nozīme).

SDLC
Software Development Life Cycle - programmatūras izstrādes dzīves cikls.
SSDLC
Drošs SDLC - dzīves cikls ar iebūvētu drošību.
SDL
Security Development Lifecycle - Microsoft drošas izstrādes process.
SSDF
Secure Software Development Framework - NIST SP 800-218 ietvars.
SAMM
Software Assurance Maturity Model - OWASP brieduma modelis.
BSIMM
Building Security In Maturity Model - reālās prakses mērījums.
SAST
Static Application Security Testing - statiskā pirmkoda analīze.
DAST
Dynamic Application Security Testing - darbojošās lietotnes tests.
IAST
Interactive Application Security Testing - instrumentēts izpildlaika tests.
SCA
Software Composition Analysis - atkarību/komponenšu analīze.
RASP
Runtime Application Self-Protection - izpildlaika pašaizsardzība.
WAF
Web Application Firewall - tīmekļa lietojumu ugunsmūris.
DevSecOps
Drošība iestrādāta DevOps kultūrā un automatizācijā.
CI/CD
Nepārtraukta integrācija / piegāde (konveijers).
IaC
Infrastructure as Code - infrastruktūra kā kods.
SBOM
Software Bill of Materials - programmatūras sastāvdaļu saraksts.
SLSA
Supply-chain Levels for Software Artifacts - piegādes ķēdes līmeņi.
CWE
Common Weakness Enumeration - programmatūras vājību klasifikācija.
CVE
Common Vulnerabilities and Exposures - publiskais ievainojamību reģistrs.
ASVS
OWASP Application Security Verification Standard.
STRIDE
Draudu modelēšanas kategorijas (Microsoft).
MFA
Multi-Factor Authentication - vairākfaktoru autentifikācija.
TLS
Transport Layer Security - transporta slāņa šifrēšana.
CRA
EU Cyber Resilience Act - ES kibernoturības regula.
provenance
Izcelsmes pieraksts - kā un no kā artefakts uzbūvēts (SLSA).
artefakts
Būves gala rezultāts - izpildfails, pakotne vai konteinera attēls.
build
Būve - pirmkoda pārvēršana palaižamā artefaktā.