Ne kemi pasur 2 analiza të kodit, 4 mjete për testimin dinamik, krijimet tona dhe 250 skenarë. Jo se gjithçka këto ishin të nevojshme në procesin aktual, por qëkur fillova të implementoj DevSecOps, duhet ta çoj deri në fund.
. Autorët e karaktereve: Justin Roiland dhe Dan Harmon.
ĂfarĂ« Ă«shtĂ« SecDevOps? Dhe DevSecOps? ĂfarĂ« ka ndryshime? Siguria e Aplikacioneve â pĂ«r çfarĂ« Ă«shtĂ« kjo? Pse qasja klasike nuk funksionon mĂ«? TĂ« gjitha kĂ«to pyetje kanĂ« pĂ«rgjigje. Yuri Shabalin nga Swordfish Security. Yuri do tĂ« pĂ«rgjigjet pĂ«r gjithçka dhe do tĂ« shqyrtojĂ« problemet e kalimit nga modeli klasik i SigurisĂ« sĂ« Aplikacioneve nĂ« procesin DevSecOps: si tĂ« qasemi nĂ« mĂ«nyrĂ« tĂ« duhur pĂ«r integrimin e procesit tĂ« zhvillimit tĂ« sigurt nĂ« procesin DevOps dhe tĂ« mos dĂ«mtojmĂ« asgjĂ« nĂ« kĂ«tĂ«, si tĂ« kalojmĂ« nĂ«pĂ«r hapat kryesorĂ« tĂ« testimit tĂ« sigurisĂ«, cilat mjete mund tĂ« aplikohen, çfarĂ« e ndan ato dhe si t'i konfigurojmĂ« saktĂ« pĂ«r tĂ« shmangur pengesat.
PĂ«r folĂ«sin: Yuri Shabalin â Arkitekt i SigurisĂ« Kryesore nĂ« kompaninĂ« Swordfish Security. Ai Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r implementimin e SSDL, pĂ«r integrimin e pĂ«rgjithshĂ«m tĂ« mjeteve tĂ« analizĂ«s sĂ« aplikacioneve nĂ« njĂ« ekosistem tĂ« vetĂ«m tĂ« zhvillimit dhe testimit. 7 vjet pĂ«rvojĂ« nĂ« sigurinĂ« informacionit. Ka punuar nĂ« Alfa-Bank, Sberbank dhe nĂ« Positive Technologies, e cila zhvillon softuer dhe ofron shĂ«rbime. FolĂ«s nĂ« konferenca ndĂ«rkombĂ«tare si ZerONights, PHDays, RISSPA, OWASP.
Siguria e Aplikacioneve: për çfarë është kjo?
Siguria e Aplikacioneve ështĂ« njĂ« degĂ« e sigurisĂ« qĂ« Ă«shtĂ« pĂ«rgjegjĂ«se pĂ«r sigurinĂ« e aplikacioneve. Kjo nuk i pĂ«rket infrastrukturĂ«s ose sigurisĂ« rrjetĂ«ve, por saktĂ«sisht asaj qĂ« ne shkruajmĂ« dhe mbi tĂ« cilat punojnĂ« zhvilluesit â janĂ« defektet dhe dobĂ«sitĂ« e vetĂ« aplikacionit.
Direktiva  â Cikli zhvillim tĂ« sigurisĂ«Â u zhvillua nga kompania Microsoft. NĂ« diagram, Ă«shtĂ« modeli kanonik i SDLC, ku qĂ«llimi kryesor Ă«shtĂ« pĂ«rfshirja e sigurisĂ« nĂ« çdo fazĂ« tĂ« zhvillimit, nga kĂ«rkesat deri nĂ« lĂ«shim dhe daljen nĂ« prodhim. NĂ« Microsoft e kuptuan se nĂ« prodhim ka shumĂ« gabime, ato po rriten dhe duhet bĂ«rĂ« diçka pĂ«r kĂ«tĂ«, dhe propozuan kĂ«tĂ« qasje qĂ« u bĂ« kanonike.
Siguria e Aplikacioneve dhe SSDL nuk janë të orientuara ndaj zbardhjes së dobësive, siç mendohet zakonisht, por ndaj parandalimit të shfaqjes së tyre. Me kalimin e kohës, qasja kanonike nga Microsoft u përmirësua, u zhvillua, duke ofruar një përfshirje më të thellë dhe më të detajuar.
SDLC kanonik Ă«shtĂ« shumĂ« i detajuar nĂ« metodologjitĂ« e ndryshme â OpenSAMM, BSIMM, OWASP. MetodologjitĂ« ndryshojnĂ«, por, nĂ« pĂ«rgjithĂ«si, janĂ« tĂ« ngjashme.
Modeli i Pjekurisë për Ndërtimin e Sigurisë
MĂ« pĂ«lqen mĂ« shumĂ« BSIMM â . Baza e metodologjisĂ« Ă«shtĂ« ndarja e procesit tĂ« SigurisĂ« sĂ« Aplikacioneve nĂ« 4 fusha: Qeverisje, InteligjencĂ«, PikĂ«prekje SSDL dhe Zbatim. NĂ« çdo fushĂ« ka 12 praktika, tĂ« cilat paraqiten si 112 aktivitete.
Ădo aktivitet nga 112 ka 3 nivele pjekurie: fillestar, mesatar dhe avancuar. TĂ« gjitha 12 praktikat mund tĂ« studiohen sipas kapitujve, tĂ« zgjidhen elementĂ«t e rĂ«ndĂ«sishĂ«m pĂ«r ju, tĂ« kuptoni se si t'i implementoni dhe gradualisht tĂ« shtoni elemente, pĂ«r shembull, analizĂ«n statike dhe dinamike tĂ« kodit ose rishikimin e kodit. Shkruani njĂ« plan dhe sipas tij punoni pa njĂ« problem nĂ« implementimin e aktiviteteve tĂ« zgjedhura.
Pse DevSecOps
DevOps është një proces i madh tërësor, në të cilin duhet të kujdesesh për sigurinë.
Fillimisht mbante parasysh kontrollet për sigurinë. Në praktikë, numri i ekipeve të sigurisë ishte shumë më i vogël se tani, dhe ata vepronin jo si pjesëmarrës në proces, por si një organ kontrollues dhe mbikëqyrës që vendos kërkesa dhe kontrollon cilësinë e produktit në fund të lëshimit. Ky është një qasje klasike, në të cilën ekipet e sigurisë ndodheshin përtej zhvillimit dhe nuk merrnin pjesë në proces.
Problemi kryesor Ă«shtĂ« se siguria e informacionit Ă«shtĂ« e ndarĂ« nga zhvillimi. Zakonisht, kjo Ă«shtĂ« njĂ« strukturĂ« e sigurisĂ« e informacionit dhe pĂ«rmban 2-3 mjete tĂ« mĂ«dha dhe tĂ« shtrenjta. Ădo gjashtĂ« muaj vjen njĂ« kod burimi ose aplikacion qĂ« duhet kontrolluar, ndĂ«rsa çdo vit bĂ«hen . Kjo çon nĂ« vonesa nĂ« lĂ«shimin nĂ« treg, dhe zhvilluesit pĂ«rballen me njĂ« mori tĂ« madhe tĂ« dobĂ«sive nga mjetet automatizuese. Gjithçka Ă«shtĂ« e pamundur pĂ«r t'u lexuar dhe rregulluar, sepse pasi gjashtĂ« muaj tĂ« kaluar, rezultatet nuk janĂ« analizuar, ndĂ«rsa tani ka njĂ« grup tĂ« ri.
GjatĂ« punĂ«s sĂ« kompanisĂ« sonĂ«, shohim se siguria nĂ« tĂ« gjitha fushat dhe industrive kupton se Ă«shtĂ« koha tĂ« pĂ«rmirĂ«sohet dhe tĂ« punojĂ« bashkĂ« me zhvillimin nĂ« njĂ« rrotĂ« â nĂ«Â . Paradigma DevSecOps pĂ«rshtatet mrekullisht me metodologjinĂ« e zhvillimit tĂ« shkathĂ«t, me implementimin, mbĂ«shtetje dhe pjesĂ«marrje nĂ« çdo lĂ«shim dhe iteracion.
Kalimi në DevSecOps
Fjala më e rëndësishme në Jetën e Zhvillimit të Sigurisë është "procesi"Duhet ta kuptoni këtë para se të mendoni për blerjen e mjeteve.
Thjesht të përfshish mjetet në procesin DevOps nuk është e mjaftueshme - është e rëndësishme ndërveprimi dhe kuptimi midis pjesëmarrësve në proces.
Njerëzit janë më të rëndësishëm se mjetet
Shpesh planifikimi i procesit të zhvillimit të sigurt fillon me zgjedhjen dhe blerjen e një mjeti, dhe përfundon me përpjekjet për të integruar mjetin në procesin ekzistues, i cili mbetet thjesht përpjekje. Kjo çon në pasoja të trishtueshme, sepse çdo mjet ka karakteristikat dhe kufizimet e veta.
Një rast i zakonshëm është kur departamenti i sigurisë zgjodhi një mjet të mirë, të shtrenjtë, me mundësi të gjera, dhe shkonte te zhvilluesit - për ta integruar në proces. Por nuk funksionon - procesi është ndërtuar në një mënyrë që kufizimet e mjetit të blerë nuk përputhen me paradigmën aktuale.
Së pari, përshkruani se cili është rezultati që dëshironi dhe si do të duket procesi. Kjo do të ndihmojë në kuptimin e rolit të mjeteve dhe sigurisë në proces.
Filloni me atë që tashmë përdoret
Para se tĂ« blini mjete tĂ« shtrenjta, shikoni nĂ« atĂ« qĂ« tashmĂ« keni. Ădo kompani ka kĂ«rkesa pĂ«r siguri qĂ« i paraqiten zhvillimit, ka kontrolle, teste penetruese - pse tĂ« mos i transformoni kĂ«to nĂ« njĂ« format tĂ« qartĂ« dhe tĂ« pĂ«rshtatshĂ«m pĂ«r tĂ« gjithĂ«?
Zakonisht kërkesat janë një dokument i shkruar që peshon për një gozhdë. Ka pasur raste kur shkojmë në një kompani për të parë proceset dhe kërkojmë të shohim kërkesat për siguri për softuerin. Specialistja që merrej me këtë kërkoi për një kohë të gjatë:
â Tani, ndoshta nĂ« shĂ«nime kishte njĂ« rrugĂ« se ku ndodhej ky dokument.
Si rezultat, morëm dokumentin pas një jave.
PĂ«r kĂ«rkesat, kontrollet dhe gjĂ«ra tĂ« tjera, krijoni njĂ« faqe, pĂ«r shembull, nĂ«Â Confluence â Ă«shtĂ« e pĂ«rshtatshme pĂ«r tĂ« gjithĂ«.
Më lehtë është të riparformatizoni atë që tashmë ekziston dhe ta përdorni si pikënisje.
PĂ«rdorni Security Champions
Zakonisht, në një kompani mesatare me 100-200 zhvillues ka një ekspert sigurie, i cili kryen disa funksione dhe fizikisht nuk arrin të kontrollojë gjithçka. Edhe nëse ai përpiqet me të gjitha forcat - vetëm nuk do të kontrollojë të gjithë kodin që gjeneron zhvillimi. Për këto raste është zhvilluar koncepti - .
Security Champions është një person në brendësi të ekipit të zhvillimit i interesuar për sigurinë e produktit tuaj.
Security Champion është pika e hyrjes në ekipin e zhvillimit dhe evangjelisti i sigurisë në një person.
Zakonisht, kur një specialist i sigurisë hyn në ekipin e zhvillimit dhe tregohet për një gabim në kod, përgjigjja është:
â QĂ« kush je ti? TĂ« shoh pĂ«r herĂ« tĂ« parĂ«. Kam gjithçka nĂ« rregull â mĂ« rishikoi dikush mĂ« i madh dhe mĂ« tha âaplikoâ, ne vazhdojmĂ« pĂ«rpara!
Kjo është një situatë tipike, sepse ka shumë më tepër besim tek të moshuarit ose thjesht tek shokët e ekipit, me të cilët zhvilluesi bashkëvepron vazhdimisht në punë dhe gjatë rishikimit të kodit. Nëse vendin e specialistit të sigurisë e zë një Security Champion që tregon për gabimin dhe pasojat, fjala e tij do të ketë më shumë peshë.
Po ashtu, zhvilluesit e njohin kodin e tyre mĂ« mirĂ« se çdo specialist sigurie. PĂ«r njĂ« person qĂ« ka tĂ« paktĂ«n 5 projekte nĂ« mjetin e analizĂ«s statike, zakonisht Ă«shtĂ« e vĂ«shtirĂ« tĂ« mbash mend tĂ« gjitha nuancat. Security Champions e njohin produktin e tyre: se çfarĂ« ndĂ«rvepron me çfarĂ« dhe nĂ« çfarĂ« duhet tĂ« shikohet mĂ« shumĂ« â ata janĂ« mĂ« efikas.
Pra, mendoni pĂ«r implementimin e Security Champions dhe zgjerimin e ndikimit tĂ« ekipit tĂ« sigurisĂ«. PĂ«r vetĂ« kampionin, kjo Ă«shtĂ« gjithashtu e dobishme: zhvillim profesional nĂ« njĂ« fushĂ« tĂ« re, zgjerim tĂ« njohurive teknike, pĂ«rmirĂ«sim tĂ« aftĂ«sive teknike, menaxheriale dhe udhĂ«heqĂ«se, rritje tĂ« vlerĂ«s nĂ« treg. Ky Ă«shtĂ« njĂ« element i caktuar i inxhinierisĂ« sociale, âsytĂ«â tuaj nĂ« ekipin e zhvillimit.
Hapat e testimit
 tregon se 20% e pĂ«rpjekjeve japin 80% tĂ« rezultateve. KĂ«to 20% janĂ« praktikat e analizĂ«s sĂ« aplikacioneve, tĂ« cilat mund dhe duhet tĂ« automatizohen. Shembuj tĂ« aktiviteteve tĂ« tilla janĂ« analiza statike â SAST, analiza dinamike â DAST, dhe kontrolli i Open Source. Do tĂ« flas mĂ« shumĂ« rreth aktiviteteve, si dhe pĂ«r mjetet, me cilĂ«sitĂ« e cilat zakonisht pĂ«rballemi gjatĂ« implementimit tĂ« tyre nĂ« proces, dhe si ta bĂ«jmĂ« siç duhet.
Problemet kryesore të mjeteve
Do të veçoj problemet që janë aktuale për të gjitha mjete, të cilat kërkojnë vëmendje. Do t'i shqyrtoj ato në detaje për të mos u përsëritur më tej.
Koha e gjatë e analizës. Nëse nga komitimi deri në daljen në prodhim kalojnë 30 minuta për të gjitha testet dhe ndërtimin, kontrollet për sigurinë informacionit do të kërkojnë një ditë. Askush nuk do të ngadalësojë procesin. Merrni parasysh këtë veçori dhe bëni përfundime.
Niveli i lartë i False Negative ose False Positive. Produkte të ndryshme përdorin framework të ndryshme dhe stilin e vet të kodimit. Në baza të ndryshme kode dhe teknologjish, mjetet mund të tregojnë nivele të ndryshme të False Negative dhe False Positive. Prandaj shikoni se çfarë saktësisht në kompaninë tuaj dhe për aplikacionet tuaja do të tregojë rezultat të mirë dhe të besueshëm. Nuk ka integrime me mjete ekzistuese. Shikoni mjete nga këndvështrimi i integrimeve, me ato që tashmë përdorni. Për shembull, nëse keni Jenkins ose TeamCity, kontrolloni integrimin e mjeteve pikërisht me këtë softuer, jo me GitLab CI, që nuk e përdorni.
Mungesa ose kompleksiteti i tepruar i personalizimit.NĂ«se mjeti nuk ka API, pĂ«rse do tĂ« ishte i nevojshĂ«m? Ădo gjĂ« qĂ« mund tĂ« bĂ«het nĂ« ndĂ«rfaqe duhet tĂ« jetĂ« e aksesueshme pĂ«rmes API. NĂ« ideal, mjeti duhet tĂ« ketĂ« mundĂ«sinĂ« e personalizimit tĂ« kontrolleve.
Nuk ka roadmap për zhvillimin e produktit. Zhvillimi nuk qëndron në vend, ne gjithmonë përdorim framework dhe funksione të reja, duke e shkruar sërish kodin e vjetër në gjuhë të reja. Duam të jemi të sigurt se mjeti që do të blejmë do të mbështesë framework dhe teknologji të reja. Prandaj është e rëndësishme të dimë se produkti ka një
zhvillimi të vërtetë dhe të duhur. Veçoritë e procesit Përveç veçorive të mjeteve, merrni parasysh edhe veçoritë e procesit të zhvillimit. Për shembull, të pengosh zhvillimin është një gabim tipik. Le të shohim cilat veçori të tjera duhet të merren parasysh dhe në çfarë duhet të përqendrohet ekipi i sigurisë.
Për të mos prishur afatet e zhvillimit dhe publikimit, krijoni
rregulla të ndryshme
dhe show stoppers â kriteret e ndalimit tĂ« procesit tĂ« ndĂ«rtimit nĂ« rast se ka dobĂ«si â pĂ«r ambientet e ndryshme. PĂ«r shembull, ne kuptojmĂ« se dega aktuale po shkon nĂ« skenĂ«n e zhvillimit ose UAT, prandaj nuk ndalojmĂ« dhe nuk themi: â KĂ«tu keni dobĂ«si, nuk do tĂ« shkoni tutje!NĂ« kĂ«tĂ« fazĂ«, Ă«shtĂ« e rĂ«ndĂ«sishme t'u themi zhvilluesve se ka probleme sigurie qĂ« meritojnĂ« vĂ«mendje.
â KĂ«tu keni do tĂ« meta, nuk do tĂ« shkoni mĂ« tej!
Në këtë fazë është e rëndësishme të thuhet developerëve se ka probleme sigurie, për të cilat duhet të kushtojnë vëmendje.
Prania e dobësisë nuk është një pengesë për testim të mëtejshëm: manual, integrues ose manual. Nga ana tjetër, na nevojitet ndonjë mënyrë për të rritur sigurinë e produktit, dhe që zhvilluesit të mos injorojnë atë që gjen siguria. Prandaj, herë pas here bëjmë kështu: në një stendë, kur zbulohet në ambientin e zhvillimit, thjesht informojmë zhvillimin:
â Djem, keni probleme, ju lutem, kushtoni vĂ«mendje atyre.
Në fazën UAT përsëri tregojmë paralajmërime për dobësitë dhe në fazën e lëshimit në prodhim themi:
â Djem, ne ju kemi paralajmĂ«ruar disa herĂ«, nuk keni bĂ«rĂ« asgjĂ« â me kĂ«tĂ« nuk do t'ju lejojmĂ« tĂ« lĂ«shoni.
NĂ«se flasim pĂ«r kodin dhe dinamikĂ«n, Ă«shtĂ« e nevojshme tĂ« tregojmĂ« dhe paralajmĂ«rojmĂ« pĂ«r dobĂ«sitĂ« e vetĂ«m atyre karakteristikave dhe kodit qĂ« janĂ« shkruar rishtazi nĂ« kĂ«tĂ« karakteristikĂ«. NĂ«se njĂ« zhvillues ka lĂ«vizur njĂ« buton pĂ«r 3 piksel dhe i themi se ka njĂ« SQL injeksion dhe prandaj duhet tĂ« rregullohet urgent â kjo Ă«shtĂ« e gabuar. Shikoni vetĂ«m atĂ« qĂ« Ă«shtĂ« shkruar tani dhe atĂ« ndryshim qĂ« po vjen nĂ« aplikacion.
PĂ«r shembull, kemi njĂ« defekt funksional â ashtu si aplikacioni nuk duhet tĂ« funksionojĂ«: paratĂ« nuk transferohen, kur klikoni nĂ« buton nuk ka kalim nĂ« faqen tjetĂ«r ose nuk ngarkohet produkti. Defektet e sigurisĂ«Â â janĂ« njĂ«soj si defektet, por jo nĂ« prizmin e funksionimit tĂ« aplikacionit, por tĂ« sigurisĂ«.
Jo të gjitha problemet e cilësisë së softuerit janë probleme sigurie. Por të gjitha problemet e sigurisë lidhen me cilësinë e softuerit. Sherif Mansour, Expedia.
Meqenëse të gjitha dobësitë janë njësoj si defektet, ato duhet të jenë në të njëjtin vend si të gjitha defektet e zhvillimit. Prandaj, harrojeni raportet dhe PDF-të e frikshme që askush nuk i lexon.
Kur punoja në një kompani që merrej me zhvillimin, më erdhi një raport nga mjetet e analizës statike. E hapa atë, u tmerrua, bëra kafe, e shfletoja 350 faqe, e lidha dhe shkova të punoja më tej. Raportet e mëdha janë raportet e vdekur. Zakonisht ato nuk shkojnë askund, e-mailet fshihen, harrohen, humbasin ose biznesi thotë se pranon rreziqet.
ĂfarĂ« duhet tĂ« bĂ«jmĂ«? Defektet e konfirmuara qĂ« kemi gjetur, thjesht i shndĂ«rrojmĂ« nĂ« njĂ« format tĂ« pĂ«rshtatshĂ«m pĂ«r zhvillim, pĂ«r shembull, i vendosim nĂ« backlog nĂ« Jira. Ne i prioritojmĂ« defektet dhe i eliminojmĂ« sipas rendit tĂ« prioriteteve, njĂ«soj si defektet funksionale dhe defektet e testeve.
Analiza Statike - SAST
Ky është një analizë e kodit për prani të dobësive., por kjo nuk është e njejtë si SonarQube. Ne kontrollojmë jo vetëm për modele apo stil. Gjatë analizës përdoren një sërë qasje për: pemën e dobësive, për , analiza e skedave të konfigurimit. Këto janë të gjitha lidhur me kodin.
Avantazhet e qasjes: identifikimi i dobësive në kod gjatë një faze të hershme të zhvillimit, kur ende nuk ka ambiente dhe mjete të gatshme, dhe mundësia e skanimit incremental: skanimi i pjesës së kodit që është ndryshuar, dhe vetëm të asaj funksionaliteti që po zhvillojmë tani, e cila redukton kohën e skanimit.
Disavantazhet - është mungesa e mbështetjes për gjuhët e nevojshme.
Integrimet e nevojshme, të cilat duhet të jenë në mjetet, sipas mendimit tim subjektiv:
- Mjeti i integrimit: Jenkins, TeamCity dhe Gitlab CI.
- Mediat e zhvillimit: Intellij IDEA, Visual Studio. Zhvilluesi është më komod te mos kërkojë në një ndërfaqe të panjohur, e cila duhet të mbahet mend, por përkundrazi të shohë të gjitha integrimet e nevojshme dhe dobësitë që ka gjetur aty ku punon.
- Rishikimi i kodit: SonarQube dhe rishikimi manual.
- Sistemet e ndjekjes së defekteve: Jira dhe Bugzilla.
Në figurë janë disa nga përfaqësuesit më të mirë të analizës statike.
Mjetet nuk janë të rëndësishme, por procesi është, prandaj ekzistojnë zgjidhje Open Source që janë po aq të mira për testimin e procesit.
SAST Open Source nuk do tĂ« gjejnĂ« njĂ« sasi tĂ« madhe dobĂ«sish ose Flow tĂ« DhĂ«nash tĂ« ndĂ«rlikuara, por kur ndĂ«rtoni procesin, mund dhe duhet tâi pĂ«rdorni. Ato ndihmojnĂ« nĂ« kuptimin se si do tĂ« ndĂ«rtohet procesi, kush do tĂ« jetĂ« pĂ«rgjegjĂ«s pĂ«r defektet, kush do tĂ« raportojĂ«, kush do tĂ« raportojĂ«. NĂ«se dĂ«shironi tĂ« realizoni njĂ« fazĂ« fillestare tĂ« ndĂ«rtimit tĂ« sigurisĂ« sĂ« kodit tuaj - pĂ«rdorni zgjidhje Open Source.
Si mund ta integroni këtë, nëse jeni në fillim të rrugës, nuk keni asgjë: as CI, as Jenkins, as TeamCity? Le t'i shohim integrimet në proces.
Integrimi në nivelin CVS
Nëse keni Bitbucket ose GitLab, mund të bëni integrimin në nivelin .
NĂ« pĂ«rputhje me ngjarjen â pull request, commit. Ju skanoni kodin dhe nĂ« statusin e build-it tregoni nĂ«se kontrolli pĂ«r sigurinĂ« kaloi apo jo.
RrĂ«fimi. Sigurisht, feedback-u Ă«shtĂ« gjithmonĂ« i nevojshĂ«m. NĂ«se thjesht keni ecur nĂ« anĂ«n e sigurisĂ«, keni mbledhur gjithçka nĂ« njĂ« kuti dhe nuk keni treguar askujt pĂ«r kĂ«tĂ«, dhe pastaj nĂ« fund tĂ« muajit lĂ«shoni njĂ« sĂ«rĂ« gabimesh â kjo nuk Ă«shtĂ« e drejtĂ« dhe e mirĂ«.
Integrimi me sistemin e recensioneve të kodit
NjĂ«herĂ«, ne vendosĂ«m nĂ« njĂ« seri projektesh tĂ« rĂ«ndĂ«sishme njĂ« pĂ«rdorues teknik default si revizor AppSec. NĂ« varĂ«si nga ajo nĂ«se janĂ« gjetur gabime nĂ« kodin e ri apo jo, revizori nĂ« pull request vendos statusin nĂ« «accept» ose «need work» â ose gjithçka Ă«shtĂ« nĂ« rregull, ose duhet tĂ« punohet mĂ« shumĂ« dhe lidhje pĂ«r atĂ« qĂ« duhet tĂ« rregullohet. PĂ«r integrimin me versionin qĂ« shkon nĂ« prodhim, ne kishim aktivizuar ndalimin e merge-it nĂ«se testi pĂ«r sigurinĂ« nuk kalonte. Kjo e aktivizonim nĂ« revizimin manual tĂ« kodit dhe pjesĂ«marrĂ«sit e tjerĂ« nĂ« proces shihnin statuset pĂ«r sigurinĂ« pĂ«r kĂ«tĂ« proces tĂ« veçantĂ«.
Integrimi me SonarQube
ShumĂ« kanĂ« pĂ«r cilĂ«sinĂ« e kodit. KĂ«tu Ă«shtĂ« e njĂ«jta gjĂ« â mund tĂ« bĂ«hen tĂ« njĂ«jtat gates vetĂ«m pĂ«r mjetet SAST. Do tĂ« ketĂ« tĂ« njĂ«jtin ndĂ«rfaqe, tĂ« njĂ«jtin quality gate, vetĂ«m se do tĂ« quhet security gate. Po ashtu, nĂ«se keni instaluar njĂ« proces me pĂ«rdorimin e SonarQube, mund ta integrosh gjithçka pa problem.
Integrimi në nivelin CI
Këtu gjithashtu është mjaft e thjeshtë:
- Në një nivel me testet automatike, testet njësinë.
- Pjesëtimi sipas fazave të zhvillimit: dev, test, prod. Mund të përfshihen grupe të ndryshme rregullash, ose kushte të ndryshme dështimi: ndalojmë ndërtimin, nuk ndalojmë ndërtimin.
- Aktivizimi sinkron/asinkron. Ne presim përfundimin e kontrollit të testeve për sigurinë ose nuk presim. Do të thotë se thjesht i kemi nisur ato dhe vazhdojmë përpara, dhe më pas na vjen statusi, që gjithçka është mirë ose keq.
Kjo është gjithçka në një botë ideale. Në jetën reale nuk ka diçka të tillë, por ne përpiqemi. Rezultati i kontrollit të sigurisë duhet të jetë i ngjashëm me rezultatet e testeve njësinë.
PĂ«r shembull, morĂ«m njĂ« projekt tĂ« madh dhe vendosĂ«m se tani do ta skanojmĂ« me SAST â OK. E kemi futur kĂ«tĂ« projekt nĂ« SAST, ai na dha 20,000 dobĂ«si dhe me njĂ« vendim tĂ« fortĂ« pranuam se gjithçka Ă«shtĂ« nĂ« rregull. 20,000 dobĂ«si â Ă«shtĂ« borxhi ynĂ« teknik. Borxhin do ta vendosim nĂ« njĂ« kutizĂ«, do ta shohim ngadalĂ« dhe do tĂ« krijojmĂ« defekte nĂ« tracker-in tonĂ« tĂ« defekteve. Do tĂ« punĂ«sojmĂ« njĂ« kompani, do ta bĂ«jmĂ« gjithçka vetĂ« ose do tĂ« na ndihmojnĂ« Security Champions â dhe borxhi teknik do tĂ« zvogĂ«lohet.
NdĂ«rsa tĂ« gjitha dobĂ«sitĂ« e reja nĂ« kodin e ri duhet tĂ« zgjidhen po ashtu siç janĂ« zgjidhur gabimet nĂ« testet unitare ose automatizuar. Me fjalĂ« tĂ« tjera, u lançua ndĂ«rtimi, u ekzekutuan testet dhe dĂ«shtuan dy teste dhe dy teste pĂ«r sigurinĂ«. OK â shkuam, pamĂ« se çfarĂ« ndodhi, korrigjuam njĂ«, korrigjuam tjetrĂ«n, herĂ«n tjetĂ«r e ekzekutuam â gjithçka Ă«shtĂ« nĂ« rregull, nuk ka pasur dobĂ«si tĂ« reja, testet nuk janĂ« dĂ«shtuar. NĂ«se ky detyrĂ« Ă«shtĂ« mĂ« e thellĂ« dhe kĂ«rkon tĂ« kuptohet mirĂ«, ose korrigjimi i dobĂ«sive prek pjesĂ« tĂ« mĂ«dha tĂ« asaj qĂ« ndodhet nĂ«n kapak: krijuam njĂ« defekt nĂ« tracker-in e defekteve, ai prioritizohet dhe rregullohet. FatkeqĂ«sisht, bota nuk Ă«shtĂ« ideale dhe testet ndonjĂ«herĂ« dĂ«shtojnĂ«.
NjĂ« shembull i security gate â analog i quality gate, sipas pranisĂ« dhe numrit tĂ« dobĂ«sive nĂ« kod.
Integrimi me SonarQube â plug-in instalohet, gjithçka Ă«shtĂ« shumĂ« e pĂ«rshtatshme dhe e shkĂ«lqyer.
Integrimi me mjedisin e zhvillimit
Mundësitë e integrimit:
- Ekzekutimi i skanimit nga mjedisi i zhvillimit para commit-it.
- Shikimi i rezultateve.
- Analiza e rezultateve.
- Sinkronizimi me serverin.
Diku në këtë mënyrë duket marrja e rezultateve nga serveri.
NĂ« mjedisin tonĂ« tĂ« zhvillimit thjesht shfaqet njĂ« pikĂ« shtesĂ«, e cila tregon se gjatĂ« skanimit janĂ« zbuluar kĂ«to dobĂ«si. Mund tĂ« korrigjoni menjĂ«herĂ« kodin, tĂ« shikoni rekomandimet dhe . TĂ« gjitha kĂ«to janĂ« tĂ« vendosura nĂ« vendin e punĂ«s sĂ« zhvilluesit, qĂ« Ă«shtĂ« shumĂ« e pĂ«rshtatshme â nuk Ă«shtĂ« nevoja tĂ« shkoni nĂ« lidhje tĂ« tjera dhe tĂ« shikoni diçka shtesĂ«.
Open Source
Kjo Ă«shtĂ« tema ime e preferuar. TĂ« gjithĂ« pĂ«rdorin biblioteka Open Source â pse tĂ« shkruajmĂ« njĂ« mori çështjesh dhe biçikletash, kur mund tĂ« marrim njĂ« bibliotekĂ« gati, nĂ« tĂ« cilĂ«n gjithçka Ă«shtĂ« e realizuar tashmĂ«?
Sigurisht, është ashtu, por bibliotekat gjithashtu shkruhen nga njerëzit, përfshijnë gjithashtu rreziqe të caktuara dhe gjithashtu kanë vulnerabilitete mbi të cilat raportohen periodikisht, ose vazhdimisht. Prandaj, hapi tjetër në Sigurinë e Aplikacioneve është analiza e komponenteve Open Source.
Analiza Open Source â OSA
Instrumenti përfshin tre faza të mëdha.
Gjetja e vulnerabiliteteve në biblioteka. Për shembull, instrumenti di se ne po përdorim një bibliotekë të caktuar, dhe se në ose në sistemet e raportimit të defekteve ka disa vulnerabilitete që lidhen me këtë version të bibliotekës. Kur përpiqemi ta përdorim, instrumenti do të japë një paralajmërim se biblioteka është vulnerabël dhe do të sugjerojë përdorimin e një versioni tjetër ku nuk ka vulnerabilitete.
Analiza e pastërtisë së licencave. Për ne kjo nuk është ende shumë e njohur, por nëse punoni me të huajt, atje herë pas here mund të merrni pasoja për përdorimin e një komponente me kod të hapur që nuk lejohet të përdoret ose modifikohet. Sipas politikës së bibliotekës licencuese, ne nuk mund ta bëjmë këtë. Ose, nëse e kemi modifikuar dhe po e përdorim, duhet të publikojmë kodin tonë. Sigurisht, askush nuk dëshiron të publikojë kodin e produkteve të tij, por ky problem gjithashtu mund të mbrohet.
Analiza e komponenteve qĂ« pĂ«rdoren nĂ« mjedisin industrial. Le tĂ« imagjinojmĂ« njĂ« situatĂ« hipotezike qĂ« ne pĂ«rfundimisht pĂ«rfunduam zhvillimin dhe nxorĂ«m nĂ« prodhim versionin mĂ« tĂ« fundit tĂ« mikroservisit tonĂ«. Ai jeton atje shkĂ«lqyeshĂ«m â pĂ«r njĂ« javĂ«, njĂ« muaj, njĂ« vit. Ne nuk e mbledhim, nuk bĂ«jmĂ« kontrolle tĂ« sigurisĂ«, gjithçka duket mirĂ«. Por papritmas dy javĂ« pas lĂ«shimit del njĂ« vulnerabilitet kritik nĂ« komponentin Open Source qĂ« ne pĂ«rdorim pikĂ«risht nĂ« kĂ«tĂ« ndĂ«rtim, nĂ« mjedisin e prodhimit. NĂ«se nuk e regjistron se çfarĂ« dhe ku e pĂ«rdorim, atĂ«herĂ« nuk do ta shohim kĂ«tĂ« vulnerabilitet. NĂ« disa instrumente ka mundĂ«sinĂ« pĂ«r monitorimin e vulnerabiliteteve nĂ« bibliotekat qĂ« aktualisht janĂ« nĂ« pĂ«rdorim nĂ« prodhimin. Kjo Ă«shtĂ« shumĂ« e dobishme.
Mundësitë:
- Politika të ndryshme për faza të ndryshme të zhvillimit.
- Monitorimi i komponenteve në mjedisin industrial.
- Kontrolli i bibliotekave brenda konturit të organizatës.
- Mbështetje për sisteme të ndryshme ndërtimi dhe gjuhë.
- Analiza e imazheve Docker.
Disa shembuj të liderëve në fushë që merren me analizën e Open Source.
I vetmi falas prej tyre është nga OWASP. Mund ta aktivizoni në fazat e para për të parë si funksionon dhe çfarë mbështet. Kryesisht janë të gjitha produktet e reja cloud, ose on-premise, por me bazën e tyre gjithsesi dërgohen në internet. Ato nuk dërgojnë bibliotekat tuaja, por heshët ose vlerat e tyre që llogarisin dhe fingerprintet në serverin e tyre për të marrë njoftime për praninë e dobësive.
Integrimi në proces
Kontrolli i bibliotekave në perimeter, që shkarkohen nga burime të jashtme. Ne kemi repo të jashtme dhe të brendshme. Për shembull, brenda Event Central ndodhet Nexus, dhe dëshirojmë që brenda repos tonë të mos ketë dobësi me status "kritik" ose "të lartë". Mund të konfigurojmë proksimin me anë të mjetit Nexus Firewall Lifecycle në mënyrë që dobësitë e tilla të ndalohen dhe të mos hyjnë në repo të brendshme.
Integrimi në CI. Në një nivel me autotestet, testet e njësisë dhe ndarjen sipas fazave të zhvillimit: dev, test, prod. Në çdo fazë mund të shkarkoni çdo bibliotekë, të përdorni çfarëdo, por nëse ndodhet diçka e ndjeshme me status "kritik" - ndoshta duhet të tërheqë vëmendjen e zhvilluesve në fazën e daljes në prodhim.
Integrimi me artefaktet: Nexus dhe JFrog.
Integrimi në ambientin e zhvillimit. Instrumentet që zgjidhni duhet të kenë integrim me ambientet e zhvillimit. Zhvilluesi duhet të ketë qasje nga vendi i tij të punës në rezultatet e skanimit, ose mundësinë për të skanuar dhe kontrolluar kodin për praninë e dobësive para se të bëjë commit në CVS.
Integrimi në CD. Kjo është një veçori e shkëlqyer, që më pëlqen shumë dhe për të cilën kam folur më parë - monitorimi i shfaqjes së dobësive të reja në ambientin industrial. Kjo funksionon dikur kështu.
Ne kemi Repo Publike tĂ« KomponentĂ«ve â disa disa mjete jashtĂ«, dhe depoja jonĂ« e brendshme. Ne duam qĂ« aty tĂ« jenĂ« vetĂ«m komponentĂ« tĂ« besueshĂ«m. Kur proxy-ojmĂ« njĂ« kĂ«rkesĂ«, kontrollojmĂ« qĂ« biblioteka e shkarkuar tĂ« mos ketĂ« cenueshmĂ«ri. NĂ«se ajo pĂ«rfshihet nĂ« disa politika tĂ« caktuara, tĂ« cilat ne i vendosim dhe i konfirmojmĂ« patjetĂ«r me zhvillimin, atĂ«herĂ« ne nuk e shkarkojmĂ« dhe vjen njĂ« refuzim pĂ«r pĂ«rdorimin e njĂ« versioni tjetĂ«r. PĂ«r rrjedhojĂ«, nĂ«se nĂ« bibliotekĂ« ka diçka tĂ« vĂ«rtetĂ« kritike dhe tĂ« keqe, zhvilluesi nuk do ta marrĂ« bibliotekĂ«n qĂ« nĂ« fazĂ«n e instalimit â le tĂ« pĂ«rdorĂ« versionin mĂ« lart ose mĂ« poshtĂ«.
- Gjatë ndërtimit, ne kontrollojmë që askush të mos ketë futur diçka të keqe, që të gjitha komponentët të jenë të sigurt dhe askush të mos ketë sjellë asgjë të rrezikshme në flash.
- Në depozitën tonë kemi vetëm komponentë të besueshëm.
- Gjatë deploy-it, ne kontrollojmë përsëri pikërisht paketën: war, jar, DL ose imazhin Docker për të parë nëse përputhet me politikën.
- Kur dalim në prodhim, ne monitorojmë atë që po ndodh në mjedisin industrial: shfaqen ose nuk shfaqen cenueshmëri kritike.
Analiza dinamike â DAST
Mjetet e analizës dinamike janë radikalisht të ndryshme nga gjithçka që u tha më parë. Ato janë një simulim i punës së përdoruesit me aplikacionin. Nëse ky është një aplikacion web, ne dërgojmë kërkesa, duke simuluar punën e klientit, klikojmë në butona në front, dërgojmë të dhëna artificiale nga forma: thonjëza, kurriza, simbole në kodime të ndryshme, për të parë se si aplikacioni punon dhe përpunon të dhëna të jashtme.
Ky sistem gjithashtu lejon tĂ« kontrollojmĂ« cenueshmĂ«rinĂ« pĂ«r shembuj nĂ« Open Source. Duke qenĂ« se DAST nuk e di se cilin Open Source po pĂ«rdorim, ai thjesht hedh pattern-e âtĂ« kĂ«qijaâ dhe analizon pĂ«rgjigjet e serverit:
â Ah, kĂ«tu ka njĂ« problem tĂ« deserializimit, ndĂ«rsa kĂ«tu nuk ka.
KĂ«tu ka rreziqe tĂ« mĂ«dha, sepse nĂ«se ju kryeni kĂ«tĂ« test sigurie nĂ« tĂ« njĂ«jtin stand me tĂ« cilin punojnĂ« testuesit â mund tĂ« ndodhin gjĂ«ra tĂ« pakĂ«ndshme.
- Ngarkesë e lartë në serverin e aplikacionit.
- Nuk ka integrime.
- Mundësia për të ndryshuar cilësimet e aplikacionit që po analizohet.
- Nuk ka mbështetje për teknologjitë e nevojshme.
- Vështirësi në konfigurim.
Kemi pasur një situatë kur përfundimisht lançuam AppScan: morëm me vështirësi qasjen në aplikacion, siguruam 3 llogari dhe u gëzuam - më në fund do të kontrollojmë gjithçka! Lançuam skanimin dhe gjëja e parë që bëri AppScan - hyri në panelin administrativ, provokoi të gjithë butonat, ndryshoi gjysmën e të dhënave dhe më pas e shkatërroi serverin me kërkesat. -kërkesat. Zhvilluesit me testim thanë:
â Djem, a po talleni?! Ju dhamĂ« llogaritĂ« dhe ju e shkatĂ«rruat serverin!
Konsideroni rreziqet e mundshme. Idealisht, përgatitni një stendë të veçantë për testimin e sigurisë, e cila do të jetë e izoluar nga ambienti tjetër disi, dhe është më mirë të kontrolloni panelin administrativ manualisht. Ky është një testim i penetrimit - ato përqindje të mbetura përpjekjesh që tani nuk po i shqyrtojmë.
Kjo mund të përdoret edhe si një analog i testimit të ngarkesës. Në fazën e parë, mund të aktivizoni skanerin dinamik me 10-15 rrjedha dhe të shihni çfarë ndodh, por zakonisht, siç tregon praktika, nuk del asgjë e mirë.
Disa burime që zakonisht përdorim.
Vlen tĂ« theksohet  â Ă«shtĂ« njĂ« "thikĂ« zvicerane" pĂ«r çdo specialist tĂ« sigurisĂ«. TĂ« gjithĂ« e pĂ«rdorin atĂ« dhe Ă«shtĂ« shumĂ« e lehtĂ« pĂ«r t'u pĂ«rdorur. SĂ« fundmi dolĂ«n njĂ« version i ri demo i edicionit enterprise. NĂ«se mĂ« parĂ« ishte thjesht njĂ« utilitar stand alone me plugins, tani pĂ«rfundimisht zhvilluesit po krijojnĂ« njĂ« server tĂ« madh, nga i cili mund tĂ« menaxhohen disa agjentĂ«. Kjo Ă«shtĂ« e shkĂ«lqyer, e rekomandoj tĂ« provoni.
Integrimi në proces
Integrimi ndodh mjaft mirë dhe lehtësisht: aktivizimi i skanimit pas instalimit të suksesshëm të aplikacionit në stendë dhe skanimi pas kryerjes me sukses të testimit integrues.
Nëse integrimet nuk funksionojnë ose ka bllokues dhe funksione të falsifikuara, kjo është e kotë dhe e pavlerë - çfarëdo që modeli të dërgojmë, serveri do të përgjigjet gjithmonë në të njëjtën mënyrë.
- Idealisht - një stendë e veçantë për testimin.
- Para fillimit të testimit, regjistroni sekuencën e hyrjes.
- Testimi i sistemit të administratës - vetëm manual.
Në ditën e fillimit të modulit, struktura e tij bëhet e disponueshme. Studimi në UoL përbëhet nga cikli në vijim:
Pak më në përgjithësi për procesin dhe për funksionimin e çdo mjeti, në veçanti. Të gjitha aplikacionet janë të ndryshme - njëra punon më mirë me analizën dinamike, tjetra me atë statike, një e tretë me analizën OpenSource, testet e penetrimit ose në fakt diçka tjetër, për shembull, ngjarjet .
Ădo proces ka nevojĂ« pĂ«r kontroll.
Për të kuptuar se si funksionon procesi dhe ku mund të përmirësohet, duhet të mblidhen metrika nga gjithçka që arrin të prekesh, duke përfshirë metrika prodhimi, metrika nga mjetet dhe nga sistemet e gjurmimit të defekteve.
Ădo tĂ« dhĂ«nĂ« Ă«shtĂ« e dobishme. Duhet tĂ« shikohet nga kĂ«nde tĂ« ndryshme se ku aplikohet mĂ« mirĂ« ky ose ai mjet, ku procesi konkretisht ka vĂ«shtirĂ«si. Ndoshta, vlen tĂ« shikohet koha e pĂ«rgjigjes nga zhvillimi, pĂ«r tĂ« kuptuar ku mund tĂ« pĂ«rmirĂ«sohet procesi bazuar nĂ« kohĂ«n. Sa mĂ« shumĂ« tĂ« dhĂ«na, aq mĂ« shumĂ« kĂ«nde mund tĂ« ndĂ«rtohen nga niveli mĂ« i lartĂ« deri te detajet e çdo procesi.
Duke qenĂ« se tĂ« gjithĂ« analizatorĂ«t statikĂ« dhe dinamikĂ« kanĂ« API tĂ« tyre, mĂ«nyra tĂ« ndryshme pĂ«r t'u aktivizuar, disa kanĂ« orare, disa nuk kanĂ« â ne po shkruajmĂ« njĂ« mjet Orkestratori i AppSec, qĂ« lejon tĂ« krijohet njĂ« pikĂ« e vetme hyrjeje nĂ« tĂ« gjithĂ« procesin nga produkti dhe ta menaxhosh atĂ« nga njĂ« pikĂ« e vetme.
MenaxherĂ«t, zhvilluesit dhe inxhinierĂ«t e sigurisĂ« kanĂ« njĂ« pikĂ« hyrjeje, nga e cila mund tĂ« shikojnĂ« se çfarĂ« Ă«shtĂ« aktivizuar, tĂ« konfigurojnĂ« dhe tĂ« aktivizojnĂ« skanimin, tĂ« marrin rezultatet e skanimit, tĂ« paraqesin kĂ«rkesat. Ne pĂ«rpiqemi tĂ« shmangim dokumentet, t'i pĂ«rkthejmĂ« gjithçka nĂ« njĂ« mĂ«nyrĂ« qĂ« Ă«shtĂ« e kuptueshme, e cila pĂ«rdoret nga zhvillimi â faqe nĂ« Confluence me status dhe metrika, defekte nĂ« Jira ose nĂ« sistemet e ndryshme tĂ« gjurmimit tĂ« defekteve, ose integrimi nĂ« njĂ« proces sinhron/asinkron nĂ« CI/CD.
Pikat Kryesore
Mjetet nuk janĂ« kryesore. SĂ« pari, mendoni pĂ«r procesin â pastaj implementoni mjetet. Mjetet janĂ« tĂ« mira, por tĂ« shtrenjta, prandaj mund tĂ« filloni me procesin dhe tĂ« rregulloni ndĂ«rveprimin dhe kuptimin midis zhvillimit dhe sigurisĂ«. Nga kĂ«ndvĂ«shtrimi i sigurisĂ« â nuk duhet tĂ« "ndaloni" gjithçka pa dallim, nga kĂ«ndvĂ«shtrimi i zhvillimit â nĂ«se ka diçka tĂ« rĂ«ndĂ«sishme, atĂ«herĂ« duhet tĂ« eleminohet, jo tĂ« mbyllen sytĂ« ndaj problemit.
CilĂ«sia e produktit â objektivi i pĂ«rbashkĂ«t si pĂ«r sigurinĂ«, ashtu dhe pĂ«r zhvillimin. Ne bĂ«jmĂ« njĂ« punĂ« tĂ« vetme, pĂ«rpiqemi qĂ« gjithçka tĂ« funksionojĂ« siç duhet dhe tĂ« mos ketĂ« rreziqe pĂ«r reputacionin dhe humbje financiare. PikĂ«risht pĂ«r kĂ«tĂ« arsye ne pĂ«rhapim qasjen ndaj DevSecOps, SecDevOps, pĂ«r tĂ« bĂ«rĂ« lidhjen dhe pĂ«r tĂ« pĂ«rmirĂ«suar cilĂ«sinĂ« e produktit.
Filloni me atĂ« qĂ« tashmĂ« ekziston: kĂ«rkesat, arkitektura, kontrolli i pjesshĂ«m, trajnimet, udhĂ«zimet. Nuk Ă«shtĂ« e nevojshme tĂ« aplikoni tĂ« gjitha praktikat menjĂ«herĂ« nĂ« tĂ« gjitha projektet â shkoni iterativisht. Nuk ka njĂ« standard tĂ« vetĂ«m â eksperimentoni dhe provoni qasje dhe zgjidhje tĂ« ndryshme.
Midis defekteve të sigurisë dhe defekteve funksionale, shenja është baraz.
Automatizoni gjithçka, qĂ« lĂ«viz. Ădo gjĂ« qĂ« nuk lĂ«viz â e bĂ«ni tĂ« lĂ«vizĂ« dhe automatizoni. NĂ«se diçka bĂ«het me dorĂ«, ajo nuk Ă«shtĂ« njĂ« pjesĂ« e mirĂ« e procesit. Ndoshta merret parasysh pĂ«r ta rishikuar dhe automatizuar gjithashtu.
NĂ«se ekipi i sigurisĂ« Ă«shtĂ« i vogĂ«l â pĂ«rdorni Security Champions.
Ndoshta ajo qĂ« kam treguar nuk do t'ju pĂ«rshtatet dhe do tĂ« inventoni diçka tuajĂ«n â dhe kjo Ă«shtĂ« mirĂ«. Por zgjidhni mjetet, duke u bazuar nĂ« kĂ«rkesat specifike tĂ« procesit tuaj. Mos shikoni se çfarĂ« thotĂ« komuniteti, se ky mjet Ă«shtĂ« i keq dhe ky tjetĂ«r i mirĂ«. Ndoshta, nĂ« produktin tuaj do tĂ« jetĂ« krejt ndryshe.
Kërkesat për mjetet.
- Nivel i ulët False Positive.
- Koha e arsyeshme e analizës.
- Lehtësia e përdorimit.
- Prania e integrimeve.
- Kuptimi i Roadmap-it të zhvillimit të produktit.
- Mundësia për personalizimin e mjeteve.
Referati i Yuri u zgjodh si njĂ« nga mĂ« tĂ« mirat nĂ« DevOpsConf 2018. PĂ«r tâu njohur me njĂ« numĂ«r tĂ« madh ideve interesante dhe rasteve praktike, vini mĂ« 27 dhe 28 maj nĂ« Skolkovo nĂ«Â kuadĂ«r . Dhe mĂ« mirĂ«, nĂ«se jeni tĂ« gatshĂ«m tĂ« ndani pĂ«rvojĂ«n tuaj, atĂ«herĂ« pĂ«r referatin deri mĂ« 21 prill.
Burimi: habr.com
