Turvalisus tarkvaraarenduses ja DevSecOpsis

Informatec Digital » Ressursid » Turvalisus tarkvaraarenduses ja DevSecOpsis

Tarkvaraturve ei ole enam projekti lõpus lisatav valikuline lisa, vaid juba esimesest rakenduse visandist alates oluline komponent. Maailmas, kus koodi juurutatakse mitu korda päevas ja kus küberrünnakud on üha keerukamad, on viimase hetke käsitsi tehtud ülevaatustele lootmine katastroofi retsept.

Turvalisuse integreerimine kogu arendustsükli vältel (esialgsest kontseptsioonist kuni tootmishoolduseni) on selliste lähenemisviiside nagu DevSecOps, arendajakeskne turvalisus ja turvalised tarkvaraarenduse ja -halduse mudelid sellistest raamistikest nagu OWASP SAMM või NIST SSDF alus. Eesmärk on lihtne sõnastada, kuid keeruline saavutada: luua turvaline tarkvara juba disainilt, takistamata ärilist paindlikkust ja takistamata turvalisuse muutumist kitsaskohaks.

Mis on tarkvaraarenduses turvalisus ja miks see on oluline?

Tarkvaraarenduse turvalisusest rääkides peame silmas kõiki tavasid, tööriistu ja protsesse, mida rakendatakse, et tagada rakenduse vastupidavus rünnakutele, andmete terviklikkuse säilitamine ja teenuste kättesaadavus kogu selle elutsükli vältel. See ei puuduta ainult tulemüüri paigaldamist või krüptimise kasutamist, vaid tarkvara kujundamist ja programmeerimist viisil, mis vähendab turvaaukude tekkimise tõenäosust.

Pahavararünnakud ja tarkvara haavatavused võivad kahjustada autentimist, autoriseerimist, terviklikkust ja konfidentsiaalsust. Kui nende ohtudega tegeletakse juba projekteerimisfaasis, saab paljusid neist enne tootmises probleemiks muutumist leevendada, ennetades hädaolukorra parandusi ja andmetega seotud rikkumisi.

Keskne idee on see, et iga tarkvara peaks enne kasutajani jõudmist läbima turvatestimise ning et need testid ei tohiks olla isoleeritud "filter", vaid pigem iga versiooni rutiinne osa. Selle tulemuseks on vastupidavam tarkvara, mis ei pea haavatavuste avastamisel lisaturvalisust kiht-kihi haaval koguma.

Lõppeesmärk on saavutada turvalised rakendused , mille arhitektuuri on sisse ehitatud kontrollid, sagedane automatiseeritud testimine ja kultuur, kus arendajad, turvalisus ja operatsioonid teevad kõik koostööd. See nõuab teadlikku pingutust kogu tehniliselt meeskonnalt, mitte ainult väikeselt küberturvalisuse spetsialistide rühmalt.

DevSecOps ja arendajakeskne turvalisus

Mõiste DevSecOps tekkis väga spetsiifilise probleemi lahendamiseks: traditsioonilised mudelid, kus turvameeskond liitus alles arendustsükli lõpus, ei sobinud enam sagedaste väljalasete, agiilsete metoodikate ja CI/CD-torustike jaoks. Varem võimaldas rakenduse värskendamine üks või kaks korda aastas põhjalikku ülevaatamist; nüüd, pidevate juurutuste korral, on see lähenemisviis muutunud vastuvõetamatuks takistuseks.

DevSecOps edendab turvalisuse sujuvat integreerimist Agile'i ja DevOpsi meetoditesse , nii et rakenduste ja infrastruktuuri turvalisusega tegeletakse algusest peale ja pidevalt. Idee seisneb haavatavuste tuvastamises ja parandamises kohe, kui need ilmnevad, kui need on veel odavad parandada, mitte aga avastamises vahetult enne juurutamist.

Lisaks edendab DevSecOps turvalisust jagatud vastutusena : arendus, toimingud ja turvalisus teevad tihedat koostööd, selle asemel et töötada eraldi seisvates kohtades, mis suhtlevad omavahel alles lõpus. Selle lähenemisviisi motot võetakse sageli kokku kui „tarkvara, turvalisem, varasem“: kiirema ja turvalisema tarkvara pakkumine, automatiseerides juhtelemente ja vähendades hõõrdumist arendustsüklis.

Selle filosoofia võtmeelement on arendajakeskne turvalisus . Selle asemel, et turvameeskond protsessi lõpus "politseijõuna" tegutseks, tuuakse turvatööriistad arendajate enda töökeskkonnale lähemale, näiteks skännerite integreerimise abil IDE-sse või versioonikontrollisüsteemi. Nii tehakse osa analüüsist, testimisest ja parandustest otse arendaja klaviatuurilt.

See lähenemisviis, mis „tuua turvalisus koodile lähemale“, võimaldab haavatavusi avastada ja parandada peaaegu kohe pärast nende kirjutamist, ilma et peaksite ootama perioodilisi auditeid või ulatuslikke penetratsiooniteste. Selle tulemusel ei pea arendusmeeskonnad turvalisust enam nuhtluseks, mis aeglustab nende tööd, vaid peavad seda peamiseks kvaliteedikriteeriumiks.

Turvalisus on sisse ehitatud SDLC igasse etappi.

Selleks, et turvalisus oleks tõeliselt tõhus, tuleb see integreerida arendustsükli kõikidesse etappidesse , mitte käsitleda seda lõpliku "kvaliteedikontrollina". Turvalisuse käsitlemine ainult projekti lõpetamise murena loob turvameeskonnale kitsaskoha, eriti kuna nad ei saa olla eksperdid kõigis tänapäeval kasutatavates tehnoloogiates ja pilvekeskkondades.

Kaasaegne lähenemisviis pakub turvalisust, mis on „läbi põimitud“ kogu toote elutsüklisse (SDLC): alates nõuete määratlemisest planeerimise ja disaini kaudu kuni rakendamise, testimise, juurutamise ja hoolduseni. Kogu organisatsioon mõistab, et turvalisus on toote edu oluline osa , mitte eraldi mure, mida saab edasi lükata.

Varem olid turvaülevaated peamiselt käsitsi testimine ja iga rakenduse või teenuse jaoks eraldi tööriistad , mis ühendasid kohapealseid skannereid penetratsioonitestimisega. Tänapäeval on tööriistad loodud integratsiooni ja automatiseerimist silmas pidades: need ühenduvad CI/CD torujuhtmete, intsidentide jälgimissüsteemide ja koodihoidlatega, võimaldades palju sujuvamat töövoogu.

Haavatavuse skannerid on integreeritud pidevasse integratsiooniprotsessi, seega analüüsitakse iga koodimuudatust automaatselt enne järgmisse etappi liikumist. Samal ajal logitakse leiud tavaliste ülesannetena, mis on nähtavad kogu meeskonnale, muutes prioriseerimise, jälgimise ja lahendusaegade mõõtmise lihtsamaks.

Kõik see tähendab, et turvalisus ei ole enam teisejärguline, vaid sellest saab SDLC struktuuriline komponent . Selle asemel, et lihtsalt enne juurutamist „läbida turvakontroll“, eeldab organisatsioon, et iga commit, iga liitmine ja iga edastus on osa pidevast turvakontrollide ahelast.

Levinud tarkvaraturbe tavad

Selle töömeetodi raames on mitmeid tarkvaraturbealgatusi , mida paljud organisatsioonid juba rakendavad või hakkavad kasutusele võtma. See ei ole ammendav loetelu, kuid see aitab mõista, milliseid tegevusi peaksime tarkvaraturbe juhtimiskeskusesse turvalisuse tugevdamiseks integreerima.

Esimene ja oluline samm on staatiline koodianalüüs (SAST). See hõlmab lähtekoodi (sh infrastruktuuri koodina) analüüsimist, et tuvastada ohtlikke programmeerimismustreid või teadaolevaid haavatavusi. See on tavaliselt automatiseeritud protsess, mida saab käivitada iga commit'i või pushi puhul, pakkudes arendajatele peaaegu reaalajas tagasisidet.

Teisest küljest hindab dünaamiline turvaanalüüs (DAST ja sarnased lähenemisviisid) kogu rakendust ja selle aluseks olevat infrastruktuuri selle töötamise ajal. See hõlmab näiteks portide skaneerimist, saidiüleseid skriptimisteste, konteineri konfiguratsiooni ülevaatamist ja internetipõhiste teenuste analüüsi, et tuvastada haavatavusi, mis on nähtavad ainult siis, kui süsteem töötab.

Lisaks automatiseeritud tööriistadele on käsitsi koodiülevaatused endiselt olulised. Kuigi paljusid funktsioone juba loogiliste vigade suhtes üle vaadatakse, võimaldab turvaperspektiivi lisamine nendesse koodiülevaadetesse tuvastada vähem ilmseid haavatavusi, mida skanner võib kahe silma vahele jätta. See aga nõuab meeskonnalt teatud koolitust rünnakumustrite ja parimate tavade alal.

Tungimistestid lähevad sammu võrra kaugemale: ründajatena palgatakse eksperte, kes üritavad infrastruktuuri või rakendusi ohtu seada. Nad võivad kasutada kõike alates automatiseeritud analüüsist kuni reaalsete ärakasutamisteni ning tulemuseks on tavaliselt aruanne, milles on üksikasjalikult kirjeldatud haavatavusi, mida standardtestid ei avastanud, koos konkreetsete soovitustega nende leevendamiseks.

Seotud, kuid erinev lähenemisviis on vigade teatamise programmid (Bug Bounty) . See mudel kutsub teadlasi ja edasijõudnud kasutajaid üles teatama haavatavustest rahalise tasu või tunnustuse eest. See on tõhus viis kolmandate osapoolte leidude edastamiseks ja potentsiaalsete ründajate koostööpartneriteks muutmiseks.

Lõpuks ei tohi me unustada tehnilise personali turvakoolitust . Ohumaastik muutub kiiresti: see, mis oli kümme aastat tagasi mõistlik, võib tänapäeval olla halb tava. Arendajate kursis hoidmine OWASP-i 10 parima rünnaku, tekkivate rünnakute ja turvaliste disainimustritega vähendab oluliselt inimlike vigade riski, mis on endiselt olulise osa turvarikkumiste põhjuseks.

Turvaline tarkvaraarenduse elutsükkel (Secure SDLC)

Turvalisuse integreerimine turvahaldusprotsessi ei tähenda "täiendava etapi" lisamist lõppu, vaid pigem tavade ja kontrollide põimimist olemasolevatesse etappidesse. See loob jätkusuutliku protsessi, mis pakub reaalset väärtust ilma meeskonna dünaamikat häirimata. Turvaline turvahaldusprotsess hõlmab tavaliselt järgmisi etappe:

Nõuete etapis määratletakse selgelt lahendatav probleem ja vajalik turvatase. See on aeg muuta intsidendid, uute funktsioonide taotlused ja teadaolevad haavatavused konkreetseteks projektideks, hinnates nende mõju üldisele riskile. Turvameeskonna kaasamine selles etapis aitab tõhusalt prioriteete seada ja mõista iga muudatuse tagajärgi.

Järgmisena tuleb planeerimisetapp , kus tehakse otsused selle kohta, mida ehitatakse ja kuidas sellega tegeletakse. Oluline on, et selles etapis osaleksid ka turvalisuse osakonnad, kes kontrollivad, et kavandatud lahendus ei tooks kaasa uusi rünnakuvektoreid ning et ärieesmärgid oleksid kooskõlas andmekaitse, regulatiivse vastavuse ja vastupidavusnõuetega.

Lahenduse disaini etapp keskendub arhitektuurile: millised süsteemid omavahel suhtlevad, milliseid teenuseid luuakse, kuidas need on omavahel seotud ja millised andmevood luuakse. Skeemid tuleks turvameeskonnaga üle vaadata, et tuvastada potentsiaalsed haavatavused usalduspiirides, sisenemispunktides, autentimismehhanismides, krüptimises jne. Sujuv suhtlus nendes varajastes etappides hoiab ära tõsiste probleemide avastamise, kui kõik on juba programmeeritud.

Järgmisena tuleb rakendamine – hetk disaini koodiks tõlkimiseks. Siin on üliolulised sellised tavad nagu staatiline analüüs iga commit'i ajal, turvareeglite integreerimine CI-torustikku ja koodi ülevaatuste läbiviimine, keskendudes turvalisusele. Mida varem koodis viga avastatakse, seda madalamad on selle parandamise kulud.

Kui kood on valmis, liigub see testimise ja juurutamise faasi . Lisaks funktsionaalsetele testidele on soovitatav siia lisada põhjalikumaid turvaanalüüse: DAST-skaneeringud, kriitiliste funktsionaalsuste käsitsi turvatestimine ja, kui ressursid lubavad, olulistele muudatustele keskenduv penetratsioonitestimine. Selle etapi tulemusi tuleks kasutada automatiseeritud tööriistade kohandamiseks, et vältida regressioone.

Pärast juurutamist algab ennetav hooldus . Isegi kui tarkvara avaldatakse tootmiskeskkonnas "ilma teadaolevate haavatavusteta", muutuvad keskkond ja ohud: ilmnevad uued CVE-d, avastatakse sõltuvusvigu, muudetakse juriidilisi nõudeid jne. Hooldusetapp hõlmab uute haavatavuste jälgimist, komponentide värskendamist, turvalogide ülevaatamist ja intsidentidele reageerimist.

Kogu protsess on ringikujuline: iga avastatud uus viga, täiustus või haavatavus annab tagasisidet nõuete faasile . Turvaline SDLC on seega pideva täiustamise tsükkel, mitte lineaarne tee. See mõtteviis aitab meeskondadel iga iteratsiooniga oma juhtelemente ja tööriistu täiustada, selle asemel, et mõelda, et pärast juurutamist on "kõik tehtud".

Võrdlusraamistikud: OWASP SAMM ja NIST SSDF

Organisatsioonide jaoks, kes soovivad sammu edasi minna, on väga kasulik toetuda väljakujunenud küpsusmudelitele ja turvalistele arendusraamistikele . Kaks kõige olulisemat on OWASP SAMM-mudel ja NIST SSDF-raamistik, mis pakuvad praktilisi juhiseid turvalisuse integreerimiseks arendusprotsessidesse.

OWASP tarkvarakindlustuse küpsusmudel (SAMM) on OWASP-i endise CLASP-i edasiarendus. See pakub välja turvapraktikate komplekti, mis on korraldatud valdkondade (nt haldamine, loomine, kontrollimine ja juurutamine) kaupa, millel on erinevad küpsustasemed. Idee seisneb selles, et iga organisatsioon kohandab need tavad oma riskiprofiiliga, selle asemel et proovida rakendada jäika kontrollimeetmete loendit.

NISTi turvalise tarkvaraarenduse raamistik (SSDF) kirjeldab mitmete ekspertorganisatsioonide soovitustel põhinevaid turvalise arenduse põhipraktikaid. See jagab turvalise SDLC neljaks põhiosaks: organisatsiooni ettevalmistamine, tarkvara turvamine, turvalise tarkvara loomine ja haavatavustele reageerimine. Iga osa sisaldab konkreetseid tegevusi, mida saab järk-järgult rakendada.

„Organisatsiooni ettevalmistamine“ tähendab inimeste, protsesside ja tehnoloogiate ettevalmistamist nii, et turvaline arendus oleks läbiv praktika nii ettevõtte tasandil kui ka igas meeskonnas. „Tarkvara kaitsmine“ hõlmab meetmeid koodi, ehitusartefaktide ja tarneahela volitamata manipuleerimise vältimiseks.

„Turvalise tarkvara loomise” plokk keskendub iga versiooni haavatavuste minimeerimisele , integreerides staatilise analüüsi, sõltuvuste ülevaatuse, konteinerite skaneerimise ja sarnaste kontrollide igapäevastesse toimingutesse. Lõpuks viitab „haavatavustele reageerimine” tähelepanuta jäetud vigade tuvastamisele, nende kiirele parandamisele ja protsessi kohandamisele, et vältida nende kordumist.

Koolitus, ohtude modelleerimine ja ohutuskultuur

Selleks, et see kõik toimiks, ei piisa ainult tööriistade installimisest; see nõuab meeskonnas ühise turvakultuuri loomist . See tähendab, et arendajad peavad mõistma, et rakenduste kaitsmine on osa nende tööst ja et turvameeskonnad tuleb integreerida igapäevategevusse, mitte ainult intsidendi korral.

Hea alguspunkt on spetsiifiline koolitus. Arendajatele haavatavuste tuvastamise ja turvalisema koodi kirjutamise võimaldamine vähendab oluliselt elementaarsete vigade esinemist. Sellised ressursid nagu OWASP Top 10 aitavad tuvastada veebirakenduste kõige levinumaid nõrkusi ja mõista ründajate mõtlemisviisi.

Teine suure mõjuga praktika on ohtude modelleerimine . See hõlmab rakenduse (või uue funktsiooni) analüüsimist ründaja vaatenurgast: millised varad vajavad kaitset, millised sisendid on olemas, millised andmevood on kriitilise tähtsusega ja milliseid haavatavusi saaks ära kasutada. Selle analüüsi põhjal kavandatakse leevendusmeetmed ja need lisatakse tehnilisse projekti.

Kui seda tehakse disainifaasis, mõjutab ohtude modelleerimine arhitektuuri algusest peale , ennetades ebaturvalisi lahendusi, mis hiljem vajaksid ümberkirjutamist. Analüüsi struktureerimiseks kasutatakse tavaliselt andmevoo diagramme ja teadaolevaid rünnakumustreid, kaasates nii arendus- kui ka turvameeskondi.

Samal ajal on oluline julgustada arendusmeeskondi õppima mõtlema nagu ründaja . See ei tähenda, et igaüks peab olema ekspert penetratsioonitestijana, vaid pigem seda, et nad mõistaksid, kuidas väikesed haavatavused koos suurema rünnaku loomiseks loovad, kuidas volitusi varastatakse või kuidas nõrku pilvekonfiguratsioone ära kasutatakse.

Traditsioonilise penetratsioonitestimise piirangud

Traditsiooniline penetratsioonitestimine on endiselt väärtuslik tööriist, kuid sellel on piirangud pideva juurutamisega keskkondades. Definitsiooni järgi annab penetratsioonitest hetktõmmise turvalisusest konkreetsel ajahetkel: see hindab rakenduse ja infrastruktuuri olekut sellisena, nagu need sel päeval on.

Niipea kui meeskond juurutab uusi versioone või muudab konfiguratsioone, võivad mõned leiud vananeda . Kui väljaandeid tuleb sageli, muutub täielike penetratsioonitestide tegemine pärast iga muudatust aja ja kulude osas ebapraktiliseks.

Lisaks, kui penetratsioonitesti tehakse arendustsükli väga edasijõudnud etappides, on avastatud haavatavuste parandamine tavaliselt kulukas ja hõlmab sageli keerukate turvavärskenduste rakendamist . Mõnikord hõlmab see võtmekomponentide muutmist või rakenduse tervete osade ümberkirjutamist, millel on sellest tulenev mõju planeerimisele, eelarvele ja meeskonna moraalile.

Ja organisatsioonides, kus on palju teenuseid ja rakendusi, on keeruline käsitsi penetratsioonitestimist kogu kataloogi ulatuses laiendada. Kiputakse prioriseerima ainult kõige kriitilisemaid süsteeme, jättes lüngad teistesse valdkondadesse, mida ründajad saavad samuti ära kasutada.

CI/CD torujuhtmete pidev ohutustestimine

Selle muutuste tempoga kohanemiseks on tekkimas sellised mudelid nagu pidev turvatestimine CI/CD torujuhtmes, mis ühendab ööpäevaringseid automatiseeritud skaneeringuid sihipäraste ühekordsete käsitsi testidega. Idee on liikuda ad hoc audititelt pideva haavatavuste tuvastamise ja parandamise voo poole.

See lähenemisviis ühendab automatiseeritud skannerid, mis kontrollivad rakendusi, veebivarasid, API-sid ja haavatavaid pindu, penetratsioonitestimise ekspertide sekkumisega, kes uurivad kõige keerulisemaid leide ja otsivad loogilisi haavatavusi, mida tööriistad ise ei suuda tuvastada.

Peamine eelis on see, et meeskonnad saavad turvaprobleemide kohta kiiresti ja üksikasjalikku teavet isegi siis, kui CI/CD andmevoog on väga kiire. See vähendab haavatavuste tekkimise aega, kuna haavatavused tuvastatakse ja parandatakse enne, kui mõjutatud kood jõuab (või jääb) tootmiskeskkonda pikemaks ajaks.

Teine eelis on see, et pidev testimine hõlbustab haavatavuste haldamise ja rakenduste turvalisuse vahelist seost . Sagedased aruanded koos selgete haavatavuste ja nende arengu loenditega aja jooksul aitavad teha riskiotsuseid, seada tähtsuse järjekorda parandusi ja õigustada investeeringuid turvalisuse parandamisse.

Mõned teenused pakuvad isegi tasuta uuesti testimist pärast paranduste rakendamist, mis võimaldab teil kontrollida, kas lahendused tegelikult toimivad ja et pole tekkinud regressioone. See kõik sobib ideaalselt DevSecOpsi pideva täiustamise eetosega.

Tüüpilised DevSecOpsi komponendid ja tööriistad

Praktikas tugineb DevSecOpsi keskkond mitmele olulisele tehnoloogilisele komponendile . Pidev integratsioon (CI) ühendab kõigi arendajate töö ja käivitab automaatselt ühiku-, integratsiooni- ja turvatestid iga kord, kui uus kood integreeritakse.

Pidev edastamine (CD) tagab tarkvara alati juurutamiseks valmisoleku, kontrollides ja kinnitades tarkvara (sh turvakontrollid) järjestikku igas etapis. Ainult versioonid, mis läbivad kõik määratletud kontrollid, suunatakse kõrgema taseme keskkondadesse.

Turvalisuse automatiseerimine saavutatakse SAST- ja DAST-tööriistade, sõltuvusskannerite, koodina infrastruktuuri analüüsi ja konteinerite ülevaatuste abil. Need tööriistad on integreeritud CI/CD torujuhtmesse sellistes süsteemides nagu Jenkins, GitLab CI või sarnased, nii et need töötavad ilma käsitsi sekkumiseta.

Haavatavuse haldamise lahendusi kasutatakse sageli ka leidude tsentraliseerimiseks, riskide tähtsuse järjekorda seadmiseks ja nende lahendamise jälgimiseks. Lisaks neile takistavad salajaste andmete haldamise tööriistad (näiteks Vault) volituste ja võtmete avalikustamist koodis või juurutuskonfiguratsioonides.

Lõpuks tugineb pidev jälgimine ja auditeerimine jälgitavusele ja SIEM-platvormidele (nt ELK või Splunk), mis koguvad logisid, tuvastavad anomaalset käitumist ja hõlbustavad vastavusauditeid. See kiht viib tsükli lõpule, võimaldades tuvastada tootmisintsidente ja neile õigeaegselt reageerida.

DevSecOpsi rakendamine mobiilirakenduste arendamisel

Mobiilirakenduste puhul tuleb DevSecOpsi lähenemisviisi kohandada nende spetsiifiliste omadustega. Planeerimis- ja disainifaasis tuleb arvestada konkreetsete riskidega: seadme õiguste haldamine, turvaline volituste salvestamine, side krüptimine ja vastavus sellistele eeskirjadele nagu GDPR.

Arenduse käigus kasutatakse SAST-skannereid, mis on kohandatud sellistele keeltele nagu Kotlin, Swift ja Java, ning hoolikalt vaadatakse üle välised sõltuvused ja SDK-d. Paljud mobiilirakenduste haavatavused tulenevad just halvasti hooldatud kolmandate osapoolte teekidest või liigsete õigustega teekidest.

Testimisfaasis kombineeritakse DAST-skaneeringuid mobiilispetsiifiliste testidega : vahemehe (MITM) rünnaku simulatsioon, binaarfailide terviklikkuse kontrollimine, kohaliku salvestusruumi analüüs ja taustsüsteemi API interaktsiooni ülevaade. See aitab tuvastada vigu nii rakenduses kui ka selle poolt tarbitavates teenustes.

CI/CD torujuhtmesse integreerimine tähendab, et iga commit läbib automaatsed turvakontrollid , tagades, et ükski tõsiste vigadega versioon ei jõua rakenduste poodidesse. Lisaks on juurutamisjärgne jälgimissüsteem konfigureeritud tuvastama ebatavalist käitumist, veapiike või mustreid, mis võivad viidata rünnakule.

Lõpuks on määratletud selge intsidentidele reageerimise protsess , mis võimaldab kiireloomuliste paranduste kiiret avaldamist, kui tootmises avastatakse kriitiline haavatavus. Rakenduse kiire reageerimine ja värskendamine on kasutajate usalduse säilitamise võti.

Kokkuvõttes võimaldavad kõik need tavad, raamistikud ja tööriistad turvalisusel mitte enam takistuseks olla, vaid agiilse arenduse liitlaseks. Arendajate kaasamine algusest peale, testimise automatiseerimine iga muudatusega ja selliste standardite kasutamine nagu OWASP SAMM või NIST SSDF võimaldavad organisatsioonidel luua vastupidavamat tarkvara, vähendada veaparanduste kulusid ja olla palju paremini ette valmistatud pidevalt muutuva ohumaastiku jaoks.