Techninis due diligence nėra kodo grožio konkursas. Jo tikslas — suprasti, ar technologija gali saugiai palaikyti planuojamą verslo scenarijų, kiek kainuos paslėptos rizikos ir ar komanda geba sistemą valdyti. Žemiau pateiktą struktūrą naudočiau vertindamas produktą prieš investiciją, įsigijimą arba agresyvesnį augimo etapą.
Po patikros turite gebėti atsakyti
- Kurios trys rizikos gali sustabdyti augimą per artimiausius 12 mėnesių?
- Kiek laiko ir biudžeto reikės kritinėms spragoms uždaryti?
- Ar produktas priklauso nuo vieno žmogaus, tiekėjo ar neaprašyto proceso?
- Kokius įrodymus turime, o kur remiamės tik komandos teiginiais?
1. Pradėkite nuo verslo scenarijaus, ne nuo repozitorijos
Tas pats kodas gali būti pakankamas 500 klientų produktui ir pavojingas platformai, kuri po finansavimo turi aptarnauti 100 000 vartotojų. Todėl pirmiausia užrašykite 12–24 mėnesių verslo scenarijų: vartotojų augimą, geografiją, mokėjimų apimtį, reguliacinius reikalavimus ir planuojamą komandą.
Audito klausimai turi būti susieti su šiuo scenarijumi. Jei planuojama plėtra į naują rinką, svarbi duomenų rezidencija ir lokalizacija. Jei augs transakcijų skaičius, svarbiausi tampa mokėjimų būsenų vientisumas, audito pėdsakas ir incidentų valdymas.
- Koks konkretus augimo scenarijus vertinamas?
- Kurios funkcijos generuoja pajamas arba mažina kritinę riziką?
- Kokie SLA ir prieinamumo lūkesčiai realiai reikalingi?
- Kokie duomenys yra jautrūs ir kas turi teisę juos pasiekti?
2. Susikurkite įrodymų kambarį
Interviu yra naudingi, bet jie nėra įrodymas. Gera patikra remiasi artefaktais: architektūros schema, diegimo istorija, incidentų žurnalu, prieigos matrica, stebėsenos ekranais ir realiu atsarginės kopijos atkūrimo bandymu.
Paprašykite komandos parodyti vieno pakeitimo kelią nuo užduoties iki produkcijos. Tada vieno incidento kelią nuo signalo iki sprendimo. Šios dvi demonstracijos dažnai atskleidžia daugiau nei ilgas technologijų sąrašas.
- Sistemos ir duomenų srautų schema su savininkais
- CI/CD eiga, testų rezultatai ir paskutinių diegimų istorija
- Produkcijos stebėsena, perspėjimai ir incidentų retrospektyvos
- Naudotojų rolių bei privilegijuotų prieigų sąrašas
- Atsarginių kopijų politika ir paskutinio atkūrimo įrodymas
- Trečiųjų šalių paslaugos, licencijos ir kritinės priklausomybės
3. Vertinkite šešias rizikos sritis
Architektūra parodo, ar sistema turi aiškias ribas ir ar brangiausios vietos gali būti keičiamos atskirai. Saugumas parodo, ar prieigos, paslaptys ir auditas valdomi sistemiškai. Duomenys atskleidžia, ar informacija patikima, atkuriama ir teisėtai valdoma.
Likusios trys sritys dažnai nepelnytai pamirštamos: pristatymo procesas, produkcijos operacijos ir žmonių priklausomybės. Puikus kodas nepadeda, jei tik vienas žmogus moka jį įdiegti arba incidentai pastebimi iš klientų laiškų.
- Architektūra: ribos, mastelio kliūtys, sinchroniniai priklausomybių taškai
- Saugumas: autentifikacija, autorizacija, paslaptys, pažeidžiamumai, auditas
- Duomenys: kokybė, migracijos, saugojimas, atsarginės kopijos, nuosavybė
- Pristatymas: testai, peržiūros, diegimai, grąžinimas į ankstesnę versiją
- Operacijos: metrikos, perspėjimai, incidentai, pajėgumai ir kaštai
- Komanda: sistemos savininkai, dokumentacija, vieno žmogaus rizika
4. Riziką skaičiuokite vienodu principu
Kad auditas nevirstų nuomonių sąrašu, kiekvienai išvadai skirkite tikimybės ir poveikio balą nuo 1 iki 5. Padauginti balai suteikia bendrą prioritetą. Pridėkite aptikimo sudėtingumą, jei problema gali ilgai likti nematoma, pavyzdžiui, tylus finansinių duomenų neatitikimas.
Kartu užrašykite pasitikėjimo lygį: aukštą, jei išvada patvirtinta produkcijos įrodymais; vidutinį, jei turite dokumentus; žemą, jei remiatės interviu. Tai apsaugo nuo klaidingo tikslumo.
5. Gera išvada yra sprendimo dokumentas
Galutinis rezultatas neturėtų būti 80 puslapių techninė ataskaita. Sprendimų priėmėjui reikia vieno puslapio santraukos: kas veikia, kas gali sužlugdyti planą, kiek kainuos sutvarkyti ir ką daryti per pirmąsias 30, 60 bei 90 dienų.
Atskirkite sandorį stabdančias rizikas nuo įprastos techninės skolos. Beveik kiekvienas veikiantis produktas turi skolų. Esminis klausimas — ar jos žinomos, valdomos ir proporcingos verslo etapui.
- 3–5 svarbiausios išvados verslo kalba
- Rizikų registras su savininku ir įrodymų nuorodomis
- Remediacijos kaštų intervalas, ne tariamai tikslus skaičius
- 30/60/90 dienų veiksmų planas
- Aiškiai įvardytos prielaidos ir nepatikrintos sritys
Naudokite savo komandoje
40 punktų greitoji patikra
Pažymėkite punktą tik tada, kai turite konkretų įrodymą — dokumentą, metriką, demonstraciją ar atsakingo žmogaus patvirtintą procesą.
- 01Yra aktuali sistemos ir duomenų srautų schema
- 02Kiekvienas kritinis komponentas turi savininką
- 03Aiškios sistemos ribos ir integracijų sutartys
- 04Žinomos dabartinės talpos ir mastelio ribos
- 05Nėra nevaldomo vieno tiekėjo užrakto
- 06Technologijų pasirinkimai atitinka komandos gebėjimus
- 07Autentifikacija centralizuota ir dokumentuota
- 08Autorizacija tikrinama serveryje
- 09Privilegijuotos prieigos peržiūrimos
- 10Paslaptys nelaikomos kode
- 11Priklausomybės reguliariai skenuojamos
- 12Saugumo įvykiai palieka audito pėdsaką
- 13Asmens duomenys inventorizuoti
- 14Duomenų saugojimo terminai apibrėžti
- 15Migracijos versijuojamos ir pakartojamos
- 16Atsarginės kopijos šifruojamos
- 17Atkūrimas realiai išbandytas
- 18Kritinių duomenų kokybė matuojama
- 19Pagrindiniai srautai turi automatinius testus
- 20Kodo pakeitimai peržiūrimi
- 21Diegimas automatizuotas
- 22Yra patikrintas grįžimo planas
- 23Aplinkos atskirtos
- 24Produkcijos pakeitimai atsekami
- 25Verslo KPI matomi kartu su techninėmis metrikomis
- 26Kritiniai perspėjimai turi savininką
- 27Incidentai dokumentuojami
- 28Yra aiški eskalavimo tvarka
- 29Debesijos kaštai priskiriami produktams ar funkcijoms
- 30Talpos planas atitinka augimo scenarijų
- 31Žinomos visos kritinės trečiųjų šalių paslaugos
- 32Licencijos leidžia planuojamą naudojimą
- 33Tiekėjų gedimams numatyti atsarginiai scenarijai
- 34Kritiniai procesai nepriklauso nuo vieno žmogaus
- 35Naujokas gali paleisti projektą pagal dokumentaciją
- 36Atsakomybės tarp produkto ir technologijų aiškios
- 37Techninė skola registruojama ir prioritetizuojama
- 3890 dienų planas turi realius savininkus
- 39Remediacijos biudžetas įtrauktas į finansinį modelį
- 40Neapibrėžtumai aiškiai atskirti nuo patvirtintų faktų
FAQ
Dažniausi klausimai
Kiek trunka techninis due diligence?+
Tikslinė mažo ar vidutinio produkto patikra dažniausiai telpa į 5–10 darbo dienų, jei komanda greitai pateikia įrodymus. Sudėtinga, reguliuojama ar kelių produktų aplinka reikalauja daugiau laiko.
Ar būtina peržiūrėti visą kodą?+
Ne. Efektyviau pradėti nuo rizikos hipotezių ir tikslinių reprezentatyvių sričių: prieigų, mokėjimų, duomenų, kritinių srautų bei diegimo. Pilna eilutė-po-eilutės peržiūra retai proporcinga naudai.
Kuo techninis auditas skiriasi nuo due diligence?+
Auditas dažnai optimizuoja esamą sistemą komandos poreikiams. Due diligence padeda priimti konkretų investicijos, įsigijimo ar partnerystės sprendimą ir riziką išverčia į komercines pasekmes.
Kas turėtų atlikti patikrą?+
Žmogus, turintis realios architektūros ir produkcijos operacijų patirties, bet nepriklausantis vertinamo produkto komandai. Saugumo ar reguliuojamoms sritims verta pasitelkti atskirus specialistus.
Pirminiai šaltiniai
Tolimesniam techniniam gilinimuisi:
OWASP Application Security Verification Standard