{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Frica \u0219i ur\u0103 DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Am avut 2 analizatori de cod, 4 instrumente pentru testare dinamic\u0103, propriile crea\u021bii \u0219i 250 de scripturi. Nu c\u0103 ar fi fost toate necesare \u00een procesul actual, dar odat\u0103 ce am \u00eenceput implementarea DevSecOps, trebuie s\u0103 mergem p\u00e2n\u0103 la cap\u0103t.<\/p>\n

\"Frica
\n
\nSursa<\/a><\/noindex>. Creatorii personajelor: Justin Roiland \u0219i Dan Harmon.<\/i><\/p>\n

Ce este SecDevOps? \u0218i DevSecOps? Care sunt diferen\u021bele? Ce \u00eenseamn\u0103 Securitatea Aplica\u021biilor? De ce abordarea clasic\u0103 nu mai func\u021bioneaz\u0103? La toate aceste \u00eentreb\u0103ri \u0219tie r\u0103spunsul Yuri Shabalin<\/b> din\u00a0Swordfish Security. <\/b>Yuri va r\u0103spunde detaliat la tot \u0219i va analiza problemele tranzi\u021biei de la modelul clasic de Securitate a Aplica\u021biilor la procesul DevSecOps: cum s\u0103 abordezi corect integrarea procesului de dezvoltare sigur\u0103 \u00een procesul DevOps f\u0103r\u0103 a strica nimic, cum s\u0103 treci prin etapele principale de testare a securit\u0103\u021bii, ce instrumente pot fi folosite, cu ce se deosebesc \u0219i cum s\u0103 le configurezi corect pentru a evita capcanele.
\n<\/a><\/noindex>
\n

\r\n \"Reda\u021bi\r\n
<\/div>\r\n <\/div><\/center>
\nDespre vorbitor:<\/b> Yuri Shabalin \u2014 <\/b>Chief Security Architect la Swordfish Security<\/b>. Este responsabil pentru implementarea SSDL, pentru integrarea general\u0103 a instrumentelor de analiz\u0103 a aplica\u021biilor \u00eentr-o ecosistem\u0103 unificat\u0103 de dezvoltare \u0219i testare. Are 7 ani de experien\u021b\u0103 \u00een securitate informa\u021bional\u0103. A lucrat la Alfa-Bank, Sberbank \u0219i la Positive Technologies, care dezvolt\u0103 software \u0219i ofer\u0103 servicii. Vorbitor la conferin\u021be interna\u021bionale cum ar fi ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Securitatea Aplica\u021biilor: ce \u00eenseamn\u0103?<\/h2>\n

\nSecuritatea Aplica\u021biilor<\/b>\u00a0\u2014 este o ramur\u0103 a securit\u0103\u021bii care se ocup\u0103 cu securitatea aplica\u021biilor. Aceasta nu se refer\u0103 la infrastructur\u0103 sau la securitatea re\u021belei, ci la ceea ce scriem \u0219i la ce lucreaz\u0103 dezvoltatorii \u2014 adic\u0103 la defectele \u0219i vulnerabilit\u0103\u021bile aplica\u021biei \u00een sine.<\/p>\n

Direc\u021bia SDL sau SDLC<\/a><\/noindex>\u00a0\u2014 Ciclul de via\u021b\u0103 al dezvolt\u0103rii securit\u0103\u021bii<\/b>\u00a0\u2014 a fost dezvoltat de Microsoft. \u00cen schema de mai sus se afl\u0103 modelul canonic SDLC, a c\u0103rui sarcin\u0103 principal\u0103 este participarea securit\u0103\u021bii la fiecare etap\u0103 a dezvolt\u0103rii, de la cerin\u021be p\u00e2n\u0103 la lansare \u0219i produc\u021bie. Microsoft a realizat c\u0103 \u00een industrie sunt prea multe bug-uri \u0219i c\u0103 acestea devin mai multe, iar cu asta trebuie f\u0103cut ceva, iar aceast\u0103 abordare a fost propus\u0103 \u0219i de atunci a devenit canonic\u0103.<\/p>\n

\"Frica
\n
\nSecuritatea Aplica\u021biilor \u0219i SSDL sunt orientate nu spre identificarea vulnerabilit\u0103\u021bilor, a\u0219a cum se crede de obicei, ci spre prevenirea apari\u021biei acestora. De-a lungul timpului, abordarea canonic\u0103 de la Microsoft a fost \u00eembun\u0103t\u0103\u021bit\u0103, dezvoltat\u0103, av\u00e2nd o aprofundare mai detaliat\u0103.<\/p>\n

\"Frica
\n
\nCiclul de via\u021b\u0103 software (SDLC) este detaliat \u00een diferite metodologii \u2013 OpenSAMM, BSIMM, OWASP. Metodologiile difer\u0103, dar \u00een general, sunt similare.<\/p>\n

Modelul de Maturitate a Securit\u0103\u021bii \u00een Construire<\/h3>\n

\nCel mai mult \u00eemi place BSIMM<\/b>\u00a0\u2014 Modelul de Maturitate a Securit\u0103\u021bii \u00een Construire<\/a><\/noindex>. Fundamentul metodologiei este \u00eemp\u0103r\u021birea procesului de Securitate a Aplica\u021biilor \u00een 4 domenii: Guvernan\u021b\u0103, Inteligen\u021b\u0103, Puncte de contact SSDL \u0219i Implementare. Fiecare domeniu are 12 practici, prezentate sub form\u0103 de 112 activit\u0103\u021bi.<\/p>\n

\"Frica
\n
\nFiecare dintre cele 112 activit\u0103\u021bi are 3 niveluri de maturitate<\/b>: ini\u021bial, mediu \u0219i avansat. Toate cele 12 practici pot fi studiate pe sec\u021biuni, select\u00e2nd aspectele importante pentru tine, \u00eenv\u0103\u021b\u00e2nd cum s\u0103 le implementezi \u0219i ad\u0103ug\u00e2nd treptat elemente, cum ar fi analiza static\u0103 \u0219i dinamic\u0103 a codului sau revizuirea codului. \u00ce\u021bi elaborezi un plan \u0219i lucrezi lini\u0219tit \u00een cadrul implement\u0103rii activit\u0103\u021bilor selectate.<\/p>\n

De ce DevSecOps<\/h2>\n

<\/p>\n

DevOps este un proces mare, complex, \u00een care trebuie s\u0103 ai grij\u0103 de securitate.<\/p><\/blockquote>\n

\nIni\u021bial DevOps<\/b><\/a><\/noindex> era a prev\u0103zut verific\u0103ri de securitate. \u00cen practic\u0103, num\u0103rul echipelor de securitate era mult mai mic dec\u00e2t acum, iar acestea ac\u021bionau nu ca participan\u021bi \u00een proces, ci ca un organism de control \u0219i supraveghere, care impune cerin\u021be \u0219i verific\u0103 calitatea produsului la finalul rundei de lans\u0103ri. Aceasta este abordarea clasic\u0103, \u00een care echipele de securitate se aflau \u00een spatele unui zid fa\u021b\u0103 de dezvoltare \u0219i nu participau \u00een proces.<\/p>\n

\"Frica
\n
\nPrincipala problem\u0103 este tocmai c\u0103 securitatea informa\u021bional\u0103 este separat\u0103 de dezvoltare. De obicei, exist\u0103 un anumit contur de securitate informa\u021bional\u0103, \u00een care se afl\u0103 2-3 instrumente mari \u0219i scumpe. O dat\u0103 la \u0219ase luni se prime\u0219te codul surs\u0103 sau aplica\u021bia care trebuie verificat\u0103, iar o dat\u0103 pe an se efectueaz\u0103 teste de penetrare<\/a><\/noindex>. Toate acestea duc la \u00eent\u00e2rzieri \u00een livrarea produsului pe pia\u021b\u0103, iar dezvoltatorii se confrunt\u0103 cu un num\u0103r imens de vulnerabilit\u0103\u021bi provenite din instrumente automatizate. Totul este imposibil de analizat \u0219i reparat, deoarece n-au fost analizate rezultatele din ultimele \u0219ase luni, iar acum a ap\u0103rut o nou\u0103 serie.<\/p>\n

\u00cen procesul activit\u0103\u021bii noastre, observ\u0103m c\u0103 securitatea \u00een toate domeniile \u0219i industriile \u00een\u021belege c\u0103 este timpul s\u0103 se sincronizeze \u0219i s\u0103 colaboreze cu dezvoltarea \u00eentr-un singur ritm \u2013 \u00een\u00a0Agile<\/b><\/a><\/noindex>. Paradigma DevSecOps se potrive\u0219te perfect cu metodologia de dezvoltare agil\u0103, cu implementarea, suportul \u0219i participarea \u00een fiecare lansare \u0219i itera\u021bie.<\/p>\n

\"Frica
\n<\/p>\n

Tranzi\u021bia c\u0103tre DevSecOps<\/h2>\n

\nCel mai important cuv\u00e2nt \u00een Ciclul de Via\u021b\u0103 al Dezvolt\u0103rii Securizate este \"proces\"<\/b>Trebuie s\u0103 \u00een\u021belege\u021bi acest lucru \u00eenainte de a lua \u00een considerare achizi\u021bia de instrumente.<\/p>\n

A include instrumente \u00een procesul DevOps nu este suficient - interac\u021biunea \u0219i \u00een\u021belegerea \u00eentre participan\u021bii la proces sunt importante.<\/p><\/blockquote>\n

<\/p>\n

Oamenii sunt mai importan\u021bi dec\u00e2t instrumentele.<\/h3>\n

\nDe multe ori, planificarea procesului de dezvoltare sigur\u0103 \u00eencepe cu alegerea \u0219i achizi\u021bionarea unui instrument, dar se termin\u0103 cu \u00eencerc\u0103ri de integrare a instrumentului \u00een procesul actual, care r\u0103m\u00e2n doar \u00eencerc\u0103ri. Acest lucru duce la consecin\u021be triste, deoarece fiecare instrument are propriile sale caracteristici \u0219i limit\u0103ri.<\/p>\n

Un caz frecvent este atunci c\u00e2nd departamentul de securitate a ales un instrument bun, scump, cu posibilit\u0103\u021bi largi \u0219i s-a dus la dezvoltatori pentru a-l integra \u00een proces. Dar nu func\u021bioneaz\u0103 - procesul este construit astfel \u00eenc\u00e2t limit\u0103rile instrumentului deja achizi\u021bionat nu se aliniaz\u0103 cu paradigma actual\u0103.<\/p>\n

Mai \u00eent\u00e2i, descrie\u021bi ce rezultat dori\u021bi \u0219i cum va ar\u0103ta procesul. Acest lucru va ajuta la \u00een\u021belegerea rolurilor instrumentului \u0219i securit\u0103\u021bii \u00een proces.<\/p><\/blockquote>\n

<\/p>\n

\u00cencepe\u021bi cu ceea ce este deja folosit.<\/h3>\n

\n\u00cenainte de a achizi\u021biona instrumente scumpe, arunca\u021bi o privire asupra a ceea ce ave\u021bi deja. Fiecare companie are cerin\u021be de securitate care sunt impuse dezvolt\u0103rii, exist\u0103 verific\u0103ri, teste de penetrare - de ce s\u0103 nu transforma\u021bi totul \u00eentr-o form\u0103 clar\u0103 \u0219i convenabil\u0103 pentru to\u021bi?<\/p>\n

De obicei, cerin\u021bele sunt un document greu, care st\u0103 pe o poli\u021b\u0103. A fost un caz c\u00e2nd am ajuns \u00eentr-o companie s\u0103 analiz\u0103m procesele \u0219i am cerut s\u0103 ne arate cerin\u021bele de securitate pentru software. Specialistul responsabil cu acest lucru a c\u0103utat mult:<\/p>\n

\u2014 Acum, undeva \u00een noti\u021be am avut calea unde se afl\u0103 acest document.<\/i><\/p>\n

\u00cen cele din urm\u0103, am ob\u021binut documentul dup\u0103 o s\u0103pt\u0103m\u00e2n\u0103.<\/p>\n

Pentru cerin\u021be, verific\u0103ri \u0219i altele, crea\u021bi o pagin\u0103, de exemplu, pe\u00a0Confluence<\/b>\u00a0\u2014 este convenabil pentru toat\u0103 lumea.<\/p>\n

Este mai simplu s\u0103 reformata\u021bi ceea ce exist\u0103 deja \u0219i s\u0103 folosi\u021bi pentru \u00eenceput.<\/p><\/blockquote>\n

<\/p>\n

Folosi\u021bi Security Champions. <\/h3>\n

\n\u00cen general, \u00eentr-o companie medie de 100-200 de dezvoltatori lucreaz\u0103 un specialist \u00een securitate, care \u00eendepline\u0219te mai multe func\u021bii \u0219i nu are timpul fizic s\u0103 verifice totul. Chiar dac\u0103 se str\u0103duie\u0219te din greu - nu poate verifica singur tot codul generat de dezvoltare. Pentru astfel de cazuri a fost dezvoltat conceptul de Security Champions.<\/b><\/a><\/noindex>.<\/p>\n

Security Champions sunt persoane din echipa de dezvoltare care sunt interesate de securitatea produsului dumneavoastr\u0103.<\/p><\/blockquote>\n

\"Frica
\n
\nSecurity Champion este un punct de contact \u00een echipa de dezvoltare \u0219i un avocat al securit\u0103\u021bii \u00eentr-o singur\u0103 persoan\u0103.<\/p>\n

De obicei, c\u00e2nd un specialist \u00een securitate se al\u0103tur\u0103 echipei de dezvoltare \u0219i indic\u0103 o eroare \u00een cod, r\u0103spunsul pe care \u00eel prime\u0219te este de obicei surprins:<\/p>\n

\u2014 \u0218i cine e\u0219ti tu? Te v\u0103d pentru prima dat\u0103. Eu sunt bine \u2014 mentorul meu mi-a dat \u00abapply\u00bb la code review, continu\u0103m mai departe!<\/i><\/p>\n

Aceasta este o situa\u021bie tipic\u0103, deoarece exist\u0103 mult mai mult\u0103 \u00eencredere \u00een colegii mai vechi sau \u00een cei cu care dezvoltatorul interac\u021bioneaz\u0103 constant la locul de munc\u0103 \u0219i \u00een code review. Dac\u0103, \u00een loc de specialistul \u00een securitate, Security Champion atrage aten\u021bia asupra erorii \u0219i a consecin\u021belor, atunci cuv\u00e2ntul s\u0103u va avea mai mult\u0103 greutate.<\/p>\n

De asemenea, dezvoltatorii cunosc mai bine codul lor dec\u00e2t orice specialist \u00een securitate. Pentru cineva care are cel pu\u021bin 5 proiecte \u00een instrumentul de analiz\u0103 static\u0103, este de obicei greu s\u0103-\u0219i aminteasc\u0103 toate nuan\u021bele. Security Champions \u0219tiu produsul lor: ce interac\u021bioneaz\u0103 cu ce \u0219i la ce s\u0103 se uite \u00eent\u00e2i \u2014 sunt mai eficien\u021bi.<\/p>\n

A\u0219adar, g\u00e2ndi\u021bi-v\u0103 s\u0103 implementa\u021bi Security Champions \u0219i s\u0103 extinde\u021bi influen\u021ba echipei de securitate. Pentru \u00eensu\u0219i campionul, aceasta este de asemenea benefic\u0103: dezvoltare profesional\u0103 \u00eentr-un nou domeniu, extinderea orizontului tehnic, \u00eembun\u0103t\u0103\u021birea abilit\u0103\u021bilor tehnice, de management \u0219i de leadership, cre\u0219terea valorii pe pia\u021b\u0103. Este un element de inginerie social\u0103, \u00abochii\u00bb dumneavoastr\u0103 \u00een echipa de dezvoltare.<\/p>\n

Etapele test\u0103rii<\/h2>\n

\nParadigma 20 la 80<\/a><\/noindex>\u00a0indic\u0103 faptul c\u0103 20% din eforturi dau 80% din rezultate. Aceste 20% constituie practicile de analiz\u0103 a aplica\u021biilor care pot \u0219i trebuie automatizate. Exemple de astfel de activit\u0103\u021bi sunt analiza static\u0103 \u2014 SAST<\/b>, analiza dinamic\u0103 \u2014 DAST,<\/b> \u0219i\u00a0controlul Open Source<\/b>. Voi vorbi mai \u00een detaliu despre activit\u0103\u021bi, dar \u0219i despre instrumentele cu care ne confrunt\u0103m de obicei \u00een timpul implement\u0103rii acestora \u00een proces \u0219i cum s\u0103 facem acest lucru corect.<\/p>\n

\"Frica
\n<\/p>\n

Problemele principale ale instrumentelor<\/h3>\n

\nVoi eviden\u021bia problemele relevante pentru toate instrumentele, care necesit\u0103 aten\u021bie. Le voi analiza \u00een detaliu pentru a nu mai repeta mai departe.<\/p>\n

Timp \u00eendelungat de analiz\u0103. <\/b>Dac\u0103 de la commit la lansarea \u00een produc\u021bie trec 30 de minute pentru toate testele \u0219i compilare, atunci verific\u0103rile de securitate vor dura o zi. Nimeni nu va \u00eencetini procesul din aceast\u0103 cauz\u0103. Lua\u021bi \u00een considerare aceast\u0103 particularitate \u0219i trasa\u021bi concluziile.<\/p>\n

Un nivel ridicat de False Negative sau False Positive. <\/b>Toate produsele sunt diferite, fiecare folose\u0219te cadre diferite \u0219i propriul stil de scriere a codului. Pe diferite baze de cod \u0219i tehnologii, instrumentele pot ar\u0103ta niveluri diferite de False Negative \u0219i False Positive. A\u0219adar, verifica\u021bi ce anume va ar\u0103ta\u00a0\u00een compania dumneavoastr\u0103 \u0219i pentru<\/b> aplica\u021biile dumneavoastr\u0103 un rezultat bun \u0219i de \u00eencredere. Nu exist\u0103 integrare cu instrumentele existente<\/b> . Privind instrumentele din perspectiva integr\u0103rilor, g\u00e2ndi\u021bi-v\u0103 la cele pe care deja le folosi\u021bi. De exemplu, dac\u0103 ave\u021bi Jenkins sau TeamCity, verifica\u021bi integrarea instrumentelor exact cu acel software, nu cu GitLab CI, pe care nu \u00eel utiliza\u021bi.<\/p>\n

Lipsa sau complexitatea excesiv\u0103 a personaliz\u0103rii.<\/b>Dac\u0103 instrumentul nu are API, atunci de ce este necesar? Tot ce se poate face \u00een interfa\u021b\u0103 ar trebui s\u0103 fie disponibil \u0219i prin API. Ideal, instrumentul ar trebui s\u0103 permit\u0103 personalizarea verific\u0103rilor.<\/p>\n

Lipsa unui Roadmap de dezvoltare a produsului. <\/b>Dezvoltarea nu st\u0103 pe loc, \u00eentotdeauna folosim cadre \u0219i func\u021bii noi, rescriem codul vechi \u00een limbaje noi. Vrem s\u0103 fim siguri c\u0103 instrumentul pe care \u00eel cump\u0103r\u0103m va sus\u021bine cadre \u0219i tehnologii noi. De aceea, este important s\u0103 \u0219tim c\u0103 produsul are un<\/p>\n

plan de dezvoltare real \u0219i bine definit. <\/b>Particularit\u0103\u021bile procesului Planul de ac\u021biune<\/a><\/noindex> Pe l\u00e2ng\u0103 particularit\u0103\u021bile instrumentelor, lua\u021bi \u00een considerare \u0219i particularit\u0103\u021bile procesului de dezvoltare. De exemplu, a interveni \u00een dezvoltare este o gre\u0219eal\u0103 tipic\u0103. S\u0103 vedem ce alte particularit\u0103\u021bi ar trebui s\u0103 lu\u0103m \u00een considerare \u0219i la ce ar trebui echipa de securitate s\u0103 fie atent\u0103.<\/p>\n

Pentru a nu \u00eent\u00e2rzia termenele de dezvoltare \u0219i lansare, crea\u021bi<\/h3>\n

\nreguli diferite<\/p>\n

\u0219i diferite show stoppers<\/b> \u2014 criterii de oprire a procesului de compilare \u00een prezen\u021ba vulnerabilit\u0103\u021bilor \u2014 pentru diferite medii\u00a0<\/b>. De exemplu, \u00een\u021belegem c\u0103 ramura curent\u0103 merge pe un mediu de dezvoltare sau UAT, a\u0219a c\u0103 nu ne oprim \u0219i nu spunem: \u2014 Ave\u021bi aici vulnerabilit\u0103\u021bi, nu ve\u021bi merge mai departe!<\/b>Este important s\u0103 le spunem dezvoltatorilor, \u00een aceast\u0103 etap\u0103, c\u0103 exist\u0103 probleme de securitate la care ar trebui s\u0103 fie aten\u021bi.<\/p>\n

\u2014 Ave\u021bi vulnerabilit\u0103\u021bi aici, nu ve\u021bi putea merge mai departe!<\/i><\/p>\n

\u00cen aceast\u0103 etap\u0103, este important s\u0103 spunem dezvoltatorilor c\u0103 exist\u0103 probleme de securitate la care ar trebui s\u0103 fie aten\u021bi.<\/p>\n

Prezen\u021ba vulnerabilit\u0103\u021bilor nu reprezint\u0103 un obstacol pentru testarea ulterioar\u0103<\/b>: manual\u0103, integrat\u0103 sau manual\u0103. Pe de alt\u0103 parte, trebuie s\u0103 g\u0103sim o modalitate de a spori securitatea produsului, astfel \u00eenc\u00e2t dezvoltatorii s\u0103 nu ignore ceea ce descoper\u0103 echipa de securitate. A\u0219adar, uneori ac\u021bion\u0103m astfel: pe stand, c\u00e2nd se face transferul c\u0103tre mediu de dezvoltare, doar notific\u0103m echipa de dezvoltare:<\/p>\n

\u2014 Guys, ave\u021bi probleme, v\u0103 rug\u0103m s\u0103 le acorda\u021bi aten\u021bie.<\/i><\/p>\n

\u00cen etapa UAT, din nou prezent\u0103m avertiz\u0103ri cu privire la vulnerabilit\u0103\u021bi, iar \u00een etapa de lansare \u00een produc\u021bie spunem:<\/p>\n

\u2014 Guys, v-am avertizat de c\u00e2teva ori, nu a\u021bi f\u0103cut nimic \u2014 cu asta nu v\u0103 vom lansa.<\/i><\/p>\n

Dac\u0103 vorbim despre cod \u0219i dinamic\u0103, este necesar s\u0103 ar\u0103t\u0103m \u0219i s\u0103 avertiz\u0103m doar cu privire la vulnerabilit\u0103\u021bile func\u021biilor \u0219i codului care au fost scrise recent \u00een aceast\u0103 func\u021bie. Dac\u0103 dezvoltatorul a mutat un buton cu 3 pixeli \u0219i \u00eei spunem c\u0103 are o injec\u021bie SQL \u0219i c\u0103 trebuie s\u0103 corecteze urgent \u2014 este gre\u0219it. Uita\u021bi-v\u0103 doar la ceea ce este scris acum \u0219i la modificarea care vine \u00een aplica\u021bie.<\/p>\n

S\u0103 presupunem c\u0103 avem un defect func\u021bional \u2014 adic\u0103 modul \u00een care aplica\u021bia nu ar trebui s\u0103 func\u021bioneze: banii nu se transfer\u0103, nu exist\u0103 navigare c\u0103tre pagina urm\u0103toare atunci c\u00e2nd face\u021bi clic pe buton sau produsul nu se \u00eencarc\u0103. Defectele de securitate<\/b>\u00a0\u2014 sunt defecte la fel ca orice altele, dar nu \u00een privin\u021ba func\u021bion\u0103rii aplica\u021biei, ci a securit\u0103\u021bii. <\/p>\n

Nu toate problemele de calitate ale software-ului sunt probleme de securitate. Dar toate problemele de securitate sunt legate de calitatea software-ului. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nDeoarece toate vulnerabilit\u0103\u021bile sunt defecte, ele ar trebui s\u0103 se afle acolo unde se afl\u0103 toate defectele de dezvoltare. A\u0219adar, uita\u021bi de rapoarte \u0219i de PDF-uri \u00eenfrico\u0219\u0103toare pe care nimeni nu le cite\u0219te.<\/p>\n

\"Frica
\n
\nC\u00e2nd lucram \u00eentr-o companie de dezvoltare, am primit un raport din instrumentele de analiz\u0103 static\u0103. L-am deschis, am fost devastat, am f\u0103cut o cafea, m-am r\u0103sfoit 350 de pagini, l-am \u00eenchis \u0219i m-am apucat din nou de munc\u0103. Rapoartele mari sunt rapoarte moarte<\/b>. De obicei, nu ajung nic\u0103ieri, e-mailurile sunt \u0219terse, uitate, pierdute sau business-ul spune c\u0103 \u00ee\u0219i asum\u0103 riscurile.<\/p>\n

Ce trebuie s\u0103 facem? Defectele confirmate identificate sunt transformate \u00eentr-o form\u0103 \u0443\u0434\u043e\u0431\u043d\u043e\u0439 pentru dezvoltare, de exemplu, adunate \u00een backlog \u00een Jira. Prioritiz\u0103m defectele \u0219i le remedieze \u00een ordinea priorit\u0103\u021bii, la fel ca defectele func\u021bionale \u0219i defectele testelor.<\/p>\n

Analiz\u0103 static\u0103 - SAST<\/h2>\n

\nAceasta este analiza codului pentru identificarea vulnerabilit\u0103\u021bilor<\/b>, dar nu este acela\u0219i lucru cu SonarQube. Verific\u0103m nu doar dup\u0103 modele sau stil. \u00cen analiz\u0103 se aplic\u0103 o serie de abord\u0103ri: pe baza arborelui vulnerabilit\u0103\u021bilor, pe\u00a0DataFlow<\/a><\/noindex>, pe analiza fi\u0219ierelor de configurare. Acestea sunt toate aspectele legate direct de cod.<\/p>\n

Avantajele abord\u0103rii<\/b>: identificarea vulnerabilit\u0103\u021bilor \u00een cod \u00een etapele timpurii ale dezvolt\u0103rii<\/b>, c\u00e2nd nu exist\u0103 \u00eenc\u0103 standuri \u0219i un instrument gata, \u0219i\u00a0posibilitatea scan\u0103rii incrementale<\/b>: scanarea unei por\u021biuni de cod care a fost modificat\u0103 \u0219i doar a acelei caracteristici pe care o realiz\u0103m acum, ceea ce reduce timpul de scanare.<\/p>\n

Dezavantaje<\/b>\u00a0\u2014 este lipsa suportului pentru limbajele necesare.<\/p>\n

Integr\u0103rile necesare, <\/b>care ar trebui s\u0103 fie \u00een instrumente, din punctul meu de vedere subiectiv:<\/p>\n