Visualizzazione post con etichetta Qualità del software. Mostra tutti i post
Visualizzazione post con etichetta Qualità del software. Mostra tutti i post

martedì 3 marzo 2026

Sviluppo software, intelligenza artificiale e sicurezza

Roberto Piazzolla e Alessandro Vallega, il 12 gennaio 2026, hanno tenuto un webinar per il Clusit dal titolo "Vibe coding: programmare con l'AI, tra opportunità e rischi": https://clusit.it/blog/webinar-vibe-coding-programmare-con-lai-tra-opportunita-e-rischi/

Purtroppo è disponibile solo agli iscritti al Clusit. 

Posso dire che hanno parlato dei problemi di sicurezza del codice sviluppato con il supporto dell'IA.

Non mi dilungo oltre perché il contenuto è decisamente tecnico. Però posso riportare alcune raccomandazioni:

  • bisogna formare i programmatori sulla sicurezza e i limiti dell'IA; inutile (e sbagliato) vietarla;
  • se si usa il vibe coding, ossia si delega all'IA lo sviluppo o parte di esso, il lavoro si sposta sulla fase di test, funzionale e di sicurezza, e quindi il processo di sviluppo deve essere adattato (anche tecnologicamente, per esempio usando un'IA anche per i test);
  • i possibili errori dell'IA implicano la necessità di segregare gli ambienti di sviluppo, test e produzione,
  • effetto psicologico 1, sindrome dell'impostore: i programmatori si impauriscono quando vedono che l'IA, in alcuni casi, fa meglio di loro; ma questo solitamente succede a quelli bravi, quindi, se uno ha paura, vuol dire che è bravo e non deve aver paura;
  • effetto psicologico 2, sindrome di Dunning-Kruger: i programmatori pensano di essere più bravi di quello che sono perché aiutati dall'IA; questo solitamente succede a quelli non bravi, quindi va prestata molta attenzione al fatto che potrebbero non controllare correttamente;
  • effetto psicologico 3: il programmatore potrebbe non essere più soddisfatto dal proprio lavoro, visto che l'IA fa le cose divertenti (risolvere problemi), e poi, senza più la dopamina scatenata dalla gioia di risolvere problemi, potrebbe lavorare male e questo va affrontato.

sabato 4 gennaio 2025

European accessibility act (EAA)

Franco Vincenzo Ferrari mi ha segnalato questo articolo dal titolo "Con l’European accessibility act (EAA) l’accessibilità digitale dei prodotti e dei servizi diventa comune per tutti gli Stati UE": https://www.associazionecittadinanzadigitale.org/2024/12/28/con-leuropean-accessibility-act-eaa-laccessibilita-digitale-dei-prodotti-e-dei-servizi-diventa-comune-per-tutti-gli-stati-ue/.

Della Direttiva UE 882 del 2019 e del suo recepimento con il D. Lgs. 82 del 2022 avevo già scritto (https://blog.cesaregallotti.it/2024/04/european-accessibility-act-d-lgs-82-del.html), ma questo articolo ci ricorda la scadenza del 28 giugno e richiama meglio alcune cose.

martedì 23 aprile 2024

European Accessibility Act: D. Lgs. 82 del 2022

Claudio Nasti di Chantecler mi ha segnalato che è stato approvato, ormai diverso tempo fa, il D. Lgs. 82 del 2022, di recepimento del European Accessibility Act (Direttiva europea 882 del 2019), con requisiti di accessibilità dei prodotti e dei servizi.

Questo D. Lgs. estende quanto previsto dalla Legge Stanca (L. 4 del 2004) a diversi prodotti e servizi. Tali prodotti e servizi devono quindi assicurare l'accessibilità a persone con disabilità.

Il link al D. Lgs. 82 del 2022 da Normattiva: https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2022-05-27;82!vig=2024-04-23.

Un articolo che mi sembra utile per iniziare a capire: https://scuderimottaeavvocati.it/accessibility-act-verso-uneuropa-piu-inclusiva/.

La pagina AgID sull'accessibilità: https://www.agid.gov.it/it/design-servizi/accessibilita.

Un punto importante, a mio avviso, riguarda i siti di e-commerce. Infatti anche questi devono rispettare la normativa dal 28 giugno 2025. Però, se ho capito correttamente, per i siti già attivi, l'adeguamento va assicurato dal 28 giugno 2030.

Vanno comunque analizzati i servizi e prodotti che devono rispettare la normativa.

domenica 21 agosto 2022

Linee guida di design per i siti internet e i servizi digitali della PA

Franco Vincenzo Ferrari mi ha segnalato la pubblicazione delle "Linee guida di design per i siti internet e i servizi digitali della PA". La notizia è qui:
- https://www.agid.gov.it/it/agenzia/stampa-e-comunicazione/notizie/2022/07/27/pubblicate-linee-guida-design-i-siti-internet-i-servizi-digitali-pa?s=03.

Particolarmente significativi sono le linee guida stesse (https://docs.italia.it/italia/design/lg-design-servizi-web/it/versione-corrente/index.html) e il Manuale operativo di design (dove non appare alcun paragrafo dedicato alla sicurezza, ahimè).

Le linee guida sono molto ad alto livello e per quanto riguarda la privacy e la sicurezza ripropongono requisiti generali.

Insomma: è opportuno sapere che esistono, ma non mi sembrano significative.

giovedì 7 luglio 2022

Accessibilità anche dai privati

Franco Vincenzo Ferrari di DNV mi ha segnalato questo articolo dal titolo "Linee guida AgID per l'accessibilità dei siti web: i nuovi obblighi per le grandi aziende":
- https://www.agendadigitale.eu/cittadinanza-digitale/linee-guida-agid-per-laccessibilita-dei-siti-web-i-nuovi-obblighi-per-le-grandi-aziende/.

Così ho scoperto che, con il DL 76/2020, la Legge 4/2004 (Legge Stanca sull'accessibilità) è stata estesa anche le grandi imprese, e non solo la PA, "a garantire a persone con disabilità l'accessibilità dei propri servizi, erogati tramite siti web o applicazioni".

Alla pagina https://www.agid.gov.it/it/linee-guida è possibile scaricare le "Linee guida sull'accessibilità degli strumenti informatici – Per i soggetti erogatori di cui all'art 3 comma 1-bis della legge n. 4/2004". Purtroppo la pagina le riporta come "Linee guida" e basta e bisogna avere un po' di fantasia per trovarle.

Le linee guida non si applicano al solo web, ma ai documenti che sono incorporati nelle pagine web e che sono utilizzati nella rappresentazione o che sono destinati a essere rappresentati insieme alla pagina web in cui sono incorporati, alle web app, al software incorporato nelle pagine web e utilizzato nella rappresentazione o destinato alla rappresentazione insieme alla pagina web in cui è incorporato.

Mi sembra una bella iniziativa, anche se comporterà investimenti per alcune aziende. Penso che anche le altre aziende dovrebbero seguire queste linee guida, anche adottandole con minor fretta.

martedì 12 novembre 2019

Stato delle assicurazioni GDPR in Europa

Pierfrancesco Maistrello mi ha segnalato questo schema che indica la possibilità di assicurarsi rispetto alle multe del GDPR:
- https://www.dlapiper.com/de/austria/insights/publications/2019/07/updated-guide-on-the-insurability-of-gdpr-fines-across-europe/.

Lo studio completo è disponibile dietro registrazione e mi sembra curioso, visto che si parla di privacy. Comunque ho deciso di non registrarmi e quindi di non leggere il rapporto completo. Infatti l'Italia appare come Paese in cui non sono disponibili assicurazioni per multe da GDPR, ma mi sembra che qualche cosa sia invece stato sviluppato. Forse il rapporto completo riporta qualche indicazione in più.

venerdì 30 agosto 2019

Progettare l'accessibilità dei servizi IT - Poster

Da un tweet di Daniela Quetti, riporto le sue parole: "segnalo questi bellissimi poster che vanno oltre l'accessibilità definita per legge; dovrebbero essere appesi in qualsiasi luogo in cui si progettano servizi digitali":
- https://ukhomeoffice.github.io/accessibility-posters/.

Io non tratto solo di sicurezza, ma anche di qualità e di gestione dei servizi IT e quindi questa segnalazione non è assolutamente fuori tema. Però voglio ricordare che anche chi si occupa di sicurezza deve pensare all'accessibilità anche nella sua accezione più vasta (che potrei denominare con "comodità"), visto che uno dei principi della sicurezza è il KISS: "keep it simple (and stupid)".

domenica 16 settembre 2018

Ampliata la Legge accessibilità alle app

E' stato pubblicato il D. Lgs. 106 del 2018 dal titolo "Riforma dell'attuazione della direttiva (UE) 2016/2102 relativa all'accessibilità dei siti web e delle applicazioni mobili degli enti pubblici":
- www.gazzettaufficiale.it/eli/id/2018/09/11/18G00133/sg.

Modifica la Legge 4 del 2004 sull'accessibilità agli strumenti informatici da parte delle persone con disabilità. La estende ai siti web e alle applicazioni mobili degli enti pubblici.

Mi pare una bella cosa (anche se non avevo capito che la precedente Legge non includeva i siti web).

martedì 4 settembre 2018

EN 301 549 sull'accessibilità

Non sono per niente un esperto in materia, ma credo sia importante seguirla.


E' stato pubblicato lo standard EN 301 549 con le specifiche per l'accessibilità (da parte di invalidi) ai siti web e alle applicazioni per dispositivi mobili, con i requisiti di percezione, operatività, comprensibilità e robustezza definiti dalla Web and Mobile Accessibility Directive:
- https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=50127.

giovedì 30 agosto 2018

Guida AgID su metriche software applicativo

Franco Vincenzo Ferrari di DNV GL mi ha segnalato la "Guida tecnica all'uso di metriche per il software applicativo sviluppato per conto delle pubbliche amministrazioni" di AgID (si trova al link seguente sotto "Documentazione"):
- https://www.agid.gov.it/it/design-servizi/linee-guida-design-servizi-digitali-pa.

Mi sembra interessante ma forse (!) troppo teorico e inattuabile nella realtà.

giovedì 17 marzo 2016

ISO 8000-8:2015

Franco Ferrari di DNV GL mi ha segnalato la pubblicazione della ISO 8000-8:2015 dal titolo "Information and data quality: Concepts and measuring":
- http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=60805.

Mi sembra interessante perché definisce cosa si intende per "qualità dei dati" nelle tre categorie di sintassi, semantica e pragmatica (questa è la più complessa, in quanto comprende sicurezza, accessibilità e completezza).

Vedo che si tratta di uno standard di "requisiti", ossia certificabile, in quanto usa la forma verbale "shall".

Da notare un'altra cosa: è pubblicata anche un'altra norma sulla qualità dei dati. È la ISO/IEC 25012:2008 dal titolo "Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Data quality model". Giusto per creare un po' di confusione.

sabato 16 gennaio 2016

OWASP Top 10 Proactive Controls 2016 (e il Joel Test)

L'OWASP ha pubblicato la OWASP Top 10 Proactive Controls 2016:
- https://www.owasp.org/index.php/OWASP_Proactive_Controls.

Questa notizia mi è stata riferita dalla Newsletter d'information de HSC <newsletter@hsc-news.com>.

L'articolo della newsletter, richiama un punto di cui ho già parlato anche io in passato: per la sicurezza delle applicazioni web, purtroppo il riferimento è la OWASP Top 10, ossia la lista delle 10 vulnerabilità più diffuse delle applicazioni web, che però rappresentano l'inverso del problema:
- https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.

Ringrazio quindi OWASP per aver presentato la nuova lista.

L'articolo della newsletter, richiama anche la lista di buone pratiche di Joel Spolsky:
- http://www.joelonsoftware.com/articles/fog0000000043.html.

L'ho letta con dolore, pensando a quante volte non ho visto applicati i 12 punti:
- usare un sistema di controllo dei file;
- fare in modo che le build siano prodotte in un solo passaggio;
- fare build almeno ogni giorno;
- usare un sistema di ticketing per tracciare i bug;
- correggere i bug prima di scrivere nuovo codice;
- mantenere un piano di lavoro;
- scrivere le specifiche;
- assicurare ai programmatori un ambiente di lavoro tranquillo;
- fornire ai programmatori gli strumenti migliori;
- avere dei tester;
- in fase di selezione del personale, far scrivere del codice ai programmatori;
- chiedere all'"uomo della strada" di fare dei test di usabilità.

Per ciascun punto è fornita una spiegazione molto utile.

La lista è del 2000 e forse qualche voce potrebbe essere aggiornata. Ciò non toglie che dovrebbe essere studiata e applicata con attenzione.

mercoledì 9 dicembre 2015

Progettare software sicuro

Da un articolo dell'ISACA Journal, volume 4 del 2015, dal titolo "Three Ways to Simplify Auditing Software Security Requirements and Design", segnalo alcuni link.

Il primo è uno studio di IBM dell'ottobre 2008 dal titolo " Minimizing code defects to improve software quality and lower development costs". Questo articolo riporta una delle dichiarazioni più famose della sicurezza ("identificare un difetto del software dopo la consegna costa 30 volte in più che farlo in fase di progettazione") e quindi può essere usata come autorevole fonte. Poi non si capisce bene come sia stato calcolato questo valore, ma se lo ha inventato IBM è sicuramente più veritiero che se lo avessi inventato io:
- ftp://ftp.software.ibm.com/software/rational/info/do-more/RAW14109USEN.pdf.

L'articolo poi tratta di "analisi delle minacce" ("threat modeling") a cui il software potrebbe essere sottoposto. Confesso che non ho mai visto usare questo strumento, però mi piace segnalare quello proposto da Microsoft, visto che è gratuito (l'articolo ne segnala altri, ma non capisco come possano essere utilizzati). Mi piacerebbe ricevere contributi (da chi li ha usati realmente, la pura teoria non mi interessa):
- http://www.microsoft.com/en-ca/download/details.aspx?id=42518.

sabato 7 novembre 2015

Presentazione sulla sicurezza del software

Segnalo questa presentazione di Gary McGraw, un guru della sicurezza del software:
- https://www.cigital.com/blog/annotated-att-cybersecurity-conference-keynote.

Alcuni dei link proposti conducono ad articoli interessanti. Per i più attenti potrebbe valere la pena considerare i libri di Gary McGraw.

Promuove anche il BSIMM, uno studio sulle iniziative per la sicurezza del software:
- https://www.bsimm.com/about/.

Non parlate di "ingegneria" del software

Segnalo questo articolo dal titolo "Programmers: stop calling yourselves engineers":
- http://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/.

In poche parole: i programmatori e gli sviluppatori non sono "ingegneri", visto che non adottano le tecniche di ingegneria e i risultati, con bug, difetti e vulnerabilità, si vedono.

Personalmente ritengo che programmatori e sviluppatori dovrebbero tendere ad essere "ingegneri". Purtroppo, però, quando si chiede loro piani di progetto, documenti di requisiti e verbali di test (con o senza elementi di sicurezza), dimostrano di essere degli "artigiani". Nella peggiore delle ipotesi non hanno neanche idea di cosa gli sia stato chiesto; nella maggior parte dei casi, per contro, questi requisiti sono ben chiari ma applicati poco e male.

Certamente la colpa è gran parte da addebitare alle aziende che li pagano poco, considerano il loro lavoro come "banale", impongono tempi di analisi, sviluppo e verifica brevissimi. Un vero "ingegnere" (per esempio chiamato a progettare e costruire un ponte) rifiuterebbe di adeguarsi a queste condizioni (e non rimarrebbe senza lavoro, al contrario di programmatori e sviluppatori software).

Quindi, forse, per non confondersi e non illudersi, sarebbe effettivamente meglio essere consapevoli dei limiti della "ingegneria" del software nel mondo reale.

L'articolo segnala la "Guide to the software engineering body of knowledge (SWEBOK Guide)" dell'IEEE, che sembra interessante (è necessario fornire la propria email all'IEEE, ma si tratta di un ente serio e non credo la usi per fare spamming):
- http://www.computer.org/web/swebok/index.

Riportare bug

Questo articolo ha titolo "If You Find a Software Bug, Don't Try to Report It to These Companies":
- http://blogs.wsj.com/digits/2015/11/05/if-you-find-a-software-bug-dont-try-to-report-it-to-these-companies/.

In breve: ci sono delle grandi società che non mettono a disposizione del pubblico un indirizzo a cui segnalare difetti o vulnerabilità individuati, altre (Microsoft, Amazon) lo fanno.

Ovviamente un canale di comunicazione per ricevere segnalazioni è fondamentale per poter migliorare i prodotti e servizi. Alcuni pensano che questo rappresenterebbe una dichiarazione di disfatta (come se non si sappia che i software sono sempre pieni di bug e vulerabilità), altri semplicemente non ci pensano.

giovedì 25 giugno 2015

DevOps e Microsoft

Stefano Ramacciotti mi ha segnalato il test dal titolo: "DevOps Self-Assessment: Moving you to the second decade of agile":
- https://profile.microsoft.com/RegSysProfileCenter/wizardnp.aspx?wizid=ba58aa87-54dc-4ffe-8066-05de46edb8a2

Il commento di Stefano è "anche se è targato MS mi sembra una cosa interessante".

In effetti, Microsoft è criticabile da molti punti di vista, ma il loro lavoro è sicuramente notevole se pensiamo alle complessità che devono affrontare.

Ho provato a fare il test, ma è certamente per persone (manager) che si occupano di sviluppo.

Per chi non volesse fare il test (anche perché non si fida a dare la propria e-mail a Microsoft, come se non ce l'avesse già...), può leggersi la loro pubblicazione di 21 pagine dal titolo "From Agile to DevOps at Microsoft Developer Division" (io però non l'ho ancora letto):
- https://www.microsoft.com/en-us/download/details.aspx?id=46920

giovedì 14 maggio 2015

CSSLP (libro) - Sviluppo sicuro

Da tempo volevo approfondire il tema dello sviluppo sicuro. Ho cercato un libro e ho trovato questo:
- Mano Paul. "Official (ISC)2 Guide to the CSSLP". USA: CRC Press, 2011.

È il libro per la preparazione all'esame CSSLP del (ISC)2 e quindi soffre di qualche limite, il primo dei quali è che un manuale per preparare ad un esame non è la stessa cosa di un libro scritto per altri scopi.

Il libro ha altri limiti, tra cui: errori di inglese (li ho trovati io!) e ripetitività di alcuni argomenti in diversi capitoli (e non sempre sono presentati in modo allineato). Drammaticamente ci sono anche errori tecnici (mi chiedo cosa abbia letto della ISO/IEC 27006, visto che la considera una norma per la "certificazione" del software e non per gli organismi che certificano secondo ISO 9001, 14001 e altri standard per i sistemi di gestione).

Però, in questi tempi in cui parlo con gli sviluppatori di "politiche di sviluppo sicuro" o, più banalmente, di "accorgimenti di sviluppo sicuro", vedo solo: a) sguardo di mucca quando passa il treno; b) i risultati di un vulnerability assessment; c) documenti in cui la parola "sicurezza" è nominata per sbaglio una o due volte senza ulteriori dettagli.

Allora è benvenuto un libro, per quanto mal fatto, che parla di sviluppo sicuro o, in inglese, di secure software development lifecycle (SSDLC).

In questo libro si parte dal "solito" risk management, per poi trattare del ciclo di vita: requisiti, progettazione, codifica, testing (tecnico), accettazione, messa in produzione, conduzione, manutenzione e eliminazione. Ci sono anche capitoli sulla catena di fornitura e sull'acquisizione di software da parti esterne.

Ovviamente, chiunque voglia segnalare altri testi è il benvenuto.

domenica 19 aprile 2015

Linee guida del CERT sulla codifica

Vi segnalo i "CERT Coding Standards" per C, C++, Java, Perl e Android:
- https://www.securecoding.cert.org/confluence/display/seccode/CERT+Coding+Standards

Il un'altra pagina, sono a disposizione le "Java Coding Guidelines":
- https://www.securecoding.cert.org/confluence/display/java/Java+Coding+Guidelines

La differenza tra gli "standard" e le "linee guida" al momento mi sfugge.