Detyrimet e raportimit sipas nenit 14 të Aktit të Rezistencës Kibernetike fillojnë

Detyrimet e raportimit sipas nenit 14 të Aktit të Rezistencës Kibernetike hynë në fuqi më 11 shtator 2026 dhe ato shtrihen më gjerë sesa mendojnë shumë prodhues softuerësh. Neni 14 është pjesa e parë e Aktit Evropian të Rezistencës Kibernetike, ligji i Bashkimit Evropian për sigurinë e produkteve me elemente dixhitale, që bëhet detyrues. Patchstack, e cila thotë se ka koordinuar më shumë se gjysmën e të gjitha dobësive të njohura në ekosistemin WordPress dhe e përshkruan veten si një nga autoritetet numëruese më aktive në botë, publikoi një shpjegim të rregullave të reja së bashku me lançimin e një shërbimi për t'i trajtuar ato. Sipas atij shpjegimi, detyrimet prekin kryesisht kompanitë që bëjnë të disponueshme produkte me elemente dixhitale në tregun evropian, por ato zbatohen edhe për mirëmbajtësit e softuerëve me burim të hapur, të cilët ligji i trajton si kujdestarë të burimeve të hapura. Një detaj ka rëndësi për këdo që mendonte se ora fillon vetëm me versionet e reja: neni 14 mbulon të gjitha produktet dhe softuerët, përfshirë çdo gjë që është bërë e disponueshme në tregun evropian përpara 11 shtatorit 2026.

Dy lloje ngjarjesh duhet të raportohen nga ajo datë. E para është një dobësi që sulmuesit po e shfrytëzojnë në mënyrë aktive, që do të thotë një dobësi softuerike që tashmë po përdoret në sulme reale, jo një që thjesht mund të përdoret një ditë. E dyta është një incident i rëndë sigurie që prek një produkt. Raportet dorëzohen pranë autoriteteve kombëtare të sigurisë kibernetike dhe ENISA-s, Agjencia e Bashkimit Evropian për Sigurinë Kibernetike, përmes një platforme të vetme të BE-së. Afatet janë të rrepta: një paralajmërim i hershëm brenda 24 orëve, një njoftim më i plotë brenda 72 orëve dhe një raport përfundimtar i detajuar më vonë. Përveç vetë raporteve, prodhuesit duhet gjithashtu t'u tregojnë përdoruesve të prekur se çfarë ndodhi dhe si mund të mbrohen.

Kush saktësisht e mban detyrën varet nga mënyra se si financohet softueri, dhe Patchstack përdor një shtojcë WordPress për të treguar se ku qëndron kufiri. Nëse kodi i shtojcës është me burim të hapur nën licencën GPL, licenca e përdorur gjerësisht që lejon këdo të lexojë dhe ripërdorë kodin, por shtojca ka gjithashtu një version premium ose një mënyrë tjetër për të gjeneruar të ardhura për mirëmbajtësin e saj, atëherë shitësi konsiderohet prodhues dhe jo kujdestar i burimeve të hapura. Një shtojcë plotësisht falas dhe me burim të hapur pa asnjë qëllim komercial, edhe nëse mirëmbahet nga punonjës të një personi juridik, trajtohet si kujdestar i burimeve të hapura. Detyrimet e nenit 14 zbatohen në të dyja rastet. Dallimi është se një kujdestar i burimeve të hapura nuk mund të gjobitet, ndërsa Bashkimi Evropian mund të përdorë ende mjete të tjera për të hequr një produkt jokonformues nga tregu evropian. Patchstack thekson se kjo zbatohet në çdo ekosistem me burim të hapur dhe nuk është specifike për WordPress, të cilin e përdor si shembull sepse burimi i hapur atje nuk do të thotë falas: të gjitha shtojcat WordPress janë me burim të hapur dhe të licencuara me GPL, megjithatë shumica e atyre popullore janë produkte komerciale.

Çdo raport përbëhet nga tre formularë dhe secili formular ka afatin e vet. I pari është një paralajmërim i hershëm, i cili duhet dorëzuar pa vonesë të panevojshme dhe në çdo rast brenda 24 orëve nga momenti kur kompania bëhet e vetëdijshme për një dobësi të shfrytëzuar në mënyrë aktive ose një incident të rëndë. I dyti është njoftimi i asaj dobësie të shfrytëzuar në mënyrë aktive ose incidenti të rëndë, i cili duhet dorëzuar pa vonesë të panevojshme dhe në çdo rast brenda 72 orëve, dhe duhet të përmbajë informacion të përgjithshëm plus një vlerësim fillestar. I treti është raporti përfundimtar. Për një dobësi të shfrytëzuar në mënyrë aktive, ai duhet dorëzuar jo më vonë se 14 ditë pasi të bëhet i disponueshëm një masë korrigjuese, si një patch (një përditësim softueri që rregullon dobësinë). Për një incident të rëndë, ai duhet dorëzuar brenda një muaji pas njoftimit 72-orësh.

Të gjitha këto raporte duhet të kalojnë përmes Platformës së Vetme të Raportimit të BE-së, ose SRP. Këshilla e Patchstack është që mirëmbajtësit të krijojnë llogaritë e tyre menjëherë, sepse llogaritë e EU Login janë personale dhe kërkohet vërtetim me shumë faktorë, një provë e dytë identiteti si një kod i dërguar në telefon, përpara se të mund të arrihet platforma. SRP nuk ka API, që do të thotë se nuk ka mënyrë të automatizuar që një sistem tjetër të dorëzojë një raport në emrin tuaj, dhe platforma kërkon që tre formularë të ndryshëm të plotësohen me dorë për çdo raport të vetëm. Me një afat të rreptë 24-orësh në lojë, Patchstack thotë se krijimi i llogarive të BE-së menjëherë e bën shumë më të lehtë përmbushjen e atij afati kur diçka ndodh në të vërtetë.

Patchstack përdori të njëjtën datë për të njoftuar një platformë për mirëmbajtësit e burimeve të hapura, e cila sipas tyre mbulon përputhshmërinë me nenin 14 nga fillimi në fund, falas për t'u aksesuar në fillim. Kompania paralajmëron se mund të vendosë një tarifë në të ardhmen, e ngarkuar për raport, nëse vëllimi i raporteve bëhet shumë i lartë dhe Platforma e Vetme e Raportimit ende nuk ka API. Sipas Patchstack, platforma bën tre gjëra: gjurmon shfrytëzimin aktiv të dobësive individuale, mbledh prova dhe njofton mirëmbajtësin sapo aktivizohen kërkesat e nenit 14; mund të veprojë si Përfaqësuesi Zyrtar i Caktuar për mirëmbajtësin, duke dorëzuar raportet dhe duke mbajtur çdo formular brenda afatit të tij; dhe ofron një kanal të vetëm për një program të menaxhuar të zbulimit të dobësive (mVDP) së bashku me një program bug bounty, për një produkt ose disa. Patchstack thotë se platforma mVDP u ndërtua për këtë qëllim në bashkëpunim me Bashkimin Evropian (EIC), dhe se kompania është në përputhje me GDPR, e certifikuar sipas ISO 27001 dhe SOC 2 Type 2, dhe e bazuar në BE. Ajo thotë gjithashtu se më shumë se 1,000 produkte dhe projekte me burim të hapur tashmë përdorin mVDP-në e saj për koordinimin e dobësive, dhe vlerëson partneritetet me kompani të mëdha hostimi web dhe teknologjinë e saj RapidMitigate për atë që e përshkruan si zbulimin më të shpejtë dhe më të detajuar të dobësive të njohura të shfrytëzuara (KEV) në treg.

Për pronarët e faqeve web, leximi praktik është i drejtpërdrejtë. Njerëzit që dorëzojnë këto raporte janë shitësit, jo klientët, kështu që një pronar faqeje nuk do të plotësojë formularë të BE-së pasi një shtojcë të sulmohet. Ajo që ndryshon është presioni mbi ata shitës: një dobësi e shfrytëzuar në mënyrë aktive në një shtojcë komerciale tani e vendos prodhuesin e saj në një afat ligjor për të paralajmëruar përdoruesit dhe për të shpjeguar se si të mbrohen, dhe mosrespektimi i kësaj ka pasoja. Meqenëse shumica e shtojcave popullore janë komerciale, kjo detyrë qëndron mbi kompanitë pas tyre, ndërsa projektet falas dhe jo-komerciale duhet të raportojnë gjithsesi, por nuk mund të gjobiten. Në çdo rast, mbrojtja më e shpejtë për një faqe mbetet e njëjta, që është instalimi i përditësimeve të sigurisë dhe heqja e softuerit që askush nuk e mirëmban. Për ekipet që preferojnë të mos i ndjekin vetë dritaret e patch-eve, AEU Hosting është shërbimi ynë i hostimit të menaxhuar WordPress, i ndërtuar rreth mbajtjes së faqeve WordPress të përditësuara dhe të siguruara nga fillimi në fund, që është pikërisht lloji i punës themelore që shpërblen kjo histori.

Një pikë që vlen të përsëritet, sepse është e lehtë për t'u anashkaluar: detyrimet nuk kufizohen vetëm në softuerin e lëshuar pas afatit. Produktet dhe softuerët tashmë në tregun evropian përpara 11 shtatorit 2026 mbulohen gjithashtu, kështu që pyetja përkatëse për një shitës nuk është kur u publikua kodi, por nëse ka një dobësi të shfrytëzuar në mënyrë aktive ose një incident të rëndë për të raportuar.