Cadrul Secure OPSWAT:
Un angajament față de reziliență și securitate prin apărare în profunzime

Actorii rău intenționați țintesc sistemele pentru a obține profit sau pentru a le perturba, ceea ce conduce la costuri, riscuri de afaceri și daune reputaționale pentru organizații. 

Conform unui studiu recent, costul remedierii unei erori de securitate este de 30 de ori mai mare atunci când este descoperită în producție decât în timpul etapei de analiză și cerințe.

Cadrul Secure OPSWATdefinește metodologii structurate și principii de securitate care ghidează dezvoltarea sigură a software-ului. 

OPSWAT ciclul de viață Software agile Software . Pentru a ne asigura că respectăm pe deplin cerințele clienților noștri, am adaptat cadrul Secure la cerințele de reglementare și la standardele internaționale. Această abordare consolidează angajamentul nostru față de îmbunătățirea continuă și reziliență într-un peisaj al securității cibernetice în continuă evoluție.

Cadrul Secure OPSWATse bazează pe standardul NIST SP 800-218 SSDF (Secure Software Framework), asigurând faptul că securitatea este structurată, măsurabilă și aplicată în mod consecvent în toate etapele procesului de dezvoltare a software-ului.  

Prin integrarea celor mai bune practici SSDF, OPSWAT menține o poziție de securitate proactivă, integrând securitatea în fiecare fază a dezvoltării software-ului - de la planificare și proiectare la implementare, verificare și monitorizare continuă. 

Certificarea conformității produselor individuale este furnizată la cerere clienților noștri din guvernul federal al SUA. A se vedea detaliile de contact de mai jos.

Pe măsură ce reglementările în domeniul securității cibernetice continuă să evolueze, OPSWAT angajamentul de a-și alinia cadrul Secure la cerințele normative globale, începând cu Legea UE privind reziliența cibernetică și Directiva NIS2. Prin adaptarea proactivă la standardele emergente, OPSWAT că cadrul său Secure rămâne cuprinzător, conform și rezilient într-un peisaj normativ din ce în ce mai complex.

Menținerea unui nivel ridicat de securitate a informațiilor este esențială atât pentru integritatea operațională, cât și pentru respectarea cerințelor de reglementare. Cadrul Secure OPSWAT încorporează principiile Sistemului de Management al Securității Informațiilor (ISMS) conform standardului ISO 27001, asigurând integrarea perfectă a controalelor de securitate, a strategiilor de gestionare a riscurilor și a măsurilor de conformitate în funcționarea produselor noastre cloud. 

În calitate atât de furnizor, cât și de consumator al soluțiilor noastre de securitate, OPSWAT aplică politicile de securitate interne ale companiei, asigurându-se că produsele noastre certificate aderă la așteptările de securitate de nivel enterprise înainte de implementare.  

Vedeți mai multe detalii despre conformitate și certificări.

Pentru a asigura cele mai înalte standarde de calitate a software-ului, cadrul Secure OPSWATeste integrat în sistemul de management al calității (QMS) conform standardului ISO 9001. Acest sistem de management al calității stabilește controale de calitate auditate pentru guvernanță, gestionarea schimbărilor și procesele interfuncționale, sprijinind definirea, proiectarea, dezvoltarea, producția și întreținerea produsului și a serviciilor de asistență, extinzându-se dincolo de cercetare și dezvoltare către domenii precum vânzări, asistență pentru clienți, tehnologia informației și resurse umane.  

Această abordare consolidează angajamentul nostru față de o abordare structurată, bazată pe riscuri, a managementului calității, asigurând că securitatea aplicațiilor rămâne o considerație integrală în toate funcțiile de afaceri.

Vedeți mai multe detalii despre conformitate și certificări.

OWASP Software Assurance Maturity Model (SAMM) este un cadru cuprinzător conceput pentru a ajuta organizațiile să evalueze, să formuleze și să implementeze strategii eficiente de securitate software în cadrul SDLC-ului lor existent.

Fiind un cadru open-source, SAMM beneficiază de contribuții globale, asigurând o abordare colaborativă, în continuă evoluție, a securității aplicațiilor. Metodologia sa structurată oferă organizațiilor o modalitate eficientă și măsurabilă de a analiza și de a-și îmbunătăți ciclul de dezvoltare. SAMM sprijină întregul ciclu de viață al dezvoltării. SAMM este agnostic față de tehnologie și procese. SAMM este evolutiv și axat pe riscuri. Prin utilizarea SAMM, echipele obțin informații utile cu privire la lacunele de securitate și își pot îmbunătăți în mod sistematic poziția de securitate pe tot parcursul ciclului de viață al dezvoltării.

Standardul OWASP de verificare a securității aplicațiilor (ASVS) este un cadru recunoscut la nivel mondial, conceput pentru a stabili o abordare structurată, măsurabilă și acționabilă a securității aplicațiilor web. Acesta oferă dezvoltatorilor și echipelor de securitate un set cuprinzător de cerințe de securitate și orientări de verificare pentru a se asigura că aplicațiile respectă cele mai bune practici din industrie. 

Fiind un cadru open-source, ASVS beneficiază de contribuții ample din partea comunității globale de securitate, asigurându-se că rămâne la zi cu amenințările emergente și cu evoluția standardelor de securitate.

Programul Secure OPSWAT transpune Cadrul Secure într-un sistem structurat de guvernanță, asigurându-se că cerințele de securitate sunt documentate, menținute, evaluate și îmbunătățite continuu, garantând totodată că toate părțile implicate beneficiază de o pregătire adecvată. Acesta stabilește rolurile, responsabilitățile și măsurile de securitate pentru mediile de dezvoltare, testare și producție, precum și pentru securitatea fluxului de lucru, definind Mediul Secure și impunând aplicarea politicilor de securitate în cadrul Procesului Secure .

Management la nivel înalt - Chief Product Officer (CPO)

Directorul de produs (CPO) este responsabil de supravegherea strategică și punerea în aplicare a Programului Secure în cadrul tuturor echipelor de produs, precum și a altor programe de cercetare și dezvoltare (C&D), cum ar fi Programul de asigurare a calității (QA) și Programul de experiență a utilizatorului (UX), asigurând o abordare coerentă în vederea dezvoltării de software sigur, de înaltă calitate și centrat pe utilizator.

În calitate de principal responsabil pentru gestionarea riscurilor legate de toate produsele și procesele de cercetare și dezvoltare, CPO-ul încredințează departamentului de Operațiuni de Cercetare și Dezvoltare responsabilitatea pentru Programul Secure și se asigură că liderii de produs impun aplicarea Programului Secure și pun în aplicare în mod eficient Procesul Secure în cadrul echipelor de produs. În acest rol, CPO-ul aprobă modificările aduse Programului Secure , precum și abaterile de la Procesul Secure .

De asemenea, CPO monitorizează rezultatele Programului Secure , urmărind nivelul de maturitate în materie de securitate, vulnerabilitățile, conformitatea și activitățile de dezvoltare, pentru a menține un nivel ridicat de securitate al produselor.

În plus, CPO este responsabil de alocarea și aprobarea bugetului pentru securitatea activităților de cercetare și dezvoltare, asigurându-se că sunt alocate resurse adecvate programului Secure .

Priorități strategice

Planul strategic al OPSWATpentru securitatea aplicațiilor este aliniat la prioritățile sale de afaceri și la apetitul pentru risc, luând în considerare nivelul de maturitate al fiecărui produs și expunerea acestuia la amenințările de securitate. Accentul se pune în primul rând pe protejarea produselor cu risc ridicat, în special a celor cu o bază mare de clienți, cu implementări orientate către public sau cu integrare în infrastructuri critice.

În cadrul Programului Secure , pe lângă cursurile generale de sensibilizare în materie de securitate organizate de companie, se impune ca toți angajații implicați în procesul de dezvoltare securizată să urmeze cursuri de formare în domeniul securității, adaptate rolului fiecăruia. Toate cursurile sunt înregistrate în sistemele de gestionare a formării profesionale ale companiei. Programele de formare și de sensibilizare sunt revizuite periodic pentru a integra noile tendințe în materie de securitate și pentru a asigura respectarea continuă a standardelor de securitate.

OPSWAT angajează să-și îmbunătățească în mod continuu programul Secure prin măsurarea structurată a performanței, evaluări ale gradului de maturitate și actualizări periodice, pentru a asigura eficacitatea continuă a securității.  

Pentru a menține o poziție de securitate solidă, OPSWAT utilizează o abordare sistematică pentru urmărirea și îmbunătățirea performanțelor de securitate. Aceasta include evaluări trimestriale ale maturității securității produselor, revizuiri interne ale securității pentru a verifica respectarea celor mai bune practici și definirea indicatorilor-cheie de performanță (KPI) anual, care sunt măsurați trimestrial.  

Pentru a măsura în mod eficient nivelul de securitate al aplicațiilor, OPSWAT echipele folosind indicatori structurați. Maturitatea securității produselor este evaluată pentru fiecare echipă în parte pe baza cadrului SAMM, oferind o măsură cuantificabilă a progresului în materie de securitate. În plus, produsele sunt supuse unei evaluări de conformitate cu ASVS pentru a asigura respectarea cerințelor de verificare a securității. Conformitatea cu procesul Secure este monitorizată și evaluată îndeaproape, iar atingerea obiectivelor KPI se bazează pe dovezi concrete, asigurându-se astfel că atât nivelul de securitate, cât și îmbunătățirile în materie de securitate sunt măsurabile și pot fi puse în practică. Toate echipele de produs sunt obligate să îndeplinească obiectivele de maturitate în materie de securitate ca parte a evaluării anuale a performanței. 

Ca parte a eforturilor sale de îmbunătățire continuă, OPSWAT introduce periodic noi inițiative de securitate a produselor pentru a crește nivelul de maturitate și a consolida securitatea aplicațiilor. Aceste inițiative includ actualizarea politicilor de securitate pentru a aborda amenințările emergente, integrarea de noi instrumente de securitate pentru o detecție și o prevenire îmbunătățite și extinderea obiectivelor KPI pentru a stimula progresul continuu. 

Pentru a consolida și mai mult guvernanța în materie de securitate, OPSWAT o revizuire anuală a cadrului Secure , integrând concluziile analizelor cauzelor fundamentale ale incidentelor de securitate anterioare, evaluările tendințelor privind vulnerabilitățile, precum și îmbunătățirile aduse proceselor și politicilor existente.  

Această abordare structurată a îmbunătățirii continue asigură că OPSWAT menține o poziție proactivă și rezistentă în ceea ce privește securitatea produselor, adaptându-se în mod eficient la provocările în materie de securitate cibernetică în continuă evoluție și îndeplinind în același timp obiectivele de securitate operaționale și de reglementare.

Procesul Secure pune în practică Programul Secure prin definirea măsurilor de securitate pe care echipele trebuie să le respecte, inclusiv activități specifice precum verificările automate de securitate și mecanismele de verificare din fiecare fază de dezvoltare. Acest proces este aliniat la alte programe cheie de cercetare și dezvoltare, precum Programul de asigurare a calității și Programul de experiență a utilizatorului, asigurând o abordare coerentă pentru o dezvoltare de software sigură, de înaltă calitate și orientată către client. 

Procesul Secure este descris în detaliu în secțiunile următoare:

• Secure și evaluarea riscurilor
• Secure , compilare și distribuire Secure
• Testarea și verificarea securității aplicațiilor
• Secure
• Secure și întreținere Secure

Procesul Secure este un proces de nivel înalt; echipele îl pot implementa într-o manieră extinsă și personalizată, cu condiția ca nivelul de securitate al procesului să fie menținut cel puțin la același nivel. Orice abatere de la procesul Secure trebuie documentată și aprobată.

Programul Secure cuprinde diverse politici care trebuie aprobate și acceptate în mod oficial de către echipele de produs pentru a asigura respectarea cerințelor acestuia. Respectarea acestor politici este obligatorie la nivel intern, iar fiecare echipă are responsabilitatea de a le analiza, semna și pune în aplicare în cadrul proceselor sale de dezvoltare. 

Mai jos este prezentată o listă a politicilor-cheie, împreună cu scopurile lor respective. Pentru politicile cu semnificație externă, în prezentul document sunt incluse detalii suplimentare.

În cadrul procesului Secure , cerințele de securitate sunt monitorizate, documentate și menținute pe tot parcursul ciclului de viață al dezvoltării. Furnizorii terți au obligația de a recunoaște și de a respecta standardul ASVS, asigurând astfel coerența așteptărilor în materie de securitate și respectarea Politicii de conformitate privind confidențialitatea produselor pentru toate componentele software. 

Securitatea este integrată în fiecare etapă a ciclului de viață al dezvoltării. Responsabilitatea de a ține cont de așteptările procesului Secure și de a le promova în cadrul echipelor lor revine responsabililor cu securitatea. 

Setul de cerințe Secure include cerințe de securitate funcționale și nefuncționale bazate pe ASVS. Modelele de referință sunt furnizate de departamentul de Cercetare și Dezvoltare pentru a sprijini deciziile de proiectare, împreună cu ajustările documentate ale cerințelor ASVS, dacă este necesar (de exemplu, cerințe mai stricte privind criptarea).

Modelarea amenințărilor este un proces structurat de identificare a amenințărilor și a vulnerabilităților încă din primele etape ale ciclului de viață al dezvoltării. Aceasta face parte integrantă din procesul Secure și se desfășoară periodic — cel puțin o dată pe an sau ori de câte ori sunt introduse noi funcționalități sau modificări arhitecturale. Echipele de produs realizează modelarea amenințărilor prin definirea obiectivelor de securitate, identificarea resurselor și a dependențelor, analizarea scenariilor potențiale de atac și atenuarea amenințărilor identificate.  

O abordare îmbunătățită încorporează analiza fluxului de date și practici consacrate de modelare a amenințărilor (de exemplu, modelul STRIDE), asigurând o evaluare cuprinzătoare a tuturor produselor. Atunci când este necesar, sunt inițiate analize de securitate pentru a valida conformitatea cu cerințele de securitate și pentru a aborda în mod proactiv riscurile potențiale. Deciziile de proiectare sunt documentate cu atenție, iar orice riscuri rămase sunt urmărite în permanență pe parcursul ciclului de viață al produsului.

Riscurile de securitate ale aplicațiilor sunt evaluate folosind surse multiple, inclusiv amenințările reziduale identificate în timpul modelării amenințărilor, vulnerabilitățile de securitate recunoscute pe scară largă, cum ar fi cele din Top 10 OWASP și Top 25 SANS, și controalele de securitate lipsă pe baza orientărilor ASVS. Factorii de risc suplimentari includ deficiențe în gestionarea secretelor pe parcursul proceselor de creare, implementare și lansare, precum și vulnerabilități în componentele open-source și ale terților. 

În urma evaluării riscurilor, sunt elaborate planuri de atenuare pentru a reduce gravitatea riscurilor identificate, luând în considerare atât impactul, cât și probabilitatea. Aceste planuri, împreună cu riscurile și etapele de atenuare corespunzătoare, sunt documentate temeinic. 

Riscurile reziduale sunt urmărite pe tot parcursul ciclului de viață al produsului, fac obiectul unei revizuiri periodice și trebuie să fie recunoscute în mod oficial de către proprietarii riscurilor. Acestea sunt, de asemenea, încorporate în rapoartele interne de publicare pentru a menține vizibilitatea și responsabilitatea. 

Atunci când este necesar, sunt inițiate evaluări de securitate pentru a asigura conformitatea cu cerințele de securitate și pentru a aborda în mod proactiv riscurile potențiale, consolidând poziția generală de securitate a produsului.

Ca parte a procesului Secure , care include implementarea, compilarea și punerea în funcțiune, se urmărește prevenirea vulnerabilităților și a defectelor, pe baza Secure și a evaluării riscurilor. Setul de cerințe conține așteptări privind cerințele de securitate funcționale și nefuncționale bazate pe ASVS, precum și metodologia de dezvoltare și testare securizată, care se bazează pe mediul Secure .  

În timpul implementării, trebuie aplicate cele mai bune practici Secure , revizuirea Secure și detectarea timpurie a vulnerabilităților de securitate. Echipele trebuie să respecte Politica Supply Chain (inclusiv aspectele legate de integrarea furnizorilor și de software-ul open source), Politica privind utilizarea IA și Politica privind gestionarea eșantioanelor de malware. În timpul procesului de compilare și implementare, sunt obligatorii Secure și implementarea Secure , cu utilizarea unui pipeline CI/CD centralizat, precum și separarea atribuțiilor.

În timpul implementării, echipele de produs trebuie să urmeze cele mai bune practici de codare securizată independente de limbaj. Acestea trebuie să valideze datele de intrare, să igienizeze datele trimise către alte sisteme, să elimine avertismentele compilatorului, să stabilească mesaje de eroare securizate, să aplice codificarea de ieșire, dacă este cazul, să pună în aplicare înregistrarea securizată fără a expune date sensibile și să urmeze liniile directoare adecvate privind gestionarea erorilor și a excepțiilor. De asemenea, echipele trebuie să se asigure că criptografia, în cazul în care este utilizată, se bazează pe algoritmi aprobați și pe generarea de numere aleatorii sigure și să gestioneze în siguranță resursele sistemului prin manipularea sigură a memoriei, prevenirea condițiilor de cursă și evitarea blocajelor prin sincronizarea corespunzătoare. 

Echipele de produs sunt sfătuite, de asemenea, să urmeze liniile directoare privind codarea securizată specifice fiecărei limbi, puse în aplicare de instrumentele SAST, după cum se exemplifică mai jos: 

Pentru Java, echipele ar trebui să se asigure că cheile utilizate în operațiunile de comparare sunt imuabile, să utilizeze SecureRandom în loc de Random și să evite deserializarea nesigură prin validarea sau restricționarea claselor de intrare.

În C++, se recomandă detectarea și gestionarea erorilor de alocare a memoriei, prevenirea depășirii limitelor bufferului prin verificarea limitelor și utilizarea de pointeri inteligenți precum std::unique_ptr() și evitarea funcțiilor nesigure precum strcpy() și sprintf(). 

Pentru Python, dezvoltatorii ar trebui să evite utilizarea funcțiilor precum eval() sau exec() pentru a reduce riscurile de injectare a codului și să prefere formatele de serializare securizate, precum modulul json, în locul pickle atunci când procesează date care nu sunt de încredere.

În cadrul proceselor de evaluare a securității prevăzute de Politica de verificare a securității aplicațiilor, revizuirea codului din perspectiva securității este un element important și se realizează în funcție de tehnologia de dezvoltare utilizată, aplicându-se diverse liste de verificare pentru revizuirea Secure , bazate peseria OWASP Cheatsheet.

Conform cerințelor politicii de verificare a securității aplicațiilor, detectarea timpurie a defectelor de securitate este o componentă esențială a procesului de dezvoltare. Pentru a minimiza potențialele probleme de securitate, este obligatorie o abordare de tip "fail to build", asigurându-se că codul nesigur nu trece prin pipeline. În plus, este impusă o abordare de tip "fail to merge", care impune echipelor să remedieze orice probleme detectate înainte ca modificările să poată fi integrate. Rezolvarea defectelor detectate este esențială pentru îndeplinirea criteriilor de lansare.

În cadrul procesului Secure , utilizarea unui pipeline CI/CD centralizat și coordonat este obligatorie pentru a asigura compilări sigure și pentru a preveni atacurile asupra lanțului de aprovizionare. Jurnalele de audit, de compilare și de implementare sunt generate, păstrate și analizate conform prevederilor din politicile de securitate ale companiei. 

Fiecare echipă de produs este responsabilă pentru respectarea configurațiilor de compilare și de construire securizate, acolo unde este cazul. Acestea trebuie să utilizeze opțiuni de compilare securizate, să dezactiveze codul de depanare, să consolideze timpii de execuție pentru limbajele interpretate, să fixeze versiunile dependențelor, să asigure compilări reproductibile și să consolideze imaginile containerului. Configurațiile utilizate trebuie să fie documentate și revizuite periodic. 

În conformitate cu principiul separării atribuțiilor, dezvoltatorii și alți membri ai echipei care au acces la cod sau la construcție nu pot avea acces la mediul de producție. În cazul produselor cloud, numai inginerii care se ocupă de fiabilitatea site-ului produsului sunt autorizați să implementeze în mediul de producție.

Conform Politicii noastre de verificare a securității aplicațiilor, implementăm o documentare formală și un sistem de urmărire a problemelor identificate și utilizăm instrumente automatizate pentru verificarea continuă. În cadrul procesului Secure , verificările de securitate sunt aplicate și monitorizate în fiecare etapă a ciclului de viață al dezvoltării software-ului (SDLC), pentru a respecta cerințele de conformitate. Scopul acestora este identificarea eficientă a eventualelor vulnerabilități de securitate. Problemele de securitate apărute sunt investigate de către echipe și rezolvate în termenele stabilite. Aceste termene fac parte din indicatorii-cheie de performanță (KPI) definiți în domeniul securității.

• Revizuirea arhitecturii și a proiectării: Inginerii seniori și membrii echipei virtuale de securitate a aplicațiilor evaluează aspectele de securitate în modificările de proiectare, inclusiv criptarea, autentificarea, autorizarea, auditarea, întărirea sistemului, arhitectura sistemului și a rețelei. 
• Revizuiri ale codului: pe lângă revizuirile regulate ale codului de către ingineri colegi și seniori, membrii echipei virtuale de securitate a aplicațiilor revizuiesc modificările pentru a preveni defectele comune precum injectarea, gestionarea erorilor și configurațiile nesigure.

• Scanarea secretului pentru a evita exfiltrarea secretului și pentru a asigura o bună proiectare și o implementare sigură a gestionării secretului.
• Instrumente SAST (Static Application Security Testing) pentru detectarea vulnerabilităților (de exemplu, SQL Injection, Buffer Overflows).
• SCA (Software Composition Analysis) este utilizat pentru a detecta vulnerabilitățile open-source.
• DAST (Dynamic Application Security Testing - Testarea dinamică a securității aplicațiilor) este utilizat pentru a găsi probleme legate de timpul de execuție (de exemplu, defecte de memorie) și de mediu

Instrumentele care sunt definite în secțiunea Detectarea timpurie a problemelor de securitate trebuie utilizate în mod obligatoriu în conducta CI/CD. Toate vulnerabilitățile identificate trebuie remediate în conformitate cu politica de Vulnerability Management produsului.

Metodologiile de testare a securității, atât automatizate, cât și manuale, sunt utilizate în conformitate cu programul de asigurare a calității care execută planul de testare a securității.

• Instrumentele DAST sunt utilizate pentru detectarea vulnerabilităților în timpul rulării, testarea configurațiilor implicite și testarea rezistenței sistemului după aplicarea sugestiilor de întărire. Testele vizează atât software-ul, cât și infrastructura de bază. 
• Pentru a evita regresia cerințelor și caracteristicilor de securitate, utilizăm instrumente de testare automată pentru a verifica în permanență integritatea caracteristicilor și a controalelor de securitate. 
• Testarea manuală se aplică atunci când instrumentele automatizate nu sunt suficiente, cum ar fi în cazul verificării controalelor pentru scurgerea de informații, identificarea defectelor de logică de afaceri și a vulnerabilităților contextuale. 
• Scanarea malware automată a artefactelor din ciclul de viață al dezvoltării face parte, de asemenea, din etapele care se concentrează pe prevenirea problemelor de securitate.

Ca parte a procesului Secure , procesul de lansare impune respectarea criteriilor de lansare, asigurând atât conformitatea cu procesul Secure , cât și securitatea generală a produsului, pe baza rezultatelor obținute în urma testării și verificării securității aplicației. Gestionarea versiunilor produsului joacă un rol crucial în menținerea îmbunătățirilor de securitate de la o versiune la alta, în prevenirea regresiei legate de securitate și în menținerea nivelului de securitate atins, ca cerință fundamentală pentru fiecare versiune. 

Procesul de lansare include generarea de rapoarte interne de lansare, care documentează riscurile reziduale și orice probleme de securitate restante. Aceste rapoarte trebuie să fie aprobate în mod oficial de către șeful de produs. În plus, notele de lansare externe comunică modificările și corecțiile legate de securitate ca parte a lansării oficiale a produsului. 

Pentru produsele cloud, implementarea urmează o abordare automatizată de tip "fail to deploy", asigurându-se că sunt lansate numai build-uri securizate. Testarea și verificarea securității aplicațiilor sunt integrate în conducta de implementare, cu o strategie operațională de tip pull, mai degrabă decât push, consolidând validarea securității înainte de implementarea producției. 

Conform politicii de gestionare a SBOM, fiecare versiune include oBill of Materials (SBOM) Software Bill of Materials (SBOM) pentru a menține trasabilitatea provenienței componentelor, susținând transparența și securitatea lanțului de aprovizionare. Toate fișierele necesare lansării sunt arhivate în siguranță pentru a asigura accesibilitatea pe termen lung.

În conformitate cu politica de integritate a versiunilor, pentru a susține integritatea și securitatea versiunilor de produse, se aplică un sistem structurat de versionare (de exemplu, Semantic Versioning), care asigură o trasabilitate clară a modificărilor și o perioadă de păstrare definită pentru toate artefactele publicate, inclusiv documentația. Pentru a spori și mai mult securitatea, artefactele software sunt semnate digital sub numele companiei, cu amprente digitale SHA publicate care permit utilizatorilor să verifice autenticitatea și să detecteze orice încercare de falsificare. 

Documentația în versiuni însoțește fiecare versiune, oferind îndrumări detaliate privind metodele de verificare a integrității, procedurile de instalare sigură, cele mai bune practici de configurare și măsurile de întărire a sistemului. Aceste resurse ajută utilizatorii să implementeze eficient controalele de securitate, reducând potențialele suprafețe de atac. În plus, Acordul de licență pentru utilizatorul final (EULA) este inclus pentru a stabili obligațiile de conformitate și a menține transparența juridică. 

SBOM pentru produse individuale este furnizat clienților noștri la cerere. Contactați-ne.

Mediile de dezvoltare, testare și producție sunt separate în siguranță pentru a preveni accesul neautorizat. Fiecare mediu urmează linii de bază stricte de întărire și protocoale de securitate a punctelor finale. Mediile de dezvoltare trebuie să fie conforme cu politicile de securitate ale companiei.

Ca parte a protecției punctelor finale, toate dispozitivele deținute de OPSWAT sunt monitorizate în ceea ce privește vulnerabilitățile, software-ul instalat, patch-urile instalate și conformitatea cu politicile de securitate ale companiei. În caz de neconformitate, sunt luate măsuri restrictive pentru a limita accesul la resursele companiei. 

Resursele clasificate cu o categorie de risc ridicat pot fi accesate numai prin intermediul rutelor de acces controlat (VPN). Dispozitivele din afara rețelei companiei sunt obligate să utilizeze canale securizate pentru a accesa resursele de cercetare și dezvoltare.

Securitatea conductei CI/CD aderă la directive stricte de securitate pentru a atenua amenințările în evoluție. Sursa amenințărilor ar putea fi elemente de infrastructură învechite (cum ar fi sistemele de operare, instrumentele de analiză etc.), accesele neautorizate datorate controlului slab al privilegiilor și mediile slab izolate. Menținerea infrastructurii CI/CD la zi, verificată temeinic și controlată strict este o piatră de temelie a SDLC-ului nostru securizat. 

La nivel regional, serverele din SUA sunt utilizate pentru toate serviciile centralizate, inclusiv stocarea codului, conducta CI/CD, instrumentele de analiză și testare și semnarea securizată a artefactelor. Configurarea tuturor instrumentelor centralizate se află sub controlul departamentului R&D Operations. 

Aplicăm mecanisme de autentificare puternică (autentificare cu factori multipli - MFA) și controale de autorizare (control al accesului bazat pe roluri - RBAC). Sunt efectuate revizuiri periodice ale accesului și ale privilegiilor minime. 

Conductele noastre încorporează mai multe instrumente de automatizare a analizei și testării, inclusiv testarea statică a securității aplicațiilor (SAST), analiza compoziției Software (SCA), testarea dinamică a securității aplicațiilor (DAST), scanarea secretă și scanarea malware-ului. 

În soluția noastră securizată de semnare a codului, folosim module de securitate Hardware (HSM) pentru a proteja materialul cheie împotriva accesului neautorizat și pentru a genera semnătura. Soluția de semnare face parte din infrastructura CI/CD, dar există o segmentare a rețelei. Numai operațiunile de cercetare și dezvoltare sunt autorizate să acceseze HSM-urile pentru perioade scurte. Fiecare acțiune de semnare este înregistrată și poate fi revizuită în timpul unei piste de audit. 

Setul de instrumente utilizat pentru construirea, compilarea sau testarea software-ului trebuie să conțină informații privind proveniența și să provină dintr-o sursă validată. Numărul instrumentelor utilizate în fluxul CI/CD este limitat; se instalează doar instrumentele necesare. Pentru etapele de compilare și construire din cadrul fluxului este permisă utilizarea exclusivă a software-ului LTS. În cadrul operării serviciilor centralizate, sunt definite perioade regulate de întreținere și de rotație a cheilor. Instrumentele dezvoltate intern se încadrează în Procesul Secure .

Consolidarea mediului pentru toate serviciile centralizate este continuă, iar aceste cerințe de securitate sunt revizuite periodic. Orientările privind consolidarea sunt comunicate echipelor de produse pentru a se asigura că acestea sunt pregătite și își pot adapta procesele de dezvoltare în consecință. În cazul unui incident de securitate, se efectuează un RCA pentru a lua măsuri preventive și a actualiza aceste cerințe.

Protecția codului sursă este o parte esențială a dezvoltării de software pentru a garanta confidențialitatea și integritatea codului sursă în cadrul companiei. 

Codul sursă este stocat în conformitate cu principiul privilegiului minim, permițând accesul numai personalului și instrumentelor autorizate. Codul sursă se află sub controlul versiunilor. Sistemul de gestionare a controlului versiunii garantează trasabilitatea și responsabilitatea modificărilor codului. Stocarea codului sursă este criptată cu criptografie conformă cu standardul FIPS 140-3 și protejată cu o lungime de cheie corespunzătoare.

Respectarea acestei politici este obligatorie pentru toate echipele interne. Acest document este subordonat politicilor companiei, ceea ce înseamnă că, în caz de contradicții, politicile companiei au prioritate și trebuie respectate. 

Procesul de escaladare a încălcărilor Secure : Orice încălcare a acestei politici este gestionată la nivel intern, începând cu departamentul de operațiuni de cercetare și dezvoltare și fiind escaladată până la directorul de produs (CPO), dacă este necesar.

Furnizorii care oferă componente sau servicii pentru produsele care intră sub incidența standardelor ISO 27001, SOC2 și NIST SSDF trebuie să respecte cerințele prezentate mai jos, prevăzute în Cadrul Secure . Conformitatea este supusă unor audituri periodice de securitate, evaluărilor efectuate de terți și obligațiilor fiecărei părți prevăzute în contractele încheiate. 

Toți furnizorii trebuie să furnizeze informații privind proveniența și integritatea, împreună cu documente justificative, astfel cum sunt definite în secțiunea Integritatea versiunii. 

Furnizorii de componente de produs și biblioteci trebuie să creeze medii de dezvoltare conforme cu practicile noastre, așa cum sunt descrise în secțiunea „Mediul Secure ”. Aceștia trebuie să efectueze teste de securitate asupra componentelor și bibliotecilor lor, conform descrierii din secțiunea „Testarea și verificarea securității aplicațiilor”. 

Furnizorii de componente pentru conducte trebuie, de asemenea, să creeze medii de dezvoltare conforme cu practicile noastre, așa cum sunt descrise în secțiunea „Mediul Secure ”. În plus, procesele lor de dezvoltare trebuie să fie conforme cu procesul Secure OPSWAT. 

Se așteaptă ca furnizorii de servicii să utilizeze medii situate în SUA, care să ofere un nivel de securitate comparabil cu OPSWATserviciilor OPSWAT. Secure lor Secure trebuie să includă atât un program Secure , cât și un proces Secure care să reflecte așteptările OPSWAT.