Un ordonator care cade sub obligația de diligență din NIS2 trebuie să poată demonstra că înțelege riscurile din propria sa lanț de aprovizionare. Software-ul pe care îl construiți pentru acel ordonator face parte din acel lanț. În practică, aceasta se traduce în cerințe contractuale care acționează simultan asupra a două lucruri: produsul pe care îl livrați și modul în care faceți acel produs. Ambele apar în textul acordului, adesea ca anexă la contractul de achiziție.
Esența este ușor de reținut: ordonatorul nu doar că întreabă dacă software-ul funcționează, ci și dacă puteți demonstra cum rămâne acesta în siguranță, cine poate accesa și ce se întâmplă dacă ceva merge prost. Aceasta reprezintă o schimbare față de trecut, când funcționalitatea și termenul de livrare erau adesea singurele puncte de discuție.
Cerințe pentru produsul pe care îl livrați
Cea mai comună cerință contractuală se referă la compoziția software-ului în sine. Ordonatorii cer din ce în ce mai des o Listă de materiale software (SBOM) - un inventar al bibliotecilor și componentelor open-source utilizate. Motivul este că o vulnerabilitate într-o componentă subiacentă este la fel de mult un risc ca o eroare în codul dumneavoastră propriu, iar ordonatorul dorește să poată discerne aceste riscuri fără a citi singur codul sursă.
În plus, apar cerințe cu privire la modul în care sunt identificate și remediate vulnerabilitățile din software și în ce termen. Aceasta poate implica scanări automatizate ale punctelor slabe cunoscute, o procedură stabilită pentru plasturi sau întrebarea cui i se permite să raporteze o vulnerabilitate și unde aceasta este adresată. Pentru software-ul existent, uneori se întreabă și perioada de suport: cât timp rămâne o versiune prevăzută cu actualizări de securitate.
Cerințe pentru propria dumneavoastră linie de dezvoltare
Un al doilea set de cerințe nu se concentrează pe produs, ci pe procesul prin care acesta este realizat: linia de dezvoltare. Gândiți-vă la cine are acces la codul sursă și la mediul în care se construiește și se testează, cum sunt controlate modificările înainte de a deveni active, și dacă există separare între un mediu de testare, acceptare și producție. Utilizarea autentificării multifactoriale pentru dezvoltatorii care au acces la codul sursă sau la sisteme de compilare apare, de asemenea, în contracte, la fel ca și întrebarea cu privire la cine gestionează cheile și acreditările de acces care însoțesc lansarea software-ului.
Unii ordonatori întreabă, de asemenea, despre originea software-ului pe care îl utilizați pentru a construi: compilatorul, instrumentele de compilare, pachetele care sunt preluate în timpul compilării. Aceasta se aliniază cu o conștientizare mai largă că un atac nu poate circula doar prin produsul final, ci și prin fabrica în care este realizat.
De ce aceste cerințe sunt formulate exact așa
Obligația de diligență care stă la baza tuturor acestora obligă o organizație supusă reglementării să evalueze și să gestioneze riscurile din propria sa lanț de aprovizionare. Modul exact în care aceasta este implementată diferă în funcție de țară în legea națională care se bazează pe directiva europeană și în funcție de sectorul în care operează ordonatorul. Ceea ce într-un contract este o cerință strictă, într-un alt contract apare încă ca o întrebare cu caracter orientativ. Dacă doriți să aflați cum esta obligația în esență construită, o citiți în explicația pentru fiecare obligație din baza noastră de cunoștințe.
Important de reținut: ordonatorul pune aceste cerințe deoarece el însuși este sub supraveghere, nu pentru că companiile de software cad ca atare sub directivă. Dacă și cât de riguros se aplică aceasta în cazul dumneavoastră depinde de sectorul și dimensiunea acelui ordonator specific. Pentru situația dumneavoastră, textul legii naționale sau sfatul unui jurist este punctul de plecare recomandat, nu o estimare generală.
Ce înseamnă aceasta pentru pregătirea dumneavoastră
Majoritatea acestor cerințe pot fi bine satisfăcute cu puțin pregătit anterior, iar răspunsurile pe care le elaborați o dată pot fi reutilizate de fiecare dată la următorul client. O listă a componentelor utilizate, o descriere scurtă a controlului accesului dumneavoastră și o procedură fixă pentru remedieri nu sunt documente pe care trebuie să le pregătiți din nou pentru fiecare contract.
Dacă doriți mai întâi să vedeți dacă și cum aceasta vă afectează afacerea, atunci oferă evaluarea care în câteva întrebări vă determină poziția în lanț o primă direcție, fără a avea nevoie de cont. Pentru întrebările pe care clienții le adresează în mod specific și modul în care vă ajutăm în acest sens, citiți mai mult pe pagina cu întrebări frecvente sau vizionați modul în care susținem informațiile de pe platformă.
Baza de cunoștințe gratuită și evaluarea vă oferă o primă imagine fără obligații. Dacă ulterior doriți să transformați în mod efectiv cerințele contractuale într-un dosar activ cu dovezi și răspunsuri gata făcute la chestionarele de securitate, atunci acela este momentul pentru a examina ce adaugă un abonament la aceasta.