Program radi, klijent je zadovoljan, faktura je poslata. Za mnoge softverske projekte to je trenutak kada se nazdravlja i prelazi na sledeći posao. Održavanje ostaje za poseban ugovor, bezbednost za naredni sastanak, a neprijatna pitanja za čoveka koji trenutno koristi godišnji odmor. Onda neko pronađe način da kroz vaš proizvod uđe tamo gde ne bi smeo.
Evropski Cyber Resilience Act, skraćeno CRA, menja upravo taj odnos prema isporučenom softveru. Njegova poruka nije da programeri više ne smeju da pogreše. Poruka je da proizvođač ne može bezbednost tretirati kao usputnu uslugu, nevezanu za proizvod od kojeg zarađuje.
Za firme iz Srbije ova tema nije daleka briselska razonoda. Ako posluju na evropskom tržištu, moraju razumeti gde počinje njihova odgovornost. Nije dovoljno proveriti da li program radi. Treba znati i šta firma radi kada se ispostavi da program ugrožava korisnika.
Prodaja više nije poslednja stranica priče
CRA obuhvaćenim hardverskim i softverskim proizvodima postavlja zahteve koji prate njihov razvoj, plasman i podršku. Reč „proizvođač“ zato ne označava samo fabriku sa montažnom trakom. U pitanju mogu biti aplikacije, operativni sistemi i softverske komponente. Za obuhvaćene proizvode predviđene su procena rizika, tehnička dokumentacija i odgovarajući postupak provere usaglašenosti. Proizvođač treba da navede period podrške i tokom njega obrađuje ranjivosti. Predviđeni su i deklaracija o usaglašenosti i CE oznaka. To ipak ne znači da svaki program mora proći istu nezavisnu sertifikaciju. Postupak zavisi od kategorije proizvoda. Suština je da odgovornost proizvođača obuhvata i bezbednost nakon izlaska proizvoda na tržište.
Glavnina obaveza primenjuje se od 11. decembra 2027. godine. Prijavljivanje određenih ranjivosti i incidenata za proizvođače počinje ranije, 11. septembra 2026. To razdvajanje rokova važno je za svaku ozbiljnu pripremu. Firma može pogrešno zaključiti da ima još mnogo vremena, jer je zapamtila samo godinu pune primene. Druga može panično naručiti sertifikat koji joj trenutno niko nije tražio. Obe reakcije promašuju početak posla. Najpre treba utvrditi da li konkretan proizvod potpada pod propis i koju ulogu firma ima. Tek tada razgovor o dokumentaciji, podršci i troškovima dobija stvarno značenje. Bez toga se lako kupuje administracija umesto potrebne pripreme.
Za razvojne timove ovo otvara neprijatno, ali korisno pitanje o načinu ugovaranja posla. Kada klijentu obećavate proizvod, šta tačno obećavate nakon njegove isporuke? Ko prati prijavljene probleme i ko odlučuje o njihovoj ozbiljnosti? Ko zna koje verzije još koriste kupci? To nisu pitanja koja dobro zvuče na prezentaciji novog interfejsa. Ipak, upravo ona razdvajaju proizvod od fascikle koju je neko predao uz lozinku. Industrija je dugo nagrađivala brzinu objavljivanja vidljivih funkcionalnosti. Bezbednosni proces uglavnom postaje vidljiv tek kada zakaže. CRA menja računicu tako što deo ranije prećutnog očekivanja pretvara u proverljivu obavezu. Softver ostaje nematerijalan, ali odgovornost za njegovo održavanje postaje mnogo opipljivija.
Dvadeset četiri sata nije rok da popraviš svaki bag
Najlakše bi bilo napisati da Evropa daje programerima jedan dan da poprave bezbednosnu rupu. Naslov bi verovatno privukao pažnju, ali bi objašnjenje bilo pogrešno. Obaveza se odnosi na aktivno iskorišćene ranjivosti i ozbiljne incidente koji utiču na bezbednost obuhvaćenog proizvoda. Svako upozorenje skenera nije takav događaj. Rano upozorenje šalje se bez neopravdanog odlaganja, najkasnije 24 sata od saznanja. Detaljnije obaveštenje sledi najkasnije za 72 sata, takođe računato od saznanja. Završni izveštaj o aktivno iskorišćenoj ranjivosti dostavlja se najkasnije 14 dana nakon dostupnosti korektivne mere. Za ozbiljan incident predviđen je mesec dana nakon obaveštenja u okviru roka od 72 sata.
Prijavljivanje ide preko jedinstvene platforme, a odgovarajući evropski tim za odgovor na incidente bira se prema propisanim pravilima. Obaveze mogu obuhvatiti i ranije plasirane proizvode koji potpadaju pod CRA. Važno je razumeti šta pokreće prijavljivanje i od kog trenutka se računaju rokovi. Rok za upozorenje nije istovremeno obećanje da je istraga završena. Niti znači da već postoji proverena zakrpa. Za firmu to praktično znači da mora umeti da reaguje dok informacije još pristižu. Treba odvojiti ono što zna od onoga što pretpostavlja. Potrebno je i sačuvati trag o tome kada je saznala za događaj. Haotično dopisivanje teško može zameniti takav postupak.
Zamisli prijavu koja stiže u petak popodne na adresu koju proverava samo jedan zaposleni. On je odsutan, prodaja misli da je stvar tehnička, a razvoj čeka odobrenje rukovodioca. Vikend prođe u uverenju da problem već rešava neko drugi. Takav scenario ne zahteva loše programere. Dovoljno je loše raspoređena odgovornost. Zbog toga priprema nije samo kupovina boljeg skenera ili angažovanje stručnjaka za testiranje. Potrebni su nadziran kanal za prijave, odgovorna osoba i zamena. Tim mora znati kome prosleđuje sumnju i ko donosi sledeću odluku. To je organizacioni posao, često manje privlačan od novog razvojnog alata. Međutim, kada počne da teče zakonski rok, niko vas neće pitati koliko vam je alat bio moderan.
Srbija nije izuzeće, a svaki programer nije proizvođač
Firma iz Srbije ne može zaključiti da je izvan priče samo zato što nije registrovana u Evropskoj uniji. Pravila prijavljivanja predviđaju i proizvođače bez glavnog sedišta u EU. Ipak, iz toga ne sledi da je svaki domaći programer automatski obveznik. Potrebno je razdvojiti proizvod, tržište i ulogu onoga ko ga razvija ili plasira. Samostalni programer koji prodaje sopstvenu aplikaciju nije u istoj poziciji kao zaposleni u razvojnom timu. Nije isto ni kada firma isporučuje svoj proizvod ili radi za naručioca. Nazivi poput frilensera, agencije ili startapa sami po sebi ne rešavaju pitanje. Odgovor mora da prati konkretan posao, a ne opis na poslovnoj mreži.
Open source zahteva dodatnu preciznost. Javnost izvornog koda ne znači automatsko izuzeće, ali ni automatsku obavezu svakog saradnika. Razlikuju se nekomercijalno distribuiran slobodan softver, komercijalni proizvodi i organizacije koje trajno podržavaju određene projekte. Programer koji doprinosi tuđem projektu, za koji nije odgovoran, nije zbog samog doprinosa obuhvaćen kao proizvođač. Komercijalno plasiran open-source proizvod, međutim, može podleći obavezama proizvođača. Za kategoriju open-source software stewards postoji poseban, prilagođen režim. Zato otvoren izvorni kod i komercijalna odgovornost nisu međusobno isključivi pojmovi. Njihove odgovarajuće obaveze prijavljivanja počinju 11. decembra 2027, a ne zajedno sa obavezama proizvođača u septembru 2026. Te kategorije ne treba mešati radi dramatičnijeg naslova.
Za domaći outsourcing sektor najzanimljivija posledica mogla bi doći kroz razgovore sa klijentima. To je poslovna procena, a ne posebna zakonska obaveza svakog izvođača. Naručioci koji moraju dokazivati sopstvenu usaglašenost mogu tražiti jasnije podatke od razvojnih partnera. Pitaće ko održava zavisnosti, kako se predaju bezbednosne informacije i šta pokriva ugovorena podrška. U takvom razgovoru odgovor „mi smo samo pisali kod“ možda neće biti dovoljan za dobijanje sledećeg posla. Ne zato što je svaki programer postao regulatorni obveznik, nego zato što kupac mora urediti svoj proces. Za ozbiljne timove to može biti prilika da pokažu kvalitet rada. Za ostale će predstavljati trošak sređivanja onoga što su godinama ostavljali nedorečeno.
Najskuplja će biti odgovornost koju niko nije ugovorio
Razumna priprema počinje pregledom onoga što firma zaista ima, a ne gomilanjem dokumenata sa istim zaglavljem. Koji proizvodi se prodaju, koje verzije su aktivne i gde se koriste? Koje zavisnosti sadrže i ko prati njihovo održavanje? Bez takvog pregleda teško je proceniti posledice prijavljene ranjivosti. Nije dovoljno imati spisak biblioteka ako niko ne zna kojem izdanju pripadaju. Nije dovoljno ni imenovati odgovorno lice ako ono nema pristup podacima i ovlašćenje da pokrene postupak. To su praktični zaključci za organizaciju rada, ne iscrpan spisak pravnih zahteva. Njihova vrednost vidi se već tokom prve vežbe reagovanja. Ako tim ne može da odgovori u mirnim uslovima, teško će biti precizniji pod pritiskom.
Posebno treba pogledati ugovore koji uredno određuju cenu razvoja, ali nejasno govore o životu proizvoda posle primopredaje. Ko plaća održavanje i koliko ono traje? Šta se dešava kada problem potiče iz komponente koju nije napisao ugovorni partner? Ko obaveštava korisnike, a ko priprema tehničke podatke? Nije svaka nedorečenost pokušaj izbegavanja odgovornosti. Često je posledica žurbe i želje da posao što pre počne. Ipak, dobar odnos sa klijentom nije zamena za jasan dogovor. Kada nastane incident, prijateljska pretpostavka da će se svi nekako snaći brzo postaje spor oko nadležnosti. Tada se obično otkrije da su obe strane pod istom rečju „podrška“ podrazumevale potpuno različite stvari.
CRA zaslužuje kritički razgovor o troškovima, naročito za male firme. Priprema zahteva vreme koje se ne može istovremeno prodati kao razvoj nove funkcionalnosti. Loše sprovođenje moglo bi nagraditi urednu dokumentaciju više nego stvarnu bezbednost. To je razlog da se traže razumljiva pravila i srazmerni postupci, ali ne i opravdanje za nebrigu. Kupac softvera već plaća posledice kada se proizvod napusti čim prestane prodajni razgovor. Pitanje je ko treba da snosi cenu tog propusta i kako odgovornost učiniti proverljivom. Evropski odgovor sada se pretvara u konkretne obaveze i rokove. Za programere i firme najkorisnije je da razumeju sopstvenu ulogu pre prvog problema. Kod može biti isporučen za jedan dan. Odgovornost za proizvod ne staje u potvrdu o primopredaji.
