Saugumas programinės įrangos kūrime ir „DevSecOps“

Informatec Digital » Ištekliai » Saugumas programinės įrangos kūrime ir „DevSecOps“

Programinės įrangos saugumas nebėra pasirenkamas priedas, pridedamas projekto pabaigoje, o pagrindinis komponentas nuo pat pirmojo programos eskizo. Pasaulyje, kuriame kodas diegiamas kelis kartus per dieną ir kuriame kibernetinės atakos tampa vis sudėtingesnės, tolesnis pasikliavimas paskutinės minutės rankinėmis peržiūromis yra tiesus kelias į katastrofą.

Saugumo integravimas į visą kūrimo gyvavimo ciklą (nuo pradinės koncepcijos iki gamybinės priežiūros) yra tokių metodų kaip „DevSecOps“, kūrėjui skirtas saugumas ir saugūs SDLC modeliai iš tokių sistemų kaip OWASP SAMM arba NIST SSDF pagrindas. Tikslas yra paprastas, bet sudėtingas pasiekti: sukurti saugią programinę įrangą pagal dizainą, netrukdant verslo lankstumui ir neužkertant kelio saugumui tapti kliūtimi.

Kas yra saugumas programinės įrangos kūrime ir kodėl jis svarbus?

Kalbėdami apie programinės įrangos kūrimo saugumą, turime omenyje visas praktikas, įrankius ir procesus, taikomus siekiant užtikrinti, kad programa atlaikytų atakas, išsaugotų duomenų vientisumą ir palaikytų paslaugų prieinamumą per visą jos gyvavimo ciklą. Kalbama ne tik apie „užkardos įdiegimą“ ar šifravimo naudojimą, bet ir apie programinės įrangos projektavimą bei programavimą taip, kad saugumo pažeidžiamumas būtų mažesnis.

Kenkėjiškų programų atakos ir programinės įrangos pažeidžiamumai gali pakenkti autentifikavimui, autorizavimui, vientisumui ir konfidencialumui. Jei šios grėsmės bus pašalintos projektavimo etape, daugelį jų bus galima sušvelninti, kol jos netaps problema gamyboje, taip užkertant kelią avariniams pataisymams ir duomenų nutekėjimui.

Pagrindinė idėja yra ta, kad kiekviena programinė įranga turėtų būti patikrinta saugumo požiūriu prieš pasiekiant vartotoją, ir kad šie testai neturėtų būti izoliuotas „filtras“, o įprasta kiekvienos versijos dalis. Tai sukuria atsparesnę programinę įrangą, kuriai nereikia kaupti papildomų saugumo sluoksnių, kai aptinkami pažeidžiamumai.

Galutinis tikslas – sukurti saugias programas , kurių architektūra būtų integruota į kontrolę, atliekamas dažnas automatizuotas testavimas ir kultūra, kurioje kūrėjai, saugumo ir operacijų specialistai veiktų kartu. Tam reikia sąmoningų visos techninės komandos, o ne tik nedidelės kibernetinio saugumo specialistų grupės, pastangų.

„DevSecOps“ ir kūrėjams skirtas saugumas

Terminas „DevSecOps“ atsirado siekiant išspręsti labai specifinę problemą: tradiciniai modeliai, kai saugumo komanda prisijungdavo tik kūrimo ciklo pabaigoje, nebeatitiko dažniems leidimams, lanksčioms metodikoms ir CI/CD srautams. Anksčiau programos atnaujinimas kartą ar du per metus leido atlikti išsamią peržiūrą; dabar, nuolat diegiant, šis metodas tapo nepriimtina kliūtimi.

„DevSecOps“ skatina sklandų saugumo integravimą į „Agile“ ir „DevOps“ , kad programų ir infrastruktūros saugumas būtų sprendžiamas nuo pat pradžių ir nuolat. Idėja yra aptikti ir ištaisyti pažeidžiamumus, kai tik jie atsiranda, kai juos dar galima nebrangiai pašalinti, o ne atrasti juos prieš pat diegimą.

Be to, „DevSecOps“ propaguoja saugumą kaip bendrą atsakomybę : kūrimo, operacijų ir saugumo specialistai glaudžiai bendradarbiauja, o ne dirba atskirai, bendraujant tik pabaigoje. Šio požiūrio šūkis dažnai apibendrinamas kaip „programinė įranga – saugesnė, greitesnė“: teikti greitesnę ir saugesnę programinę įrangą automatizuojant valdiklius ir mažinant trintį kūrimo gyvavimo cikle.

Pagrindinis šios filosofijos ramstis yra į kūrėją orientuotas saugumas . Užuot proceso pabaigoje saugumo komandai atlikus „policijos pajėgų“ vaidmenį, saugumo įrankiai priartinami prie kūrėjų darbo aplinkos, pavyzdžiui, integruojant skaitytuvus į IDE arba versijų valdymo sistemą. Tokiu būdu dalis analizės, testavimo ir pataisymų atliekama tiesiai iš kūrėjo klaviatūros.

Toks „saugumo priartinimo prie kodo“ metodas leidžia aptikti ir ištaisyti pažeidžiamumus beveik iš karto po jų rašymo, nelaukiant periodinių auditų ar didelio masto įsiskverbimo testų. Dėl to kūrimo komandos nustoja laikyti saugumą nepatogumu, kuris sulėtina jų darbą, ir verčiau laiko jį pagrindiniu kokybės kriterijumi.

Saugumas yra integruotas į kiekvieną SDLC etapą.

Kad saugumas būtų tikrai veiksmingas, jis turi būti integruotas į visus kūrimo gyvavimo ciklo (SDLC) etapus, o ne traktuojamas kaip galutinis „kokybės patikrinimas“. Saugumo laikymas tik kaip rūpestis projekto pabaigoje sukuria kliūtį saugumo komandai, ypač todėl, kad jie negali būti visų šiandien naudojamų technologijų ir debesijos aplinkų ekspertai.

Šiuolaikinis požiūris siūlo saugumą, kuris yra „įaustas“ į visą programinės įrangos kūrimo ir kūrimo procesą (SDLC): nuo reikalavimų apibrėžimo, planavimo ir projektavimo iki įgyvendinimo, testavimo, diegimo ir priežiūros. Visa organizacija supranta, kad saugumas yra esminė produkto sėkmės dalis , o ne atskiras rūpestis, kurį galima atidėti.

Anksčiau saugumo peržiūros daugiausia buvo atliekamos rankiniu būdu ir buvo atliekamos kaip atskiri įrankiai kiekvienai programai ar paslaugai, derinantys taškinius skaitytuvus su įsiskverbimo testavimu. Šiandien įrankiai kuriami atsižvelgiant į integraciją ir automatizavimą: jie jungiasi prie CI/CD kanalų, incidentų stebėjimo sistemų ir kodo saugyklų, taip užtikrindami daug sklandesnį darbo eigą.

Pažeidžiamumų skaitytuvai yra integruoti į nuolatinio integravimo procesą, todėl kiekvienas kodo pakeitimas yra automatiškai analizuojamas prieš pereinant prie kito etapo. Tuo pačiu metu išvados registruojamos kaip įprastos užduotys, matomos visai komandai, todėl lengviau nustatyti prioritetus, stebėti ir matuoti sprendimo laiką.

Visa tai reiškia, kad saugumas nebėra antraeilis dalykas, o tampa struktūriniu SDLC komponentu . Užuot tiesiog „praėjus saugumo patikrą“ prieš pat diegimą, organizacija daro prielaidą, kad kiekvienas patvirtinimas, kiekvienas sujungimas ir kiekvienas pristatymas yra nuolatinės saugumo patikrų grandinės dalis.

Įprasta programinės įrangos saugumo praktika

Taikant šį darbo būdą, daugelis organizacijų jau įgyvendina arba pradeda taikyti keletą programinės įrangos saugumo iniciatyvų . Tai nėra išsamus sąrašas, tačiau jis padeda suprasti, kokias veiklas turėtume integruoti į programinės įrangos saugumo valdymo schemą (SDLC), kad sustiprintume saugumą.

Svarbus pirmasis žingsnis yra statinė kodo analizė (SAST). Tai apima šaltinio kodo (įskaitant infrastruktūrą kaip kodą) analizę, siekiant aptikti nesaugius programavimo modelius arba žinomus pažeidžiamumus. Paprastai tai automatizuotas procesas, kurį galima paleisti su kiekvienu pakeitimu arba įkėlimu, suteikiant kūrėjams beveik realiuoju laiku grįžtamąjį ryšį.

Kita vertus, dinaminė saugumo analizė (DAST ir panašūs metodai) įvertina visą programą ir jos pagrindinę infrastruktūrą jai veikiant. Tai apima, pavyzdžiui, prievadų nuskaitymą, skirtingų svetainių scenarijų testus, konteinerių konfigūracijos peržiūras ir interneto paslaugų analizę, siekiant nustatyti pažeidžiamumus, kurie matomi tik sistemai veikiant.

Kartu su automatizuotais įrankiais, rankinė kodo peržiūra išlieka svarbi. Nors daugelis funkcijų jau yra peržiūrimos siekiant nustatyti loginius trūkumus, įtraukus saugumo perspektyvą į šias kodo peržiūras, galima aptikti mažiau akivaizdžius pažeidžiamumus, kurių skaitytuvas gali nepastebėti. Tačiau tam reikia, kad komanda būtų apmokyta atakų modelių ir geriausios praktikos.

Įsilaužimo testavimas žengia dar vieną žingsnį: samdomi ekspertai, kurie atlieka užpuolikų vaidmenį ir bando pažeisti infrastruktūrą ar programas. Jie gali naudoti bet ką – nuo ​​automatizuotos analizės iki realių spragų išnaudojimo būdų, o rezultatas paprastai yra ataskaita, kurioje išsamiai aprašomi standartinių testų nepastebėti pažeidžiamumai ir pateikiamos konkrečios rekomendacijos, kaip juos sušvelninti.

Panašus, bet kitoks metodas yra klaidų pranešimo programos . Šis modelis kviečia tyrėjus ir patyrusius naudotojus pranešti apie pažeidžiamumus mainais už finansinį atlygį ar pripažinimą. Tai veiksmingas būdas perduoti trečiųjų šalių išvadas ir paversti potencialius užpuolikus bendradarbiais.

Galiausiai, neturime pamiršti techninių darbuotojų saugumo mokymų . Grėsmių kraštovaizdis sparčiai keičiasi: tai, kas atrodė logiška prieš dešimt metų, šiandien gali būti bloga praktika. Nuolatinis kūrėjų informavimas apie OWASP 10 populiariausių atakų sąrašą, kylančias atakas ir saugaus projektavimo modelius labai sumažina žmogiškųjų klaidų riziką, kuri tebėra didelės dalies saugumo pažeidimų priežastis.

Saugus programinės įrangos kūrimo gyvavimo ciklas (Secure SDLC)

Saugumo integravimas į SDLC nereiškia „papildomo etapo“ pridėjimo pabaigoje, o veikiau praktikų ir kontrolės priemonių įpynimo į esamus etapus. Tai sukuria tvarų procesą, kuris teikia realią vertę netrikdant komandos dinamikos. Saugus SDLC paprastai apima šiuos etapus:

Reikalavimų etape aiškiai apibrėžiama spręstina problema ir reikalingas saugumo lygis. Tai laikas, kai incidentai, naujų funkcijų užklausos ir žinomi pažeidžiamumai transformuojami į konkrečius projektus, įvertinant jų poveikį bendrai rizikai. Įtraukus saugumo komandą šiame etape, galima veiksmingai nustatyti prioritetus ir suprasti kiekvieno pakeitimo pasekmes.

Toliau eina planavimo etapas , kurio metu priimami sprendimai dėl to, kas bus kuriama ir kaip tai bus daroma. Svarbu, kad šiame etape dalyvautų ir saugumo specialistai, patvirtinantys, kad planuojamas sprendimas nesukuria naujų atakų vektorių ir kad verslo tikslai atitinka duomenų apsaugos, reguliavimo atitikties ir atsparumo reikalavimus.

Sprendimo projektavimo etape daugiausia dėmesio skiriama architektūrai: kurios sistemos sąveikauja, kokios paslaugos kuriamos, kaip jos susijusios ir kokie duomenų srautai užmezgami. Diagramos turėtų būti peržiūrėtos kartu su saugumo komanda, siekiant nustatyti galimus pažeidžiamumus pasitikėjimo ribose, įėjimo taškuose, autentifikavimo mechanizmuose, šifravime ir kt. Sklandus bendravimas šiuose ankstyvuosiuose etapuose neleidžia aptikti rimtų problemų, kai viskas jau užprogramuota.

Toliau ateina įgyvendinimas – momentas, kai projektas paverčiamas kodu. Čia labai svarbios tokios praktikos kaip statinė analizė kiekvieno įvykdymo metu, saugumo taisyklių integravimas į CI srautą ir kodo peržiūrų atlikimas, daugiausia dėmesio skiriant saugumui. Kuo greičiau aptinkamas kodo trūkumas, tuo mažesnės jo taisymo išlaidos.

Kai kodas paruoštas, jis pereina į testavimo ir diegimo etapą . Be funkcinių testų, patartina atlikti išsamesnes saugumo analizes: DAST nuskaitymus, rankinį kritinių funkcijų saugumo testavimą ir, kai leidžia ištekliai, įsiskverbimo testavimą, skirtą pagrindiniams pokyčiams. Šio etapo išvados turėtų būti naudojamos automatizuotoms priemonėms koreguoti, kad būtų išvengta regresijos.

Po diegimo prasideda prevencinė priežiūra . Net jei programinė įranga išleidžiama į gamybinę aplinką „be žinomų pažeidžiamumų“, aplinka ir grėsmės keičiasi: atsiranda naujų CVE, aptinkami priklausomybių trūkumai, keičiami teisiniai reikalavimai ir pan. Priežiūros etapas apima naujų pažeidžiamumų stebėjimą, komponentų atnaujinimą, saugos žurnalų peržiūrą ir reagavimą į incidentus.

Visas procesas yra cikliškas: kiekviena naujai atrasta klaida, patobulinimas ar pažeidžiamumas yra grįžtamasis ryšys su reikalavimų etapu . Todėl saugus SDLC yra nuolatinio tobulinimo ciklas, o ne linijinis kelias. Toks mąstymas padeda komandoms tobulinti savo valdiklius ir įrankius su kiekviena iteracija, užuot manius, kad „viskas padaryta“ po diegimo.

Nuorodų sistemos: OWASP SAMM ir NIST SSDF

Organizacijoms, norinčioms žengti dar vieną žingsnį, labai naudinga pasikliauti nusistovėjusiais brandos modeliais ir saugiomis kūrimo sistemomis . Du iš svarbiausių yra OWASP SAMM modelis ir NIST SSDF sistema, kurios siūlo praktines gaires, kaip integruoti saugumą į kūrimo procesus.

OWASP programinės įrangos užtikrinimo brandos modelis (SAMM) yra ankstesnio OWASP CLASP evoliucija. Jame siūlomas saugumo praktikų rinkinys, suskirstytas pagal sritis (pvz., valdymas, kūrimas, tikrinimas ir diegimas), turint skirtingus brandos lygius. Idėja yra ta, kad kiekviena organizacija pritaiko šias praktikas prie savo rizikos profilio, o ne bando taikyti griežtą kontrolės priemonių sąrašą.

NIST saugios programinės įrangos kūrimo sistema (SSDF) apibrėžia pagrindines saugaus programinės įrangos kūrimo praktikas, pagrįstas daugelio ekspertų organizacijų rekomendacijomis. Ji suskirsto saugų SDLC į keturis pagrindinius skyrius: organizacijos parengimą, programinės įrangos apsaugos užtikrinimą, saugios programinės įrangos kūrimą ir reagavimą į pažeidžiamumus. Kiekviename skyriuje pateikiamos konkrečios veiklos, kurias galima įgyvendinti palaipsniui.

„Organizacijos paruošimas“ reiškia žmonių, procesų ir technologijų paruošimą , kad saugus kūrimas būtų visapusiška praktika tiek įmonės lygmeniu, tiek kiekvienoje komandoje. „Programinės įrangos apsauga“ apima priemones, skirtas užkirsti kelią neteisėtam kodo, kūrimo artefaktų ir tiekimo grandinės manipuliavimui.

„Saugios programinės įrangos kūrimo“ blokas orientuotas į kiekvienos versijos pažeidžiamumų mažinimą , statinės analizės, priklausomybių peržiūros, konteinerių skenavimo ir panašių valdiklių integravimą į kasdienes operacijas. Galiausiai, „reagavimas į pažeidžiamumus“ reiškia nepastebėtų trūkumų nustatymą, greitą jų ištaisymą ir proceso koregavimą, siekiant užkirsti kelią jų pasikartojimui.

Mokymai, grėsmių modeliavimas ir saugos kultūra

Kad visa tai veiktų, nepakanka vien įdiegti įrankius; reikia sukurti bendrą saugumo kultūrą komandoje. Tai reiškia, kad kūrėjai turi suprasti, jog programų apsauga yra jų darbo dalis ir kad saugumo komandos turi būti integruotos į kasdienes operacijas, o ne tik įvykus incidentui.

Specialūs mokymai yra gera pradžia. Įgalinant kūrėjus nustatyti pažeidžiamumus ir rašyti saugesnį kodą, smarkiai sumažėja pagrindinių klaidų skaičius. Tokie ištekliai kaip „OWASP Top 10“ padeda nustatyti dažniausiai pasitaikančius žiniatinklio programų trūkumus ir suprasti, kaip mąsto užpuolikai.

Kita didelės įtakos praktika yra grėsmių modeliavimas . Tai apima programos (arba naujos funkcijos) analizę iš užpuoliko perspektyvos: kokius išteklius reikia apsaugoti, kokie įvesties duomenys egzistuoja, kokie duomenų srautai yra kritiniai ir kokiais pažeidžiamumais galima pasinaudoti. Remiantis šia analize, į techninį projektą įtraukiami ir sušvelninimo veiksmai.

Jei grėsmių modeliavimas atliekamas projektavimo etape, jis nuo pat pradžių daro įtaką architektūrai , užkertant kelią nesaugiems sprendimams, kuriuos vėliau reikėtų perrašyti. Duomenų srautų diagramos ir žinomi atakų modeliai paprastai naudojami analizei struktūrizuoti, įtraukiant tiek kūrimo, tiek saugumo komandas.

Tuo pačiu metu svarbu skatinti kūrimo komandas išmokti mąstyti kaip užpuolikas . Tai nereiškia, kad kiekvienas turi būti įsiskverbimo testavimo ekspertas, bet veikiau tai, kad jie suprastų, kaip maži pažeidžiamumai susijungia, kad sukurtų didesnę ataką, kaip vagiami prisijungimo duomenys arba kaip išnaudojamos silpnos debesies konfigūracijos.

Tradicinio skverbties testavimo apribojimai

Tradicinis įsiskverbimo testavimas išlieka vertinga priemone, tačiau jis turi apribojimų, kai taikomas aplinkose su nuolatiniu diegimu. Pagal apibrėžimą, įsiskverbimo testas pateikia saugumo momentinę nuotrauką konkrečiu laiko momentu: jis įvertina programos ir infrastruktūros būseną tą dieną.

Kai tik komanda įdiegia naujas versijas arba pakeičia konfigūracijas, kai kurie rezultatai gali pasenti . Jei versijos išleidžiamos dažnai, atlikti išsamius įsiskverbimo testus po kiekvieno pakeitimo tampa nepraktiška laiko ir išlaidų požiūriu.

Be to, kai skverbties testas atliekamas labai pažengusiuose kūrimo ciklo etapuose, aptiktų pažeidžiamumų taisymas dažnai yra brangus ir dažnai reikalauja sudėtingų saugumo atnaujinimų . Kartais tai apima pagrindinių komponentų modifikavimą arba ištisų programos dalių perrašymą, o tai turi įtakos planavimui, biudžetui ir komandos moralei.

O organizacijose, turinčiose daug paslaugų ir programų, sunku pritaikyti rankinį įsiskverbimo testavimą visam katalogui. Yra tendencija teikti pirmenybę tik svarbiausioms sistemoms, paliekant spragas kitose srityse, kuriomis užpuolikai taip pat gali pasinaudoti.

Nuolatiniai CI/CD vamzdynų saugos bandymai

Siekiant prisitaikyti prie šio pokyčių tempo, atsiranda tokie modeliai kaip nuolatinis saugumo testavimas CI/CD sistemoje, derinant visą parą vykdomus automatinius nuskaitymus su tiksliniais, vienkartiniais rankiniais testais. Idėja yra pereiti nuo ad hoc auditų prie nuolatinio pažeidžiamumų aptikimo ir taisymo srauto.

Šis metodas sujungia automatinius skaitytuvus, kurie tikrina programas, žiniatinklio išteklius, API ir pažeidžiamus paviršius, su įsiskverbimo testavimo ekspertų įsikišimu, kurie tiria sudėtingiausius radinius ir ieško loginių pažeidžiamumų, kurių įrankiai negali aptikti patys.

Pagrindinis privalumas yra tas, kad komandos gauna greitą ir išsamią informaciją apie saugumo problemas, net kai CI/CD srautas yra labai greitas. Tai sumažina pažeidžiamumo laikotarpį, nes pažeidžiamumai nustatomi ir ištaisomi prieš tai, kai paveiktas kodas pasiekia (arba joje išlieka) gamyboje ilgą laiką.

Dar vienas privalumas yra tas, kad nuolatinis testavimas palengvina ryšį tarp pažeidžiamumų valdymo ir programų saugumo . Dažnos ataskaitos su aiškiais pažeidžiamumų sąrašais ir jų raida laikui bėgant padeda priimti sprendimus dėl rizikos, suskirstyti taisymus pagal prioritetus ir pagrįsti investicijas į saugumo gerinimą.

Kai kurios paslaugos netgi siūlo nemokamą pakartotinį testavimą pritaikius pataisymus, kad galėtumėte patikrinti, ar sprendimai iš tikrųjų veikia ir ar nebuvo įvesta jokių regresijų. Visa tai puikiai atitinka „DevSecOps“ nuolatinio tobulėjimo etosą.

Tipiniai „DevSecOps“ komponentai ir įrankiai

Praktiškai „DevSecOps“ aplinka remiasi keliais pagrindiniais technologiniais komponentais . Nuolatinė integracija (CI) suvienija visų kūrėjų darbą ir automatiškai atlieka vienetų, integracijos ir saugumo testus kiekvieną kartą, kai integruojamas naujas kodas.

Nuolatinis teikimas (CD) užtikrina, kad programinė įranga visada būtų paruošta diegimui, nuosekliai tikrinant ir tvirtinant programinę įrangą (įskaitant saugumo patikras) kiekviename etape. Į aukštesnio lygio aplinkas perkeliamos tik tos versijos, kurios atitinka visus apibrėžtus kontrolės reikalavimus.

Saugumo automatizavimas pasiekiamas naudojant SAST ir DAST įrankius, priklausomybių skaitytuvus, infrastruktūros kaip kodo analizę ir konteinerių peržiūras. Šie įrankiai yra integruoti į CI/CD srautą tokiose sistemose kaip „Jenkins“, „GitLab CI“ ar panašiose, todėl jie veikia be rankinio įsikišimo.

Pažeidžiamumų valdymo sprendimai taip pat dažnai naudojami išvadoms centralizuoti, rizikoms nustatyti pagal svarbą ir jų sprendimui stebėti. Be to, paslapčių valdymo įrankiai (pvz., „Vault“) apsaugo nuo kredencialų ir raktų atskleidimo kode ar diegimo konfigūracijose.

Galiausiai, nuolatinis stebėjimas ir auditas remiasi stebimumu ir SIEM platformomis (pvz., ELK arba Splunk), kurios renka žurnalus, aptinka anomalų elgesį ir palengvina atitikties auditus. Šis sluoksnis užbaigia ciklą, leisdamas aptikti gamybinius incidentus ir laiku į juos reaguoti.

„DevSecOps“ taikymas kuriant mobiliąsias programėles

Kalbant apie mobiliąsias programas , „DevSecOps“ metodas turi būti pritaikytas prie jų specifinių savybių. Planavimo ir projektavimo etape reikia atsižvelgti į konkrečias rizikas: įrenginių leidimų valdymą, saugų kredencialų saugojimą, ryšio šifravimą ir atitiktį tokiems reglamentams kaip BDAR.

Kūrimo metu naudojami SAST skaitytuvai, pritaikyti tokioms kalboms kaip Kotlin, Swift ir Java, o išorinės priklausomybės ir SDK yra atidžiai peržiūrimi. Daugelis mobiliųjų programėlių pažeidžiamumų kyla būtent dėl ​​prastai prižiūrimų trečiųjų šalių bibliotekų arba tų, kurios turi pernelyg daug leidimų.

Testavimo etape DAST nuskaitymai derinami su mobiliesiems įrenginiams skirtais testais : „man-in-the-middle“ (MITM) atakos modeliavimu, dvejetainių failų vientisumo patikrinimu, vietinės saugyklos analize ir vidinės API sąveikos peržiūra. Tai padeda nustatyti tiek programėlės, tiek jos naudojamų paslaugų trūkumus.

Integracija į CI/CD srautą reiškia, kad kiekvienas pakeitimas yra automatiškai patikrinamas saugumo požiūriu , užtikrinant, kad jokia versija su rimtais trūkumais nepasiektų programėlių parduotuvių. Be to, po diegimo įdiegta stebėjimo sistema sukonfigūruota taip, kad aptiktų neįprastą elgesį, klaidų šuolius ar modelius, kurie gali rodyti ataką.

Galiausiai, apibrėžtas aiškus incidentų reagavimo procesas , leidžiantis greitai išleisti skubius pataisymus, jei gamyboje aptinkamas kritinis pažeidžiamumas. Gebėjimas greitai reaguoti ir atnaujinti programą yra labai svarbus norint išlaikyti vartotojų pasitikėjimą.

Visos šios praktikos, sistemos ir įrankiai kartu leidžia saugumui nebebūti kliūtimi ir tapti lanksčios plėtros sąjungininku. Įtraukdamos kūrėjus nuo pat pradžių, automatizuodamos testavimą su kiekvienu pakeitimu ir naudodamos tokius standartus kaip OWASP SAMM ar NIST SSDF, organizacijos gali sukurti patikimesnę programinę įrangą, sumažinti klaidų taisymo išlaidas ir būti daug geriau pasirengusios nuolat besikeičiančiai grėsmių aplinkai.