Eredu tradizionala eta bere kostuak
Software-garapen eredu klasikoan, segurtasuna ekoizpeneko inplementazioaren aurretik sistema frogatzen zuen talde espezializatuaren eremua zen. Aurkitutako ahultasunek lanaren desbideratze garestiak sortzen zituzten — programatzaileek aspaldi itxitako zereginetatik atzera joan, asteetako testuingurua ulertu eta dagoeneko probatutako beste elementuei eragiten zieten aldaketak sartu behar zituzten. Frustrazioa elkarrekikoa zen: segurtasun-taldea blokeoa bezala hautematen zen, programatzaileak kode segurua idazteko prestatu gabeak bezala.
Shift-left filosofia
Shift-left-ek literalki segurtasun-jarduerak proiektuaren denbora-ardatzean ezkerrera mugitzea esan nahi du — proba eta inplementazio fasetik diseinu eta kodifikazio fasera. Zenbat eta lehenago detektatu ahultasun bat, orduan eta merkeagoa eta sinpleagoa da kentzea. Programatzaile batek segundo gutxitan ahultasun-alerta ikusten duenean bere garapen-ingurunean kode problematikoa idatzi ondoren berehala konpontzen du, testuingurua galdu gabe eta talde osoaren lan-fluxua eten gabe.
Automatizazioa CI/CD pipeline-an
Shift-left integrazio eta emate jarraituaren pipeline-aren etapa bakoitzean segurtasun-kontrol automatikoak txertatuz gauzatzen da. Commit bakoitzak segurtasun-egiaztapen sekuentzia bat abiarazten du, ahultasun larriak detektatuz gero hurrengo etapara igarotzea blokeatzen duena.
- SAST (kode-analisi estatikoa) — iturburu-kodean ahultasunak detektatzen ditu exekutatu gabe: SQL injekzioak, deserializazio ez-seguruak, funtzio arriskutsuen erabilera
- SCA (softwarearen osaketaren analisia) — dependentziak aztertzen ditu ahultasun ezagunak detektatzeko, lizentziak egiaztatzen ditu, liburutegi zaharkituak detektatzen ditu
- Sekretuen eskaneoa — biltegian pasahitzen, API gakoen eta ziurtagirien ustekabeko bidalketa blokeatzen du
- DAST (analisi dinamikoa) — martxan dagoen aplikazioa proba-ingurunean frogatzen du, API eta web interfazeei erasoak simulatuz
- Edukiontzien eta azpiegituraren probak — Docker irudien konfigurazioa eta azpiegitura-definizioak segurtasun-erroreak detektatzeko egiaztatzen ditu
Segurtasuna kode gisa
Erakunde helduek segurtasun-politikak kode gisa tratatzen dituzte — biltegian gordetako konfigurazio-fitxategietan definitzen dituzte, berrikusketa eta probapean. Horrek esan nahi du WAF arauak, sare-politikak, anomalien detekzio-sistemen konfigurazioak eta RBAC politikak aplikazioaren kodearen zorroztasun berberarekin kudeatzen direla. Aldaketek berrikusketa eskatzen dute, historia auditagarria da eta rollback minututan posiblea da.
Kultura oinarri gisa
Tresnak kulturarik gabe ez dute emaitzarik ematen. DevSecOps-ek eskatzen du programatzaileek diseinu-erabakien ondorioak segurtasunerako ulertzea eta alertak oztopo gisa ez, feedback baliotsu gisa tratatzea. Horrek prestakuntzan inbertitzea, segurtasun-adituek diseinuan bazkide gisa (ez auditore gisa) eskuragarri egotea, neurri argiak eta ahultasunen gaineko erantzukizun partekatua esan nahi du. ESKOM.AI-k DevSecOps eredua aplikatzen du bere sistemen garapenean, proben automatizazioa garapen-zikloaren etapa bakoitzean segurtasunaren gaineko erantzukizun partekatuaren kulturarekin uztartuz.