[{"data":1,"prerenderedAt":674},["ShallowReactive",2],{"/it-it/the-source/security/":3,"footer-it-it":35,"the-source-banner-it-it":342,"the-source-navigation-it-it":354,"the-source-newsletter-it-it":381,"the-source-the-source-resources-it-it":392,"authors-it-it":423,"categories-it-it":454,"security-articles-list-it-it":455},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"config":8,"seo":9,"content":12,"type":27,"slug":28,"_id":29,"_type":30,"title":7,"_source":31,"_file":32,"_stem":33,"_extension":34},"/it-it/the-source/security","the-source",false,"",{"layout":5},{"title":10,"description":11,"ogImage":7},"Sicurezza e conformità","Scopri in che modo le organizzazioni possono assicurarsi di essere al passo con l'evoluzione delle minacce alla sicurezza e dei requisiti di conformità.",[13,19],{"componentName":14,"componentContent":15},"TheSourceCategoryHero",{"title":10,"description":11,"image":16},{"config":17},{"src":18},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463273/aplkxrvwpii26xao5yhi.png",{"componentName":20,"componentContent":21},"TheSourceCategoryMainSection",{"config":22},{"sourceCTAs":23},[24,25,26],"source-lp-guide-to-dynamic-sboms","source-lp-a-field-guide-to-threat-vectors-in-the-software-supply-chain","application-security-in-the-digital-age","category","security","content:it-it:the-source:security:index.yml","yaml","content","it-it/the-source/security/index.yml","it-it/the-source/security/index","yml",{"_path":36,"_dir":37,"_draft":6,"_partial":6,"_locale":7,"data":38,"_id":338,"_type":30,"title":339,"_source":31,"_file":340,"_stem":341,"_extension":34},"/shared/it-it/main-footer","it-it",{"text":39,"source":40,"edit":46,"contribute":51,"config":56,"items":61,"minimal":330},"Git è un marchio di Software Freedom Conservancy e l'uso del termine \"GitLab\" è regolato da un accordo di licenza",{"text":41,"config":42},"Visualizza origine pagina",{"href":43,"dataGaName":44,"dataGaLocation":45},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":47,"config":48},"Modifica questa pagina",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":52,"config":53},"Contribuisci",{"href":54,"dataGaName":55,"dataGaLocation":45},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":57,"facebook":58,"youtube":59,"linkedin":60},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[62,89,161,229,291],{"title":63,"links":64,"subMenu":70},"Piattaforma",[65],{"text":66,"config":67},"Piattaforma DevSecOps",{"href":68,"dataGaName":69,"dataGaLocation":45},"/it-it/platform/","devsecops platform",[71],{"title":72,"links":73},"Prezzi",[74,79,84],{"text":75,"config":76},"Visualizza i piani",{"href":77,"dataGaName":78,"dataGaLocation":45},"/it-it/pricing/","view plans",{"text":80,"config":81},"Perché passare a Premium?",{"href":82,"dataGaName":83,"dataGaLocation":45},"/it-it/pricing/premium/","why premium",{"text":85,"config":86},"Perché passare a Ultimate?",{"href":87,"dataGaName":88,"dataGaLocation":45},"/it-it/pricing/ultimate/","why ultimate",{"title":90,"links":91},"Soluzioni",[92,97,101,106,111,116,121,126,131,136,141,146,151,156],{"text":93,"config":94},"Trasformazione digitale",{"href":95,"dataGaName":96,"dataGaLocation":45},"/it-it/topics/digital-transformation/","digital transformation",{"text":10,"config":98},{"href":99,"dataGaName":100,"dataGaLocation":45},"/solutions/application-security-testing/","Application security testing",{"text":102,"config":103},"Distribuzione software automatizzata",{"href":104,"dataGaName":105,"dataGaLocation":45},"/solutions/delivery-automation/","automated software delivery",{"text":107,"config":108},"Sviluppo Agile",{"href":109,"dataGaName":110,"dataGaLocation":45},"/it-it/solutions/agile-delivery/","agile delivery",{"text":112,"config":113},"Trasformazione cloud",{"href":114,"dataGaName":115,"dataGaLocation":45},"/it-it/topics/cloud-native/","cloud transformation",{"text":117,"config":118},"SCM",{"href":119,"dataGaName":120,"dataGaLocation":45},"/it-it/solutions/source-code-management/","source code management",{"text":122,"config":123},"CI/CD",{"href":124,"dataGaName":125,"dataGaLocation":45},"/it-it/solutions/continuous-integration/","continuous integration & delivery",{"text":127,"config":128},"Gestione del flusso di valore",{"href":129,"dataGaName":130,"dataGaLocation":45},"/it-it/solutions/value-stream-management/","value stream management",{"text":132,"config":133},"GitOps",{"href":134,"dataGaName":135,"dataGaLocation":45},"/it-it/solutions/gitops/","gitops",{"text":137,"config":138},"Aziende",{"href":139,"dataGaName":140,"dataGaLocation":45},"/it-it/enterprise/","enterprise",{"text":142,"config":143},"Piccole imprese",{"href":144,"dataGaName":145,"dataGaLocation":45},"/it-it/small-business/","small business",{"text":147,"config":148},"Pubblica amministrazione",{"href":149,"dataGaName":150,"dataGaLocation":45},"/it-it/solutions/public-sector/","public sector",{"text":152,"config":153},"Istruzione",{"href":154,"dataGaName":155,"dataGaLocation":45},"/it-it/solutions/education/","education",{"text":157,"config":158},"Servizi finanziari",{"href":159,"dataGaName":160,"dataGaLocation":45},"/it-it/solutions/finance/","financial services",{"title":162,"links":163},"Risorse",[164,169,174,179,184,189,194,199,204,209,214,219,224],{"text":165,"config":166},"Installazione",{"href":167,"dataGaName":168,"dataGaLocation":45},"/it-it/install/","install",{"text":170,"config":171},"Guide rapide",{"href":172,"dataGaName":173,"dataGaLocation":45},"/it-it/get-started/","quick setup checklists",{"text":175,"config":176},"Formazione",{"href":177,"dataGaName":178,"dataGaLocation":45},"https://university.gitlab.com/","learn",{"text":180,"config":181},"Documentazione di prodotto",{"href":182,"dataGaName":183,"dataGaLocation":45},"https://docs.gitlab.com/","docs",{"text":185,"config":186},"Blog",{"href":187,"dataGaName":188,"dataGaLocation":45},"/blog/","blog",{"text":190,"config":191},"Storie di successo dei clienti",{"href":192,"dataGaName":193,"dataGaLocation":45},"/it-it/customers/","customer success stories",{"text":195,"config":196},"Lavorare da remoto",{"href":197,"dataGaName":198,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":200,"config":201},"Servizi GitLab",{"href":202,"dataGaName":203,"dataGaLocation":45},"/it-it/services/","services",{"text":205,"config":206},"TeamOps",{"href":207,"dataGaName":208,"dataGaLocation":45},"/it-it/teamops/","teamops",{"text":210,"config":211},"Community",{"href":212,"dataGaName":213,"dataGaLocation":45},"/community/","community",{"text":215,"config":216},"Forum",{"href":217,"dataGaName":218,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":220,"config":221},"Eventi",{"href":222,"dataGaName":223,"dataGaLocation":45},"/events/","events",{"text":225,"config":226},"Partner",{"href":227,"dataGaName":228,"dataGaLocation":45},"/partners/","partners",{"title":230,"links":231},"Azienda",[232,237,242,247,252,257,262,266,271,276,281,286],{"text":233,"config":234},"Informazioni",{"href":235,"dataGaName":236,"dataGaLocation":45},"/it-it/company/","company",{"text":238,"config":239},"Opportunità di lavoro",{"href":240,"dataGaName":241,"dataGaLocation":45},"/jobs/","jobs",{"text":243,"config":244},"Leadership",{"href":245,"dataGaName":246,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":248,"config":249},"Team",{"href":250,"dataGaName":251,"dataGaLocation":45},"/company/team/","team",{"text":253,"config":254},"Manuale",{"href":255,"dataGaName":256,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":258,"config":259},"Rapporti con gli investitori",{"href":260,"dataGaName":261,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":263,"config":264},"Sustainability",{"href":265,"dataGaName":263,"dataGaLocation":45},"/sustainability/",{"text":267,"config":268},"Diversità, inclusione e appartenenza (DIB)",{"href":269,"dataGaName":270,"dataGaLocation":45},"/it-it/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":272,"config":273},"Trust Center",{"href":274,"dataGaName":275,"dataGaLocation":45},"/it-it/security/","trust center",{"text":277,"config":278},"Newsletter",{"href":279,"dataGaName":280,"dataGaLocation":45},"/company/contact/","newsletter",{"text":282,"config":283},"Rassegna stampa",{"href":284,"dataGaName":285,"dataGaLocation":45},"/press/","press",{"text":287,"config":288},"Dichiarazione di trasparenza sulla schiavitù moderna",{"href":289,"dataGaName":290,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":292,"links":293},"Contattaci",[294,299,304,309,314,319,324],{"text":295,"config":296},"Contatta un esperto",{"href":297,"dataGaName":298,"dataGaLocation":45},"/it-it/sales/","sales",{"text":300,"config":301},"Richiedi assistenza",{"href":302,"dataGaName":303,"dataGaLocation":45},"/support/","get help",{"text":305,"config":306},"Portale clienti",{"href":307,"dataGaName":308,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"text":310,"config":311},"Stato",{"href":312,"dataGaName":313,"dataGaLocation":45},"https://status.gitlab.com/","status",{"text":315,"config":316},"Termini di utilizzo",{"href":317,"dataGaName":318,"dataGaLocation":45},"/terms/","terms of use",{"text":320,"config":321},"Informativa sulla privacy",{"href":322,"dataGaName":323,"dataGaLocation":45},"/it-it/privacy/","privacy statement",{"text":325,"config":326},"Preferenze dei cookie",{"dataGaName":327,"dataGaLocation":45,"id":328,"isOneTrustButton":329},"cookie preferences","ot-sdk-btn",true,{"items":331},[332,334,336],{"text":315,"config":333},{"href":317,"dataGaName":318,"dataGaLocation":45},{"text":320,"config":335},{"href":322,"dataGaName":323,"dataGaLocation":45},{"text":325,"config":337},{"dataGaName":327,"dataGaLocation":45,"id":328,"isOneTrustButton":329},"content:shared:it-it:main-footer.yml","Main Footer","shared/it-it/main-footer.yml","shared/it-it/main-footer",{"_path":343,"_dir":344,"_draft":6,"_partial":6,"_locale":7,"id":345,"visibility":329,"title":346,"button":347,"_id":351,"_type":30,"_source":31,"_file":352,"_stem":353,"_extension":34},"/shared/it-it/the-source/banner/the-economics-of-software-innovation-2025-08-18","banner","The Economics of Software Innovation","The Economics of Software Innovation—AI’s $750 Billion Opportunity",{"config":348,"text":350},{"href":349},"/software-innovation-report/","Get the research report","content:shared:it-it:the-source:banner:the-economics-of-software-innovation-2025-08-18.yml","shared/it-it/the-source/banner/the-economics-of-software-innovation-2025-08-18.yml","shared/it-it/the-source/banner/the-economics-of-software-innovation-2025-08-18",{"_path":355,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"logo":356,"subscribeLink":361,"navItems":365,"_id":377,"_type":30,"title":378,"_source":31,"_file":379,"_stem":380,"_extension":34},"/shared/it-it/the-source/navigation",{"altText":357,"config":358},"the source logo",{"src":359,"href":360},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1750191004/t7wz1klfb2kxkezksv9t.svg","/it-it/the-source/",{"text":362,"config":363},"Iscriviti",{"href":364},"#subscribe",[366,370,373],{"text":367,"config":368},"Intelligenza artificiale",{"href":369},"/it-it/the-source/ai/",{"text":10,"config":371},{"href":372},"/it-it/the-source/security/",{"text":374,"config":375},"Piattaforma e infrastruttura",{"href":376},"/it-it/the-source/platform/","content:shared:it-it:the-source:navigation.yml","Navigation","shared/it-it/the-source/navigation.yml","shared/it-it/the-source/navigation",{"_path":382,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":383,"description":384,"submitMessage":385,"formData":386,"_id":389,"_type":30,"_source":31,"_file":390,"_stem":391,"_extension":34},"/shared/it-it/the-source/newsletter","Newsletter di The Source","Rimani al passo con le ultime tendenze dello sviluppo software grazie a preziosi approfondimenti.","Hai effettuato l'iscrizione alla newsletter di The Source.",{"config":387},{"formId":388,"formName":280,"hideRequiredLabel":329},28469,"content:shared:it-it:the-source:newsletter.yml","shared/it-it/the-source/newsletter.yml","shared/it-it/the-source/newsletter",[393,409],{"_path":394,"_dir":395,"_draft":6,"_partial":6,"_locale":7,"config":396,"title":398,"description":399,"link":400,"_id":406,"_type":30,"_source":31,"_file":407,"_stem":408,"_extension":34},"/shared/it-it/the-source/source-lp-ctas/navigating-ai-maturity-in-devsecops","source-lp-ctas",{"slug":397},"navigating-ai-maturity-in-devsecops","Capire come implementare l'IA in un ambiente DevSecOps","Scopri i [risultati del nostro sondaggio rivolto a oltre 5.000 professionisti DevSecOps in tutto il mondo (disponibile in inglese)](/developer-survey/2024/ai/) e ottieni informazioni utili su come le organizzazioni stanno incorporando l'IA nel ciclo di sviluppo software.",{"text":401,"config":402},"Leggi il report",{"href":403,"dataGaName":404,"dataGaLocation":405},"/developer-survey/2024/ai/","Navigating AI Maturity in DevSecOps","thesource","content:shared:it-it:the-source:source-lp-ctas:navigating-ai-maturity-in-devsecops.yml","shared/it-it/the-source/source-lp-ctas/navigating-ai-maturity-in-devsecops.yml","shared/it-it/the-source/source-lp-ctas/navigating-ai-maturity-in-devsecops",{"_path":410,"_dir":395,"_draft":6,"_partial":6,"_locale":7,"config":411,"title":413,"description":414,"link":415,"_id":420,"_type":30,"_source":31,"_file":421,"_stem":422,"_extension":34},"/shared/it-it/the-source/source-lp-ctas/source-lp-how-to-get-started-using-ai-in-software-development",{"slug":412},"source-lp-how-to-get-started-using-ai-in-software-development","Come iniziare a utilizzare l'IA nello sviluppo software","Leggi il nostro ebook e scopri i concetti essenziali che ti aiuteranno a creare un framework di IA strategico per sviluppare software sicuro più velocemente.",{"text":416,"config":417},"Leggi l'ebook",{"href":418,"dataGaName":419,"dataGaLocation":405},"/the-source/ai/getting-started-with-ai-in-software-development-a-guide-for-leaders/","How to Get Started Using AI in Software Development","content:shared:it-it:the-source:source-lp-ctas:source-lp-how-to-get-started-using-ai-in-software-development.yml","shared/it-it/the-source/source-lp-ctas/source-lp-how-to-get-started-using-ai-in-software-development.yml","shared/it-it/the-source/source-lp-ctas/source-lp-how-to-get-started-using-ai-in-software-development",{"amanda-rueda":424,"andre-michael-braun":425,"andrew-haschka":426,"ayoub-fandi":427,"brian-wald":428,"bryan-ross":429,"chandler-gibbons":430,"dave-steer":431,"ddesanto":432,"derek-debellis":433,"emilio-salvador":434,"erika-feldman":435,"george-kichukov":436,"gitlab":437,"grant-hickman":438,"haim-snir":439,"iganbaruch":440,"jlongo":441,"joel-krooswyk":442,"josh-lemos":443,"julie-griffin":444,"kristina-weis":445,"lee-faus":446,"ncregan":447,"rschulman":448,"sabrina-farmer":449,"sandra-gittlen":450,"sharon-gaudin":451,"stephen-walters":452,"taylor-mccaslin":453},"Amanda Rueda","Andre Michael Braun","Andrew Haschka","Ayoub Fandi","Brian Wald","Bryan Ross","Chandler Gibbons","Dave Steer","David DeSanto","Derek DeBellis","Emilio Salvador","Erika Feldman","George Kichukov","GitLab","Grant Hickman","Haim Snir","Itzik Gan Baruch","Joseph Longo","Joel Krooswyk","Josh Lemos","Julie Griffin","Kristina Weis","Lee Faus","Niall Cregan","Robin Schulman","Sabrina Farmer","Sandra Gittlen","Sharon Gaudin","Stephen Walters","Taylor McCaslin",{"ai":367,"platform":374,"security":10},{"allArticles":456,"visibleArticles":673,"showAllBtn":6},[457,482,521,540,558,577,597,631,652],{"_path":458,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"config":459,"seo":463,"content":468,"type":477,"category":28,"slug":478,"_id":479,"_type":30,"title":464,"_source":31,"_file":480,"_stem":481,"_extension":34,"date":469,"description":470,"timeToRead":471,"heroImage":466,"keyTakeaways":472,"articleBody":476},"/it-it/the-source/security/key-security-trends-for-cisos-in-2025",{"layout":5,"template":460,"author":461,"featured":6,"sourceCTA":462,"isHighlighted":6,"authorName":443},"TheSourceArticle","josh-lemos","source-lp-ai-guide-for-enterprise-leaders-building-the-right-approach",{"title":464,"description":465,"ogImage":466,"config":467},"Principali tendenze del 2025 per i responsabili della sicurezza delle informazioni","Approfondisci Secure by Design e i concetti correlati e scopri cosa puoi fare oggi per integrare la sicurezza nei tuoi processi di sviluppo software.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464506/hyue0lgqq2lqk3arwnel.jpg",{"ignoreTitleCharLimit":329},{"title":464,"date":469,"description":470,"timeToRead":471,"heroImage":466,"keyTakeaways":472,"articleBody":476},"2025-02-25","Dai un'occhiata alle principali tendenze del 2025 nel campo della sicurezza e scopri come l'IA crea nuovi rischi e opportunità, rimodella la gestione delle identità e rafforza i team DevOps.","Tempo di lettura: 5 minuti",[473,474,475],"L'IA porta sia rischi che opportunità per la sicurezza. Le organizzazioni devono controllare attentamente come viene integrata nei prodotti di aziende esterne, sfruttarla per rafforzare i controlli e prepararsi a eventuali interruzioni del servizio.","È necessario modernizzare la gestione delle identità per poter controllare complesse interazioni tra macchine, autorizzazioni dinamiche e l'accesso ai sistemi basati sull'IA. A tal fine bisogna avvalersi di strumenti di sicurezza più flessibili e adattivi.","Questi ultimi possono contribuire a colmare il divario di competenze in materia di sicurezza DevOps automatizzando i controlli, suggerendo pattern di programmazione affidabili e integrando la sicurezza in ogni fase del ciclo di sviluppo software.","Nel 2025, molti dei tuoi principali strumenti di sicurezza includeranno modelli di IA che non sarai in grado di comprendere a fondo o gestire nella loro interezza. I membri del consiglio di amministrazione della tua organizzazione si staranno già interrogando su cosa fare per prevenire la prossima breccia nel sistema di sicurezza ed evitare di finire sui giornali. Nel frattempo, le aziende concorrenti stanno utilizzando l'IA per automatizzare la sicurezza a un livello assolutamente impensabile solo fino a qualche mese fa. L'evoluzione dei requisiti normativi aggiunge un altro livello di complessità, in quanto le nuove norme dell'Unione europea e della California disciplinano le modalità in cui è possibile utilizzare i sistemi basati sull'IA.\n\nIl panorama della sicurezza si sta evolvendo rapidamente ma, con il giusto approccio, è possibile sfruttare queste sfide per costruire difese più solide e proteggersi dalle nuove minacce informatiche. Ecco tre tendenze a cui è necessario prepararsi e che domineranno il panorama della sicurezza aziendale nel corso di quest'anno.\n\n## 1. Vulnerabilità nei modelli linguistici di grandi dimensioni (LLM) proprietari\nOggigiorno, molti fornitori integrano modelli linguistici di grandi dimensioni (LLM) proprietari nei loro prodotti, esponendo la tua organizzazione a nuovi rischi. La maggior parte di questi LLM sono come scatole nere: non è possibile comprenderne a fondo il funzionamento interno o le misure di sicurezza implementate. I ricercatori nel campo della sicurezza informatica hanno dimostrato la fragilità dei sistemi di protezione dell'IA. La superficie di attacco dei modelli stessi e, di riflesso, dei prodotti che essi supportano è in aumento.\n\nPoiché molti prodotti si basano sui medesimi LLM proprietari, un singolo attacco potrebbe danneggiare molti dei tuoi sistemi nello stesso momento. Una simile concentrazione del rischio è particolarmente preoccupante, in quanto le funzioni aziendali più critiche dipendono da strumenti basati sull'IA. Per far fronte a questa circostanza, dovrai:\n\n- Verificare quali dei tuoi fornitori utilizzano LLM\n- Valutare i controlli di sicurezza messi in atto da questi fornitori\n- Prepararti a eventuali interruzioni dei servizi basati su LLM\n- Sviluppare piani di ripristino per i sistemi critici dipendenti dall'IA\n\n> Per saperne di più: [7 domande da porre al tuo fornitore DevOps per costruire una strategia di IA incentrata sulla trasparenza]((https://about.gitlab.com/the-source/ai/building-a-transparency-first-ai-strategy-7-questions-to-ask-your-devops/)\n\n## 2. Sfide nella gestione delle identità\nI sistemi cloud e di intelligenza artificiale stanno cambiando il modo in cui controlliamo l'accesso ai sistemi di uso quotidiano. Al giorno d'oggi, i tuoi sistemi di gestione delle identità sono chiamati a gestire:\n\n- Un aumento delle identità non umane basate su servizi\n- Un numero maggiore di connessioni tra macchine\n- Cambiamenti frequenti nelle necessità di accesso ai sistemi di identità\n- Complesse catene di autorizzazioni tra i servizi\n- Sistemi di intelligenza artificiale che richiedono diversi livelli di accesso ai dati\n\nI tradizionali strumenti di Identity and Access Management non sono stati creati per far fronte a queste sfide. Avrai bisogno di versioni più flessibili e in grado di adattarsi rapidamente al mutare delle tue esigenze. Valuta la possibilità di implementare [principi Zero Trust e accessi just-in-time](https://about.gitlab.com/the-source/security/field-guide-to-threat-vectors-in-the-software-supply-chain/) per controllare al meglio questi ambienti dinamici.\n\nInoltre, i team della sicurezza dovrebbero sviluppare strategie mirate e prepararsi ad affrontare le complessità dell'IA agentica applicando gli stessi criteri di rigore e verificabilità che seguono in presenza di utenti umani. Con la proliferazione dei sistemi di intelligenza artificiale, [monitorare e proteggere queste identità non umane](https://about.gitlab.com/blog/improve-ai-security-in-gitlab-with-composite-identities/) diventa importante tanto quanto la gestione dell'accesso degli utenti umani.\n\n## 3. Implementare misure di sicurezza efficienti in un ambiente DevOps\n[In un recente sondaggio](https://about.gitlab.com/developer-survey/), il 58% degli sviluppatori ha dichiarato di avvertire una certa responsabilità nei confronti della sicurezza delle applicazioni. Tuttavia, trovare personale DevOps che possa vantare le necessarie competenze in materia rimane piuttosto difficile. Gli strumenti basati sull'IA possono essere utili per:\n\n- Scandagliare il codice alla ricerca di vulnerabilità di sicurezza e potenziali minacce sin dalle prime fasi del ciclo di sviluppo\n- Ricevere suggerimenti di pattern di programmazione sicuri\n- Impostare automaticamente le autorizzazioni di accesso corrette\n- Automatizzare le attività ripetitive durante tutto il processo di sviluppo\n\nQuesti strumenti possono aiutare il tuo team della sicurezza a lavorare in modo più efficiente e gli sviluppatori a rilevare le vulnerabilità più comuni prima che il codice raggiunga la fase di produzione. Tutto ciò si traduce in un numero minore di incidenti e in una maggiore solidità dei tuoi sistemi.\n\nValuta la possibilità di investire in strumenti in grado di integrarsi direttamente nei flussi di lavoro degli sviluppatori. Se fornisci loro gli strumenti adeguati per produrre codice sicuro, è probabile che lo facciano.\n\n## Agire: adottare l'IA per proteggersi dalle minacce informatiche\nSe vuoi restare al passo con questi cambiamenti, dovrai:\n\n1. Individuare i punti di contatto tra gli strumenti di IA e i tuoi sistemi, valutando i rischi\n1. Aggiornare il tuo approccio alla gestione delle identità per soddisfare le esigenze del cloud e dell'IA\n1. Cercare soluzioni per integrare l'IA in modo efficace nelle operazioni di sicurezza\n1. Informare costantemente il tuo consiglio di amministrazione riguardo alle minacce informatiche emergenti e alle nuove normative legate all'IA\n1. Stringere rapporti con i principali fornitori per capire come funzionano le loro misure di sicurezza basate sull'IA\n1. Formare il tuo team riguardo ai rischi per la sicurezza generati dall'IA, ma anche in merito alle opportunità\n\nSe da una parte l'integrazione dell'IA potrebbe generare minacce mai affrontate prima d'ora, dall'altra ti offre nuovi strumenti per proteggere la tua organizzazione. Concentrati sull'intelligenza artificiale come strumento per rafforzare la security posture della tua organizzazione, facendo al contempo attenzione ai rischi che ne derivano. L'esecuzione periodica di revisioni delle misure di sicurezza basate sull'IA ti aiuterà a prevenire i rischi legati all'integrità dei tuoi sistemi.\n\n## Guardare al futuro\nIl panorama della sicurezza continuerà a evolversi di pari passo con l'intelligenza artificiale. Adotta una strategia flessibile e proattiva in modo da affrontare con le dovute precauzioni sia le minacce emergenti che le nuove opportunità. Costruisci relazioni solide a tutti i livelli della tua organizzazione, in particolare con il dipartimento legale, gli sviluppatori e i team delle operazioni. Questi rapporti ti aiuteranno a fronteggiare in modo più efficace le sfide legate alla sicurezza.\n\nE ricorda che, per quanto la tecnologia si evolva, il tuo obiettivo principale non cambia: proteggere le risorse della tua organizzazione e garantire la sicurezza della operazioni aziendali. Utilizza nuovi strumenti e adotta approcci alternativi laddove ti sembrino ragionevoli, senza tuttavia perdere di vista i fondamenti della sicurezza nella fretta di integrare l'IA.","article","key-security-trends-for-cisos-in-2025","content:it-it:the-source:security:key-security-trends-for-cisos-in-2025.yml","it-it/the-source/security/key-security-trends-for-cisos-in-2025.yml","it-it/the-source/security/key-security-trends-for-cisos-in-2025",{"_path":483,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"slug":484,"type":477,"category":28,"config":485,"seo":488,"content":492,"_id":518,"_type":30,"title":493,"_source":31,"_file":519,"_stem":520,"_extension":34,"heroImage":490,"description":494,"timeToRead":495,"date":496,"keyTakeaways":497,"articleBody":501,"faq":502},"/it-it/the-source/security/why-legacy-code-is-a-security-risk-and-how-ai-can-help","why-legacy-code-is-a-security-risk-and-how-ai-can-help",{"layout":5,"template":460,"featured":6,"author":486,"sourceCTA":487,"isHighlighted":6,"authorName":442},"joel-krooswyk","source-lp-how-a-devsecops-platform-drives-business-success-the-complete-guide",{"description":489,"ogDescription":489,"ogImage":490,"title":491,"ogTitle":491,"noIndex":329},"Scopri come il refactoring del codice basato su IA può modernizzare i sistemi legacy, migliorare i protocolli di sicurezza e portare la tua azienda nel futuro.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463670/cdynzww9p2annh3mmbhl.png","Come proteggerti dal codice legacy rischioso con l'IA",{"heroImage":490,"title":493,"description":494,"timeToRead":495,"date":496,"keyTakeaways":497,"articleBody":501,"faq":502},"Perché il codice legacy è un rischio per la sicurezza e come proteggerti con l'IA","Scopri come il refactoring del codice basato sull'IA può modernizzare i sistemi legacy, migliorare i protocolli di sicurezza e traghettare la tua azienda verso il futuro.","Tempo di lettura: 6 minuti","2025-01-15T00:00:00.000Z",[498,499,500],"Il codice legacy è costoso e richiede tempo per la manutenzione. Inoltre, se non è compatibile con gli strumenti di sicurezza più recenti, può rappresentare un grave rischio per le aziende di tutti i settori.","Il refactoring può aiutare a rendere il codice più leggibile, migliorando la stabilità della codebase nonché la produttività e l'efficienza degli sviluppatori.","Insieme agli strumenti di sicurezza preventiva, il refactoring del codice basato sull'IA può contribuire a modernizzare il codice legacy, riducendo al contempo il rischio di vulnerabilità della sicurezza.","Today’s rapid acceleration of technology is exciting. It means new products and opportunities for growth and innovation are around every corner. And yet this speed of growth and change has its downsides, especially regarding security: just one bad actor can cause massive business disruption, reputation damage, and lost revenue.\n\nYou have likely heard industry leaders talk about their need for digital transformation and the worrisome dependency on outdated or “legacy” systems. While legacy code is not inherently problematic, it often isn’t compatible with modern security tools, leading to exploitable vulnerabilities. Coupled with open source code — which requires ongoing security vigilance — your code base may be putting your organization’s data, users, and reputation at risk. \n\nLegacy code is risky from a security and compliance perspective, and it’s also expensive and time-consuming for developers to maintain — if developers on your team even have the legacy knowledge to do the work. \n\nUltimately, this industry-wide reliance on legacy code is a concerning and costly practice. So, how do we work our way out of it?  \n\nBelow, I’ll explore legacy code and how organizations can increase the security of their code base with AI-powered code refactoring. Together with AI-driven testing and security capabilities, code refactoring will propel your codebase into the future while empowering your whole team to look ahead, not behind. \n\n## What is legacy code? \n\nBroadly, legacy code refers to an existing code base that a team inherits from previous team members and continues to use and maintain. The code might work just fine, but several different developers have likely modified it over the years. The current team might struggle to identify which modifications are valuable and which are not. Additionally, the code might be written using an outdated framework or in a programming language that no one on the team knows (whether it’s simply old or completely obsolete). \n\nIt might seem strange that companies still rely on legacy code. While the reasons can vary, think of it like this: You live in an old house. It's cozy and familiar, but the plumbing's unreliable, the wiring is outdated, and every time you fix one thing, something else breaks. Sure, you could remodel, but that means a huge upheaval – contractors, permits, living in chaos for months, and costs that can spiral out of control.\n\nSo, you keep patching things up, hoping for the best. It's not ideal, but it works — for now. That's kind of what it's like with legacy code. It's the familiar, “working” solution, even if it's creaky and inefficient. Rewriting it from scratch is a daunting prospect with its own risks and costs. Plus, who has time for a massive overhaul when there are new features to build and urgent bugs to fix?\n\nWhen it comes to updating code, many companies decide to keep their legacy code because maintaining it can be less disruptive in the short term. Updating code involves a lot of developing and testing code. It can also involve training a team to ensure they have the skills to work with the outdated code language or framework. If there isn’t any documentation, it can be even more challenging to navigate.   \n\n## What’s the problem with legacy code?\n\nIf your organization does decide to stick with your legacy code — and many do — you’re opening yourself up to a host of potential issues. Since this code wasn’t designed for newer tech, you might not be able to integrate it with the latest and greatest software (like AI tools, for example), which could also impact the performance and scalability of your products. This can hold you back and impact customer experience down the line. \n\nWhat’s most concerning about legacy code, whether it was written five years ago or 50, is that there may be no security scanners that work for this code. That means you can’t detect problems on your own while making updates. Moreover, developers making these updates may not understand the language or its structure well and might even accidentally create vulnerable code in the process. Finally, older applications are commonly written in C or C++, which are memory unsafe languages — proven to host [70% of identified vulnerabilities](https://www.cisa.gov/news-events/news/urgent-need-memory-safety-software-products).\n\nThese three issues — the fact that there may be no way to secure legacy code, there are fewer ways to safely update it, and that the end result is far more likely to be vulnerable — should be warning signs for organizations across industries. \n\nIn developing a catalog of bad practices that can put critical infrastructure at risk, the U.S. [Cybersecurity and Infrastructure Security Agency](https://www.cisa.gov/stopransomware/bad-practices) added the following:\n\n“Use of unsupported (or end-of-life) software in service of Critical Infrastructure and National Critical Functions is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety. This dangerous practice is especially egregious in technologies accessible from the Internet.”\n\nEven if you aren’t working in national security or for national public health and safety, this warning is still applicable: Using old code is not a best practice. It’s a bad one. \n\n## The solution: Code refactoring\n\nAccording to software developer and author [Martin Fowler](https://www.martinfowler.com/), “Refactoring is a controlled technique for improving the design of an existing code base, a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” \n\nIn other words, code refactoring allows you to secure and modernize your legacy code without obscuring its original functionality. \n\nThere are many refactoring techniques — from inline refactoring, which involves simplifying code by removing obsolete elements, to refactoring by abstraction, where duplicate code is deleted. What’s important to know is that code refactoring requires time and significant developer skills to do well. It also requires a lot of testing when developers are already busy working on other tasks. \n\nSo, while code refactoring is certainly the answer to bringing your legacy code into the future, making it readable, efficient, and secure, it is a project in and of itself, especially at scale. \n\n## How AI can help\n\nWe know that AI is already accelerating the software development lifecycle — and there’s a lot that [AI can do to help teams accelerate the refactoring process](https://about.gitlab.com/blog/2024/08/26/refactor-code-into-modern-languages-with-ai-powered-gitlab-duo/), too. For example, tools like [GitLab Duo](https://about.gitlab.com/blog/2024/04/18/gitlab-duo-chat-now-generally-available/) can help explain existing code and create new code, two of the biggest hurdles when modernizing legacy code. If a developer isn’t familiar with a language, AI can help fill in the blanks. Regarding testing and security, AI can also [analyze root causes, generate tests](https://about.gitlab.com/blog/2024/06/06/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/), and [help developers remediate vulnerabilities](https://about.gitlab.com/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/). With AI in your toolkit, code refactoring can finally be more accessible and achievable for organizations, so they can move this project off their backlog for good. \n\nAccording to [our research](https://about.gitlab.com/developer-survey/2024/ai/), 34% of all respondents using AI across the software development lifecycle already use AI to modernize legacy code. This is even higher in the financial services industry (46%). \n\nOf course, there are a few things to keep in mind as you start to implement AI in any of your practices. \n\nAI isn’t perfect. It still requires testing, guardrails, and human oversight. So, while it absolutely can facilitate and accelerate some of these critical, time-consuming manual tasks, it can’t do this work alone. Especially regarding security, you should implement other tools to keep your code as secure as possible. We recommend creating a [dynamic software bill of materials](https://about.gitlab.com/blog/2022/10/25/the-ultimate-guide-to-sboms/) (also called an SBOM) to give you full visibility into the license and security risks associated with your software, including any legacy code you may have.\n\n## Bring your codebase into the future\n\nWhile the jump from legacy codebase maintenance to modernization might feel daunting, it is the best path forward if you want to keep your organization and user data secure. With the right tools and methods, it may be more efficient for your teams and cost-effective for your company. \n\nThe good news is that your teams don’t need to spend time and resources deciphering old languages and working with old frameworks — causing frustration, delays, and bottlenecks. By letting AI do the hard work of refactoring your code so that it’s safe, secure, and functioning as it should, developers can focus on what they do best: building new products and features and driving value for customers.",[503,506,509,512,515],{"header":504,"content":505},"Perché il codice legacy è considerato un rischio per la sicurezza?","Il codice legacy è rischioso perché spesso usa framework o linguaggi di programmazione obsoleti, privi di moderne misure di sicurezza. Per questo motivo è incompatibile con gli strumenti di sicurezza più recenti e aumenta il rischio di vulnerabilità. Inoltre, il software non supportato o a fine vita può essere facilmente sfruttato dai malintenzionati, compromettendo l'integrità e la sicurezza dei dati.",{"header":507,"content":508},"In che modo il refactoring del codice basato sull'IA può migliorare la sicurezza del codice legacy?","Il refactoring del codice basato sull'IA modernizza i sistemi legacy:\n - identificando pattern di programmazione obsoleti o non sicuri e suggerendo alternative sicure;\n - automatizzando i miglioramenti del codice senza alterare il comportamento esterno, migliorando la leggibilità e la manutenibilità;\n - generando test di sicurezza e analizzando le cause principali delle vulnerabilità, consentendo una correzione più rapida.\nQuesto approccio riduce il lavoro manuale e accelera la transizione verso codebase più sicure, efficienti e scalabili.",{"header":510,"content":511},"Perché è complesso eseguire la manutenzione del codice legacy senza l'IA?","Le difficoltà includono:\n - __Mancanza di un supporto di sicurezza moderno__: gli scanner di sicurezza tradizionali potrebbero non essere compatibili con il codice legacy.\n - __Framework complessi e obsoleti__: gli sviluppatori potrebbero non avere le competenze necessarie per mantenere o aggiornare il vecchio codice.\n - __Costi di manutenzione elevati__: la manutenzione dei sistemi legacy è costosa e richiede tempo, dirottando le risorse dall'innovazione.\n - __Rischi per la sicurezza__: il codice obsoleto è più soggetto a vulnerabilità e attacchi, aumentando il rischio di violazioni dei dati.",{"header":513,"content":514},"In che modo GitLab supporta il refactoring basato sull'IA e la modernizzazione del codice legacy?","GitLab usa GitLab Duo per aiutare gli sviluppatori a comprendere il codice legacy fornendo spiegazioni e generando nuovo codice. Inoltre, offre:\n - Analisi di sicurezza guidate dall'IA per rilevare vulnerabilità nel codice legacy\n - Test e correzioni automatici per migliorare la sicurezza del codice\n - Distinte base del software dinamiche (SBOM) per la visibilità dei rischi legati alle licenze e alla sicurezza, inclusi i componenti legacy",{"header":516,"content":517},"Quali sono i vantaggi dell'IA nel refactoring del codice legacy?","I vantaggi includono:\n - __Maggiore sicurezza__: l'IA identifica e mitiga le vulnerabilità, migliorando la security posture.\n - __Maggiore produttività__: l'automazione delle attività ripetitive consente agli sviluppatori di concentrarsi sull'innovazione.\n - __Risparmio di denaro__: i costi di manutenzione sono ridotti grazie alla modernizzazione del codice, per lavorare con i framework e gli strumenti attuali.\n - __Modernizzazione scalabile__: l'IA consente un refactoring scalabile e coerente su codebase complesse, garantendo risorse software aziendali sempre all'avanguardia.","content:it-it:the-source:security:why-legacy-code-is-a-security-risk-and-how-ai-can-help.yml","it-it/the-source/security/why-legacy-code-is-a-security-risk-and-how-ai-can-help.yml","it-it/the-source/security/why-legacy-code-is-a-security-risk-and-how-ai-can-help",{"_path":522,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"config":523,"seo":524,"content":528,"type":477,"category":28,"slug":536,"_id":537,"_type":30,"title":526,"_source":31,"_file":538,"_stem":539,"_extension":34,"date":529,"description":526,"timeToRead":530,"heroImage":527,"keyTakeaways":531,"articleBody":535},"/it-it/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security",{"layout":5,"template":460,"author":461,"featured":329,"sourceCTA":26,"isHighlighted":6,"authorName":443},{"title":525,"description":526,"ogImage":527},"Non solo cultura aziendale per gestire la sicurezza | GitLab","Non solo cultura aziendale: come affrontare la causa principale dei comuni problemi di sicurezza","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464489/mragusmxl1wz8ozdaoml.png",{"title":526,"date":529,"description":526,"timeToRead":530,"heroImage":527,"keyTakeaways":531,"articleBody":535},"2024-10-29","5 minuti di lettura",[532,533,534],"Il passaggio alla scansione autenticata nella gestione delle vulnerabilità aumenta l'efficacia del processo, ma può portare i tecnici a occuparsi di attività non fondamentali, creando una divisione tra team di sicurezza e tecnici.","Un approccio minimalista allo sviluppo software può ridurre le dipendenze e i falsi allarmi generati dallo scanner di vulnerabilità e alleggerire il carico di lavoro per gli sviluppatori, contribuendo a migliorare la sicurezza del software.","Adottare pattern di progettazione collaudati e sicuri basati su casi d'uso ripetibili può ridurre il carico di lavoro per i team tecnici e aumentare la sicurezza.","Quest'anno il [sondaggio annuale tra i professionisti del DevSecOps](https://about.gitlab.com/developer-survey/) di GitLab ha rilevato numerosi problemi nella cultura organizzativa che potrebbero impedire un allineamento più profondo tra i team tecnici e della sicurezza. La maggioranza delle persone intervistate (58%) dichiara che è difficile far sì che i team di sviluppo diano priorità alla correzione delle vulnerabilità; il 52% riferisce che le procedure spesso ne impediscono la risoluzione rapida. Inoltre, gli specialisti di sicurezza intervistati riportano vari problemi specifici legati al proprio lavoro, tra cui difficoltà a comprendere i risultati delle analisi di sicurezza, un numero eccessivo di falsi positivi e lo svolgimento di test in una fase troppo tarda dello sviluppo software.\n\nIl [DevSecOps](/topics/devsecops/) promette di offrire un'integrazione migliore tra il lavoro dei tecnici e quello dei team di sicurezza, ma è chiaro che persistono frustrazioni e un certo disallineamento. Queste difficoltà sono sintomi di un problema più ampio, legato all'idea che l'organizzazione ha della sicurezza, alla collaborazione tra team e al tempo dedicato alle attività di sicurezza.\n\n## Sfuggire al circolo vizioso della vulnerabilità\n\nLe analisi mettono in evidenza tutte le potenziali vulnerabilità, ma il fatto che un pacchetto software presenti una vulnerabilità o un'esposizione comune non significa che sia raggiungibile o sfruttabile. Molti team della sicurezza e sviluppatori potrebbero essere occupati a categorizzare e filtrare i risultati delle vulnerabilità, cresciuti esponenzialmente negli anni da quando si è diffusa la scansione autenticata delle vulnerabilità.\n\nIl passaggio alla scansione autenticata ha migliorato l'efficacia dei programmi di sicurezza sotto vari aspetti, ma ha anche inserito gli sviluppatori in un ciclo infinito di correzione di elementi poco rilevanti. Se i team usano il proprio tempo per lavorare su patch che non riguardano una vulnerabilità sfruttabile, non riescono a occuparsi di attività più critiche, come la correzione di falle vulnerabili e sfruttabili. Questa attualmente è la fonte di gran parte delle tensioni tra team di sicurezza e tecnici.\n\nCome è possibile affrontare la causa principale di questi problemi e promuovere una migliore integrazione tra tecnici ed esperti di sicurezza? Ecco tre modi per eliminare alla fonte le frustrazioni più comuni dei team di sicurezza.\n\n### 1. Silenzia il rumore, concentrati su segnali utili ad alta fedeltà\n\nSecondo gli esperti di sicurezza intervistati durante il nostro sondaggio, l'eccesso di falsi positivi è il secondo problema più pressante. La sfida è evidente, ma spesso è solo un problema di gestione delle vulnerabilità sotto mentite spoglie.\n\nLa presenza di molti falsi positivi potrebbe indicare che non si è fatto tutto il possibile per garantire l'alta fedeltà dei risultati di sicurezza. I team di sicurezza devono quindi restringere il campo a ciò che conta di più. Ciò significa che le tradizionali soluzioni di test statico della sicurezza delle applicazioni (SAST) sono probabilmente insufficienti. Il SAST è uno strumento potente, ma perde gran parte del suo valore se i risultati sono ingestibili o mancano di un contesto appropriato. Affinché il SAST sia più efficace, deve integrarsi [fluidamente con altri strumenti di sicurezza e sviluppo ed essere accessibile agli sviluppatori](https://about.gitlab.com/blog/oxeye-joins-gitlab-to-advance-application-security-capabilities/).\n\nUn altro problema è che gran parte degli strumenti di analisi ha una finestra di contesto molto ristretta per comprendere i risultati delle vulnerabilità. Questo è uno dei campi in cui possono venire in aiuto le [funzionalità basate sull'IA in grado di spiegare le vulnerabilità della sicurezza](https://about.gitlab.com/it-it/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/).\n\n### 2. Ridurre al minimo lo stack tecnologico e la superficie di attacco\n\nConcentrarsi su ciò che conta non è importante solo per i test di sicurezza, ma anche per lo sviluppo software in primo luogo.\n\nNonostante l'IA prometta di semplificare lo sviluppo software, [la nostra indagine indica che molte aziende hanno ancora molta strada da fare](https://about.gitlab.com/it-it/the-source/platform/3-surprising-findings-from-our-2024-global-devsecops-survey/). Rispetto agli intervistati che non usano l'IA, chi la usa è nettamente più propenso a consolidare la propria toolchain; questo dato indica che la proliferazione di diverse point solution che eseguono modelli di IA diversi potrebbe aggiungere complessità, non eliminarla.\n\nLa complessità crescente degli stack tecnologici aziendali è una delle principali difficoltà per i team di sicurezza. Un certo grado di complessità è inevitabile durante lo sviluppo di sistemi software estesi e sfaccettati, ma le organizzazioni devono cercare di evitare le complessità derivanti da decisioni di progettazione non ottimali, come codice difficile da aggiornare e dipendenze ridondanti. Questa complessità evitabile crea una superficie di attacco più ampia e genera più risultati delle analisi di sicurezza, che i team devono ordinare, a cui devono assegnare priorità e che devono affrontare.\n\nBisogna quindi affrontare lo sviluppo attraverso la lente della minimizzazione del software, ovvero adottare intenzionalmente alcuni strumenti e integrare intenzionalmente determinati elementi nelle codebase. In questo modo le dipendenze sono ridotte al minimo, la sicurezza della catena di fornitura del software è migliorata, i falsi allarmi generati dallo scanner di vulnerabilità sono ridotti e, nel complesso, gli sviluppatori hanno meno problemi non critici da correggere.\n\n### 3. Normalizzare l'approccio orientato a una strada già battuta\n\nTra i problemi principali individuati dagli intervistati c'è anche lo svolgimento di test di sicurezza troppo tardi nel ciclo di sviluppo software. Alcuni dipendenti possono sentirsi frustrati quando vogliono distribuire un elemento ma non possono farlo perché una vulnerabilità viene rilevata in ritardo (e spesso era impossibile rilevarla prima). Ciò che è possibile, però, è usare componenti di sicurezza riutilizzabili e di cui è facile eseguire il deployment, limitando le variabili e le potenziali vulnerabilità.\n\nPer evitare sorprese in fase avanzata di sviluppo si possono adottare [pattern di progettazione collaudati e sicuri basati su casi d'uso ripetibili](https://about.gitlab.com/the-source/platform/how-devops-and-platform-engineering-turbocharge-efficiency/): è il cosiddetto approccio orientato a una strada già battuta. Una \"strada battuta\" (\"paved way\") è un percorso consigliato che include un set definito di strumenti, processi e componenti, utilizzabile dai team per creare applicazioni sicure in modo più efficiente, ad esempio usando GitOps per la versione ed eseguendo il deployment di una Infrastructure as Code ben progettata e testata che si distribuisce su larga scala per tutti i carichi di lavoro.\n\nAdottare questo tipo di approccio può ridurre in parte la flessibilità, ma nel complesso limita il carico operativo e la rilavorazione necessaria per i team tecnici, migliorando la sicurezza. Per applicarlo, serve la collaborazione tra team di sicurezza e di sviluppo: i primi possono aiutare a definirlo, ma occorre coinvolgere i tecnici per gestirlo e aggiornarlo come parte della codebase.\n\n## La sicurezza è un dominio, non un team{class=\"no-anchor\"}\n\nLa sicurezza si sta già integrando nel lavoro dei team tecnici, e possiamo aspettarci che i confini tra i due continueranno a confondersi. Ma con la rapida adozione dell'IA e la corrispondente accelerazione dello sviluppo software (il 66% degli intervistati dichiara di effettuare release due volte più velocemente, o comunque più velocemente, rispetto allo scorso anno), la sicurezza sarà fondamentale per creare sistemi e framework ottimizzati affinché diano il massimo vantaggio in termini di sicurezza. Per questo motivo, la disconnessione tra sviluppo e sicurezza è solo una sfaccettatura del problema. È essenziale promuovere una cultura della collaborazione, ma i team di sicurezza e tecnici devono anche collaborare per ripensare gli aspetti fondamentali dello sviluppo software, come l'ottimizzazione delle codebase esistenti e la creazione di soluzioni scalabili incentrate sugli aspetti tecnici, che possano essere adottate senza problemi dai team tecnici in tutta l'organizzazione.","security-its-more-than-culture-addressing-the-root-cause-of-common-security","content:it-it:the-source:security:security-its-more-than-culture-addressing-the-root-cause-of-common-security.yml","it-it/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security.yml","it-it/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security",{"_path":541,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"config":542,"seo":543,"content":546,"type":477,"category":28,"slug":554,"_id":555,"_type":30,"title":547,"_source":31,"_file":556,"_stem":557,"_extension":34,"date":529,"description":548,"timeToRead":495,"heroImage":545,"keyTakeaways":549,"articleBody":553},"/it-it/the-source/security/strengthen-your-cybersecurity-strategy-with-secure-by-design",{"layout":5,"template":460,"author":486,"featured":6,"sourceCTA":24,"isHighlighted":6,"authorName":442},{"title":544,"description":465,"ogImage":545},"Secure by Design nella strategia di sicurezza | GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463932/pnfdgovoaq5qd1yprxuc.png",{"title":547,"date":529,"description":548,"timeToRead":495,"heroImage":545,"keyTakeaways":549,"articleBody":553},"Rafforzare la strategia di sicurezza informatica con Secure by Design","Esamina meglio Secure by Design e i concetti correlati e scopri i passaggi che puoi intraprendere oggi per integrare la sicurezza nei tuoi processi di sviluppo software.",[550,551,552],"Secure by Design, Secure by Default e Secure by Demand prevengono vulnerabilità e attacchi alla catena di fornitura del software, spingendo i produttori a integrare la sicurezza in ogni aspetto della progettazione e sviluppo dei prodotti.","L'adozione di un approccio DevSecOps completo e la creazione e il mantenimento di distinte base software (SBOM) sono passaggi chiave per poter essere Secure by Design.","L'integrazione dell'intelligenza artificiale nel ciclo di sviluppo software può anche accelerare i processi di sviluppo, incrementare la sicurezza e aiutare a risolvere le vulnerabilità.","L'approccio di un'organizzazione alla sicurezza informatica deve evolversi costantemente man mano che le superfici di attacco si ampliano e che si hanno a disposizione ulteriori informazioni sulle potenziali minacce. Tenendo conto del fatto che le minacce possono entrare da qualsiasi punto della catena di fornitura del software, un approccio Secure by Design integra la sicurezza nelle fasi di progettazione, codifica, test e implementazione dello sviluppo software. Quale standard per le agenzie federali degli Stati Uniti e per qualsiasi organizzazione che tocchi il loro software, Secure by Design è diventato un benchmark di riferimento per integrare la sicurezza nel ciclo di sviluppo software.\n\nNel corso del tempo, Secure by Design si è ramificato in concetti correlati come _Secure by Default_ e _Secure by Demand_, che mettono in rilievo diversi modi di avvicinarsi a Secure by Design:\n\n- [Secure by Default](#what-is-secure-by-default) si concentra sul garantire che tutti i prodotti software siano sicuri fin da subito.\n- [Secure by Demand](#what-is-secure-by-demand) estende i principi Secure by Design al processo di approvvigionamento.\n\nEcco un'analisi più approfondita di Secure by Design e di questi approcci correlati, tra cui una [guida passo-passo](# building-a-secure-by-design-cybersecurity-strategy) su come le organizzazioni possono adattare le proprie strategie per prevenire vulnerabilità sfruttabili e attacchi alla catena di fornitura del software.\n\n## Cos'è Secure by Design?\nLa Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha introdotto la sua [Secure by Design Initiative](https://www.cisa.gov/securebydesign) nell'aprile 2023, concentrandosi su tre principi chiave di sicurezza del software:\n\n1. Assumersi la responsabilità dei risultati di sicurezza del cliente\n1. Adottare un atteggiamento di trasparenza e di responsabilità radicale\n1. Definire una struttura organizzativa e una leadership finalizzate al raggiungimento di questi obiettivi\n\nSecure by Design integra principi e protocolli di sicurezza in ogni fase del processo di sviluppo software. Di conseguenza, le misure di sicurezza sono integrate nelle fasi di progettazione, codifica, test e implementazione dello sviluppo software anziché essere aggiunte a valle.\n\nL'obiettivo di Secure by Design è creare una base sicura per il software fin dall'inizio, riducendo le vulnerabilità e le potenziali superfici di attacco.\n\n### Cos'è Secure by Default?\nSecure by Default è una derivazione di Secure by Design; l'obiettivo è quello di garantire la configurazione più sicura possibile per software o hardware, senza che sia necessaria la riconfigurazione da parte dell'utente. I prodotti Secure by Default abilitano automaticamente i controlli di sicurezza più importanti necessari per proteggere le aziende dall'accesso non autorizzato da parte di malintenzionati, senza che gli utenti debbano fare altro per garantire che un prodotto sia protetto dalle tecniche di sfruttamento prevalenti.\n\nLe tattiche Secure by Default includono l'eliminazione delle password predefinite e l'obbligo dell'autenticazione a più fattori e del Single Sign-On per consentire solo agli utenti autorizzati l'accesso alle risorse. Questo approccio include anche aggiornamenti e patch automatici, nonché configurazioni sicure per tutti gli account e i dispositivi dell'utente.\n\n### Cos'è Secure by Demand?\nSecure by Demand combina i principi Secure by Design con i contratti di budget e di approvvigionamento, per far sì che Secure by Design diventi un obbligo per i fornitori e gli appaltatori. [La guida a Secure by Demand della CISA](https://www.cisa.gov/resources-tools/resources/secure-demand-guide) fornisce una serie di domande e risorse che gli acquirenti, i buyer e i procacciatori di software possono utilizzare per comprendere meglio l'approccio di un potenziale fornitore alla sicurezza informatica, tra cui domande sulle pratiche di autenticazione del fornitore, sulla sicurezza della catena di fornitura del software e sulla divulgazione e la segnalazione delle vulnerabilità.\n\nRichiedendo ai fornitori di aderire ai principi e ai protocolli Secure by Design nei loro prodotti e servizi, le organizzazioni contribuiscono a prevenire potenziali vulnerabilità che entrano nella loro catena di fornitura del software. L'approccio Secure by Demand incentiva inoltre i fornitori a migliorare continuamente la propria posizione in materia di sicurezza informatica.\n\n## Costruire una strategia di sicurezza informatica Secure by Design\nLe organizzazioni che considerano prioritario l'approccio Secure by Design devono ad esempio utilizzare pratiche DevSecOps efficaci, mantenere una distinta base software (SBOM) e incorporare l'intelligenza artificiale per difendersi dalle minacce che entrano da qualsiasi punto del ciclo di sviluppo software.\n\n### Adottare pratiche DevSecOps\nUno dei primi passi per favorire l'adozione di un atteggiamento Secure by Design è seguire un processo di sviluppo software sicuro: sviluppo, creazione, protezione e implementazione del software devono basarsi su un approccio DevSecOps completo.\n\nOggi, molti sviluppatori utilizzano set di strumenti complessi per creare nuovi programmi. Un [recente sondaggio di GitLab](https://about.gitlab.com/developer-survey/) ha rilevato che il 62% degli intervistati utilizza 6 o più strumenti per lo sviluppo, mentre il 20% ne utilizza 11 o più: si tratta un'inefficienza che incrementa il rischio introducendo potenziali vulnerabilità della sicurezza.\n\nGli sviluppatori dovrebbero essere in grado di accedere a tutti gli strumenti necessari per i flussi di lavoro DevSecOps in un'unica interfaccia facile da usare. Con una soluzione end-to-end, come una [piattaforma DevSecOps](/platform/), le organizzazioni possono implementare un approccio Secure by Design senza aumentare l'onere per gli sviluppatori.\n\n### Creare e mantenere SBOM\nAdottare la trasparenza è un altro passaggio significativo verso il Secure by Design. Le organizzazioni devono capire cosa c'è nel loro software, soprattutto quando può includere componenti provenienti da più fonti.\n\n[Le SBOM sono strumenti essenziali per raggiungere questa trasparenza](https://about.gitlab.com/blog/the-ultimate-guide-to-sboms/). Offrono inventari dettagliati dei componenti software, inclusi i dettagli di versione, licenza e dipendenza, che consentono una maggiore consapevolezza delle potenziali vulnerabilità o del codice dannoso.\n\nIl mantenimento di questo inventario consente alle organizzazioni di comprendere appieno le possibili vulnerabilità e i potenziali rischi che potrebbero sorgere quando gli elementi vengono rimossi da repository open-source e componenti di terze parti concessi in licenza. Una piattaforma DevSecOps può aiutare a [generare e aggiornare automaticamente le SBOM](/solutions/security-compliance/), integrarle nei flussi di lavoro esistenti e collegarle alle vulnerabilità associate.\n\nMolte organizzazioni utilizzano già le SBOM, che però devono essere dinamiche, collegate a strumenti di analisi della sicurezza e continuamente aggiornate per essere pienamente efficaci. Quando integrate con strumenti di scansione e dashboard, le SBOM possono fornire un modo per individuare i rischi associati a un'applicazione. Anche quando non richiesto, le SBOM possono supportare la conformità alle normative convalidando la sicurezza del codice.\n\n### Utilizzo dell'IA nello sviluppo software\nMentre le organizzazioni scoprono come poter utilizzare l'IA, i flussi di lavoro di sviluppo del software forniscono un prezioso punto di ingresso alla tecnologia, che ha il potenziale per accelerare i processi di sviluppo e migliorare la sicurezza.\n\nLe organizzazioni di tutti i settori stanno già iniziando a esplorare queste applicazioni: il 39% degli intervistati [nel sondaggio di GitLab](https://about.gitlab.com/developer-survey/2024/ai/) ha dichiarato di utilizzare già l'intelligenza artificiale nel ciclo di sviluppo software.\n\nL'uso dell'intelligenza artificiale durante tutto il ciclo di sviluppo software può aiutare le organizzazioni a evitare silos e backlog relativi all'IA all'interno dei flussi di lavoro di sviluppo. L'IA può svolgere funzioni chiave come:\n\n* Spiegazione del codice e refactoring del codice legacy in [linguaggi sicuri per la memoria](https://about.gitlab.com/blog/memory-safe-vs-unsafe/)\n* [Analisi delle cause principali per le pipeline di DevSecOps](https://about.gitlab.com/blog/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/), che accelerano la soluzione di problemi complessi durante i test\n* [Risoluzione delle vulnerabilità](https://about.gitlab.com/it-it/the-source/ai/understand-and-resolve-vulnerabilities-with-ai-powered-gitlab-duo/) per contribuire a riconciliare le vulnerabilità note, supportando una correzione più approfondita\n\nMentre i leader integrano l'IA nei loro flussi di lavoro, è fondamentale dare priorità alla privacy e alla sicurezza dei dati. Un aspetto essenziale dell'adozione di un approccio Secure by Design è lo sviluppo di una [strategia di intelligenza artificiale che salvaguardi i dati sensibili e protegga i diritti di proprietà intellettuale](https://about.gitlab.com/the-source/ai/building-a-transparency-first-ai-strategy-7-questions-to-ask-your-devops/).\n\n### Cosa succederà\nSecure by Design potrebbe presto diventare l'approccio predefinito per creare un ecosistema software più affidabile. Il [governo degli Stati Uniti](https://about.gitlab.com/the-source/security/national-cybersecurity-strategy-a-wake-up-call-for-software-developers/) sta attualmente lavorando con gli sviluppatori di software alla creazione di framework che incentivino legalmente il settore privato a produrre e rilasciare software Secure by Design, spingendo le aziende a investire di più in tecnologie e pratiche sicure.\n\nGrazie alla sicurezza integrata fin dall'inizio nello sviluppo software, alla trasparenza offerta da SBOM efficaci e all'uso dell'intelligenza artificiale per migliorare il processo di sviluppo, chiunque contribuisca al ciclo di sviluppo software può contare su ottime premesse per il successo.","strengthen-your-cybersecurity-strategy-with-secure-by-design","content:it-it:the-source:security:strengthen-your-cybersecurity-strategy-with-secure-by-design.yml","it-it/the-source/security/strengthen-your-cybersecurity-strategy-with-secure-by-design.yml","it-it/the-source/security/strengthen-your-cybersecurity-strategy-with-secure-by-design",{"_path":559,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"config":560,"seo":562,"content":566,"type":477,"category":28,"slug":573,"_id":574,"_type":30,"title":563,"_source":31,"_file":575,"_stem":576,"_extension":34,"date":567,"description":564,"timeToRead":471,"heroImage":565,"keyTakeaways":568,"articleBody":572},"/it-it/the-source/security/how-gitlab-can-help-you-prepare-for-your-soc-2-exam",{"layout":5,"template":460,"author":561,"featured":6,"isHighlighted":6,"authorName":437},"gitlab",{"title":563,"description":564,"ogImage":565},"Come prepararsi all'audit SOC 2 grazie a GitLab","Scopri le funzionalità della piattaforma DevSecOps per l'audit del framework SOC2.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463759/yk7f6poowtw5y5d5oflv.png",{"title":563,"date":567,"description":564,"timeToRead":471,"heroImage":565,"keyTakeaways":568,"articleBody":572},"2024-07-18",[569,570,571],"I report automatizzati sui test e sulla copertura del codice migliorano la disponibilità e l'integrità dell'elaborazione di SOC 2.","Le analisi di sicurezza e i controlli basati sui ruoli di GitLab garantiscono la conformità con il framework SOC 2, proteggendo i dati da vulnerabilità e accessi non autorizzati.","I modelli di GitLab per il test delle prestazioni del carico e il browser semplificano l'audit SOC 2, convalidando le prestazioni e la sicurezza delle applicazioni in ogni fase dello sviluppo.","I clienti di GitLab hanno constatato che l'uso di GitLab quale piattaforma per DevSecOps ha semplificato il processo di audit SOC 2. Questo articolo presenta il framework SOC 2 e le funzionalità di GitLab che aiutano i clienti con l'audit SOC 2.\n\n## Introduzione a SOC 2\nIl System and Organization Controls 2, o [SOC 2](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/serviceorganization-smanagement), è uno standard di conformità volontario che descrive come le aziende devono gestire i dati dei clienti. Il report dell'audit SOC 2 attesta l'affidabilità di un software per i propri clienti.\n\nSOC 2, sviluppato dall'Association of International Certified Professional Accountants (AICPA), si basa su cinque criteri, i cosiddetti criteri dei servizi fiduciari:\n- Sicurezza: protezione dei dati dei clienti da vulnerabilità e accessi non autorizzati\n- Disponibilità: garanzia che i sistemi siano a tolleranza di errore e performanti in caso di carichi elevati, per soddisfare gli accordi sui livelli di servizio\n- Integrità dell'elaborazione: funzionamento dei sistemi come previsto, senza vulnerabilità, errori o bug\n- Riservatezza: protezione delle informazioni riservate come il codice sorgente dell'applicazione, i nomi utente e le password, i dati delle carte di credito ecc., così che siano accessibili solo a chi ne ha necessità per le proprie mansioni\n- Privacy: protezione delle informazioni sull'identità da utenti non autorizzati\n\nLa sicurezza è l'unico criterio richiesto per ogni audit SOC 2. Gli altri criteri possono essere aggiunti all'audit se sono ritenuti fondamentali per i servizi forniti.\n\n## Criterio di sicurezza dei servizi fiduciari\nIl criterio di sicurezza riguarda non solo la sicurezza dei server e dei sistemi fisici, ma anche delle applicazioni. Le vulnerabilità del software possono aprire un'applicazione a un attacco, mettendo a rischio i dati dei clienti, ma GitLab può aiutare a evitarlo.\n\nGitLab fornisce analisi di sicurezza per individuare possibili vulnerabilità nelle applicazioni sviluppate da un'azienda, tra cui:\n- [Analisi statica della sicurezza delle applicazioni (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/), che analizza il codice sorgente alla ricerca di possibili bug e vulnerabilità, come la non sicurezza del codice che può comportarne l'esecuzione involontaria\n- [Analisi delle dipendenze](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/), che trova vulnerabilità della sicurezza nelle dipendenze software di un'applicazione\n- [Scansione dei container](https://docs.gitlab.com/ee/user/application_security/container_scanning/), che rileva vulnerabilità della sicurezza nelle dipendenze del sistema operativo di un'applicazione containerizzata\n- [Analisi dinamica della sicurezza delle applicazioni (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/), che trova vulnerabilità della sicurezza in un'applicazione web in esecuzione che la rendono suscettibile a un attacco\n- [Analisi dell'Infrastructure as Code (IaC)](https://docs.gitlab.com/ee/user/application_security/iac_scanning/), che esegue l'analisi dei file di configurazione della IaC, tra cui Terraform, Ansible, AWS CloudFormation e Kubernetes, per trovare vulnerabilità della sicurezza\n\nGitLab fornisce anche un [report sulle vulnerabilità](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) che mostra tutte le vulnerabilità note nell'applicazione corrente, in base alle analisi eseguite. GitLab offre inoltre una distinta base del software ([SBOM](https://docs.gitlab.com/ee/user/application_security/dependency_list/)) in formato CycloneDX JSON standard, che mostra tutte le dipendenze a livello di software e sistema operativo e le loro vulnerabilità note.\n\nSvolgere analisi delle vulnerabilità regolarmente e avere un metodo affidabile per la loro segnalazione aiuta a soddisfare tre criteri di sicurezza:\n- CC7.1. Per raggiungere i propri obiettivi, l'entità usa procedure di rilevamento e monitoraggio per individuare (1) le modifiche alle configurazioni che introducono nuove vulnerabilità, e (2) le vulnerabilità scoperte di recente.\n- CC4.1. Principio COSO 16: l'entità seleziona, sviluppa ed esegue valutazioni continue e/o separate per accertare se le componenti del controllo interno sono presenti e funzionanti.\n- CC4.2. Principio COSO 17: l'entità valuta e comunica tempestivamente le carenze del controllo interno ai responsabili dell'adozione di azioni correttive, inclusi i dirigenti senior e il Consiglio di Amministrazione, a seconda dei casi.\n\nUn elemento cruciale delle analisi di sicurezza sono governance e adempimento. Le funzionalità di GitLab garantiscono analisi regolari, non eludibili dai team di sviluppo software. Esse includono:\n- [Controlli di accesso basati sui ruoli](https://docs.gitlab.com/ee/user/permissions.html), per limitare chi può apportare modifiche alle impostazioni di configurazione a livello di progetto\n- [Criteri di esecuzione dell'analisi](ttps://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html), per garantire che le scansioni vengano eseguite su ciascun repository di codice\n- [Criteri di approvazione delle richieste di merge](https://docs.gitlab.com/ee/user/application_security/policies/merge_request_approval_policies.html), per garantire che i risultati dell'analisi siano esaminati e approvati dai responsabili della sicurezza adatti, così che le vulnerabilità rilevate recentemente non siano introdotte nel software implementato\n- [Report sulla conformità](https://docs.gitlab.com/ee/user/application_security/), per mostrare eventuali modifiche alle configurazioni di GitLab che potrebbero violare i processi di sicurezza messi in atto\n\nCon queste configurazioni, le aziende possono dimostrare che la sicurezza del software è una priorità assoluta per le loro applicazioni e che le pratiche di sicurezza vengono applicate.\n\n## Criterio di disponibilità e integrità dell'elaborazione dei servizi fiduciari\nGitLab può anche aiutare con i criteri di disponibilità e integrità dell'elaborazione dei servizi fiduciari. Questi criteri hanno a che fare con la qualità e le prestazioni dell'applicazione stessa. Per supportarli, GitLab fornisce:\n- Risultati dei test unitari e modifiche alla copertura del codice sotto forma di [report sulla copertura del codice](https://docs.gitlab.com/ee/ci/testing/code_coverage.html), che garantiscono che il codice sorgente sia convalidato da una suite di test\n- [Qualità del codice](https://docs.gitlab.com/ee/ci/testing/code_quality.html), che analizza la qualità e la complessità del codice sorgente per facilitarne la leggibilità e l'aggiornabilità\n\nQueste pratiche vengono usate all'inizio del ciclo di sviluppo software per garantire un codice testato di alta qualità, ma GitLab fornisce anche modelli per vari tipi di test automatici delle applicazioni in esecuzione, per garantire il funzionamento previsto. Questi test includono:\n- [Test delle prestazioni del browser](https://docs.gitlab.com/ee/ci/testing/browser_performance_testing.html), che misura il tempo di caricamento dei siti web durante il ciclo di vita dello sviluppo, per testare l'impatto di eventuali modifiche del codice sulle prestazioni del browser\n- [Test delle prestazioni del carico](https://docs.gitlab.com/ee/ci/testing/load_performance_testing.html), che misura le prestazioni del sistema del back-end di un'applicazione durante il ciclo di vita dello sviluppo, per testare l'impatto di eventuali modifiche del codice sulle prestazioni\n- [Fuzzing orientato alla copertura](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/), che invia dati imprevisti, non validi o casuali a un'applicazione e quindi la monitora per rilevare comportamenti instabili e arresti anomali\n- [Fuzzing dell'API web](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/), che invia dati imprevisti, non validi o casuali agli endpoint dell'API per cercare bug e problemi di sicurezza\n\nUsando GitLab per applicare solide prassi DevSecOps e dare vita ad applicazioni sicure e di alta qualità, potrai superare più facilmente un audit SOC 2 e attestare la sicurezza dei dati dei clienti.\n\n> **Ulteriori informazioni:** [Rafforzare la sicurezza informatica](https://about.gitlab.com/the-source/security/strengthen-your-cybersecurity-strategy-with-secure-by-design/) con i principi Secure by Design.","how-gitlab-can-help-you-prepare-for-your-soc-2-exam","content:it-it:the-source:security:how-gitlab-can-help-you-prepare-for-your-soc-2-exam.yml","it-it/the-source/security/how-gitlab-can-help-you-prepare-for-your-soc-2-exam.yml","it-it/the-source/security/how-gitlab-can-help-you-prepare-for-your-soc-2-exam",{"_path":578,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"config":579,"seo":580,"content":585,"type":477,"category":28,"slug":593,"_id":594,"_type":30,"title":581,"_source":31,"_file":595,"_stem":596,"_extension":34,"date":586,"description":582,"timeToRead":587,"heroImage":583,"keyTakeaways":588,"articleBody":592},"/it-it/the-source/security/10-tips-to-prioritize-security-in-software-development",{"layout":5,"template":460,"author":561,"featured":6,"isHighlighted":6,"authorName":437},{"title":581,"description":582,"ogImage":583,"config":584},"10 consigli per mettere la sicurezza al primo posto nello sviluppo software","Segui questi suggerimenti per implementare la sicurezza fin dalle prime fasi del ciclo di sviluppo, per una maggiore efficienza e software più sicuri.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464607/pmqkaclogv0y5tf4hk3t.png",{"ignoreTitleCharLimit":329},{"title":581,"date":586,"description":582,"timeToRead":587,"heroImage":583,"keyTakeaways":588,"articleBody":592},"2024-04-16","2 minuti di lettura",[589,590,591],"Adottare l'approccio Shift Left migliora la sicurezza del software rilevando le vulnerabilità nelle prime fasi dell'SDLC.","GitLab integra la sicurezza nel DevSecOps per una gestione proattiva del rischio.","Ottimizza i processi con GitLab, per sviluppare software in modo più veloce e conforme.","Gli attacchi informatici e le minacce alla sicurezza continuano a essere una delle principali priorità per le organizzazioni. Ciò porta a una continua evoluzione del ruolo dello sviluppatore. Oltre la metà delle persone intervistate nel [Sondaggio globale DevSecOps 2024](https://about.gitlab.com/developer-survey/) di GitLab ha dichiarato di partecipare alla sicurezza delle applicazioni all'interno di un team più ampio, a conferma che le pratiche di sicurezza vengono implementate fin dalle fasi iniziali del ciclo di vita del software.\n\nQuesto approccio, che prende anche il nome di Shift Left e consiste nel progettare software che integri le best practice di sicurezza per rilevare e correggere le vulnerabilità in anticipo nel ciclo di sviluppo software (SDLC), consente ai team di operare in modo più efficiente e di rilasciare software più velocemente.\n\nSebbene il 67 % dei professionisti della sicurezza intervistati da GitLab abbia dichiarato di aver adottato un approccio Shift Left o preveda di farlo nei prossimi tre anni, molte persone potrebbero non sapere da dove iniziare.\n\nEcco 10 consigli per aiutare i tuoi team ad applicare la strategia Shift Left per una metodologia DevSecOps più efficiente:\n\n### 1. Calcola il tempo\n\nQuanto tempo dedica il tuo team a correggere le vulnerabilità dopo il merge del codice? Quantificalo e individua uno schema ripetitivo per quanto riguarda la natura o la causa di tali vulnerabilità, quindi intraprendi le misure necessarie per ridurre i problemi.\n\n### 2. Individua i colli di bottiglia\n\nQuali criticità e colli di bottiglia esistono tra i processi e i protocolli di sicurezza? Individuali e, successivamente, crea ed esegui un piano di risoluzione.\n\n### 3. Inizia con poco\n\nApporta piccole modifiche al codice: sono più facili da revisionare e proteggere, inoltre possono essere lanciate più rapidamente rispetto alle modifiche di progetto di grandi dimensioni.\n\n### 4. Di' addio all'approccio a cascata\n\nI tuoi team dipendono ancora da processi di sicurezza a cascata all'interno dell'SDLC? Abbandonare o ridurre questo approccio aiuterà la tua organizzazione ad affrontare meglio i cambiamenti di rotta a seconda delle esigenze che emergono.\n\n### 5. Automatizza le analisi\n\nI processi manuali stanno rallentando e ostacolando il rilevamento delle vulnerabilità? Automatizza i risultati che riguardano le vulnerabilità in una richiesta di merge affinché gli sviluppatori possano revisionarle più facilmente, trovarne l'origine e apportare le necessarie modifiche o correzioni.\n\n### 6. Aggiorna i flussi di lavoro\n\nIl flusso di lavoro degli sviluppatori include le analisi di sicurezza? Progettare e integrare la sicurezza nei flussi di lavoro degli sviluppatori consente loro di rilevare e correggere le vulnerabilità prima che il codice passi alla fase successiva.\n\n### 7. Dimostra la conformità\n\nIl lavoro non pianificato e non programmato sta ritardando le fasi di rilascio? Automatizzare e implementare framework di conformità aiuta a mantenere la coerenza tra ambienti di sviluppo, team e applicazioni.\n\n### 8. Fornisci agli sviluppatori report sulla sicurezza\n\nI tuoi sviluppatori hanno accesso ai report SAST e DAST? Questi preziosi strumenti aiutano i team di sviluppo a creare pratiche di programmazione sicure e a correggere le vulnerabilità come parte del loro flusso di lavoro.\n\n### 9. Permetti ai team di lavorare in modo più intelligente\n\nOffri al team di sicurezza la possibilità di lavorare in modo più intelligente mediante dashboard per la sicurezza che indicano le vulnerabilità sia risolte che non risolte, la loro ubicazione, chi le ha create e lo stato della correzione.\n\n### 10. Abbandona la toolchain\n\nSemplifica e riduci la tua toolchain in modo che i dipendenti possano avere una singola interfaccia come unica fonte di riferimento.\n\n## Adotta l'approccio Shift Left con GitLab\n\nGitLab ti aiuta ad avviare una strategia di sicurezza proattiva per rilevare le vulnerabilità fin dalle prime fasi dell'SDLC. La piattaforma DevSecOps di GitLab integra le funzionalità di sicurezza e conformità e offre un flusso di lavoro end-to-end che consente di comprendere e gestire il rischio. Analizza automaticamente le vulnerabilità di un ramo della funzionalità in modo da poterle correggere prima di eseguire il push in produzione.\n\nGitLab supporta da tempo le iniziative DevSecOps di agenzie, fornitori e istituti di istruzione federali, statali e locali degli Stati Uniti con una piattaforma di sviluppo software end-to-end che soddisfa rigorosi requisiti di sicurezza e conformità. Scopri di più su [come GitLab può aiutarti ad adottare un approccio Shift Left](https://about.gitlab.com/solutions/public-sector/) e a distribuire software sicuro più velocemente.","10-tips-to-prioritize-security-in-software-development","content:it-it:the-source:security:10-tips-to-prioritize-security-in-software-development.yml","it-it/the-source/security/10-tips-to-prioritize-security-in-software-development.yml","it-it/the-source/security/10-tips-to-prioritize-security-in-software-development",{"_path":598,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"slug":599,"type":477,"category":28,"config":600,"seo":602,"content":606,"_id":628,"_type":30,"title":608,"_source":31,"_file":629,"_stem":630,"_extension":34,"description":607,"heroImage":605,"date":609,"timeToRead":471,"keyTakeaways":610,"articleBody":614,"faq":615},"/it-it/the-source/security/how-to-implement-secret-management-best-practices-with-gitlab","how-to-implement-secret-management-best-practices-with-gitlab",{"layout":5,"template":460,"featured":6,"author":601,"isHighlighted":6,"authorName":441},"jlongo",{"description":603,"ogDescription":603,"title":604,"ogTitle":604,"ogImage":605,"noIndex":329},"La gestione dei segreti può essere un rischio per chi si occupa di conservare e proteggere dati. Scopri come migliorare i processi e la fiducia dei clienti.","Best practice per gestire i segreti con GitLab","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751463593/wgbh2snwpsyle9jom1k1.png",{"description":607,"title":608,"heroImage":605,"date":609,"timeToRead":471,"keyTakeaways":610,"articleBody":614,"faq":615},"Se poco efficaci, le procedure di gestione dei segreti rappresentano un rischio per le aziende che si occupano di conservare e proteggere i dati. Scopri come migliorare i tuoi processi e rafforzare la fiducia dei clienti.","Come implementare le best practice di gestione dei segreti con GitLab","2024-03-12T00:00:00.000Z",[611,612,613],"Una gestione inadeguata dei segreti può causare violazioni dei dati. L'integrazione nativa di GitLab migliora la sicurezza.","Una gestione dei segreti verificabile e basata sugli attributi consente ai team della sicurezza di monitorare le attività anomale o dannose e di intervenire rapidamente.","GitLab consente di gestire al meglio l'archiviazione e l'utilizzo dei segreti grazie a efficaci misure di controllo dell'accesso e a potenti strumenti di rilevamento.","Se inefficaci, le procedure di gestione dei segreti possono rappresentare un rischio importante per qualsiasi azienda, in particolare per quelle che hanno il compito di archiviare e proteggere i dati dei propri clienti. Si tratta di un problema comune e spesso al centro delle preoccupazioni di un'attività. Un segreto svelato può comportare una perdita di riservatezza e potenzialmente una violazione dei dati. Questo genere di incidenti rischia di provocare un ingente danno economico e di sfiduciare la clientela.\n\nNel caso di molte aziende, procedure di gestione dei segreti non sicure possono derivare dalla mancanza di competenze o da una scarsa conoscenza degli strumenti e delle strategie necessari per risolvere questo problema. D'altro canto, adottare procedure efficaci può aiutare un'organizzazione a mitigare i rischi e a consolidare le strategie di gestione dei segreti. In questo articolo parleremo delle best practice del settore, della capacità di GitLab di supportare tali procedure e di quale sia la nostra strategia per migliorare le funzionalità native delle piattaforme DevSecOps.\n\n## Sviluppare una strategia crittografica\n\nOgni attività necessita di una strategia crittografica per consentire agli sviluppatori di operare in modo standardizzato, affinché tutte le applicazioni e i loro componenti vengano progettati in conformità con i requisiti aziendali.\n\nComprendere i dati che necessitano di elaborazione, definire la tolleranza al rischio e delineare il panorama delle minacce aiuterà la tua azienda a sviluppare un'efficace strategia crittografica.\n\n### Generazione dei segreti\n\nI segreti, inclusi i token di accesso e le chiavi SSH, dovrebbero essere generati mediante dispositivi crittografici come i moduli di protezione hardware (HSM). Questi dispositivi consentono di generare segreti crittograficamente resilienti, archiviandoli in modo da renderli impervi a manomissioni e intrusioni.\n\nAffidarsi a dispositivi fisici può comportare una spesa economica non indifferente e rivelarsi proibitivo dal punto di vista delle operazioni, ragion per cui i principali fornitori di servizi cloud offrono servizi di Cloud HSM come [AWS CloudHSM](https://aws.amazon.com/cloudhsm/) e [GCP Cloud HSM](https://cloud.google.com/kms/docs/hsm).\n\n### Archiviazione dei segreti\n\nArchiviare i segreti è fondamentale tanto quanto generarli. I segreti generati devono essere memorizzati in modo sicuro e durevole, affinché gli utenti possano recuperarli e utilizzarli in assoluta sicurezza a seconda delle esigenze.\n\nI principali fornitori di servizi cloud e di sicurezza come [HashiCorp](https://www.vaultproject.io/) offrono strumenti basati su cloud per archiviare e recuperare i segreti in modo sicuro. Questi servizi consentono agli utenti di utilizzare i segreti all'interno dei loro processi e codici senza soluzione di continuità, eliminando così ogni necessità di hardcoding.\n\n#### In che modo GitLab supporta l'archiviazione dei segreti?\n\nGitLab fornisce supporto nativo per i seguenti [fornitori di servizi di gestione dei segreti](https://docs.gitlab.com/ee/ci/secrets/index.html):\n\n- Vault di HashiCorp\n- Secret Manager di Google Cloud\n- Azure Key Vault\n\nIntegrando GitLab con un fornitore di servizi di gestione dei segreti, questi ultimi vengono richiesti esplicitamente solo quando necessari a un job di CI. Al termine dell'operazione, le informazioni rimangono archiviate in modo sicuro nell'ambiente del fornitore, mitigando così i rischi di compromissione. Oltre al supporto nativo, GitLab offre un protocollo di [autenticazione OIDC](https://docs.gitlab.com/ee/ci/secrets/id_token_authentication.html) per la verifica dell'identità (ad esempio AWS Secret Manager). Si tratta di un metodo di archiviazione molto più sicuro rispetto alla memorizzazione e al [mascheramento](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable) dei segreti come variabili di CI/CD.\n\n### Utilizzo dei segreti\n\nI segreti dovrebbero essere usati per un unico scopo. Riutilizzarli in diverse applicazioni o servizi aumenta il potenziale di esposizione e le conseguenze in caso di violazione dei dati.\n\nPer ridurre il rischio di attività fraudolente, bisognerebbe adottare il [principio del privilegio minimo](https://about.gitlab.com/blog/2024/03/06/the-ultimate-guide-to-least-privilege-access-with-gitlab/). In altre parole, l'accesso dovrebbe essere concesso solo agli utenti o ai servizi che lo richiedono in quanto funzionale al loro lavoro o alle attività operative che svolgono.\n\n#### In che modo GitLab supporta l'utilizzo dei segreti?\n\nGitLab offre agli amministratori un efficace [modello di controllo dell'accesso basato sui ruoli](https://docs.gitlab.com/ee/user/permissions.html) e anche la possibilità di creare [ruoli personalizzati](https://docs.gitlab.com/ee/user/custom_roles.html), consentendo loro di allineare i profili di accesso ai propri standard organizzativi e di tolleranza al rischio.\n\nInoltre, GitLab consente agli utenti di eseguire il [rilevamento dei segreti](https://docs.gitlab.com/ee/user/application_security/secret_detection/) per verificare la presenza di informazioni sensibili e credenziali involontariamente compromesse. Gli utenti di GitLab Ultimate possono implementare [misure di contrasto automatizzate](https://docs.gitlab.com/ee/user/application_security/secret_detection/automatic_response/), come la revoca dei segreti, per stemperare le conseguenze.\n\n### Verificabilità\n\nL'accesso e l'utilizzo dei segreti devono essere verificabili e basati sugli attributi. In uno scenario ideale, gli utenti non dovrebbero poter visualizzare i segreti in un formato non criptato. Tuttavia, il flusso delle attività operative di un'azienda non sempre lo consente.\n\nUna gestione dei segreti verificabile e basata sugli attributi permette ai team della sicurezza di monitorare le attività anomale o dannose e di intervenire rapidamente attraverso misure dirette o automatizzate.\n\n#### In che modo GitLab supporta la verificabilità?\n\nGli [eventi di audit](https://docs.gitlab.com/ee/administration/audit_events.html) di GitLab acquisiscono attività relative a token e chiavi creati all'interno della piattaforma, tra cui:\n\n- Eventi correlati a token di accesso personale\n- Eventi correlati a token di deployment\n- Eventi correlati a token di agenti cluster\n\nQueste attività vengono salvate nel database e possono inoltre [essere analizzate in tempo reale](https://docs.gitlab.com/ee/administration/audit_event_streaming/) dai clienti di GitLab Ultimate.\n\n## In arrivo: GitLab Secret Manager\n\nGitLab lancerà un servizio nativo di gestione dei segreti alla fine del 2024. GitLab Secret Manager è una soluzione multi-tenant basata su cloud che sarà accessibile sia dal sito gitlab.com che ai clienti self-managed tramite il nostro Cloud Connector. Grazie a un'interfaccia intuitiva e coerente con quella attualmente utilizzata per le variabili di CI/CD, il nuovo servizio potrà essere integrato più facilmente rispetto ai prodotti di terzi parti. GitLab Secret Manager garantirà la sicurezza e la protezione delle informazioni sensibili nelle pipeline di integrazione continua. \n\n> Per ulteriori informazioni o domande su GitLab Secret Manager, accedi alla nostra [epic di MVC](https://gitlab.com/groups/gitlab-org/-/epics/10723) e lascia un commento.",[616,619,622,625],{"header":617,"content":618},"Cos'è la gestione dei segreti e perché è importante per la sicurezza del software?","La gestione dei segreti implica l'archiviazione, l'accesso e l'utilizzo in sicurezza di informazioni sensibili come chiavi API, token di accesso e password. Una procedura corretta consente di prevenire gli accessi non autorizzati, ridurre il rischio di violazioni dei dati e garantire la riservatezza e l'integrità delle informazioni sensibili nell'ambito dei processi di sviluppo e deployment del software.",{"header":620,"content":621},"In che modo GitLab supporta l'archiviazione e il recupero in sicurezza dei segreti?","GitLab si integra con i principali fornitori di servizi di gestione dei segreti, tra cui Vault di HashiCorp, Secret Manager di Google Cloud e Azure Key Vault. Queste integrazioni consentono di archiviare in modo sicuro i segreti e di recuperarli in modo esplicito solo quando necessari per i job di integrazione continua, riducendo in tal modo il rischio di esposizione e di accessi non autorizzati.",{"header":623,"content":624},"Quali sono le best practice per la generazione e l'utilizzo dei segreti?","- __Generazione dei segreti__: utilizza dispositivi crittografici come i moduli di protezione hardware (HSM) per generare segreti complessi. Servizi di Cloud HSM come AWS CloudHSM o GCP Cloud HSM offrono funzionalità economiche e a prova di manomissione.\n- __Utilizzo dei segreti__: implementa il principio del privilegio minimo, assicurandoti che i segreti vengano utilizzati per un unico scopo e che siano accessibili solo da utenti o servizi autorizzati. Evita di ricorrere all'hardcoding per ridurre al minimo l'esposizione.",{"header":626,"content":627},"In che modo GitLab supporta il rilevamento e la verificabilità dei segreti?","GitLab offre funzionalità di rilevamento dei segreti che permettono di verificare la presenza di informazioni riservate e credenziali di cui è stato inavvertitamente eseguito il commit. Gli amministratori possono affidarsi a misure di contrasto automatizzate, come la revoca dei segreti svelati, per ridurre al minimo i rischi per la sicurezza. Inoltre, gli eventi di auditing acquisiscono e trasmettono in tempo reale le attività correlate all'utilizzo di token e chiavi, consentendo di monitorare e rilevare costantemente le anomalie.","content:it-it:the-source:security:how-to-implement-secret-management-best-practices-with-gitlab.yml","it-it/the-source/security/how-to-implement-secret-management-best-practices-with-gitlab.yml","it-it/the-source/security/how-to-implement-secret-management-best-practices-with-gitlab",{"_path":632,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"config":633,"seo":635,"content":639,"type":477,"category":28,"slug":648,"_id":649,"_type":30,"title":640,"_source":31,"_file":650,"_stem":651,"_extension":34,"date":641,"description":637,"timeToRead":642,"heroImage":638,"keyTakeaways":643,"articleBody":647},"/it-it/the-source/security/enterprise-scale-security-and-compliance-policy-management-in-the-ai-era",{"layout":5,"template":460,"author":634,"featured":6,"isHighlighted":6,"authorName":438},"grant-hickman",{"title":636,"description":637,"ogImage":638},"Gestire sicurezza e conformità nell'era dell'IA | GitLab","La gestione dei criteri di sicurezza di GitLab contribuisce alla sicurezza e alla conformità per tenere il passo con lo sviluppo software.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464499/qriml3qncnibzphitcax.png",{"title":640,"date":641,"description":637,"timeToRead":642,"heroImage":638,"keyTakeaways":643,"articleBody":647},"Gestione dei criteri di sicurezza e conformità su scala aziendale nell'era dell'IA","2023-10-17","Tempo di lettura: 8 minuti",[644,645,646],"I team della sicurezza faticano a tenere il passo con lo sviluppo rapido dei software, intensificato dall'IA. La gestione efficace delle vulnerabilità è quindi fondamentale per garantire la sicurezza.","I criteri di sicurezza di GitLab automatizzano la conformità, promuovendo la collaborazione tra AppSec e i team di sviluppo per rilevare e correggere le vulnerabilità in modo efficiente.","Le tecniche di assegnazione della priorità come CVSS e il punteggio basato sul rischio aiutano a gestire le vulnerabilità, garantendo che l'attenzione sia posta sui problemi critici, date le crescenti vulnerabilità del codice generato dall'IA.","I team della sicurezza hanno difficoltà a tenere il passo con lo sviluppo software. Si trovano di fronte a una serie di problemi, ad esempio il fatto che la dirigenza trascura erroneamente l'importanza della sicurezza nel processo di sviluppo, e il rapporto tra sviluppatori ed esperti di sicurezza. E ora che l'IA è fra noi, il ritmo è ancora più rapido. La velocità di sviluppo non farà che aumentare, di pari passo con la crescita delle imprese. Per questo motivo gli strumenti di sicurezza usati per gestire i processi di sviluppo devono corrispondere a tale crescita.\n\nInoltre, i team di sicurezza delle applicazioni devono gestire e assegnare priorità alle vulnerabilità in modo efficace. Con i [criteri di sicurezza di GitLab](https://docs.gitlab.com/ee/user/application_security/policies/) e la nostra suite di strumenti di sicurezza, è possibile promuovere la collaborazione tra AppSec e i team di sviluppo, consentendo il rilevamento, la valutazione e la correzione efficiente delle vulnerabilità. I criteri di sicurezza offrono anche un meccanismo per automatizzare la conformità alla sicurezza e gestirla su scala aziendale.\n\nL'analisi di molteplici possibili fonti di vulnerabilità offre maggiori opportunità di rilevamento precoce e risoluzione dei ticket, ma l'enorme volume di risultati può sopraffare i team di AppSec. Individuare le soluzioni attuabili sta diventando sempre più difficile man mano che ulteriori analisi fanno emergere sempre più informazioni sulle vulnerabilità.\n\n## Processi di valutazione della gestione delle vulnerabilità\nOggi esistono alcuni approcci comuni per gestire la valutazione delle vulnerabilità:\n\n- **Common Vulnerability Scoring System:** il CVSS è un metodo standardizzato per valutare la gravità della vulnerabilità. Sfruttando i punteggi CVSS, è possibile assegnare priorità alle vulnerabilità in base al loro possibile impatto e allocare le risorse di conseguenza.\n\n- **Punteggio basato sul rischio:** consente di valutare le vulnerabilità in base alla probabilità di sfruttamento e al possibile impatto aziendale. Considerando i fattori contestuali, come il valore delle risorse, le capacità degli attori delle minacce e la prevalenza dello sfruttamento, è possibile assegnare priorità alle vulnerabilità.\n\n- **Modellazione delle minacce:** un approccio che comporta l'individuazione e la valutazione delle minacce potenziali di un'applicazione o un sistema. Effettuando un'analisi completa dell'architettura del sistema, del flusso di dati e dei possibili veicoli di attacco, è possibile assegnare priorità alle vulnerabilità in base al loro legame con probabili minacce. Questo approccio aiuta ad allocare le risorse in modo efficace, concentrandosi sulle vulnerabilità che hanno maggiori probabilità di essere sfruttate.\n\n- **Business Impact Analysis (BIA):** è una tecnica per valutare il potenziale impatto delle vulnerabilità sulle operazioni e sugli obiettivi aziendali. Comporta l'individuazione delle risorse critiche, la valutazione della loro importanza per l'azienda e la quantificazione delle possibili conseguenze di un attacco riuscito. Considerando il potenziale impatto finanziario, reputazionale e operativo, è possibile assegnare priorità alle vulnerabilità che comportano il rischio maggiore per le funzioni aziendali principali.\n\nMan mano che aumenta la proliferazione del codice generato dall'IA, aumenta anche il numero di vulnerabilità involontarie introdotte. Tecniche come queste sono quindi vitali per valutare e capire come assegnare le priorità. Come possiamo applicare questi quadri concettuali nel lavoro quotidiano? Scopriamo come metterli in pratica.\n\n## Gestione dei criteri di sicurezza\nI [criteri di sicurezza](https://docs.gitlab.com/ee/user/application_security/policies/) sono la risposta per scomporre i criteri aziendali e i requisiti di conformità in istruzioni operative tangibili, integrate nelle pratiche DevSecOps e nel ciclo di sviluppo software. Creando regole all'interno dei criteri di sicurezza di GitLab, è possibile definire criteri granulari per la valutazione delle vulnerabilità, assicurando che solo i risultati utili siano contrassegnati per un'ulteriore indagine.\n\nI criteri di sicurezza ti consentono di applicare i requisiti di sicurezza e conformità e le best practice, istanziandoli nel codice. [I criteri di esecuzione dell'analisi](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html) impongono l'esecuzione degli scanner all'interno di progetti specifici in base alle esigenze e ai requisiti, assicurando che eventuali vulnerabilità ed esposizioni siano rilevate prima di eseguire il merge del codice in produzione.\n\nÈ anche possibile sfruttare i [criteri di approvazione delle richieste di merge](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html) per creare flussi di lavoro personalizzati per risolvere le vulnerabilità. I criteri valutano i risultati dell'analisi di sicurezza e conformità per impedire o bloccare le richieste di merge, a meno che queste non siano state accuratamente revisionate e approvate in base alle regole definite.\n\nUsando i criteri di approvazione delle richieste di merge e i criteri di esecuzione dell'analisi, è possibile aggiungere un livello di supervisione al processo di sviluppo. Ciò può garantire che il codice scritto da esseri umani (o in altro modo) sia stato analizzato automaticamente e che le violazioni dei criteri incoraggino la collaborazione tra i reparti di engineering e AppSec dove è più utile.\n\n### Definizione di regole granulari nei criteri di approvazione delle richieste di merge\nPer fare un passo avanti ulteriore, è possibile definire regole granulari all'interno dei criteri di approvazione delle richieste di merge in base ai filtri e agli attributi indicati qui sotto. Queste regole possono aiutarti a determinare quali vulnerabilità sono più utili e a trovare un segnale nello static:\n\n- **Stato delle vulnerabilità:** i criteri di sicurezza possono essere affrontati in base allo stato di una vulnerabilità; spesso è utile concentrarsi su vulnerabilità appena rilevate che devono essere valutate. È anche possibile creare regole basate su vulnerabilità rilevate in precedenza con una determinata gravità o includere/escludere le vulnerabilità se sono state eliminate.\n\n- **Ramo:** le procedure vengono applicate solo su rami specifici, ad esempio il ramo predefinito dei progetti critici o eventuali rami protetti.\n\n- **Disponibilità della correzione:** i risultati vanno filtrati dai risultati dell'analisi delle dipendenze e dei container per cui non è disponibile una correzione. Spesso questi dipendono da cambiamenti a monte di terze parti e non sono ancora attuabili. È possibile creare ticket a partire dalle vulnerabilità e monitorali con una data di scadenza, per risolverli quando è disponibile una correzione.\n\n- **Falso positivo:** quando i nostri scanner GitLab determinano che una vulnerabilità rilevata è un falso positivo (per l'analisi di container e dipendenze), contrassegniamo lo stato all'interno della vulnerabilità. A questo punto, i criteri di sicurezza possono usare questa informazione per filtrare i falsi positivi, consentendo agli ingegneri e agli sviluppatori AppSec di ignorare questi risultati ed eseguire il merge del codice senza scoraggiarsi. Le vulnerabilità rimarranno disponibili nel report dedicato, per consentire un'analisi più approfondita se necessario.\n\n- **Maturità o contratto di servizio (SLA):** a volte le vulnerabilità di gravità inferiore possono essere tollerate per un certo periodo, ma devono essere pianificate e affrontate in un contratto di servizio ragionevole. Con i criteri di sicurezza, è possibile impostare uno SLA in base alla gravità dei risultati di vulnerabilità. Ad esempio, è possibile consentire il merge di vulnerabilità di livello intermedio senza richiedere l'approvazione per uno SLA di 60 giorni (che può essere affrontato in un ticket di follow-up con una data di scadenza). Ma se la vulnerabilità rilevata è superiore allo SLA di 60 giorni, bloccherà le richieste di merge e richiederà che venga affrontata.\n\n![security-policies-rules-ds-all-filters](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175811/Blog/k0bror5vmcosg8jm4zi1.png)\n\n### Assegnare priorità ai risultati critici in tutta l'azienda\nUn approccio comune per la gestione di grandi volumi di vulnerabilità è quello di iniziare in piccolo e dare priorità ai risultati più critici rilevati in tutta l'azienda. Uno SLA per la valutazione della gestione delle vulnerabilità può aiutare a raggiungere questo obiettivo, definendo regole per affrontare le vulnerabilità all'interno di un determinato SLA in base alla loro gravità. Ecco una rapida dimostrazione di come sfruttare un criterio di approvazione delle richieste merge di GitLab per applicare uno SLA diverso per ogni livello di gravità della vulnerabilità. In questo caso, se viene rilevato un risultato di gravità elevata, le richieste di merge non verranno bloccate per 30 giorni, dando agli sviluppatori il tempo di risolvere il ticket nella finestra dello SLA.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/cOsAaLXdV2k\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### Garantire la separazione delle mansioni\n\nI criteri di sicurezza possono essere gestiti in diversi modi, ma vengono gestiti meglio in un progetto GitLab isolato che garantisce la separazione delle mansioni tra i professionisti della sicurezza e i team di sviluppo. I criteri sono archiviati in YAML. Questo approccio \"policy as code\" offre più possibilità al team della sicurezza e ha molti vantaggi, tra cui maggiore visibilità grazie a una cronologia Git di tutte le modifiche ai criteri, la possibilità di eseguire più facilmente il rollback delle modifiche più importanti tramite il controllo della versione, la supervisione e le approvazioni richieste di tutte le modifiche ai criteri (se necessario), la verificabilità tramite eventi di controllo di GitLab e controlli concreti condivisibili come prove con gli auditor.\n\n![gitlab security-policies policy-yml](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175821/Blog/bqfig4ufupuitbarasuj.png)\n\n## Legare i diversi elementi\nLa gestione del crescente afflusso di vulnerabilità richiede un approccio di precisione, bilanciando un'analisi approfondita con valutazioni e correzioni efficienti. I criteri di sicurezza di GitLab sono una soluzione potente che consente la collaborazione, offre flessibilità nella definizione di criteri personalizzati e un mezzo per rendere operativi con precisione i requisiti aziendali e i framework di conformità. Sfruttando gli strumenti di sicurezza di GitLab e applicando filtri e attributi personalizzati, è possibile ottimizzare la gestione delle vulnerabilità e concentrarsi sui rischi più critici, migliorando in ultima analisi la security posture generale e soddisfacendo i requisiti di enti esterni. Nonostante i timori legati al codice generato dall'IA, rimangono validi i tre pilastri della sicurezza: persone, processi e tecnologia. Incorporando i criteri di sicurezza nei processi aziendali, è possibile proteggersi da questi rischi.\n\nOltre a usare i criteri di sicurezza per applicare l'approccio \"policy as code\" su larga scala, la piattaforma DevSecOps di GitLab offre una solida suite di strumenti di sicurezza. Nel nostro recente [Report globale 2023 sulla sicurezza](https://learn.gitlab.com/devsecops-survey-2023/), il 57% dei professionisti della sicurezza dichiara di usare sei o più strumenti per lo sviluppo del software e il 69% afferma di voler consolidare la propria toolchain. Molti responsabile della sicurezza informatica desiderano consolidare gli strumenti: GitLab può essere un valido aiuto per ridurre l'espansione incontrollata della toolchain. Infatti, GitLab offre le principali soluzioni per l'analisi di sicurezza: test statici di sicurezza delle applicazioni (anche per l'Infrastructure as Code), rilevamento dei segreti, test dinamici della sicurezza delle applicazioni (anche per le API), analisi delle dipendenze e sicurezza delle API. Permette inoltre ai team AppSec di gestire le vulnerabilità grazie a report dinamici. Infine, consente di completare le prassi di conformità con i framework di conformità, i report sul rispetto della conformità e gli eventi di audit.\n\nScopri di più su come gestire la [sicurezza delle applicazioni](https://docs.gitlab.com/ee/user/application_security/#use-security-scanning-tools-with-merge-request-pipelines) con GitLab.\n\n> **Prossimo articolo:** Josh Lemos, CISO di GitLab, spiega come [risolvere alcune comuni frustrazioni legate alla sicurezza](https://about.gitlab.com/the-source/security/security-its-more-than-culture-addressing-the-root-cause-of-common-security/).\n","enterprise-scale-security-and-compliance-policy-management-in-the-ai-era","content:it-it:the-source:security:enterprise-scale-security-and-compliance-policy-management-in-the-ai-era.yml","it-it/the-source/security/enterprise-scale-security-and-compliance-policy-management-in-the-ai-era.yml","it-it/the-source/security/enterprise-scale-security-and-compliance-policy-management-in-the-ai-era",{"_path":653,"_dir":28,"_draft":6,"_partial":6,"_locale":7,"config":654,"seo":656,"content":661,"type":477,"category":28,"slug":669,"_id":670,"_type":30,"title":657,"_source":31,"_file":671,"_stem":672,"_extension":34,"date":662,"description":658,"timeToRead":663,"heroImage":659,"keyTakeaways":664,"articleBody":668},"/it-it/the-source/security/how-to-strengthen-security-by-applying-devsecops-principles",{"layout":5,"template":460,"author":655,"featured":6,"isHighlighted":6,"authorName":447},"ncregan",{"title":657,"description":658,"ogImage":659,"config":660},"Come rafforzare la sicurezza applicando i principi del DevSecOps","Scopri l'efficacia dei principi del DevSecOps e come metterli subito in pratica.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1751464433/bdwagz0bt5bpgghjkout.png",{"ignoreTitleCharLimit":329},{"title":657,"date":662,"description":658,"timeToRead":663,"heroImage":659,"keyTakeaways":664,"articleBody":668},"2023-02-23","4 minuti di lettura",[665,666,667],"Il DevSecOps integra la sicurezza nell'SDLC, garantendo applicazioni sicure senza ritardi nella consegna.","L'automazione nel DevSecOps aumenta la sicurezza e ottimizza il rilevamento e la risposta alle minacce.","La collaborazione nel DevSecOps contribuisce a un approccio unificato per uno sviluppo software rapido e sicuro.","Seguendo i principi del DevSecOps, proteggi le applicazioni dai malintenzionati e offri valore in modo rapido ed efficiente. In questo articolo vedremo in modo approfondito i principi del DevSecOps e come offrano un approccio all'avanguardia nelle pratiche di sicurezza. Iniziamo subito.\n\n## Che cos'è il DevSecOps?\nIl [DevSecOps](/topics/devsecops/) è un approccio allo sviluppo software che combina i tre principi di sviluppo, sicurezza e operazioni. Consente ai team di creare un prodotto sicuro e affidabile offrendo valore in modo rapido ed efficiente. Una corretta adozione del DevSecOps implica la necessità di svolgere continuamente integrazione, automazione e test, con l'obiettivo di accelerare il time-to-market senza sacrificare la qualità o la sicurezza.\n\n## Panoramica dei principi del DevSecOps\nSeguendo i [principi del DevSecOps](/blog/4-must-know-devops-principles/), i team di sviluppo possono creare rapidamente applicazioni sicure e affidabili attraverso test di sicurezza radicati. Seguendo un approccio DevSecOps, la sicurezza viene integrata nel ciclo di sviluppo software (SDLC), dalla progettazione iniziale fino alla distribuzione e al deployment continui. Ciò aiuta a prevenire le violazioni della sicurezza di malintenzionati che sfruttano le vulnerabilità del sistema, e riduce il rischio complessivo di attacchi informatici.\n\nI principi del DevSecOps includono:\n\n### Automazione e integrazione\nAutomazione e integrazione sono componenti essenziali del DevSecOps. L'automazione dei processi di sicurezza aiuta a sviluppare applicazioni sicure e affidabili, riducendo il rischio di futuri attacchi. Le misure di sicurezza possono essere impostate ed eseguite in più punti durante il ciclo di sviluppo, per semplificare e massimizzare tali pratiche attraverso l'applicazione della sicurezza continua.\n\n### Distribuzione e deployment continui\nLa distribuzione e il deployment continui sono un altro processo che consente ai team di rispondere rapidamente a possibili minacce e di proteggere la catena di fornitura del software dai malintenzionati. [La distribuzione continua delle applicazioni tramite processi automatici](/blog/cd-solution-overview/) agevola uno sviluppo rapido di nuove funzionalità e prodotti, garantendo al contempo la sicurezza e la qualità delle applicazioni.\n\n### Un approccio collaborativo alla sicurezza\nLa sicurezza è una parte fondamentale del DevSecOps. Per garantire la sicurezza e l'affidabilità costanti delle applicazioni, serve [un approccio fortemente collaborativo](/topics/version-control/software-team-collaboration/) con controlli di sicurezza continui e multipli. Inoltre, tutti i soggetti del processo di sviluppo devono essere coinvolti nelle procedure di sicurezza.\n\nI team della sicurezza devono collaborare con gli sviluppatori per garantire che le applicazioni siano progettate con [controlli di sicurezza adatti](/topics/devsecops/devsecops-security-checklist/) e vulnerabilità della sicurezza minime. Allo stesso tempo, per un deployment e un monitoraggio sicuro delle applicazioni, i team delle operazioni devono collaborare con gli esperti di sicurezza.\n\n### Sicurezza in ogni fase dell'SDLC\nL'approccio alla sicurezza in ogni fase dell'SDLC garantisce lo sviluppo efficiente di applicazioni sicure senza sacrificare la qualità. È essenziale considerare tale approccio in [ogni fase del ciclo di vita](/blog/top-10-gitlab-hacks/), dalla progettazione allo sviluppo, fino al deployment.\n\nAffinché il processo sia efficace, gli sviluppatori devono progettare applicazioni con controlli di sicurezza adeguati, mentre i team operativi devono eseguirne deployment e monitoraggio in modo sicuro.\n\n### Monitoraggio proattivo e strategie di risposta\nLe strategie proattive di monitoraggio e risposta sono essenziali per garantire la sicurezza delle applicazioni per tutta la loro vita utile. Il [monitoraggio](/blog/working-with-performance-metrics/) si ottiene attraverso il deployment di strumenti automatizzati che individuano possibili vulnerabilità e avvisano i team quando si presentano.\n\nCiò consente di ridurre al minimo i rischi e di garantire coerenza in tutta l'azienda. Usare una strategia di risposta completa consente di individuare e risolvere i problemi prima che si trasformino in rischi per la sicurezza.\n\n## Vantaggi dell'implementazione del DevSecOps\nApplicare il DevSecOps offre numerosi vantaggi:\n1. Aiuta a creare fiducia tra i clienti fornendo applicazioni sicure.\n2. Impedisce ai malintenzionati di sfruttare le vulnerabilità e migliora la sicurezza dei sistemi.\n3. La metodologia DevSecOps consente ai team di offrire valore rapidamente, garantendo al contempo i massimi livelli di sicurezza.\n4. Integrando la sicurezza nella pipeline di sviluppo software, dalla progettazione al deployment, i team possono individuare e affrontare tempestivamente i possibili rischi, riducendo il rischio di attacchi dannosi.\n5. Il DevSecOps aiuta a stare al passo con le minacce potenziali e a rimanere competitivi nel mercato di riferimento.\n\n[Implementare un approccio DevSecOps](/blog/whats-next-for-devsecops/) è essenziale per chiunque voglia proteggere i sistemi da attacchi dannosi, offrendo valore in modo rapido ed efficiente. Inoltre, l'integrazione della sicurezza nell'SDLC garantisce che tutte le nuove applicazioni siano sicure fin dall'inizio. Instillare una cultura e un approccio DevSecOps massimizza l'efficienza e la qualità complessive del processo di sviluppo software.","how-to-strengthen-security-by-applying-devsecops-principles","content:it-it:the-source:security:how-to-strengthen-security-by-applying-devsecops-principles.yml","it-it/the-source/security/how-to-strengthen-security-by-applying-devsecops-principles.yml","it-it/the-source/security/how-to-strengthen-security-by-applying-devsecops-principles",[457,482,521,540,558,577],1759347829354]