Un committente che ricade sotto l'obbligo di due diligence della NIS2 deve essere in grado di dimostrare di conoscere i rischi presenti nella propria catena di fornitura. Il software che sviluppate per quel committente fa parte di quella catena. In pratica, ciò si traduce in requisiti contrattuali che colpiscono due cose simultaneamente: il prodotto che consegnate e il modo in cui lo create. Entrambi ricompaiono nel testo dell'accordo, spesso come allegato al contratto di acquisto.
Il nocciolo è semplice da ricordare: il committente non chiede solo se il software funziona, ma anche se potete dimostrare come rimane al sicuro, chi vi ha accesso e cosa succede se qualcosa va male. Questo rappresenta un cambiamento rispetto al passato, quando la funzionalità e i tempi di consegna erano spesso gli unici elementi di discussione.
Requisiti per il prodotto che consegnate
Il requisito contrattuale più comune riguarda la composizione del software stesso. I committenti chiedono sempre più spesso un elenco dei componenti utilizzati, delle librerie e dei componenti open source impiegati, il cosiddetto software bill of materials. La ragione è che una vulnerabilità in un componente sottostante rappresenta un rischio tanto quanto un difetto nel vostro codice, e un committente vuole poter identificare tali rischi senza dover leggere il codice sorgente.
Inoltre, compaiono requisiti su come le vulnerabilità nel software vengono identificate e risolte, e entro quale termine. Questo può riguardare scansioni automatizzate di debolezze note, una procedura fissa per le patch, o la questione di chi può segnalare una vulnerabilità e dove deve essere inoltrata. Per il software esistente, talvolta si chiede anche il periodo di supporto: per quanto tempo una versione riceve aggiornamenti di sicurezza.
Requisiti per la vostra linea di sviluppo
Un secondo gruppo di requisiti non si focalizza sul prodotto, ma sul processo con cui viene creato: la linea di sviluppo. Pensate a chi ha accesso al codice sorgente e all'ambiente in cui si costruisce e si testa, come vengono controllate le modifiche prima di diventare operative, e se esiste separazione tra ambiente di test, di accettazione e di produzione. Anche l'uso dell'autenticazione a più fattori per gli sviluppatori che hanno accesso al codice sorgente o ai sistemi di build compare nei contratti, così come la questione di chi gestisce le chiavi e le credenziali di accesso associate al rilascio del software.
Alcuni committenti chiedono anche la provenienza del software che voi stessi utilizzate per sviluppare: il compilatore, gli strumenti di build, i pacchetti che vengono scaricati durante la compilazione. Questo si collega a una più ampia consapevolezza che un attacco non può solo colpire il prodotto finale, ma anche la fabbrica in cui viene realizzato.
Perché questi requisiti sono formulati esattamente così
L'obbligo di due diligence che sta alla base di tutto ciò obbliga un'organizzazione soggetta agli obblighi a valutare e gestire i rischi nella propria catena di fornitura. Il modo esatto in cui viene attuato varia da paese a paese nella legge nazionale che implementa la direttiva europea, e per settore in cui il committente opera. Ciò che è un requisito vincolante in un contratto può ancora essere una domanda facoltativa in un altro. Se desiderate sapere come questo obbligo è strutturato nel suo nucleo, leggete la spiegazione per obbligo nella nostra knowledge base.
È importante ricordare: il committente stabilisce questi requisiti perché ricade personalmente sotto supervisione, non perché le società di software ricadono come tali sotto la direttiva. Se e quanto rigorosamente questo viene applicato nel vostro caso dipende dal settore e dalla dimensione di quel particolare committente. Per la vostra situazione specifica, il testo della legge nazionale o il parere di un legale rappresentano il punto di partenza appropriato, non una valutazione generica.
Cosa significa questo per la vostra preparazione
La maggior parte di questi requisiti può essere affrontata bene con una preparazione iniziale, e la risposta che redige una volta può essere riutilizzata per ogni cliente successivo. Un elenco dei componenti utilizzati, una breve descrizione del controllo degli accessi e una procedura fissa per le patch non sono documenti che deve reinventare per ogni contratto.
Se desidera prima vedere se e come questa la riguarda, allora il controllo che in poche domande determina la sua posizione nella catena una prima direzione, senza che per questo abbia bisogno di un account. Per le domande che i clienti pongono concretamente e il modo in cui l'aiutiamo in questo, legga di più su la pagina delle domande frequenti oppure guardi come fondiamo le informazioni sulla piattaforma.
La banca dati gratuita e il controllo le danno una prima idea senza impegni. Se poi intende davvero tradurre i requisiti contrattuali in un dossier operativo con prove e risposte pronte all'uso ai questionari, questo è il momento per valutare cosa aggiunge un abbonamento.