Vai al contenuto
Home » Sono tutti open con il source degli altri – reprise

Sono tutti open con il source degli altri – reprise

gold and silver round coins

Lo ammetto: rompere lo stereotipo che l’opensource sia sicuro senza sé e senza ma è un mio cruccio. Ne scrivevo anche sei anni fa, proprio su questo blog, in questo post. Io amo scrivere codice e amo l’idea alla base dell’opensource. Amo che lo sviluppatore possa scrivere e condividere del codice con la comunità e questa possa collaborare migliorandolo.

Collaborare, migliorandolo.

Se la nostra idea di opensource è: “wow che figata, questa funzionalità è implementata gratis, aspetta che la inglobo nel mio mastodontico prodotto”, allora è il caso di soffermarsi sulla parola collaborare.

È chiaro, non tutti sanno scrivere codice. Ci sono poi tanti fattori che entrano in campo, alcuni anche personali come il senso di blocco del “oddio, come posso collaborare?” oppure “oddio, non sono a quel livello”.

Se però io voglio usare codice opensource, voglio sia sicuro e voglio supportare la comunità che mi ha dato quella libreria che mi sarebbe altresì costata tempo e denaro, io qualcosa devo fare. Posso dare un contributo economico al maintainer, posso scrivere documentazione, posso lavorare ai test, posso fare security audit, posso tradurre i manuali, posso scrivere post tecnico che spiegano come usare quel codice, …

Posso fare un sacco di cose. Un sacco di cose tranne il non fare nulla.

I guerrieri solitari

Dall’altra parte dell’utilizzatore finale abbiamo la figura del maintainer, del capo progetto, ovvero quella persona che è responsabile per quel pezzo di codice. Lo cura, lo fa crescere, prende i feedback della community e li trasforma in funzionalità.

Il maintainer di solito ha un lavoro ed una vita personale. Cosa succede se gli impegni sono troppi o semplicemente non è più in grado di sostenere economicamente il proprio progetto?

Ta-daan

Fa paura, vero?

A me molta, moltissima paura. Un mancato investimento di qualche centinaia di euro, facciamo finta il dominio sia un .com molto costoso, sappiamo tutti che forse sarà di un fattore 10x inferiore, ha una ripercussione su centinaia se non migliaia di altri progetti opensource che usano una particolare libreria che, caduta in mani ostili può contenere codice malevolo. Queste centinaia e migliaia di progetti opensource, sono poi inclusi in altrettanti progetti sia open che commerciali, con un impatto ben superiore al costo di un dominio per un anno.

La community deve essere una parte attiva nel ciclo di vita di un progetto opensource e tu che stai leggendo questo post, devi fare qualcosa nel tuo piccolo.

Non sai dove partire? Vai qui: https://github.com/thesp0nge. Scegli tra i miei progetti opensource e prova a contribuire in qualche modo.

Ci sono eventi organizzati in rete dove questa cosa è portata all’estremo, dove la community è chiamata a partecipare attivamente allo sviluppo e alla crescita del codice open, spesso alla base delle applicazioni che usiamo ogni giorno.

Ti do un compito. Esplora github.com o gitlab.com o sourceforge.net, scegli un progetto e contatta il maintainer chiedendo come partecipare. Se sei invece più coraggioso, prova a scaricarlo, provarlo e magari cercare qualche bug, mettendoti sempre in contatto con il maintainer. Se ti va poi, scrivi qui nei commenti quale progetto hai “adottato”.

Se invece sei tu stesso un maintainer e sei in difficoltà, chiedi aiuto alla community usando i social e qualsiasi strumento tu abbia a disposizione.

La sicurezza del codice passa soprattutto da qui.

Enjoy it!

2 commenti su “Sono tutti open con il source degli altri – reprise”

  1. Ciao,
    seguo con interesse i tuoi post.

    E’ da tempo che mi chiedo: qual è il miglior framework SAST per piccole aziende? (migliore sotto il profilo della qualità/prezzo). Quale suggeriresti ad un’azienda che non ha (o forse non vuole avere) un gran budget da investire su software da dedicare alla SAST? Un mio conoscente mi ha parlato di SonarQube: che ne pensi? Noi in ditta sviluppiamo essenzialmente due cose: portali web (eShop) e App (sia per Android che per iPhone), e siamo appunto alla ricerca di strumenti SAST per iniziare a fare analisi di sicurezza del nostro codice: ci hanno fatto un preventivo Fortify piuttosto salato… allora stiamo pensando di usare qualcos’altro, ma non vogliamo fare investimenti a vuoto.

    Grazie

    1. Ciao Giovanni, ti ringrazio per il tuo messaggio. Di SonarQube ne ho sentito parlare bene come strumento per la quality assurance, non per la security. Un paio d’anni fa, in una vita lavorativa precedente, ho fatto una software selection per un tool di SAST e SonarQube non aveva le feature che mi servivano, soprattutto non competeva con i soliti nomi dei tool commerciali: Fortify, Checkmark, Veracode, Klockwork, …).

      Questi strumenti sono salati per definizione. Il software dietro non è banale e le knowledge base vanno aggiornate di continuo.
      Visto che mi sembra di aver capito tu debba analizzare del codice che il tuo team di sviluppo scrive in casa, allora ti direi di approcciare il problema in questo modo.

      Inizia con lo scrivere delle linee guida di sviluppo sicuro che dicano loro quali pattern di sviluppo utilizzare, quali funzioni sono bandite, come memorizzare le password, che protocolli prediligere e cose del genere. Continua sviluppando qualche script a mano che va a verificare la tua codebase per violazioni di queste linee guida. Prosegui utilizzando Owasp DependencyChecker o simili per verificare le vulnerabilità librerie di terze.
      Alla fine del ciclo di sviluppo, non so che metodologia utilizzate, prima del deploy in produzione, userei un framework come selenium e Owasp ZAP che espone delle API per “simulare” alcuni attacchi dinamici tipici (XSS, SQL injection, …).

      Tutto questo però non sostituisce un penetration test ed una code review fatta da una società terza, che ti consiglio di fare almeno una volta l’anno oppure ad ogni rilascio significativo.

      Spero di aver risposto alla tua domanda, in caso contrario, non esitare a scrivermi ancora.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *