secria.eu

Mitkä vaatimukset sisältyvät ohjelmistojen kehittämisen sopimukseen NIS2:n jälkeen?

Tilaaja, jolle NIS2:n huolenpitovelvoite on voimassa, muuntaa tämän velvoitteen sopimuksellisiksi vaatimuksiksi sinun kehittämälleen ohjelmistolle ja sen kehittämistavalle. Tämä artikkeli käsittelee, mitkä vaatimukset ne yleensä ovat.

Tilaaja, joka kuuluu NIS2:n riskienhallintavelvoitteen piiriin, joutuu pystyä osoittamaan, että tuntee omat riskit toimitusketjussaan. Ohjelmisto, jonka rakennatte tälle tilaajalle, on osa tätä ketjua. Käytännössä se johtaa sopimuksen vaatimuksiin, jotka kohdistuvat kahteen asiaan samanaikaisesti: tuotteeseen, jonka toimitte, ja tapaan, jolla sen rakennatte. Molemmat näkyvät sopimustekstissä, usein hankinnan pääsopimuksen liitteenä.

Ydin on helppo muistaa: tilaaja ei kysy pelkästään, toimiiko ohjelmisto, vaan myös näyttää, miten se pysyy turvallisena, kuka siihen pääsee ja mitä tapahtuu, jos jokin menee pieleen. Tämä on muutos aiempaan, kun toiminnallisuus ja toimintaaika olivat usein ainoat keskustelun aiheet.

Vaatimukset toimittamallenne tuotteelle

Yleisin sopimuksen vaatimus koskee itse ohjelmiston koostumusta. Tilaajat pyytävät yhä useammin luetteloa käytetyistä kirjastoista ja avoimen lähdekoodin osista, niin sanotusta ohjelmistokomponenttiluettelosta. Syy on se, että haavoittuvuus pohjalla olevassa osassa on yhtä suuri riski kuin virhe omassa koodissa, ja tilaaja haluaa nähdä nämä riskit ilman, että hänen täytyy lukea itse lähdekoodia.

Lisäksi sopimuksiin sisältyvät vaatimukset siitä, miten ohjelmiston haavoittuvuudet havaitaan ja korjataan, ja missä aikarajassa. Tämä voi koskea automaattisia tuntemattomien heikkouksien skannausta, kiinteää korjausprosessia tai sitä, kuka saa ilmoittaa haavoittuvuudesta ja minne se viedään. Olemassa olevalle ohjelmistolle kysytään joskus myös tukiajasta: kuinka kauan versio saa turvapäivityksiä.

Vaatimukset omasta kehitysketjusta

Toinen vaatimusryhmä ei kohdistu tuotteeseen, vaan prosessiin, jolla se luodaan: kehitysketjuun. Ajattele sitä, kuka pääsee lähdekoodiin ja ympäristöön, jossa rakennetaan ja testataan, miten muutokset tarkistetaan ennen kuin ne menevät tuotantoon, ja onko testaus-, hyväksyntä- ja tuotantoympäristöjen välillä erottelu. Myös monitekijäisen vahvistuksen käyttö kehittäjille, joilla on pääsy lähdekoodiin tai rakennusjärjestelmiin, näkyy sopimuksissa, samoin kuin kysymys siitä, kuka hallinnoi avaimia ja tunnistetietoja, jotka liittyvät ohjelmiston käyttöönottoon.

Jotkut tilaajat kysyvät myös siitä, mistä tulee ohjelmisto, jota käytätte rakentamiseen: kääntäjä, rakennustyökalut, paketit, jotka haetaan rakennuksen aikana. Tämä liittyy laajempaan ymmärrykseen siitä, että hyökkäys ei voi tulla vain lopputuotteen kautta, vaan myös tehtaasta, jossa se valmistetaan.

Miksi nämä vaatimukset on muotoiltu juuri näin

Riskienhallintavelvoite, joka kaiken tämän pohjalla on, velvoittaa vastuullisen organisaation arvioimaan ja hallitsemaan riskejä omassa toimitusketjussaan. Miten se täsmälleen toteutetaan, vaihtelee sen mukaan, mikä maa on antanut Euroopan direktiivin kansallisen lain, ja missä sektorissa tilaaja toimii. Se, mikä on yksissä sopimuksissa kova vaatimus, on toisissa sopimuksissa vielä vapaamuotoinen kysymys. Jos haluatte tietää, miten tämä velvoite ytimeltään rakennetaan, voit lukea sen jokaisen velvoitteen selityksestä tietokannassamme.

On tärkeä muistaa: tilaaja asettaa nämä vaatimukset, koska hän itse on valvonnan alainen, ei siksi, että ohjelmistoyritykset sinänsä kuuluisivat direktiivin piiriin. Se, ovatko ja kuinka tiukasti nämä vaatimukset sinussa toteutetaan, riippuu tuon tietyn tilaajan sektorista ja koosta. Oman tilanteesi kannalta asianomaisen kansallisen lain teksti tai asianajajan neuvonto on oikea lähtökohta, ei yleinen arvio.

Mitä tämä tarkoittaa sinun valmistautumiselleen

Useimmat näistä vaatimuksista voidaan vastata hyvin jonkin esityöskentelyn jälkeen, ja vastauksen, jonka laaditte kerran, voitte käyttää uudelleen seuraavalla tilaajalla. Komponenttiluettelo, lyhyt kuvaus pääsynvalvonnastanne ja kiinteä patchaus­menettely eivät ole asiakirjoja, jotka teidän on löydettävä uudelleen jokaiselle sopimukselle.

Haluatko ensin nähdä, koskeeko ja miten tämä yritystänne, check, joka muutamalla kysymyksellä määrittää asemanne ketjussa, antaa ensimmäisen suunnan ilman, että tarvitsette tiliä. Kysymyksiin, joita tilaajat konkreettisesti esittävät, ja tapaan, jolla auttamme siinä, voitte tutustua osoitteessa sivulle usein kysytyistä kysymyksistä tai katsoa, miten perustamme alustan tiedot.

Ilmainen tietokanta ja check antavat teille alustavaa kuvaa ilman velvoitteita. Haluatteko sitten tosiasiallisesti muuttaa sopimuksien vaatimukset käynnissä olevaksi dossieeriksi todisteilla ja valmiiksi vastuksiksi kyselyihin, niin se on aika katsoa, mitä tilaus lisää.

Tämä artikkeli on yleistietoa eikä juridista neuvontaa.