NIS2 și securitatea furnizorilor după Hacktober 2026
„October? Hacktober.” Jocul de cuvinte din postările despre incidentele lunii octombrie 2026 surprinde o preocupare foarte concretă: cât de sigură este compania ta atunci când un serviciu pe care îl folosești este compromis?
Pentru un administrator de firmă, știrile despre platforme cloud, aplicații și instrumente de inteligență artificială ridică întrebări practice. Folosim serviciul respectiv? Ce acces are la sistemele noastre? Cine verifică impactul și cine poate lua măsuri imediat?
NIS2 și securitatea furnizorilor sunt direct legate. Cadrul european include protecția relației cu furnizorii în gestionarea riscurilor cibernetice. Incidentele recente oferă exemple utile pentru a înțelege ce trebuie verificat în propria organizație.
Conținut
„Hacktober” 2026: nume mari, incidente multe
Formula care a circulat în comunitățile de securitate a fost simplă:
October ❌. Hacktober ✅.
Și nu este greu de înțeles de ce.
Pe parcursul lunii octombrie, în zona de securitate cibernetică au apărut incidente, vulnerabilități sau compromiteri care au vizat nume importante din tehnologie, cloud, inteligență artificială, servicii financiare și dezvoltare software.
Pe listă s-au regăsit, într-o formă sau alta: PHP, Railway, OpenCode, Binance, Polymarket, GitHub Actions, SoftBank, Cursor Marketplace, Coinbase printr-un furnizor terț, Fireworks AI, LiteLLM, Capcom, ecosistemul npm, TiDB Cloud și un furnizor utilizat de Warp.
Nu toate aceste situații au avut aceeași natură și nu în toate cazurile putem spune simplificat că „platforma X a fost spartă”. Unele au fost atacuri directe, altele au implicat vulnerabilități critice, furnizori compromiși, extensii malițioase, pachete software modificate, credențiale expuse sau atacuri asupra lanțului de aprovizionare software.
Dar tocmai această diversitate este importantă.
O companie poate fi afectată nu doar atunci când propriul server este atacat, ci și atunci când este compromis:
- furnizorul său de cloud;
- un serviciu SaaS utilizat de angajați;
- o extensie instalată pe calculatoare;
- un pachet software folosit de dezvoltatori;
- un furnizor de analytics;
- o cheie API;
- un instrument AI;
- sau un serviciu conectat la infrastructura companiei.
Cu alte cuvinte, suprafața de atac a unei organizații nu mai coincide de mult cu perimetrul rețelei sale interne. Ea include tot ecosistemul digital pe care compania se bazează.
Acesta este și motivul pentru care NIS2 pune atât de mult accent pe managementul riscului, securitatea lanțului de aprovizionare și relația cu furnizorii.
Din lista foarte lungă a incidentelor din octombrie, trei cazuri sunt deosebit de utile pentru a înțelege această problemă: Railway, LiteLLM și Cursor Marketplace. Fiecare ilustrează un alt tip de risc care poate ajunge rapid din infrastructura unui furnizor în infrastructura clientului.
Ce arată trei incidente de securitate din octombrie 2026
Formularea „a fost hacked” poate descrie situații foarte diferite: acces la infrastructură, folosirea unor credențiale furate sau distribuirea unei componente software modificate. Pentru a decide ce măsuri iei, ai nevoie de produsul, versiunea și tipul de acces afectate.
Railway și expunerea credențialelor aplicațiilor
În raportul din 22 octombrie 2026, Railway a confirmat accesul neautorizat la o parte dintre sistemele interne și decriptarea unor variabile de mediu pentru o parte dintre spațiile de lucru. Compania a recomandat, preventiv, revocarea și înlocuirea credențialelor sensibile stocate înainte de 21 octombrie.
Variabilele de mediu pot conține parole pentru baze de date sau chei API, adică acele credențiale prin care aplicațiile comunică între ele. Într-un asemenea scenariu, analiza trebuie să urmărească și serviciile accesibile cu secretele expuse.
Verificarea utilă pentru companie: putem identifica rapid toate cheile stocate la un furnizor și persoanele care le pot revoca?
LiteLLM și o versiune software compromisă
La 21 octombrie 2026, procesul de publicare LiteLLM a distribuit versiunea compromisă 1.107.0. Raportul tehnic din 23 octombrie descrie un lanț pornit de la o cheie administrativă publicată accidental cu luni înainte și rămasă activă. Atacatorul a obținut ulterior tokenuri GitHub și a intervenit în procesul de publicare.
Cazul evidențiază două probleme distincte: gestionarea secretelor expuse și controlul accesului la actualizările software. Ștergerea unei chei dintr-un fișier nu o revocă la serviciul care a emis-o.
Verificarea utilă pentru companie: cine confirmă că o credențială expusă a fost invalidată și ce aplicații folosesc componentele afectate?
Cursor și distribuirea unei extensii malițioase
La 29 octombrie 2026, Cursor a anunțat distribuirea prin marketplace-ul său a două versiuni modificate malițios ale extensiei Anthropic.claude-code, pentru Windows și macOS. Cursor a precizat că acele versiuni nu fuseseră dezvoltate de Anthropic. Codul colecta informații despre sistem și încerca să creeze acces persistent.
Exemplul arată de ce inventarul software trebuie să includă și extensiile instalate pe calculatoarele angajaților. O aplicație secundară poate avea acces la fișiere și credențiale importante pentru activitate.
Verificarea utilă pentru companie: putem afla pe ce dispozitive există o anumită extensie și cine poate izola sistemele afectate?
Cum ajunge incidentul unui furnizor în compania ta
Imaginează-ți o firmă care își găzduiește aplicația comercială în cloud. Aplicația este conectată la baza de date, facturare, e-mail și un serviciu AI. Dacă sunt expuse credențialele acestor integrări, investigația trebuie să urmărească fiecare serviciu la care ele permit accesul.
Acesta este un exemplu ilustrativ, iar efectele depind de permisiunile acordate. O cheie limitată la citirea unor informații are un impact diferit de un cont care poate modifica date, crea utilizatori sau iniția operațiuni plătite.
Pentru o companie care nu dezvoltă software, același exercițiu poate porni de la furnizorul de mentenanță IT, contul agenției care administrează website-ul sau aplicația conectată la e-mail.
Întrebarea de management este simplă: dacă această relație de încredere este compromisă, ce poate pierde sau întrerupe compania noastră? Răspunsul ajută la stabilirea priorităților și a bugetului de securitate.
Ce cere NIS2 pentru securitatea furnizorilor
În România, cadrul NIS2 este stabilit prin OUG nr. 155/2024, aprobată cu modificări și completări prin Legea nr. 124/2025, cu modificările și completările ulterioare.
Directiva include evaluarea riscurilor, securitatea furnizorilor direcți, gestionarea vulnerabilităților, controlul accesului, răspunsul la incidente și continuitatea activității. Conducerea entităților vizate aprobă măsurile și supraveghează aplicarea lor. Măsurile trebuie adaptate riscurilor și dimensiunii organizației.
Practic, o politică privind furnizorii devine utilă atunci când răspunde unor întrebări verificabile:
- Care furnizori susțin procese fără de care activitatea se oprește?
- Ce acces primesc și cum se retrage acel acces?
- Cum aflăm despre un incident și cine preia notificarea?
- Ce dovezi avem că serviciul și datele pot fi recuperate?
Pentru organizarea întregului proces, vezi și ghidul nostru despre implementarea NIS2.
Aplicabilitatea NIS2 se verifică pentru fiecare organizație
Încadrarea depinde de activități, dimensiune și situațiile speciale prevăzute de lege. Simplul fapt că lucrezi cu o entitate reglementată nu te transformă automat într-o entitate NIS2. Poți însă primi cerințe contractuale de securitate din partea clienților care își evaluează furnizorii.
Chiar și în afara aplicării directe a NIS2, pierderea accesului la e-mail, facturare sau datele clienților rămâne un risc de afaceri care merită gestionat.
Șapte verificări practice pentru securitatea cibernetică
Recomandăm următoarele verificări ca punct de pornire. Profunzimea lor se stabilește în funcție de serviciile folosite, datele accesibile și consecințele unui incident.
1. Inventariază furnizorii și integrările
Include platformele cloud, aplicațiile de business, furnizorii IT, serviciile AI și integrările dintre ele. Notează pentru fiecare serviciu responsabilul intern, procesul susținut, datele accesibile și conturile folosite.
Începe cu serviciile a căror indisponibilitate ar bloca activitatea. Cere echipelor să declare inclusiv instrumentele folosite în afara achizițiilor centralizate. Acest pas te ajută să identifici aplicații despre care departamentul IT nu știe.
Inventarul trebuie să poată răspunde rapid la o întrebare concretă: „Folosim produsul sau versiunea menționată în alerta de securitate?”
2. Verifică permisiunile acordate
Analizează conturile administratorilor, accesul furnizorilor și aplicațiile autorizate să citească sau să modifice date. Elimină conturile nefolosite și acordă permisiuni limitate la activitățile necesare.
Activează autentificarea multifactor unde este disponibilă și adecvată. Verifică separat cheile API și tokenurile aplicațiilor: controlul autentificării unei persoane nu acoperă automat toate credențialele folosite de programe.
Pentru furnizorii care intervin ocazional, evaluează posibilitatea acordării accesului doar pe durata intervenției.
3. Stabilește cum se revocă secretele expuse
Pentru cheile și parolele importante, documentează emitentul, proprietarul intern și aplicațiile dependente. Păstrează valorile secrete într-un sistem destinat acestui scop, cu acces controlat; registrul de inventar poate conține doar referințe.
Pregătește o procedură de revocare, înlocuire și verificare a funcționării aplicațiilor. Include controlul utilizării neautorizate și al costurilor, dacă serviciul este taxat în funcție de consum.
O înlocuire completă presupune să confirmi că vechea credențială nu mai permite accesul.
4. Controlează componentele software și extensiile
Cere echipei IT sau dezvoltatorului evidența componentelor importante și a versiunilor folosite. Include extensiile de browser și de dezvoltare, pluginurile website-ului și instrumentele AI care pot accesa fișiere sau conturi.
Stabilește un proces pentru alertele relevante: identificarea sistemelor expuse, evaluarea urgenței, aplicarea recomandărilor și verificarea rezultatului. Pentru aplicațiile proprii, include controlul modificărilor și al permisiunilor în procesul de publicare.
Obiectivul este să poți lega o alertă despre un produs de dispozitivele și aplicațiile din compania ta.
5. Clarifică relația de securitate cu furnizorii
Pentru furnizorii critici, verifică ce prevede contractul despre incidente, acces la informații, cooperarea la investigație, recuperare și încetarea serviciului.
Solicită un canal de contact funcțional și informațiile necesare pentru propria evaluare. Un mesaj care spune doar „incidentul a fost remediat” poate lăsa neclarificate perioada expunerii, datele afectate și acțiunile cerute clientului.
Cerințele trebuie să fie proporționale cu rolul furnizorului. Administratorul infrastructurii și un serviciu fără acces la date sensibile necesită evaluări diferite.
6. Testează recuperarea activității
Alege un serviciu important și verifică dacă poți restaura datele într-un mediu controlat. Măsoară timpul necesar și verifică dacă persoanele responsabile au acces la copii, documentație și credențialele de recuperare.
Ia în calcul și indisponibilitatea contului principal sau a furnizorului. Evaluează copii separate ori protejate împotriva modificării, în funcție de risc.
Păstrează rezultatul testului și deficiențele identificate. Pentru conducere, informația utilă este cât de repede poate fi reluată activitatea și ce pierdere de date ar putea apărea.
7. Exersează reacția la un incident
Organizează o simulare scurtă: „Furnizorul ne anunță că unele credențiale ar fi putut fi expuse.”
Verifică cine primește alerta, cine confirmă utilizarea serviciului, cine poate restricționa accesul și cine informează conducerea. Implică persoana responsabilă cu securitatea cibernetică și DPO, atunci când există posibile consecințe asupra datelor personale.
La final, consemnează blocajele și atribuie fiecărei măsuri un responsabil și un termen. Astfel, exercițiul produce îmbunătățiri pe care le poți urmări.
Ce faci când un furnizor anunță un incident
Primele acțiuni trebuie coordonate între echipa tehnică, management și persoanele care evaluează obligațiile de notificare.
- Confirmă expunerea. Identifică serviciul, versiunile, conturile și intervalul indicate în notificarea oficială. Verifică unde sunt folosite în organizație.
- Limitează accesul neautorizat. Aplică măsurile de izolare sau revocare potrivite situației. Înlocuiește credențialele dintr-un mediu de încredere, ținând cont de remedierea cauzei.
- Păstrează dovezile. Conservă logurile și informațiile relevante în paralel cu limitarea incidentului, fără a întârzia măsurile urgente.
- Evaluează consecințele. Verifică efectele asupra serviciilor, datelor, clienților și costurilor. Documentează separat ce este confirmat și ce rămâne de investigat.
- Analizează și urmărește notificările. Stabilește obligațiile legale și contractuale, momentele de la care curg termenele și persoanele responsabile.
Aceste acțiuni se pot desfășura în paralel. Planul intern trebuie să permită decizii rapide, inclusiv atunci când persoana care administrează în mod obișnuit serviciul nu este disponibilă.
Raportarea incidentelor în NIS2 și GDPR
Termenele NIS2 pentru entitățile vizate
Pentru incidentele semnificative, art. 15 din OUG nr. 155/2024 prevede raportarea prin PNRISC, fără întârzieri nejustificate, cu următoarele repere maxime:
| Etapă | Termen și moment de referință |
| Avertizare timpurie | 24 de ore de la luarea la cunoștință a incidentului semnificativ |
| Raportarea incidentului | 72 de ore de la luarea la cunoștință a incidentului semnificativ |
| Raport final | O lună de la raportarea incidentului din etapa precedentă |
Există și reguli speciale: informațiile care permit constatarea impactului transfrontalier se raportează în maximum 6 ore de la cunoașterea lor; pentru prestatorii de servicii de încredere, raportarea incidentelor semnificative care afectează aceste servicii are termen de 24 de ore de la luarea la cunoștință a incidentului semnificativ.
Dacă incidentul este încă în desfășurare la data la care ar trebui transmis raportul final, se transmite un raport de progres, iar raportul final se transmite în termen de o lună de la gestionarea incidentului. Termenele maxime nu justifică amânarea raportării.
Analiza GDPR se desfășoară distinct
Dacă există o încălcare a securității datelor personale, operatorul analizează notificarea autorității competente, inclusiv ANSPDCP atunci când aceasta este competentă. Art. 33 GDPR cere notificarea fără întârziere nejustificată și, dacă este posibil, în maximum 72 de ore de la luarea la cunoștință, cu excepția cazului în care este improbabil ca încălcarea să genereze un risc pentru drepturile și libertățile persoanelor.
Persoana împuternicită informează operatorul fără întârziere nejustificată. Un risc ridicat poate impune și informarea persoanelor afectate, conform art. 34 și excepțiilor sale. Încălcările se documentează inclusiv când nu sunt notificate.
Notificarea NIS2 nu înlocuiește analiza GDPR. Pentru exemple, citește și când un incident IT devine o încălcare GDPR.
Cu ce poți începe în următoarele 30 de zile
Un plan inițial poate organiza munca în patru etape:
| Perioadă propusă | Rezultat urmărit |
| Săptămâna 1 | Lista serviciilor critice, a responsabililor și a principalelor integrări |
| Săptămâna 2 | Revizuirea accesului și procedura de revocare a credențialelor |
| Săptămâna 3 | Verificarea furnizorilor prioritari și un test de restaurare |
| Săptămâna 4 | Simularea unui incident și aprobarea măsurilor rămase |
Acesta este un calendar orientativ pentru îmbunătățiri inițiale. Un incident activ sau o vulnerabilitate urgentă impune intervenție imediată. Durata conformării NIS2 depinde de situația organizației și de măsurile necesare.
Cum te poate sprijini GDPR Complet
La GDPR Complet, putem sprijini organizația ta cu analiza cerințelor aplicabile, evaluarea preliminară a riscurilor și a dependențelor de furnizori, politici și proceduri, instruire și construirea unui plan de măsuri.
Un punct de pornire util este să clarificăm ce servicii îți susțin activitatea, ce acces ai acordat furnizorilor și ce poți face imediat dacă unul dintre ei anunță un incident.
Pentru coordonarea conformării, poți consulta serviciul nostru de responsabil NIS2 externalizat.
Discută cu echipa GDPR Complet despre riscurile și obligațiile organizației tale: gdprcomplet.ro/contact
Întrebări frecvente despre NIS2 și securitatea furnizorilor
O firmă mică poate fi afectată de incidentul unui furnizor?
Da. Expunerea depinde de serviciile folosite și de accesul acordat. O firmă mică poate depinde de aceleași platforme cloud și aplicații ca o organizație mare. Încadrarea juridică în NIS2 necesită o analiză separată.
Externalizarea IT transferă toate responsabilitățile de securitate?
Nu. Furnizorul își asumă obligațiile legale și contractuale proprii, iar organizația trebuie să își gestioneze propriile responsabilități. Pentru entitățile NIS2, conducerea păstrează rolul de aprobare și supraveghere a măsurilor.
Este suficient să schimbăm parola după expunerea unor chei API?
Nu. Identifică și revocă exact credențialele expuse. Schimbarea parolei unui cont poate să nu invalideze cheile API, tokenurile sau sesiunile existente. Verifică regulile serviciului și eventualele utilizări neautorizate.
O alertă despre un furnizor înseamnă că firma noastră a fost compromisă?
Nu automat. Verifică produsul, versiunea, configurația, perioada și indicatorii publicați de furnizor. O măsură preventivă, precum revocarea unei chei, nu dovedește singură că aceasta a fost utilizată de un atacator.
Surse și referințe
