{"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\/sq\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Frika dhe urrejtja DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ne kemi pasur 2 analiza t\u00eb kodit, 4 mjete p\u00ebr testimin dinamik, krijimet tona dhe 250 skenar\u00eb. Jo se gjith\u00e7ka k\u00ebto ishin t\u00eb nevojshme n\u00eb procesin aktual, por q\u00ebkur fillova t\u00eb implementoj DevSecOps, duhet ta \u00e7oj deri n\u00eb fund.<\/p>\n

\"Frika
\n
\nBurimi<\/a><\/noindex>. Autor\u00ebt e karaktereve: Justin Roiland dhe Dan Harmon.<\/i><\/p>\n

\u00c7far\u00eb \u00ebsht\u00eb SecDevOps? Dhe DevSecOps? \u00c7far\u00eb ka ndryshime? Siguria e Aplikacioneve \u2013 p\u00ebr \u00e7far\u00eb \u00ebsht\u00eb kjo? Pse qasja klasike nuk funksionon m\u00eb? T\u00eb gjitha k\u00ebto pyetje kan\u00eb p\u00ebrgjigje. Yuri Shabalin<\/b> nga\u00a0Swordfish Security. <\/b>Yuri do t\u00eb p\u00ebrgjigjet p\u00ebr gjith\u00e7ka dhe do t\u00eb shqyrtoj\u00eb problemet e kalimit nga modeli klasik i Siguris\u00eb s\u00eb Aplikacioneve n\u00eb procesin DevSecOps: si t\u00eb qasemi n\u00eb m\u00ebnyr\u00eb t\u00eb duhur p\u00ebr integrimin e procesit t\u00eb zhvillimit t\u00eb sigurt n\u00eb procesin DevOps dhe t\u00eb mos d\u00ebmtojm\u00eb asgj\u00eb n\u00eb k\u00ebt\u00eb, si t\u00eb kalojm\u00eb n\u00ebp\u00ebr hapat kryesor\u00eb t\u00eb testimit t\u00eb siguris\u00eb, cilat mjete mund t\u00eb aplikohen, \u00e7far\u00eb e ndan ato dhe si t'i konfigurojm\u00eb sakt\u00eb p\u00ebr t\u00eb shmangur pengesat.
\n<\/a><\/noindex>
\n

\r\n \"Luaj\r\n
<\/div>\r\n <\/div><\/center>
\nP\u00ebr fol\u00ebsin:<\/b> Yuri Shabalin \u2013 <\/b>Arkitekt i Siguris\u00eb Kryesore n\u00eb kompanin\u00eb Swordfish Security<\/b>. Ai \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr implementimin e SSDL, p\u00ebr integrimin e p\u00ebrgjithsh\u00ebm t\u00eb mjeteve t\u00eb analiz\u00ebs s\u00eb aplikacioneve n\u00eb nj\u00eb ekosistem t\u00eb vet\u00ebm t\u00eb zhvillimit dhe testimit. 7 vjet p\u00ebrvoj\u00eb n\u00eb sigurin\u00eb informacionit. Ka punuar n\u00eb Alfa-Bank, Sberbank dhe n\u00eb Positive Technologies, e cila zhvillon softuer dhe ofron sh\u00ebrbime. Fol\u00ebs n\u00eb konferenca nd\u00ebrkomb\u00ebtare si ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Siguria e Aplikacioneve: p\u00ebr \u00e7far\u00eb \u00ebsht\u00eb kjo?<\/h2>\n

\nSiguria e Aplikacioneve<\/b>\u00a0\u00ebsht\u00eb nj\u00eb deg\u00eb e siguris\u00eb q\u00eb \u00ebsht\u00eb p\u00ebrgjegj\u00ebse p\u00ebr sigurin\u00eb e aplikacioneve. Kjo nuk i p\u00ebrket infrastruktur\u00ebs ose siguris\u00eb rrjet\u00ebve, por sakt\u00ebsisht asaj q\u00eb ne shkruajm\u00eb dhe mbi t\u00eb cilat punojn\u00eb zhvilluesit \u2013 jan\u00eb defektet dhe dob\u00ebsit\u00eb e vet\u00eb aplikacionit.<\/p>\n

Direktiva SDL ose SDLC<\/a><\/noindex>\u00a0\u2014 Cikli zhvillim t\u00eb siguris\u00eb<\/b>\u00a0u zhvillua nga kompania Microsoft. N\u00eb diagram, \u00ebsht\u00eb modeli kanonik i SDLC, ku q\u00ebllimi kryesor \u00ebsht\u00eb p\u00ebrfshirja e siguris\u00eb n\u00eb \u00e7do faz\u00eb t\u00eb zhvillimit, nga k\u00ebrkesat deri n\u00eb l\u00ebshim dhe daljen n\u00eb prodhim. N\u00eb Microsoft e kuptuan se n\u00eb prodhim ka shum\u00eb gabime, ato po rriten dhe duhet b\u00ebr\u00eb di\u00e7ka p\u00ebr k\u00ebt\u00eb, dhe propozuan k\u00ebt\u00eb qasje q\u00eb u b\u00eb kanonike.<\/p>\n

\"Frika
\n
\nSiguria e Aplikacioneve dhe SSDL nuk jan\u00eb t\u00eb orientuara ndaj zbardhjes s\u00eb dob\u00ebsive, si\u00e7 mendohet zakonisht, por ndaj parandalimit t\u00eb shfaqjes s\u00eb tyre. Me kalimin e koh\u00ebs, qasja kanonike nga Microsoft u p\u00ebrmir\u00ebsua, u zhvillua, duke ofruar nj\u00eb p\u00ebrfshirje m\u00eb t\u00eb thell\u00eb dhe m\u00eb t\u00eb detajuar.<\/p>\n

\"Frika
\n
\nSDLC kanonik \u00ebsht\u00eb shum\u00eb i detajuar n\u00eb metodologjit\u00eb e ndryshme \u2014 OpenSAMM, BSIMM, OWASP. Metodologjit\u00eb ndryshojn\u00eb, por, n\u00eb p\u00ebrgjith\u00ebsi, jan\u00eb t\u00eb ngjashme.<\/p>\n

Modeli i Pjekuris\u00eb p\u00ebr Nd\u00ebrtimin e Siguris\u00eb<\/h3>\n

\nM\u00eb p\u00eblqen m\u00eb shum\u00eb BSIMM<\/b>\u00a0\u2014 Modeli i Pjekuris\u00eb p\u00ebr Nd\u00ebrtimin e Siguris\u00eb<\/a><\/noindex>. Baza e metodologjis\u00eb \u00ebsht\u00eb ndarja e procesit t\u00eb Siguris\u00eb s\u00eb Aplikacioneve n\u00eb 4 fusha: Qeverisje, Inteligjenc\u00eb, Pik\u00ebprekje SSDL dhe Zbatim. N\u00eb \u00e7do fush\u00eb ka 12 praktika, t\u00eb cilat paraqiten si 112 aktivitete.<\/p>\n

\"Frika
\n
\n\u00c7do aktivitet nga 112 ka 3 nivele pjekurie<\/b>: fillestar, mesatar dhe avancuar. T\u00eb gjitha 12 praktikat mund t\u00eb studiohen sipas kapitujve, t\u00eb zgjidhen element\u00ebt e r\u00ebnd\u00ebsish\u00ebm p\u00ebr ju, t\u00eb kuptoni se si t'i implementoni dhe gradualisht t\u00eb shtoni elemente, p\u00ebr shembull, analiz\u00ebn statike dhe dinamike t\u00eb kodit ose rishikimin e kodit. Shkruani nj\u00eb plan dhe sipas tij punoni pa nj\u00eb problem n\u00eb implementimin e aktiviteteve t\u00eb zgjedhura.<\/p>\n

Pse DevSecOps<\/h2>\n

<\/p>\n

DevOps \u00ebsht\u00eb nj\u00eb proces i madh t\u00ebr\u00ebsor, n\u00eb t\u00eb cilin duhet t\u00eb kujdesesh p\u00ebr sigurin\u00eb.<\/p><\/blockquote>\n

\nFillimisht DevOps<\/b><\/a><\/noindex> mbante parasysh kontrollet p\u00ebr sigurin\u00eb. N\u00eb praktik\u00eb, numri i ekipeve t\u00eb siguris\u00eb ishte shum\u00eb m\u00eb i vog\u00ebl se tani, dhe ata vepronin jo si pjes\u00ebmarr\u00ebs n\u00eb proces, por si nj\u00eb organ kontrollues dhe mbik\u00ebqyr\u00ebs q\u00eb vendos k\u00ebrkesa dhe kontrollon cil\u00ebsin\u00eb e produktit n\u00eb fund t\u00eb l\u00ebshimit. Ky \u00ebsht\u00eb nj\u00eb qasje klasike, n\u00eb t\u00eb cil\u00ebn ekipet e siguris\u00eb ndodheshin p\u00ebrtej zhvillimit dhe nuk merrnin pjes\u00eb n\u00eb proces.<\/p>\n

\"Frika
\n
\nProblemi kryesor \u00ebsht\u00eb se siguria e informacionit \u00ebsht\u00eb e ndar\u00eb nga zhvillimi. Zakonisht, kjo \u00ebsht\u00eb nj\u00eb struktur\u00eb e siguris\u00eb e informacionit dhe p\u00ebrmban 2-3 mjete t\u00eb m\u00ebdha dhe t\u00eb shtrenjta. \u00c7do gjasht\u00eb muaj vjen nj\u00eb kod burimi ose aplikacion q\u00eb duhet kontrolluar, nd\u00ebrsa \u00e7do vit b\u00ebhen testet e penetrimit<\/a><\/noindex>. Kjo \u00e7on n\u00eb vonesa n\u00eb l\u00ebshimin n\u00eb treg, dhe zhvilluesit p\u00ebrballen me nj\u00eb mori t\u00eb madhe t\u00eb dob\u00ebsive nga mjetet automatizuese. Gjith\u00e7ka \u00ebsht\u00eb e pamundur p\u00ebr t'u lexuar dhe rregulluar, sepse pasi gjasht\u00eb muaj t\u00eb kaluar, rezultatet nuk jan\u00eb analizuar, nd\u00ebrsa tani ka nj\u00eb grup t\u00eb ri.<\/p>\n

Gjat\u00eb pun\u00ebs s\u00eb kompanis\u00eb son\u00eb, shohim se siguria n\u00eb t\u00eb gjitha fushat dhe industrive kupton se \u00ebsht\u00eb koha t\u00eb p\u00ebrmir\u00ebsohet dhe t\u00eb punoj\u00eb bashk\u00eb me zhvillimin n\u00eb nj\u00eb rrot\u00eb \u2014 n\u00eb\u00a0Agile<\/b><\/a><\/noindex>. Paradigma DevSecOps p\u00ebrshtatet mrekullisht me metodologjin\u00eb e zhvillimit t\u00eb shkath\u00ebt, me implementimin, mb\u00ebshtetje dhe pjes\u00ebmarrje n\u00eb \u00e7do l\u00ebshim dhe iteracion.<\/p>\n

\"Frika
\n<\/p>\n

Kalimi n\u00eb DevSecOps<\/h2>\n

\nFjala m\u00eb e r\u00ebnd\u00ebsishme n\u00eb Jet\u00ebn e Zhvillimit t\u00eb Siguris\u00eb \u00ebsht\u00eb \"procesi\"<\/b>Duhet ta kuptoni k\u00ebt\u00eb para se t\u00eb mendoni p\u00ebr blerjen e mjeteve.<\/p>\n

Thjesht t\u00eb p\u00ebrfshish mjetet n\u00eb procesin DevOps nuk \u00ebsht\u00eb e mjaftueshme - \u00ebsht\u00eb e r\u00ebnd\u00ebsishme nd\u00ebrveprimi dhe kuptimi midis pjes\u00ebmarr\u00ebsve n\u00eb proces.<\/p><\/blockquote>\n

<\/p>\n

Njer\u00ebzit jan\u00eb m\u00eb t\u00eb r\u00ebnd\u00ebsish\u00ebm se mjetet<\/h3>\n

\nShpesh planifikimi i procesit t\u00eb zhvillimit t\u00eb sigurt fillon me zgjedhjen dhe blerjen e nj\u00eb mjeti, dhe p\u00ebrfundon me p\u00ebrpjekjet p\u00ebr t\u00eb integruar mjetin n\u00eb procesin ekzistues, i cili mbetet thjesht p\u00ebrpjekje. Kjo \u00e7on n\u00eb pasoja t\u00eb trishtueshme, sepse \u00e7do mjet ka karakteristikat dhe kufizimet e veta.<\/p>\n

Nj\u00eb rast i zakonsh\u00ebm \u00ebsht\u00eb kur departamenti i siguris\u00eb zgjodhi nj\u00eb mjet t\u00eb mir\u00eb, t\u00eb shtrenjt\u00eb, me mund\u00ebsi t\u00eb gjera, dhe shkonte te zhvilluesit - p\u00ebr ta integruar n\u00eb proces. Por nuk funksionon - procesi \u00ebsht\u00eb nd\u00ebrtuar n\u00eb nj\u00eb m\u00ebnyr\u00eb q\u00eb kufizimet e mjetit t\u00eb bler\u00eb nuk p\u00ebrputhen me paradigm\u00ebn aktuale.<\/p>\n

S\u00eb pari, p\u00ebrshkruani se cili \u00ebsht\u00eb rezultati q\u00eb d\u00ebshironi dhe si do t\u00eb duket procesi. Kjo do t\u00eb ndihmoj\u00eb n\u00eb kuptimin e rolit t\u00eb mjeteve dhe siguris\u00eb n\u00eb proces.<\/p><\/blockquote>\n

<\/p>\n

Filloni me at\u00eb q\u00eb tashm\u00eb p\u00ebrdoret<\/h3>\n

\nPara se t\u00eb blini mjete t\u00eb shtrenjta, shikoni n\u00eb at\u00eb q\u00eb tashm\u00eb keni. \u00c7do kompani ka k\u00ebrkesa p\u00ebr siguri q\u00eb i paraqiten zhvillimit, ka kontrolle, teste penetruese - pse t\u00eb mos i transformoni k\u00ebto n\u00eb nj\u00eb format t\u00eb qart\u00eb dhe t\u00eb p\u00ebrshtatsh\u00ebm p\u00ebr t\u00eb gjith\u00eb?<\/p>\n

Zakonisht k\u00ebrkesat jan\u00eb nj\u00eb dokument i shkruar q\u00eb peshon p\u00ebr nj\u00eb gozhd\u00eb. Ka pasur raste kur shkojm\u00eb n\u00eb nj\u00eb kompani p\u00ebr t\u00eb par\u00eb proceset dhe k\u00ebrkojm\u00eb t\u00eb shohim k\u00ebrkesat p\u00ebr siguri p\u00ebr softuerin. Specialistja q\u00eb merrej me k\u00ebt\u00eb k\u00ebrkoi p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb:<\/p>\n

\u2014 Tani, ndoshta n\u00eb sh\u00ebnime kishte nj\u00eb rrug\u00eb se ku ndodhej ky dokument.<\/i><\/p>\n

Si rezultat, mor\u00ebm dokumentin pas nj\u00eb jave.<\/p>\n

P\u00ebr k\u00ebrkesat, kontrollet dhe gj\u00ebra t\u00eb tjera, krijoni nj\u00eb faqe, p\u00ebr shembull, n\u00eb\u00a0Confluence<\/b>\u00a0\u2014 \u00ebsht\u00eb e p\u00ebrshtatshme p\u00ebr t\u00eb gjith\u00eb.<\/p>\n

M\u00eb leht\u00eb \u00ebsht\u00eb t\u00eb riparformatizoni at\u00eb q\u00eb tashm\u00eb ekziston dhe ta p\u00ebrdorni si pik\u00ebnisje.<\/p><\/blockquote>\n

<\/p>\n

P\u00ebrdorni Security Champions <\/h3>\n

\nZakonisht, n\u00eb nj\u00eb kompani mesatare me 100-200 zhvillues ka nj\u00eb ekspert sigurie, i cili kryen disa funksione dhe fizikisht nuk arrin t\u00eb kontrolloj\u00eb gjith\u00e7ka. Edhe n\u00ebse ai p\u00ebrpiqet me t\u00eb gjitha forcat - vet\u00ebm nuk do t\u00eb kontrolloj\u00eb t\u00eb gjith\u00eb kodin q\u00eb gjeneron zhvillimi. P\u00ebr k\u00ebto raste \u00ebsht\u00eb zhvilluar koncepti - Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions \u00ebsht\u00eb nj\u00eb person n\u00eb brend\u00ebsi t\u00eb ekipit t\u00eb zhvillimit i interesuar p\u00ebr sigurin\u00eb e produktit tuaj.<\/p><\/blockquote>\n

\"Frika
\n
\nSecurity Champion \u00ebsht\u00eb pika e hyrjes n\u00eb ekipin e zhvillimit dhe evangjelisti i siguris\u00eb n\u00eb nj\u00eb person.<\/p>\n

Zakonisht, kur nj\u00eb specialist i siguris\u00eb hyn n\u00eb ekipin e zhvillimit dhe tregohet p\u00ebr nj\u00eb gabim n\u00eb kod, p\u00ebrgjigjja \u00ebsht\u00eb:<\/p>\n

\u2014 Q\u00eb kush je ti? T\u00eb shoh p\u00ebr her\u00eb t\u00eb par\u00eb. Kam gjith\u00e7ka n\u00eb rregull \u2014 m\u00eb rishikoi dikush m\u00eb i madh dhe m\u00eb tha \u201capliko\u201d, ne vazhdojm\u00eb p\u00ebrpara!<\/i><\/p>\n

Kjo \u00ebsht\u00eb nj\u00eb situat\u00eb tipike, sepse ka shum\u00eb m\u00eb tep\u00ebr besim tek t\u00eb moshuarit ose thjesht tek shok\u00ebt e ekipit, me t\u00eb cil\u00ebt zhvilluesi bashk\u00ebvepron vazhdimisht n\u00eb pun\u00eb dhe gjat\u00eb rishikimit t\u00eb kodit. N\u00ebse vendin e specialistit t\u00eb siguris\u00eb e z\u00eb nj\u00eb Security Champion q\u00eb tregon p\u00ebr gabimin dhe pasojat, fjala e tij do t\u00eb ket\u00eb m\u00eb shum\u00eb pesh\u00eb.<\/p>\n

Po ashtu, zhvilluesit e njohin kodin e tyre m\u00eb mir\u00eb se \u00e7do specialist sigurie. P\u00ebr nj\u00eb person q\u00eb ka t\u00eb pakt\u00ebn 5 projekte n\u00eb mjetin e analiz\u00ebs statike, zakonisht \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb mbash mend t\u00eb gjitha nuancat. Security Champions e njohin produktin e tyre: se \u00e7far\u00eb nd\u00ebrvepron me \u00e7far\u00eb dhe n\u00eb \u00e7far\u00eb duhet t\u00eb shikohet m\u00eb shum\u00eb \u2014 ata jan\u00eb m\u00eb efikas.<\/p>\n

Pra, mendoni p\u00ebr implementimin e Security Champions dhe zgjerimin e ndikimit t\u00eb ekipit t\u00eb siguris\u00eb. P\u00ebr vet\u00eb kampionin, kjo \u00ebsht\u00eb gjithashtu e dobishme: zhvillim profesional n\u00eb nj\u00eb fush\u00eb t\u00eb re, zgjerim t\u00eb njohurive teknike, p\u00ebrmir\u00ebsim t\u00eb aft\u00ebsive teknike, menaxheriale dhe udh\u00ebheq\u00ebse, rritje t\u00eb vler\u00ebs n\u00eb treg. Ky \u00ebsht\u00eb nj\u00eb element i caktuar i inxhinieris\u00eb sociale, \u201csyt\u00eb\u201d tuaj n\u00eb ekipin e zhvillimit.<\/p>\n

Hapat e testimit<\/h2>\n

\nParadigma 20 mbi 80<\/a><\/noindex>\u00a0tregon se 20% e p\u00ebrpjekjeve japin 80% t\u00eb rezultateve. K\u00ebto 20% jan\u00eb praktikat e analiz\u00ebs s\u00eb aplikacioneve, t\u00eb cilat mund dhe duhet t\u00eb automatizohen. Shembuj t\u00eb aktiviteteve t\u00eb tilla jan\u00eb analiza statike \u2014 SAST<\/b>, analiza dinamike \u2014 DAST,<\/b> dhe\u00a0kontrolli i Open Source<\/b>. Do t\u00eb flas m\u00eb shum\u00eb rreth aktiviteteve, si dhe p\u00ebr mjetet, me cil\u00ebsit\u00eb e cilat zakonisht p\u00ebrballemi gjat\u00eb implementimit t\u00eb tyre n\u00eb proces, dhe si ta b\u00ebjm\u00eb si\u00e7 duhet.<\/p>\n

\"Frika
\n<\/p>\n

Problemet kryesore t\u00eb mjeteve<\/h3>\n

\nDo t\u00eb ve\u00e7oj problemet q\u00eb jan\u00eb aktuale p\u00ebr t\u00eb gjitha mjete, t\u00eb cilat k\u00ebrkojn\u00eb v\u00ebmendje. Do t'i shqyrtoj ato n\u00eb detaje p\u00ebr t\u00eb mos u p\u00ebrs\u00ebritur m\u00eb tej.<\/p>\n

Koha e gjat\u00eb e analiz\u00ebs. <\/b>N\u00ebse nga komitimi deri n\u00eb daljen n\u00eb prodhim kalojn\u00eb 30 minuta p\u00ebr t\u00eb gjitha testet dhe nd\u00ebrtimin, kontrollet p\u00ebr sigurin\u00eb informacionit do t\u00eb k\u00ebrkojn\u00eb nj\u00eb dit\u00eb. Askush nuk do t\u00eb ngadal\u00ebsoj\u00eb procesin. Merrni parasysh k\u00ebt\u00eb ve\u00e7ori dhe b\u00ebni p\u00ebrfundime.<\/p>\n

Niveli i lart\u00eb i False Negative ose False Positive. <\/b>Produkte t\u00eb ndryshme p\u00ebrdorin framework t\u00eb ndryshme dhe stilin e vet t\u00eb kodimit. N\u00eb baza t\u00eb ndryshme kode dhe teknologjish, mjetet mund t\u00eb tregojn\u00eb nivele t\u00eb ndryshme t\u00eb False Negative dhe False Positive. Prandaj shikoni se \u00e7far\u00eb sakt\u00ebsisht n\u00eb\u00a0kompanin\u00eb tuaj dhe p\u00ebr<\/b> aplikacionet tuaja do t\u00eb tregoj\u00eb rezultat t\u00eb mir\u00eb dhe t\u00eb besuesh\u00ebm. Nuk ka integrime me mjete ekzistuese.<\/b> Shikoni mjete nga k\u00ebndv\u00ebshtrimi i integrimeve, me ato q\u00eb tashm\u00eb p\u00ebrdorni. P\u00ebr shembull, n\u00ebse keni Jenkins ose TeamCity, kontrolloni integrimin e mjeteve pik\u00ebrisht me k\u00ebt\u00eb softuer, jo me GitLab CI, q\u00eb nuk e p\u00ebrdorni.<\/p>\n

Mungesa ose kompleksiteti i tepruar i personalizimit.<\/b>N\u00ebse mjeti nuk ka API, p\u00ebrse do t\u00eb ishte i nevojsh\u00ebm? \u00c7do gj\u00eb q\u00eb mund t\u00eb b\u00ebhet n\u00eb nd\u00ebrfaqe duhet t\u00eb jet\u00eb e aksesueshme p\u00ebrmes API. N\u00eb ideal, mjeti duhet t\u00eb ket\u00eb mund\u00ebsin\u00eb e personalizimit t\u00eb kontrolleve.<\/p>\n

Nuk ka roadmap p\u00ebr zhvillimin e produktit. <\/b>Zhvillimi nuk q\u00ebndron n\u00eb vend, ne gjithmon\u00eb p\u00ebrdorim framework dhe funksione t\u00eb reja, duke e shkruar s\u00ebrish kodin e vjet\u00ebr n\u00eb gjuh\u00eb t\u00eb reja. Duam t\u00eb jemi t\u00eb sigurt se mjeti q\u00eb do t\u00eb blejm\u00eb do t\u00eb mb\u00ebshtes\u00eb framework dhe teknologji t\u00eb reja. Prandaj \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb dim\u00eb se produkti ka nj\u00eb<\/p>\n

zhvillimi t\u00eb v\u00ebrtet\u00eb dhe t\u00eb duhur. <\/b>Ve\u00e7orit\u00eb e procesit Plani i Veprimit<\/a><\/noindex> P\u00ebrve\u00e7 ve\u00e7orive t\u00eb mjeteve, merrni parasysh edhe ve\u00e7orit\u00eb e procesit t\u00eb zhvillimit. P\u00ebr shembull, t\u00eb pengosh zhvillimin \u00ebsht\u00eb nj\u00eb gabim tipik. Le t\u00eb shohim cilat ve\u00e7ori t\u00eb tjera duhet t\u00eb merren parasysh dhe n\u00eb \u00e7far\u00eb duhet t\u00eb p\u00ebrqendrohet ekipi i siguris\u00eb.<\/p>\n

P\u00ebr t\u00eb mos prishur afatet e zhvillimit dhe publikimit, krijoni<\/h3>\n

\nrregulla t\u00eb ndryshme<\/p>\n

dhe show stoppers<\/b> \u2014 kriteret e ndalimit t\u00eb procesit t\u00eb nd\u00ebrtimit n\u00eb rast se ka dob\u00ebsi \u2014 p\u00ebr ambientet e ndryshme.\u00a0<\/b>P\u00ebr shembull, ne kuptojm\u00eb se dega aktuale po shkon n\u00eb sken\u00ebn e zhvillimit ose UAT, prandaj nuk ndalojm\u00eb dhe nuk themi: \u2014 K\u00ebtu keni dob\u00ebsi, nuk do t\u00eb shkoni tutje!<\/b>N\u00eb k\u00ebt\u00eb faz\u00eb, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t'u themi zhvilluesve se ka probleme sigurie q\u00eb meritojn\u00eb v\u00ebmendje.<\/p>\n

\u2014 K\u00ebtu keni do t\u00eb meta, nuk do t\u00eb shkoni m\u00eb tej!<\/i><\/p>\n

N\u00eb k\u00ebt\u00eb faz\u00eb \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb thuhet developer\u00ebve se ka probleme sigurie, p\u00ebr t\u00eb cilat duhet t\u00eb kushtojn\u00eb v\u00ebmendje.<\/p>\n

Prania e dob\u00ebsis\u00eb nuk \u00ebsht\u00eb nj\u00eb penges\u00eb p\u00ebr testim t\u00eb m\u00ebtejsh\u00ebm<\/b>: manual, integrues ose manual. Nga ana tjet\u00ebr, na nevojitet ndonj\u00eb m\u00ebnyr\u00eb p\u00ebr t\u00eb rritur sigurin\u00eb e produktit, dhe q\u00eb zhvilluesit t\u00eb mos injorojn\u00eb at\u00eb q\u00eb gjen siguria. Prandaj, her\u00eb pas here b\u00ebjm\u00eb k\u00ebshtu: n\u00eb nj\u00eb stend\u00eb, kur zbulohet n\u00eb ambientin e zhvillimit, thjesht informojm\u00eb zhvillimin:<\/p>\n

\u2014 Djem, keni probleme, ju lutem, kushtoni v\u00ebmendje atyre.<\/i><\/p>\n

N\u00eb faz\u00ebn UAT p\u00ebrs\u00ebri tregojm\u00eb paralajm\u00ebrime p\u00ebr dob\u00ebsit\u00eb dhe n\u00eb faz\u00ebn e l\u00ebshimit n\u00eb prodhim themi:<\/p>\n

\u2014 Djem, ne ju kemi paralajm\u00ebruar disa her\u00eb, nuk keni b\u00ebr\u00eb asgj\u00eb \u2014 me k\u00ebt\u00eb nuk do t'ju lejojm\u00eb t\u00eb l\u00ebshoni.<\/i><\/p>\n

N\u00ebse flasim p\u00ebr kodin dhe dinamik\u00ebn, \u00ebsht\u00eb e nevojshme t\u00eb tregojm\u00eb dhe paralajm\u00ebrojm\u00eb p\u00ebr dob\u00ebsit\u00eb e vet\u00ebm atyre karakteristikave dhe kodit q\u00eb jan\u00eb shkruar rishtazi n\u00eb k\u00ebt\u00eb karakteristik\u00eb. N\u00ebse nj\u00eb zhvillues ka l\u00ebvizur nj\u00eb buton p\u00ebr 3 piksel dhe i themi se ka nj\u00eb SQL injeksion dhe prandaj duhet t\u00eb rregullohet urgent \u2014 kjo \u00ebsht\u00eb e gabuar. Shikoni vet\u00ebm at\u00eb q\u00eb \u00ebsht\u00eb shkruar tani dhe at\u00eb ndryshim q\u00eb po vjen n\u00eb aplikacion.<\/p>\n

P\u00ebr shembull, kemi nj\u00eb defekt funksional \u2014 ashtu si aplikacioni nuk duhet t\u00eb funksionoj\u00eb: parat\u00eb nuk transferohen, kur klikoni n\u00eb buton nuk ka kalim n\u00eb faqen tjet\u00ebr ose nuk ngarkohet produkti. Defektet e siguris\u00eb<\/b>\u00a0\u2014 jan\u00eb nj\u00ebsoj si defektet, por jo n\u00eb prizmin e funksionimit t\u00eb aplikacionit, por t\u00eb siguris\u00eb. <\/p>\n

Jo t\u00eb gjitha problemet e cil\u00ebsis\u00eb s\u00eb softuerit jan\u00eb probleme sigurie. Por t\u00eb gjitha problemet e siguris\u00eb lidhen me cil\u00ebsin\u00eb e softuerit. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nMeqen\u00ebse t\u00eb gjitha dob\u00ebsit\u00eb jan\u00eb nj\u00ebsoj si defektet, ato duhet t\u00eb jen\u00eb n\u00eb t\u00eb nj\u00ebjtin vend si t\u00eb gjitha defektet e zhvillimit. Prandaj, harrojeni raportet dhe PDF-t\u00eb e frikshme q\u00eb askush nuk i lexon.<\/p>\n

\"Frika
\n
\nKur punoja n\u00eb nj\u00eb kompani q\u00eb merrej me zhvillimin, m\u00eb erdhi nj\u00eb raport nga mjetet e analiz\u00ebs statike. E hapa at\u00eb, u tmerrua, b\u00ebra kafe, e shfletoja 350 faqe, e lidha dhe shkova t\u00eb punoja m\u00eb tej. Raportet e m\u00ebdha jan\u00eb raportet e vdekur<\/b>. Zakonisht ato nuk shkojn\u00eb askund, e-mailet fshihen, harrohen, humbasin ose biznesi thot\u00eb se pranon rreziqet.<\/p>\n

\u00c7far\u00eb duhet t\u00eb b\u00ebjm\u00eb? Defektet e konfirmuara q\u00eb kemi gjetur, thjesht i shnd\u00ebrrojm\u00eb n\u00eb nj\u00eb format t\u00eb p\u00ebrshtatsh\u00ebm p\u00ebr zhvillim, p\u00ebr shembull, i vendosim n\u00eb backlog n\u00eb Jira. Ne i prioritojm\u00eb defektet dhe i eliminojm\u00eb sipas rendit t\u00eb prioriteteve, nj\u00ebsoj si defektet funksionale dhe defektet e testeve.<\/p>\n

Analiza Statike - SAST<\/h2>\n

\nKy \u00ebsht\u00eb nj\u00eb analiz\u00eb e kodit p\u00ebr prani t\u00eb dob\u00ebsive.<\/b>, por kjo nuk \u00ebsht\u00eb e njejt\u00eb si SonarQube. Ne kontrollojm\u00eb jo vet\u00ebm p\u00ebr modele apo stil. Gjat\u00eb analiz\u00ebs p\u00ebrdoren nj\u00eb s\u00ebr\u00eb qasje p\u00ebr: pem\u00ebn e dob\u00ebsive, p\u00ebr\u00a0DataFlow<\/a><\/noindex>, analiza e skedave t\u00eb konfigurimit. K\u00ebto jan\u00eb t\u00eb gjitha lidhur me kodin.<\/p>\n

Avantazhet e qasjes<\/b>: identifikimi i dob\u00ebsive n\u00eb kod gjat\u00eb nj\u00eb faze t\u00eb hershme t\u00eb zhvillimit<\/b>, kur ende nuk ka ambiente dhe mjete t\u00eb gatshme, dhe\u00a0mund\u00ebsia e skanimit incremental<\/b>: skanimi i pjes\u00ebs s\u00eb kodit q\u00eb \u00ebsht\u00eb ndryshuar, dhe vet\u00ebm t\u00eb asaj funksionaliteti q\u00eb po zhvillojm\u00eb tani, e cila redukton koh\u00ebn e skanimit.<\/p>\n

Disavantazhet<\/b>\u00a0- \u00ebsht\u00eb mungesa e mb\u00ebshtetjes p\u00ebr gjuh\u00ebt e nevojshme.<\/p>\n

Integrimet e nevojshme, <\/b>t\u00eb cilat duhet t\u00eb jen\u00eb n\u00eb mjetet, sipas mendimit tim subjektiv:<\/p>\n