# SEC 11. Come si incorporano e convalidano le proprietà di sicurezza delle applicazioni nell'intero ciclo di vita di progettazione, sviluppo e implementazione?
La formazione del personale, l'esecuzione di test tramite automazione, l'identificazione delle dipendenze e la convalida delle proprietà di sicurezza di strumenti e applicazioni riducono la probabilità del verificarsi di problemi di sicurezza nei carichi di lavoro di produzione.
**Topics**
+ [SEC11-BP01 Formazione per la sicurezza delle applicazioni](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md)
+ [SEC11-BP03 Esecuzione di test di penetrazione (pen-test) a intervalli regolari](sec_appsec_perform_regular_penetration_testing.md)
+ [SEC11-BP04 Revisioni manuali del codice](sec_appsec_manual_code_reviews.md)
+ [SEC11-BP05 Centralizzazione dei servizi per pacchetti e dipendenze](sec_appsec_centralize_services_for_packages_and_dependencies.md)
+ [SEC11-BP06 Implementazione programmatica del software](sec_appsec_deploy_software_programmatically.md)
+ [SEC11-BP07 Valutazione regolare delle proprietà di sicurezza delle pipeline](sec_appsec_regularly_assess_security_properties_of_pipelines.md)
+ [SEC11-BP08 Creazione di un programma per l'integrazione della titolarità della sicurezza nei team responsabili del carico di lavoro](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)
# SEC11-BP01 Formazione per la sicurezza delle applicazioni
Fornisci formazione sulle procedure comuni agli sviluppatori nell'organizzazione in modo da garantire la sicurezza dello sviluppo e del funzionamento delle applicazioni. L'adozione di procedure di sviluppo incentrate sulla sicurezza riduce la probabilità di riscontrare problemi solo nella fase di revisione della sicurezza.
**Risultato desiderato:** progettazione del software tenendo conto della sicurezza. Quando gli sviluppatori in un'organizzazione ricevono formazione su procedure di sviluppo sicure iniziando con un modello di rischio, la qualità e la sicurezza complessive del software prodotto sono migliori. Questo approccio può ridurre il tempo necessario per distribuire il software o le funzionalità, in quanto saranno necessarie meno correzioni dopo la fase di revisione della sicurezza.
Ai fini di questa best practice, il concetto di *sviluppo sicuro* si riferisce al software scritto e agli strumenti o ai sistemi che supportano il ciclo di vita di sviluppo del software.
**Anti-pattern comuni:**
+ Valutazione delle proprietà di sicurezza di un sistema solo in fase di revisione della sicurezza.
+ Assegnazione di tutte le decisioni in materia di sicurezza al team responsabile della sicurezza.
+ Mancata comunicazione della correlazione tra le decisioni adottate durante il ciclo di vita di sviluppo del software e le aspettative o policy complessive dell'organizzazione.
+ Svolgimento del processo di revisione della sicurezza in una fase troppo tardiva.
**Vantaggi dell'adozione di questa best practice:**
+ Migliore identificazione dei requisiti aziendali per la sicurezza all'inizio del ciclo di sviluppo.
+ Capacità di identificare e correggere più rapidamente possibili problemi di sicurezza, per una distribuzione più rapida delle funzionalità.
+ Migliore qualità del software e dei sistemi.
**Livello di rischio associato alla mancata adozione di questa best practice:** medio
## Guida all'implementazione
Fornisci formazione agli sviluppatori nell'organizzazione. Un corso iniziale sulla [modellazione delle minacce](https://catalog.workshops.aws/threatmodel/en-US) è un'ottima base per la formazione sulla sicurezza. Idealmente, gli sviluppatori devono poter accedere in modalità self-service a informazioni pertinenti ai propri carichi di lavoro. Questo accesso può aiutarli a prendere decisioni informate sulle proprietà di sicurezza dei sistemi sviluppati senza dover chiedere a un altro team. Il processo di coinvolgimento del team responsabile della sicurezza nelle revisioni deve essere definito chiaramente e facile da seguire. Le fasi del processo di revisione devono essere incluse nella formazione sulla sicurezza. Quando sono disponibili modelli o schemi di implementazione noti, devono essere facili da trovare e collegare ai requisiti complessivi per la sicurezza. Valuta se usare [AWS CloudFormation,](https://aws.amazon.com/cloudformation/) [costrutti del AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html), il [Service Catalog](https://aws.amazon.com/servicecatalog/) o altri strumenti di creazione di modelli per ridurre la necessità di configurazioni personalizzate.
### Passaggi dell'implementazione
+ Per iniziare, presenta agli sviluppatori un corso sulla [modellazione delle minacce](https://catalog.workshops.aws/threatmodel/en-US) per creare ottime basi e abituarli a riflettere sulla sicurezza.
+ Fornisci accesso a risorse di formazione [AWS Training and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult), per i diversi settori o per partner AWS.
+ Fornisci formazione sul processo di revisione della sicurezza dell'organizzazione, che spieghi la suddivisione delle responsabilità tra il team responsabile della sicurezza, i team del carico di lavoro e altri stakeholder.
+ Pubblica linee guida self-service su come soddisfare i requisiti di sicurezza, inclusi esempi e modelli di codice, se disponibili.
+ Richiedi regolarmente ai team di sviluppo feedback sull'esperienza durante il processo di revisione della sicurezza e la formazione correlata e usalo per migliorare le procedure.
+ Usa campagne di simulazione o bug bash per ridurre il numero di problemi e migliorare le competenze degli sviluppatori.
## Risorse
**Best practice correlate:**
+ [SEC11-BP08 Creazione di un programma per l'integrazione della titolarità della sicurezza nei team responsabili del carico di lavoro](sec_appsec_build_program_that_embeds_security_ownership_in_teams.md)
**Documenti correlati:**
+ [AWS Training and Certification](https://www.aws.training/LearningLibrary?query=&filters=Language%3A1%20Domain%3A27&from=0&size=15&sort=_score&trk=el_a134p000007C9OtAAK&trkCampaign=GLBL-FY21-TRAINCERT-800-Security&sc_channel=el&sc_campaign=GLBL-FY21-TRAINCERT-800-Security-Blog&sc_outcome=Training_and_Certification&sc_geo=mult)
+ [Come riflettere sulla governance della sicurezza nel cloud](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/)
+ [Come accostarsi alla modellazione delle minacce](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)
+ [Accelerazione della formazione – AWS Skills Guild](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/accelerating-training-the-aws-skills-guild.html)
**Video correlati:**
+ [Sicurezza proattiva: considerazioni e approcci](https://www.youtube.com/watch?v=CBrUE6Qwfag)
**Esempi correlati:**
+ [Workshop sulla modellazione delle minacce](https://catalog.workshops.aws/threatmodel)
+ [Industry awareness for developers](https://owasp.org/www-project-top-ten/)
**Servizi correlati:**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [Costrutti del AWS Cloud Development Kit (AWS CDK) (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/constructs.html)
+ [Service Catalog](https://aws.amazon.com/servicecatalog/)
+ [AWS BugBust](https://docs.aws.amazon.com/codeguru/latest/bugbust-ug/what-is-aws-bugbust.html)
# SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test
Automatizza i test per le proprietà di sicurezza lungo il ciclo di vita di sviluppo e test. L'automazione semplifica l'identificazione coerente e ripetibile dei potenziali problemi nel software prima del rilascio, riducendo il rischio di riscontrare problemi di sicurezza nel software fornito.
**Risultato desiderato: **l'obiettivo dei test automatici è fornire un metodo programmatico per rilevare inizialmente e regolarmente i potenziali problemi lungo l'intero ciclo di vita di sviluppo. Automatizzando i test di regressione, puoi ripetere l'esecuzione di test funzionali e non funzionali per verificare che il software testato in precedenza continui ad avere le prestazioni previste dopo una modifica. Quando definisci unit test di sicurezza per verificare la presenza di configurazioni errate comuni, come autorizzazioni non corrette o mancanti, puoi identificare e correggere i problemi all'inizio del processo di sviluppo.
Per l'automazione dei test vengono usati test case dedicati per la convalida delle applicazioni, in base ai requisiti e alle funzionalità desiderate. Il risultato dei test automatici è basato sul confronto dell'output di test generato con quello previsto, che accelera l'intero ciclo di vita dei test. Metodologie di test come i test di regressione e le suite di unit test sono le più adatte per l'automazione. L'automazione dei test delle proprietà di sicurezza permette agli sviluppatori di ricevere automaticamente feedback senza attendere una revisione della sicurezza. I test automatici sotto forma di analisi statica o dinamica del codice possono migliorare la qualità del codice e semplificare il rilevamento dei potenziali problemi software all'inizio del ciclo di vita di sviluppo.
**Anti-pattern comuni:**
+ Mancata comunicazione dei test case e dei risultati dei test automatici.
+ Esecuzione dei test solo immediatamente prima di un rilascio.
+ Automazione dei test case con requisiti che cambiano spesso.
+ Assenza di linee guida su come gestire i risultati dei test di sicurezza.
**Vantaggi dell'adozione di questa best practice:**
+ Riduzione della dipendenza da valutazioni personali delle proprietà di sicurezza dei sistemi.
+ Migliore coerenza grazie a risultati uniformi tra più flussi di lavoro.
+ Minore probabilità di introdurre problemi di sicurezza nel software di produzione.
+ Intervallo di tempo più breve tra il rilevamento e la correzione grazie all'identificazione più tempestiva dei problemi software.
+ Maggiore visibilità su comportamenti sistematici o ripetuti tra più flussi di lavoro, che può essere usata per favorire miglioramenti in tutta l'organizzazione.
**Livello di rischio associato alla mancata adozione di questa best practice: **medio
## Guida all'implementazione
Durante lo sviluppo del software, adotta diversi meccanismi di test in modo da avere la certezza di testare l'applicazione per requisiti funzionali, basati sulla logica di business, e non funzionali, incentrati sull'affidabilità, sulle prestazioni e sulla sicurezza dell'applicazione.
I test di sicurezza statici dell'applicazione analizzano il codice sorgente in cerca di modelli di sicurezza anomali e forniscono indicazioni per un codice privo di errori. I test di sicurezza statici dell'applicazione si basano su input statici, come la documentazione (definizione dei requisiti, documentazione sulla progettazione e specifiche di progettazione) e il codice sorgente dell'applicazione, per testare un'ampia gamma di problemi di sicurezza noti. Gli analizzatori di codice statici possono contribuire ad accelerare l'analisi di volumi elevati di codice. Il [NIST Quality Group](https://www.nist.gov/itl/ssd/software-quality-group) offre un confronto tra gli [analizzatori della sicurezza del codice sorgente](https://www.nist.gov/itl/ssd/software-quality-group/source-code-security-analyzers), con strumenti open source per la [scansione del codice byte](https://samate.nist.gov/index.php/Byte_Code_Scanners.html) e la [scansione del codice binario](https://samate.nist.gov/index.php/Binary_Code_Scanners.html).
Integra i test statici con metodologie di test della sicurezza tramite analisi dinamica, che eseguono test sull'applicazione in esecuzione per identificare potenziali comportamenti imprevisti. I test dinamici possono essere usati per individuare potenziali problemi non rilevabili tramite l'analisi statica. L'esecuzione di test nelle fasi di repository, compilazione e pipeline del codice permette di verificare potenziali problemi di tipi diversi, evitandone la presenza nel codice. [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) fornisce suggerimenti per il codice, tra cui analisi della sicurezza, nell'ambiente di sviluppo integrato (IDE) dello sviluppatore. Il [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) può identificare problemi critici e di sicurezza e bug difficili da individuare durante lo sviluppo delle applicazioni e fornisce suggerimenti per migliorare la qualità del codice.
Il [workshop sulla sicurezza per gli sviluppatori](https://catalog.workshops.aws/sec4devs) usa strumenti di sviluppo AWS come [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodeCommit](https://aws.amazon.com/codecommit/) e[AWS CodePipeline](https://aws.amazon.com/codepipeline/) per l'automazione della pipeline di rilascio, che include metodologie di test tramite analisi statiche e dinamiche.
Lungo il ciclo di vita di sviluppo del software definisci un processo iterativo che includa revisioni periodiche dell'applicazione con il team responsabile della sicurezza. Il feedback raccolto da queste revisioni della sicurezza deve essere affrontato e convalidato come parte della revisione dell'idoneità per il rilascio. Queste revisioni permettono di stabilire una solida posizione di sicurezza per l'applicazione e forniscono agli sviluppatori feedback di utilità pratica per affrontare i potenziali problemi.
### Passaggi dell'implementazione
+ Implementa un ambiente IDE, una revisione del codice e strumenti CI/CD coerenti che includano test di sicurezza.
+ Determina le fasi del ciclo di vita di sviluppo del software in cui è appropriato bloccare le pipeline anziché informare semplicemente gli sviluppatori riguardo alla necessità di risolvere i problemi.
+ Il [workshop sulla sicurezza per gli sviluppatori](https://catalog.workshops.aws/sec4devs) fornisce un esempio di integrazione di test statici e dinamici in una pipeline di rilascio.
+ L'esecuzione di test o di analisi del codice tramite strumenti automatici, come [Amazon CodeWhisperer](https://aws.amazon.com/codewhisperer/) integrato con gli ambienti IDE degli sviluppatori e il [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) per l'analisi del codice in fase di commit, permette agli sviluppatori di ottenere feedback tempestivo.
+ Se sviluppi soluzioni usando AWS Lambda, puoi usare [Amazon Inspector](https://aws.amazon.com/about-aws/whats-new/2023/02/code-scans-lambda-functions-amazon-inspector-preview/) per analizzare il codice dell'applicazione nelle funzioni.
+ Il [workshop sull'integrazione continua e sulla distribuzione continua in AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/) fornisce un punto di partenza per la creazione di pipeline CI/CD in AWS.
+ Quando le pipeline CI/CD includono test automatici, devi usare un sistema di gestione dei ticket per tenere traccia della notifica e della correzione dei problemi software.
+ Per test di sicurezza che possono generare risultati, il collegamento a linee guida per la correzione permette agli sviluppatori di migliorare la qualità del codice.
+ Analizza regolarmente i risultati ottenuti dagli strumenti automatici per definire le priorità delle successive iniziative di automazione, formazione degli sviluppatori o creazione di campagne di sensibilizzazione.
## Risorse
**Documenti correlati:**
+ [Distribuzione e implementazione continue](https://aws.amazon.com/devops/continuous-delivery/)
+ [Partner con competenze in AWS DevOps](https://aws.amazon.com/devops/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=partner-type%23technology&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-location=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&awsm.page-partner-solutions-cards=1)
+ [Partner con competenze nella sicurezza AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=use-case%23app-security&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc) per la sicurezza delle applicazioni
+ [Scelta di un approccio CI/CD Well-Architected](https://aws.amazon.com/blogs/devops/choosing-well-architected-ci-cd-open-source-software-aws-services/)
+ [Monitoraggio di eventi CodeCommit in Amazon EventBridge e Amazon CloudWatch Events](https://docs.aws.amazon.com/codecommit/latest/userguide/monitoring-events.html)
+ [Rilevamento dei segreti nel revisore Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/recommendations.html#secrets-detection)
+ [Accelerazione delle implementazioni su AWS con una governance efficace](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/)
+ [Approccio di AWS all'automazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
**Video correlati:**
+ [Informazioni pratiche: automazione di pipeline di distribuzione continua in Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [Automazione di pipeline CI/CD tra account](https://www.youtube.com/watch?v=AF-pSRSGNks)
**Esempi correlati:**
+ [Industry awareness for developers](https://owasp.org/www-project-top-ten/)
+ [AWS CodePipeline Governance](https://github.com/awslabs/aws-codepipeline-governance) (GitHub)
+ [Workshop sulla sicurezza per gli sviluppatori](https://catalog.us-east-1.prod.workshops.aws/workshops/66275888-6bab-4872-8c6e-ed2fe132a362/en-US)
+ [Workshop sull'integrazione continua e sulla distribuzione continua in AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/)
# SEC11-BP03 Esecuzione di test di penetrazione (pen-test) a intervalli regolari
Esegui regolarmente test di penetrazione (pen-test) sul software. Questo meccanismo permette di identificare i potenziali problemi che non possono essere rilevati tramite test automatici o la revisione manuale del codice. Può anche aiutarti a determinare l'efficacia dei controlli di rilevamento. I test di penetrazione (pen-test) devono determinare se il software può funzionare in modi imprevisti, ad esempio esponendo dati che devono essere protetti o concedendo autorizzazioni più elevate del previsto.
**Risultato desiderato:** uso di test di penetrazione (pen-test) per rilevare, correggere e convalidare le proprietà di sicurezza dell'applicazione. È necessario eseguire test di penetrazione (pen-test) regolari e pianificati come parte del ciclo di vita di sviluppo del software. I risultati ottenuti dai test di penetrazione (pen-test) devono essere affrontati prima del rilascio del software. Devi analizzare i risultati dei test di penetrazione (pen-test) per identificare se vi siano problemi che possono essere identificati con l'automazione. Un processo di esecuzione di test di penetrazione (pen-test) regolare e ripetibile che includa un meccanismo di feedback attivo aiuta a stabilire linee guida per gli sviluppatori e migliora la qualità del software.
**Anti-pattern comuni:**
+ Esecuzione di test di penetrazione (pen-test) solo per problemi di sicurezza noti o comuni.
+ Esecuzione di test di penetrazione (pen-test) delle applicazioni senza gli strumenti e le librerie di terze parti dipendenti.
+ Esecuzione di test di penetrazione (pen-test) solo per i problemi di sicurezza relativi ai pacchetti, senza valutare la logica di business implementata.
**Vantaggi dell'adozione di questa best practice:**
+ Maggiore certezza riguardo alle proprietà di sicurezza del software prima del rilascio.
+ Opportunità di identificare i modelli comportamentali preferiti delle applicazioni, per una migliore qualità del software.
+ Presenza di un ciclo di feedback che identifica all'inizio del ciclo di sviluppo i punti in cui l'automazione o una formazione aggiuntiva possono migliorare le proprietà di sicurezza del software.
**Livello di rischio associato alla mancata adozione di questa best practice: ** elevato
## Guida all'implementazione
I test di penetrazione (pen-test) sono un esercizio strutturato per l'esecuzione di test di sicurezza in cui vengono eseguiti scenari di violazione della sicurezza pianificati per rilevare, correggere e convalidare i controlli di sicurezza. I test di penetrazione (pen-test) iniziano dalla ricognizione, durante la quale vengono raccolti dati in base all'attuale progettazione dell'applicazione e alle sue dipendenze. Viene creato ed eseguito un elenco selezionato di scenari di test specifici per la sicurezza. Lo scopo principale di questi test è rivelare i problemi di sicurezza nell'applicazione che potrebbero essere sfruttati per ottenere accesso accidentale all'ambiente o accesso non autorizzato ai dati. Devi eseguire test di penetrazione (pen-test) quando avvii nuove funzionalità o ogni volta che l'applicazione viene sottoposta a modifiche importanti durante l'implementazione tecnica o di funzioni.
Devi identificare la fase più appropriata del ciclo di vita di sviluppo in cui eseguire i test di penetrazione (pen-test). Questi test devono essere eseguiti nelle fasi finali, in modo che la funzionalità del sistema sia vicina allo stato di rilascio previsto, ma con tempo sufficiente per la correzione di eventuali problemi.
### Passaggi dell'implementazione
+ Prepara un processo strutturato per definire l'ambito dei test di penetrazione (pen-test). Un ottimo metodo per mantenere il contesto consiste nel basare questo processo sul [modello di rischio](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/).
+ Identifica la fase più appropriata del ciclo di vita di sviluppo in cui eseguire test di penetrazione (pen-test). Questi devono avvenire quando sono previste modifiche minime nell'applicazione, ma quando vi è ancora tempo sufficiente per apportare eventuali correzioni.
+ Prepara gli sviluppatori su cosa aspettarsi dai risultati dei test di penetrazione (pen-test) e su come ottenere informazioni sulla correzione.
+ Usa strumenti per accelerare il processo di esecuzione dei test di penetrazione (pen-test) automatizzando test comuni o ripetibili.
+ Analizza i risultati dei test di penetrazione (pen-test) per identificare problemi di sicurezza sistematici e usa questi dati per definire altri test automatici e formazione continua per gli sviluppatori.
## Risorse
**Best practice correlate:**
+ [SEC11-BP01 Formazione per la sicurezza delle applicazioni](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documenti correlati:**
+ La pagina [Test di penetrazione (pen-test) AWS](https://aws.amazon.com/security/penetration-testing/) fornisce linee guida dettagliate per l'esecuzione di test di penetrazione (pen-test) in AWS
+ [Accelerazione delle implementazioni su AWS con una governance efficace](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/)
+ [Partner con competenze nella sicurezza AWS](https://aws.amazon.com/security/partner-solutions/?blog-posts-cards.sort-by=item.additionalFields.createdDate&blog-posts-cards.sort-order=desc&partner-solutions-cards.sort-by=item.additionalFields.partnerNameLower&partner-solutions-cards.sort-order=asc&awsf.partner-solutions-filter-partner-type=*all&awsf.Filter%20Name%3A%20partner-solutions-filter-partner-categories=*all&awsf.partner-solutions-filter-partner-location=*all&partner-case-studies-cards.sort-by=item.additionalFields.sortDate&partner-case-studies-cards.sort-order=desc&events-master-partner-webinars.sort-by=item.additionalFields.startDateTime&events-master-partner-webinars.sort-order=asc)
+ [Modernizzazione dell'architettura dei test di penetrazione (pen-test) su AWS Fargate](https://aws.amazon.com/blogs/architecture/modernize-your-penetration-testing-architecture-on-aws-fargate/)
+ [Simulatore di iniezione guasti AWS](https://aws.amazon.com/fis/)
**Esempi correlati:**
+ [Automate API testing with AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-codebuild-with-postman) (GitHub)
+ [Automated security helper](https://github.com/aws-samples/automated-security-helper) (GitHub)
# SEC11-BP04 Revisioni manuali del codice
Esegui una revisione manuale del codice del software che produci. Attraverso questo processo puoi assicurarti che chi ha scritto il codice non sia l'unica persona a controllarne la qualità.
**Risultato desiderato:** l'aggiunta di una fase di revisione manuale del codice durante lo sviluppo migliora la qualità del software scritto, permette di affinare le competenze dei membri meno esperti del team e fornisce un'opportunità per identificare i punti in cui può essere usata l'automazione. Le revisioni manuali del codice possono essere supportate da strumenti e test automatici.
**Anti-pattern comuni:**
+ Non viene eseguita alcuna revisione del codice prima dell'implementazione.
+ La scrittura e la revisione del codice vengono effettuate dalla stessa persona.
+ Non viene usata l'automazione per semplificare o orchestrare le revisioni del codice.
+ Gli sviluppatori non ricevono formazione sulla sicurezza dell'applicazione prima di eseguire la revisione del codice.
**Vantaggi dell'adozione di questa best practice:**
+ Migliore qualità del codice.
+ Maggiore coerenza dello sviluppo del codice attraverso il riutilizzo di approcci comuni.
+ Riduzione del numero di problemi riscontrati durante i test di penetrazione e nelle fasi successive.
+ Migliore circolazione delle informazioni all'interno del team.
**Livello di rischio associato alla mancata adozione di questa best practice:** medio
## Guida all'implementazione
La fase di revisione deve essere implementata come parte del flusso complessivo di gestione del codice. Le specifiche dipendono dall'approccio usato per la diramazione, le richieste pull e l'unione. Puoi usare AWS CodeCommit o soluzioni di terze parti come GitHub, GitLab o Bitbucket. Qualunque sia il metodo usato, è importante verificare che i processi richiedano la revisione del codice prima che venga implementato in un ambiente di produzione. L'uso di strumenti come il [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) può semplificare l'orchestrazione del processo di revisione del codice.
### Passaggi dell'implementazione
+ Implementa una fase di revisione manuale come parte del flusso di gestione del codice ed esegui la revisione prima di continuare.
+ Prendi in considerazione il [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) per la gestione e la semplificazione delle revisioni del codice.
+ Implementa un flusso di approvazione che richieda il completamento di una revisione prima che il codice possa passare alla fase successiva.
+ Verifica che sia stato definito un processo per identificare i problemi riscontrati durante le revisioni manuali del codice che potrebbero essere rilevati automaticamente.
+ Integra la fase di revisione manuale del codice in modo che sia allineata alla procedure di sviluppo del codice.
## Risorse
**Best practice correlate:**
+ [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documenti correlati:**
+ [Uso di richieste pull in repository AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/pull-requests.html)
+ [Uso di modelli per le regole di approvazione in AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/approval-rule-templates.html)
+ [GitHub: About pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
+ [Automazione delle revisioni del codice con il Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [Automazione del rilevamento di bug e vulnerabilità della sicurezza in pipeline CI/CD usando l'interfaccia della riga di comando del Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automating-detection-of-security-vulnerabilities-and-bugs-in-ci-cd-pipelines-using-amazon-codeguru-reviewer-cli/)
**Video correlati:**
+ [Miglioramento continuo della qualità del codice con Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw)
**Esempi correlati:**
+ [Workshop sulla sicurezza per gli sviluppatori](https://catalog.workshops.aws/sec4devs)
# SEC11-BP05 Centralizzazione dei servizi per pacchetti e dipendenze
Fornisci servizi centralizzati per permettere ai team di sviluppo di ottenere pacchetti software e altre dipendenze. Questo approccio permette la convalida dei pacchetti prima di includerli nel software scritto e fornisce un'origine dati per l'analisi del software usato nell'organizzazione.
**Risultato desiderato:** il software include una serie di altri pacchetti software oltre al codice scritto. In questo modo, è più facile utilizzare implementazioni di funzionalità usate ripetutamente, come un parser JSON o una libreria di crittografia. La centralizzazione logica delle origini per questi pacchetti e dipendenze fornisce un meccanismo tramite il quale i team responsabili della sicurezza possono convalidare le proprietà dei pacchetti prima che vengano usati. Questo approccio riduce anche il rischio di un problema imprevisto causato da una modifica in un pacchetto esistente o dall'aggiunta da parte dei team di sviluppo di pacchetti arbitrari direttamente da Internet. Usa questo approccio insieme ai flussi di test manuali e automatici per garantire ulteriormente la qualità del software sviluppato.
**Anti-pattern comuni:**
+ Recupero di pacchetti da repository arbitrari su Internet.
+ Mancata esecuzione di test sui nuovi pacchetti prima di renderli disponibili agli sviluppatori.
**Vantaggi dell'adozione di questa best practice:**
+ Migliore comprensione dei pacchetti usati nel software sviluppato.
+ Capacità di informare i team responsabili del carico di lavoro quando un pacchetto deve essere aggiornato in base alle informazioni su chi usa cosa.
+ Minor rischio di includere nel software un pacchetto con problemi.
**Livello di rischio associato alla mancata adozione di questa best practice: **medio
## Guida all'implementazione
Fornisci servizi centralizzati per i pacchetti e le dipendenze in modo da semplificarne l'uso per gli sviluppatori. La centralizzazione dei servizi può essere eseguita in modo logico anziché implementarli come sistema monolitico. Questo approccio permette di fornire servizi in modo da soddisfare le esigenze degli sviluppatori. Ti consigliamo di implementare un metodo efficiente per aggiungere pacchetti al repository quando sono necessari aggiornamenti o emergono nuovi requisiti. Servizi AWS come [AWS CodeArtifact](https://aws.amazon.com/codeartifact/) o soluzioni simili di partner AWS forniscono alcuni strumenti utili per questo scopo.
### Passaggi dell'implementazione:
+ Implementa un servizio di repository centralizzato in modo logico che sia disponibile in tutti gli ambienti in cui viene sviluppato il software.
+ Includi l'accesso al repository come parte del processo di provisioning automatico dell'Account AWS.
+ Crea automazione per testare i pacchetti prima che vengano pubblicati in un repository.
+ Gestisci le metriche dei pacchetti, dei linguaggi e dei team usati più comunemente e con la maggiore quantità di modifiche.
+ Offri ai team di sviluppo un meccanismo automatico per richiedere nuovi pacchetti e fornire feedback.
+ Analizza regolarmente i pacchetti nel repository per identificare il possibile impatto di nuovi problemi riscontrati.
## Risorse
**Best practice correlate:**
+ [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documenti correlati:**
+ [Accelerazione delle implementazioni su AWS con una governance efficace](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/)
+ [Potenziamento della sicurezza dei pacchetti con il toolkit per il controllo delle origini dei pacchetti CodeArtifact](https://aws.amazon.com/blogs/devops/tighten-your-package-security-with-codeartifact-package-origin-control-toolkit/)
+ [Rilevamento dei problemi di sicurezza nella registrazione con il Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/detecting-security-issues-in-logging-with-amazon-codeguru-reviewer/)
+ [Supply chain Levels for Software Artifacts (SLSA)](https://slsa.dev/)
**Video correlati:**
+ [Sicurezza proattiva: considerazioni e approcci](https://www.youtube.com/watch?v=CBrUE6Qwfag)
+ [La filosofia di AWS per la sicurezza (re:Invent 2017)](https://www.youtube.com/watch?v=KJiCfPXOW-U)
+ [Quando sicurezza, protezione e urgenza sono tutte importanti: gestione di Log4Shell](https://www.youtube.com/watch?v=pkPkm7W6rGg)
**Esempi correlati:**
+ [Multi Region Package Publishing Pipeline](https://github.com/aws-samples/multi-region-python-package-publishing-pipeline) (GitHub)
+ [Publishing Node.js Modules on AWS CodeArtifact using AWS CodePipeline](https://github.com/aws-samples/aws-codepipeline-publish-nodejs-modules) (GitHub)
+ [AWS CDK Java CodeArtifact Pipeline Sample](https://github.com/aws-samples/aws-cdk-codeartifact-pipeline-sample) (GitHub)
+ [Distribute private .NET NuGet packages with AWS CodeArtifact](https://github.com/aws-samples/aws-codeartifact-nuget-dotnet-pipelines) (GitHub)
# SEC11-BP06 Implementazione programmatica del software
Esegui implementazioni programmatiche del software laddove possibile. Questo approccio riduce la probabilità che un'implementazione non riesca o che si verifichi un problema imprevisto a causa dell'errore umano.
**Risultato desiderato: **un intervento minimo sui dati da parte delle persone è un principio chiave dello sviluppo sicuro nel Cloud AWS. Questo principio include anche il modo in cui viene implementato il software.
I vantaggi legati alla scelta di non affidare a persone l'implementazione del software è la migliore garanzia che la soluzione implementata sia esattamente identica a quella testata e che l'implementazione verrà eseguita in modo coerente ogni volta. Il software non deve essere modificato in modo da funzionare in ambienti diversi. Usando i principi dello sviluppo di applicazioni a dodici fattori, in particolare l'esternalizzazione della configurazione, puoi implementare lo stesso codice in più ambienti senza richiedere modifiche. La firma crittografica dei pacchetti software è un ottimo metodo per verificare che non vengano apportate modifiche tra ambienti. Il risultato complessivo di questo approccio è la riduzione dei rischi nel processo di modifica e il miglioramento della coerenza delle versioni del software.
**Anti-pattern comuni:**
+ Implementazione manuale del software nell'ambiente di produzione.
+ Applicazione manuale di modifiche al software per soddisfare i requisiti di ambienti diversi.
**Vantaggi dell'adozione di questa best practice:**
+ Maggiore affidabilità del processo di rilascio del software.
+ Riduzione dei rischi legati a modifiche errate che hanno impatto sulla funzionalità aziendale.
+ Processi di rilascio più frequenti grazie a un rischio di modifica minimo.
+ Funzionalità di ripristino automatico dello stato precedente in caso di eventi imprevisti durante l'implementazione.
+ Possibilità di usare la crittografia per dimostrare che il software implementato è esattamente identico a quello testato.
**Livello di rischio associato alla mancata adozione di questa best practice:** elevato
## Guida all'implementazione
Crea la struttura di Account AWS per eliminare l'accesso umano frequente dagli ambienti e usa strumenti CI/CD per eseguire le implementazioni. Progetta le applicazioni in modo da ottenere i dati di configurazione specifici dell'ambiente da un'origine esterna, ad esempio l'[Archivio dei parametri AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html). Firma i pacchetti dopo che vengono testati e convalida le firme durante l'implementazione. Configura le pipeline CI/CD per il push del codice delle applicazioni e usa valori Canary per confermare la corretta esecuzione dell'implementazione. Usa strumenti come [AWS CloudFormation](https://aws.amazon.com/cloudformation/) o il [AWS CDK](https://aws.amazon.com/cdk/) per definire l'infrastruttura, quindi [AWS CodeBuild](https://aws.amazon.com/codebuild/) e [AWS CodePipeline](https://aws.amazon.com/codepipeline/) per eseguire operazioni CI/CD.
### Passaggi dell'implementazione
+ Crea pipeline CI/CD ben definite per semplificare il processo di implementazione.
+ L'uso di [AWS CodeBuild](https://aws.amazon.com/codebuild/) e [AWS Code Pipeline](https://aws.amazon.com/codepipeline/) per fornire funzionalità CI/CD semplifica l'integrazione di test di sicurezza nelle pipeline.
+ Segui le linee guida sulla separazione degli ambienti nel whitepaper sull'[organizzazione dell'ambiente AWS usando più account](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html).
+ Verifica che non si verifichi accesso umano frequente agli ambienti in cui sono in esecuzione carichi di lavoro di produzione.
+ Progetta le applicazioni in modo che supportino l'esternalizzazione dei dati di configurazione.
+ Valuta se eseguire l'implementazione usando un modello di implementazione blu/verde.
+ Implementa valori Canary per convalidare la corretta implementazione del software.
+ Usa strumenti di crittografia come [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) o [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) per firmare e verificare i pacchetti software implementati.
## Risorse
**Best practice correlate:**
+ [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documenti correlati:**
+ [Workshop sull'integrazione continua e sulla distribuzione continua in AWS](https://catalog.us-east-1.prod.workshops.aws/workshops/ef1c179d-8097-4f34-8dc3-0e9eb381b6eb/en-US/)
+ [Accelerazione delle implementazioni su AWS con una governance efficace](https://aws.amazon.com/blogs/architecture/accelerate-deployments-on-aws-with-effective-governance/)
+ [Automazione di implementazioni pratiche e sicure](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Firma del codice usando l'Autorità privata per la gestione del certificato AWS (ACM CA privata/ACM PCA) e chiavi asimmetriche AWS Key Management Service](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/)
+ [Firma del codice, un controllo di attendibilità e integrità per AWS Lambda](https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/)
**Video correlati:**
+ [Informazioni pratiche: automazione di pipeline di distribuzione continua in Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
**Esempi correlati:**
+ [Implementazioni blu/verde con AWS Fargate](https://catalog.us-east-1.prod.workshops.aws/workshops/954a35ee-c878-4c22-93ce-b30b25918d89/en-US)
# SEC11-BP07 Valutazione regolare delle proprietà di sicurezza delle pipeline
Applica i principi della sicurezza Well-Architected alle pipeline, con particolare attenzione alla separazione delle autorizzazioni. Valuta regolarmente le proprietà di sicurezza dell'infrastruttura di pipeline. Una gestione efficace della sicurezza *delle* pipeline assicura la protezione del software che passa *attraverso* le pipeline.
**Risultato desiderato: **le pipeline usate per sviluppare e implementare il software devono seguire le stesse procedure consigliate di qualsiasi altro carico di lavoro nell'ambiente. I test implementati nelle pipeline non devono essere modificabili dagli sviluppatori che li usano. Le pipeline devono avere solo le autorizzazioni necessarie per le implementazioni eseguite e devono applicare misure di protezione per evitare l'implementazione negli ambienti errati. Le pipeline non devono basarsi su credenziali a lungo termine e devono essere configurate in modo da emettere lo stato, per permettere la convalida dell'integrità degli ambienti di sviluppo.
**Anti-pattern comuni:**
+ Test di sicurezza che possono essere ignorati dagli sviluppatori.
+ Autorizzazioni eccessivamente elevate per le pipeline di implementazione.
+ Pipeline non configurate per la convalida degli input.
+ Nessuna revisione periodica delle autorizzazioni associate all'infrastruttura CI/CD.
+ Uso di credenziali a lungo termine o hardcoded.
**Vantaggi dell'adozione di questa best practice:**
+ Maggiore garanzia di integrità del software sviluppato e implementato attraverso le pipeline.
+ Possibilità di arrestare un'implementazione in caso di attività sospetta.
**Livello di rischio associato alla mancata adozione di questa best practice:** elevato
## Guida all'implementazione
Iniziando con servizi CI/CD gestiti che supportano ruoli IAM, puoi ridurre il rischio di perdita di credenziali. L'applicazione dei principi della sicurezza all'infrastruttura di pipeline CI/CD può aiutarti a determinare i punti in cui apportare miglioramenti per la sicurezza. Un ottimo punto di partenza per la creazione degli ambienti CI/CD è l'[architettura di riferimento per le pipeline di implementazione AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/). La revisione periodica dell'implementazione delle pipeline e l'analisi dei log per identificare comportamenti imprevisti può semplificare la comprensione dei modelli di utilizzo delle pipeline usate per implementare il software.
### Passaggi dell'implementazione
+ Inizia dall'[architettura di riferimento per le pipeline di implementazione AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/).
+ Valuta se usare il [AWS IAM Access Analyzer](https://docs.aws.amazon.com//latest/UserGuide/what-is-access-analyzer.html) per generare in modo programmatico policy IAM con privilegi minimi per le pipeline.
+ Integra le pipeline con monitoraggio e generazione di avvisi in modo da ricevere notifiche in caso di attività imprevista o anomala, in quanto [Amazon EventBridge](https://aws.amazon.com/eventbridge/) per servizi gestiti AWS permette di instradare dati a destinazioni come [AWS Lambda](https://aws.amazon.com/lambda/) o [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS).
## Risorse
**Documenti correlati:**
+ [Architettura di riferimento per pipeline di implementazione AWS](https://aws.amazon.com/blogs/aws/new_deployment_pipelines_reference_architecture_and_-reference_implementations/)
+ [Monitoraggio di AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html)
+ [Best practice per la sicurezza per AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/security-best-practices.html)
**Esempi correlati:**
+ [DevOps monitoring dashboard](https://github.com/aws-solutions/aws-devops-monitoring-dashboard) (GitHub)
# SEC11-BP08 Creazione di un programma per l'integrazione della titolarità della sicurezza nei team responsabili del carico di lavoro
Crea un programma o un meccanismo che permetta ai team di sviluppo di prendere decisioni sulla sicurezza del software che creano. Il team responsabile della sicurezza dovrà convalidare queste decisioni durante una revisione, ma l'integrazione della titolarità della sicurezza nei team di sviluppo permette di creare carichi di lavoro più veloci e sicuri. Questo meccanismo promuove anche una cultura della responsabilità che ha un impatto positivo sul funzionamento dei sistemi che crei.
**Risultato desiderato: **per integrare la titolarità della sicurezza e il processo decisionale nei team di sviluppo, puoi insegnare agli sviluppatori come riflettere sulla sicurezza o puoi migliorarne la formazione attraverso l'integrazione o l'associazione di responsabili della sicurezza nei team di sviluppo. Entrambi gli approcci sono validi e permettono al team di prendere decisioni di qualità migliore sulla sicurezza nelle fasi iniziali del ciclo di sviluppo. Questo modello di titolarità è basato sulla formazione per la sicurezza delle applicazioni. Iniziando dal modello di rischio per il carico di lavoro specifico, puoi concentrarti sul design thinking nel contesto appropriato. Un altro vantaggio della presenza di una comunità di sviluppatori attenti alla sicurezza o di un gruppo di tecnici della sicurezza che collabora con i team di sviluppo è la possibilità di comprendere a pieno il modo in cui è compilato il codice. Questa comprensione permette di determinare le aree di miglioramento successive per l'automazione.
**Anti-pattern comuni:**
+ Assegnazione di tutte le decisioni in materia di sicurezza al team responsabile della sicurezza.
+ Gestione dei requisiti di sicurezza in fasi tardive del processo di sviluppo.
+ Assenza di feedback di sviluppatori e responsabili della sicurezza sul funzionamento del programma.
**Vantaggi dell'adozione di questa best practice:**
+ Riduzione del tempo necessario per completare le revisioni della sicurezza.
+ Riduzione dei problemi di sicurezza rilevati solo in fase di revisione della sicurezza.
+ Miglioramento della qualità complessiva del software scritto.
+ Opportunità di identificare e comprendere i problemi sistematici o le aree di miglioramento a valore elevato.
+ Riduzione della quantità di attività di correzione dovute ai risultati delle revisioni della sicurezza.
+ Migliore percezione della funzione della sicurezza.
**Livello di rischio associato alla mancata adozione di questa best practice:** basso
## Guida all'implementazione
Per iniziare, segui le linee guida fornite in [SEC11-BP01 Formazione per la sicurezza delle applicazioni](sec_appsec_train_for_application_security.md). Identifica quindi il modello operativo per il programma che ritieni più efficace per l'organizzazione. I due modelli principali consistono nel formare gli sviluppatori o nell'integrare responsabili della sicurezza nei team di sviluppo. Una volta scelto l'approccio iniziale, devi eseguire un progetto pilota con un singolo team o un piccolo gruppo di team del carico di lavoro per dimostrare il funzionamento del modello per l'organizzazione. Il supporto autorevole da parte dello sviluppatore e di altre parti responsabili della sicurezza dell'organizzazione semplifica l'implementazione e il successo del programma. Durante la creazione del programma è importante scegliere metriche da usare per dimostrarne il valore. Per un'ottima esperienza formativa, puoi documentarti sul modo in cui AWS ha affrontato questo problema. Questa best practice è per lo più incentrata sulla trasformazione e sulla cultura aziendali. Gli strumenti usati devono supportare la collaborazione tra lo sviluppatore e le comunità responsabili della sicurezza.
### Passaggi dell'implementazione
+ Per iniziare, fornisci formazione sulla sicurezza delle applicazioni agli sviluppatori.
+ Crea una comunità e un programma di onboarding per preparare gli sviluppatori.
+ Scegli un nome per il programma. Alcuni termini comunemente usati sono Responsabilità, Supporto o Promozione.
+ Identifica il modello da usare: formazione per gli sviluppatori, integrazione di tecnici della sicurezza o ruoli di sicurezza per affinità.
+ Identifica alcuni sponsor del progetto tra responsabili della sicurezza, sviluppatori e altri gruppi potenzialmente rilevanti.
+ Tieni traccia delle metriche per il numero di persone coinvolte nel programma, il tempo impiegato per le revisioni e il feedback ottenuto da sviluppatori e responsabili della sicurezza. Usa queste metriche per apportare miglioramenti.
## Risorse
**Best practice correlate:**
+ [SEC11-BP01 Formazione per la sicurezza delle applicazioni](sec_appsec_train_for_application_security.md)
+ [SEC11-BP02 Automazione dei test lungo il ciclo di vita di sviluppo e test](sec_appsec_automate_testing_throughout_lifecycle.md)
**Documenti correlati:**
+ [Come accostarsi alla modellazione delle minacce](https://aws.amazon.com/blogs/security/how-to-approach-threat-modeling/)
+ [Come riflettere sulla governance della sicurezza nel cloud](https://aws.amazon.com/blogs/security/how-to-think-about-cloud-security-governance/)
**Video correlati:**
+ [Sicurezza proattiva: considerazioni e approcci](https://www.youtube.com/watch?v=CBrUE6Qwfag)