Turvalise arenduse dokumendipakett – SSDLC, OWASP Top 10 ja audit-ready register (ISO 27001, NIS2, KüTS)
Sest SQL injection on OWASP Top 10 nimekirjas olnud alates 2003. aastast — mitte sellepärast, et keegi ei teaks, mis see on. Vaid sellepärast, et protsess puudub.
See dokumendipakett aitab sul panna protsess paika — enne järgmist kasutuselevõttu.
Komplekt: 3 dokumenti — saad emailile
1. Milleks see dokumentide pakett on?
Enamik turvaprobleeme ei tule keerulistest zeroday rünnetest. Need tulevad arendajast, kes lisas API võtme koodi "ajutiselt". Kasutajasisendist, mis läks otse SQL pärigusse ilma valideerimiseta. Teegist, mille kriitiline CVE avaldati kuus kuud tagasi — ja keegi ei uuendanud versiooni.
See pakett aitab sul:
- defineerida turvanõuded enne arendust
- rakendada OWASP Top 10 põhimõtteid igapäevases kodeerimises
- hallata saladusi (API võtmeid, paroole) nii, et need ei leki lähtekoodist
- tõendada audiitorile, et turvaline arendus toimub päriselt
Tulemus: arendus, mis päriselt kaitseb — mitte lihtsalt "arvasime, et on turvaline".
2. Kellele see sobib?
See pakett on mõeldud organisatsioonidele, kes:
- arendavad tarkvara — olgu see suur rakendus või sisemine skript, mis puudutab kliendiandmeid
- peavad vastama NIS2, KüTS või ISO 27001 nõuetele
- ei suuda kohe vastata küsimusele "kus hoiate API võtmeid ja kas koodis on saladusi?"
- ei jälgi automaatselt, kas kasutatavates komponentides on uusi CVE-sid
Sobib eriti:
- arendusjuhile, kes vastutab arenduse turvalisuse eest
- infoturbejuhile (CISO), kes paketi kasutusele võtab ja vastavust jälgib
- tarkvaraarendajale, kes tahab teada, mida turvaline arendus päriselt tähendab
- juhtkonnale, kes vastutab — KüTS § 6¹ järgi isiklikult
Kui sinu organisatsioonis on "arendus tegeleb turvalisusega" vastus küsimusele "kes vastutab?" — see pakett on sinu jaoks.
3. Mida saad?
See ei ole lihtsalt poliitika. See on täielik turvalise arenduse süsteem.
Pakett sisaldab 4 omavahel seotud dokumenti:
3.1. Turvalise arenduse dokumentide juhend
Selgitab, kuidas kõik dokumendid koos töötavad:
- kolme variandi loogika (A täielik / B lihtsustatud / C minimaalne) — milline sobib millisele projektile
- SSDLC kuue etapi ülevaade variantide kaupa
- välistab klassikalise vea: poliitika on kinnitatud, aga arendajad ei tea, mida see tähendab igapäevatöös
3.2. Turvalise arenduse poliitika vorm
Juhtkonna taseme otsuste dokument:
- rakendatavuse tabel 6 arenduse tüübiga
- variant (A/B/C) iga arenduse tüübi jaoks — juhtkond otsustab, mis proportsionaalne on
- lähtekoodile juurdepääsu kontroll
- keskkondade eraldamine
- mõõdikud
- rollid
3.3. Turvalise arenduse protseduuri vorm — SSDLC
Arendaja ja arendusjuhi käsiraamat. Seitse etappi samm-sammult, variandi kaupa:
- Etapp 1 — Nõuded
- Etapp 2 — Ohuanalüüs
- Etapp 3 — Kodeerimine
- Etapp 4 — Koodiülevaatus
- Etapp 5 — Turvatestid
- Etapp 6 — Kasutuselevõtt
- Etapp 7 — Hooldus
3.4. Turvalise arenduse kontrollnimekirja ja registri. vorm
Audiitori esimene küsimus — ja sinu elav tõenddokument. Kolm töölehte:
- Projektiregister
- SSDLC kontrollnimekiri
- Haavatavuste logi
4. KKK
Kas meil on seda vaja, kui me ei ole tarkvara arendusettevõte? Kui sinu organisatsioon arendab mingit tarkvara — kasvõi sisemisi tööriistu, automatiseerimise skripte või veebirakendusi — siis jah. Eeltingimus ei ole "tarkvara arendusettevõte" — eeltingimus on "arendame tarkvara".
Kas Variant C on piisav väikestele projektidele? Variant C katab OWASP Top 10 kontrollnimekirja, automaatse skaneerimise ja dokumenteeritud kasutuselevõtu. See on rohkem, kui enamik väikestest projektidest täna teeb. Kui projekt puudutab isikuandmeid — vali vähemalt Variant B.
Kas see sobib, kui meie arendajad kasutavad juba SonarQube'i? Jah — protseduuris (C4.18.2) on märgitud, kuidas olemasolevaid tööriistu dokumenteerida. Pakett ei nõua kindlaid tööriistu — nõuab protsessi, mille tööriist toetab.
5. Õiguslik teave
Dokument on näidismaterjal ja praktiline töövahend, mis vajab kohandamist vastavalt organisatsiooni tegevusele, struktuurile ja riskitasemele. Dokument ei kujuta endast õigusnõustamist ega asenda ametlikke juhiseid või järelevalveasutuse nõudeid.
Toote kasutamisel kehtivad Defending Data litsentsitingimused ja kasutus- ja ostutingimused.
6. Taganemisõigus
Digitaalse sisu puhul ei kohaldu 14-päevane taganemisõigus, kui tarbija on andnud nõusoleku sisu koheseks edastamiseks (VÕS § 53 lg 4).
Defending Data dokumendid on loodud juhatuse, mitte bürokraatia jaoks.