Dezvoltatorii utilizează în mod obișnuit coduri de la terți pentru a-și construi aplicațiile, din motive de eficiență și economie de timp. Cu toate acestea, această dependență de componente externe, în special de software open-source (OSS), introduce riscuri semnificative, inclusiv vulnerabilități și probleme de licențiere. Conform unui sondaj GitHub din 2023, 31% dintre dezvoltatori consideră găsirea și remedierea vulnerabilităților de securitate a doua cea mai importantă sarcină, imediat după scrierea codului (32%).
În consecință, multe organizații sunt îngrijorate de dependența lor de OSS, deoarece acesta este frecvent vizat de hackeri. Organizațiile se confruntă cu provocări legate de vulnerabilitatea crescută în întregul lanț de aprovizionare cu software și de înțelegerea modului în care pot reduce în mod eficient riscurile în urma atacurilor recente de profil înalt.
Un raport de cercetare realizat de ESG arată că 91% dintre organizații s-au confruntat cu un incident în lanțul de aprovizionare cu software în ultimele 12 luni. Cele mai frecvente incidente includ:
Vulnerabilități proeminente precum Log4J, Curl, Apache Struts și OpenSSL au condus la numeroase cazuri de daune operaționale. Acestea evidențiază impactul grav asupra organizațiilor atunci când este exploatată o singură slăbiciune în cadrul lanțului de aprovizionare cu software. Ca răspuns la aceste riscuri în creștere, organismele de reglementare din întreaga lume pun accentul pe transparența și securitatea software-ului. Adoptarea unui Software Bill of Materials (SBOM) devine o strategie-cheie pentru gestionarea riscurilor lanțului de aprovizionare cu software.
Reglementările SBOM iau amploare
Reglementările SBOM sunt din ce în ce mai răspândite. Multe guverne au publicat recomandări privind implementarea SBOM. În SUA, recomandările SBOM sunt incluse în mai multe orientări guvernamentale, inclusiv:
În Europa, Agenția Europeană pentru Securitate Cibernetică (ENISA) a publicat "Orientări pentru securizarea Supply Chain pentru internetul obiectelor", oferind organizațiilor informații valoroase pentru îmbunătățirea securității cibernetice și gestionarea riscurilor legate de lanțul de aprovizionare cu software.
Alte țări au emis orientări similare, inclusiv:
sfătuiește organizațiile să utilizeze SBOM pentru a evalua riscurile asociate componentelor software pe care le utilizează și pentru a identifica și aborda vulnerabilitățile din aceste componente.
În "Manualul de securitate a informațiilor: Guidelines for Software Development", ACSC recomandă utilizarea SBOM-urilor pentru a spori transparența lanțului de aprovizionare cibernetică, facilitând identificarea și gestionarea riscurilor de securitate legate de componentele software individuale utilizate în aplicații.
Modul în care PCI DSS necesită generarea SBOM
Recunoscând riscurile din ce în ce mai mari pentru datele cardurilor de plată, standardul PCI DSS (Payment Card Industry Data Security Standard) a devenit o forță motrice pentru adoptarea SBOM. Cea mai recentă versiune, PCI DSS 4.0, impune utilizarea SBOM-urilor, subliniind rolul critic al acestora în protejarea informațiilor sensibile. Furnizând un inventar detaliat al componentelor software, SBOM-urile permit organizațiilor să identifice și să abordeze vulnerabilitățile în mod proactiv, reducând riscul de încălcări costisitoare ale securității datelor și de pierderi financiare.
Înființat în 2004, PCI DSS este un standard de securitate cuprinzător conceput pentru a proteja informațiile privind cardurile de credit. Acesta prezintă un set de cerințe riguroase pentru întreprinderile care gestionează tranzacții cu carduri de credit, adaptate volumului de tranzacții prelucrate anual. Versiunea 2022 a PCI DSS v4.0 a introdus modificări semnificative, inclusiv mandatul SBOM, pentru a face față amenințărilor în continuă evoluție. Conformitatea cu PCI DSS v4.0 este obligatorie până în aprilie 2024, cu cerințe specifice introduse treptat până la 31 martie 2025.
Prin impunerea SBOM-urilor, PCI DSS permite organizațiilor să obțină o înțelegere cuprinzătoare a ecosistemului lor software, permițându-le să identifice și să abordeze vulnerabilitățile în mod proactiv. Această abordare reduce semnificativ riscul unor încălcări costisitoare ale securității datelor și al pierderilor financiare.
O versiune mai nouă a PCI DSS, versiunea 4.0.1, a fost lansată la mijlocul anului 2024. Aceasta înseamnă că versiunea anterioară, 4.0, nu va mai fi valabilă după 31 decembrie 2024. Cu toate acestea, noua versiune nu adaugă sau elimină nicio regulă și nu modifică termenele limită. Prin urmare, informațiile despre cerințele SBOM din acest blog se aplică atât versiunii 4.0, cât și versiunii 4.0.1.
Conformitatea cu cerința 6.3.2 din PCI DSS
Cerința SBOM din PCI DSS v4.0 face parte din îmbunătățirile mai ample aduse PCI DSS în ultima sa iterație. Introdusă ca parte a celor 64 de noi cerințe adăugate în versiunea 4.0, cerința SBOM abordează în mod specific necesitatea ca organizațiile să mențină un inventar al componentelor software, concentrându-se în special asupra software-ului personalizat și la comandă.
Această cerință este clasificată în cadrul cerinței PCI DSS 6, care impune crearea și menținerea unor sisteme și aplicații sigure prin punerea în aplicare a unor măsuri de securitate puternice și prin efectuarea periodică de evaluări și actualizări ale vulnerabilităților. Această cerință este esențială pentru reducerea riscurilor reprezentate de vulnerabilitățile software și pentru protejarea datelor deținătorilor de carduri. Secțiunea 6 acoperă cinci domenii principale:
- 6.1 Procesele și mecanismele de dezvoltare și menținere a sistemelor și software-urilor sigure sunt definite și înțelese.
- 6.2 Programele software personalizate și la comandă sunt dezvoltate în siguranță.
- 6.3 Vulnerabilitățile de securitate sunt identificate și abordate.
- 6.4 Aplicațiile web destinate publicului sunt protejate împotriva atacurilor.
- 6.5 Modificările aduse tuturor componentelor sistemului sunt gestionate în siguranță.
Mai precis, cerința 6.3.2 este o actualizare importantă care a rezultat în urma mai multor încălcări în care vulnerabilități ale componentelor terților sau încălcări ale furnizorilor de componente terți au dus la compromiterea datelor deținătorilor de carduri. Cerința este formulată după cum urmează:
6.3.2.b Examinați documentația software, inclusiv pentru software-ul la comandă și personalizat care integrează componente software terțe, și comparați-o cu inventarul pentru a verifica dacă inventarul include software-ul la comandă și personalizat și componentele software terțe.
Organizațiile trebuie să documenteze și să gestioneze în detaliu componentele și serviciile specifice utilizate în aplicațiile lor. În timp ce unele dintre aceste informații puteau fi acoperite prin diagrame de flux de date, noile cerințe necesită o documentație mult mai detaliată. Urmărirea acestor detalii poate fi o provocare pe măsură ce componentele sunt actualizate și modificate. Este recomandabil să se utilizeze un șablon standard pentru captarea acestor informații. În plus, unele depozite de cod sursă, precum GIT, pot oferi instrumente pentru a exporta o listă a componentelor utilizate. Inventarul dvs. ar trebui să includă cel puțin:
- Componente de aplicație (de obicei proiecte de depozit)
- Lista de componente terțe
- Lista dependențelor aplicației (de exemplu, Tomcat, Jboss, .NET, Middleware)
- Lista scripturilor autorizate pentru pagina de plată
Cum poate ajuta OPSWAT SBOM să îndeplinească cerințele PCI DSS
Reglementările solicită din ce în ce mai mult SBOM-uri pentru a asigura securitatea lanțului de aprovizionare cu software. Cu toate acestea, organizațiile se străduiesc să realizeze inventare exacte ale compoziției codurilor lor software.
Sursă: Raportul EGS 2024
Cu toate acestea, crearea de SBOM-uri precise și cuprinzătoare reprezintă o provocare substanțială pentru organizații. Aceste documente necesită o inventariere meticuloasă a componentelor software, necesitând informații detaliate cu privire la originea, versiunile și interdependențele acestora. În lipsa unor SBOM precise, organizațiile se luptă să identifice, să evalueze și să reducă în mod eficient riscurile inerente lanțului lor de aprovizionare cu software.
Orientări pentru generarea SBOM-urilor
OPSWAT SBOM automatizează generarea de SBOM-uri atât pentru cod, cât și pentru containere, sporind securitatea și ajutând la conformitatea în cadrul lanțului de aprovizionare cu software.
- Identificați toate componentele și dependențele
Identificați cu exactitate toate componentele software, inclusiv bibliotecile open-source și ale terților, împreună cu versiunile și dependențele acestora. Aceasta constituie baza pentru un SBOM robust. - Evaluarea riscurilor OSS
Evaluați riscurile potențiale asociate cu componentele OSS. Luați în considerare factori precum conformitatea cu licența, vulnerabilitățile de securitate și starea de întreținere. Prioritizați componentele în funcție de importanța lor pentru software. - Scanarea pentru vulnerabilitățile OSS
Utilizați instrumentele de scanare a vulnerabilităților și de generare a SBOM pentru a identifica vulnerabilitățile cunoscute în cadrul componentelor OSS. Prioritizarea vulnerabilităților în funcție de gravitatea lor și de impactul potențial asupra software-ului.
Utilizarea OPSWAT SBOM
OPSWAT SBOM automatizează generarea de SBOM-uri atât pentru cod, cât și pentru containere, sporind securitatea și ajutând la conformitatea în cadrul lanțului de aprovizionare cu software.
Iată cum puteți utiliza OPSWAT SBOM pentru a genera în mod eficient SBOM-uri:
Prin furnizarea unui inventar al tuturor bibliotecilor și componentelor open-source utilizate în cadrul unei aplicații, OPSWAT SBOM ajută la gestionarea vulnerabilităților de dependență în lanțul de aprovizionare cu software, permițând utilizatorilor să identifice și să remedieze eficient vulnerabilitățile din aplicații.
În plus față de identificarea vulnerabilităților, OPSWAT SBOM validează licențele asociate fiecărei componente software. Acest lucru asigură conformitatea cu termenii de licențiere și evită potențiale capcane juridice. Aflați mai multe despre rolul crucial al detectării licențelor în OSS.
OPSWAT SBOM acceptă peste 10 limbaje de programare, inclusiv Java, JavaScript, Go, PHP și Python. Acest suport larg asigură un vulnerability detection cuprinzător în diverse ecosisteme de dezvoltare software.
Sancțiuni pentru nerespectarea legislației
Organizațiile care nu respectă standardele PCI DSS, inclusiv cerința SBOM, pot suporta penalități financiare cuprinse între 5.000 și 100.000 de dolari pe lună. Aceste amenzi pot crește în timp dacă problemele de conformitate rămân nerezolvate.
Pe lângă sancțiunile financiare, nerespectarea PCI DSS poate duce la provocări juridice și operaționale semnificative. Consecințele juridice pot include procese, costuri de apărare și înțelegeri substanțiale. În plus, neconformitatea ar putea declanșa audituri federale din partea unor agenții precum Comisia Federală pentru Comerț (FTC), ceea ce ar conduce la sancțiuni suplimentare.
Pașii următori pentru conformitatea cu PCI DSS 4.0
Integrarea SBOM în cadrul PCI DSS 4.0 reprezintă o schimbare esențială către un lanț de aprovizionare cu software mai sigur. Prin utilizarea unor instrumente avansate precum OPSWAT SBOM, organizațiile pot gestiona eficient riscurile legate de sursele deschise, pot îmbunătăți conformitatea și se pot proteja împotriva încălcărilor costisitoare ale securității datelor.
Utilizarea SBOM-urilor nu mai este o opțiune, ci o necesitate. Luând măsuri proactive pentru a înțelege și a aborda dependențele de software, organizațiile pot construi o fundație solidă de securitate care să le protejeze operațiunile și să câștige încrederea clienților.
Îmbunătățiți-vă securitatea
Postura cu OPSWAT
Începeți să gestionați acum dependențele
open-source.
