Cadrul SDLC Secure al OPSWAT:Un angajament față de reziliență și securitate Defense-in-Depth

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 SDLC al OPSWATdefinește metodologii structurate și principii de securitate care ghidează dezvoltarea sigură a software-ului. 

OPSWAT urmează ciclul de viață Agile Software Development Lifecycle. Pentru a fi în deplină conformitate cu cerințele clienților noștri, am adoptat cadrul Secure SDLC în conformitate cu cerințele de reglementare și standardele internaționale. Această abordare consolidează angajamentul nostru față de îmbunătățirea continuă și reziliența într-un peisaj al securității cibernetice în continuă evoluție.

Cadrul SDLC Secure al OPSWATse bazează pe NIST SP 800-218 SSDFSecure Software Development Framework), asigurând că securitatea este structurată, măsurabilă și aplicată în mod consecvent în toate etapele procesului de dezvoltare software.  

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 privind securitatea cibernetică continuă să evolueze, OPSWAT își menține angajamentul de a-și alinia cadrul Secure SDLC la cerințele de reglementare globale, începând cu Legea UE privind reziliența cibernetică și Directiva NIS2. Prin adaptarea proactivă la standardele emergente, OPSWAT se asigură că Secure SDLC rămâne cuprinzător, conform și rezistent într-un peisaj de reglementare tot mai complex.

Menținerea unei securități solide a informațiilor este esențială atât pentru integritatea operațională, cât și pentru conformitatea cu reglementările. Cadrul Secure SDLC al OPSWAT încorporează principiile ISO 27001 ISMS (Information Security Management System), 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 SDLC al OPSWATeste integrat în sistemul de management al calității (QMS) ISO 9001. QMS stabilește controale de calitate auditate pentru guvernanță, gestionarea schimbărilor și procese interfuncționale, sprijinind definirea, proiectarea, dezvoltarea, producția și întreținerea ofertelor de produse și asistență, extinzându-se dincolo de cercetare și dezvoltare la domenii precum vânzările, asistența pentru clienți, tehnologia informației și resursele 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 SDLC al OPSWAT transpune cadrul Secure SDLC într-o guvernanță structurată, asigurându-se că cerințele de securitate sunt documentate, menținute, măsurate și îmbunătățite în mod continuu, asigurându-se totodată că toate părțile implicate primesc o formare adecvată. Programul stabilește roluri, responsabilități și măsuri de securitate pentru mediile de dezvoltare, testare și producție, precum și securitatea conductelor, definind mediul de dezvoltare Secure și impunând aplicarea politicilor de securitate în cadrul procesului SDLC Secure .

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

Chief Product Officer (CPO) este responsabil pentru supravegherea strategică și aplicarea programului SDLC Secure în toate echipele de produse, precum și în alte programe de cercetare și dezvoltare (R&D), cum ar fi programul de asigurare a calității (QA) și programul de experiență a utilizatorului (UX), asigurând o abordare coerentă a dezvoltării software sigure, de înaltă calitate și centrate pe utilizator.

În calitate de proprietar principal al riscurilor pentru toate produsele și procesele de cercetare și dezvoltare, CPO mandatează operațiunile de cercetare și dezvoltare să dețină programul SDLC Secure și se asigură că liderii de produs impun aplicarea programului SDLC Secure și implementează în mod eficient procesul SDLC Secure în echipele de produs. În acest rol, CPO aprobă modificarea programului Secure SDLC și abaterile de la procesul Secure SDLC.

De asemenea, CPO monitorizează rezultatele programului Secure SDLC, urmărind maturitatea securității, vulnerabilitățile, conformitatea și activitățile de dezvoltare pentru a menține o poziție de securitate puternică a produselor.

În plus, CPO este responsabil pentru alocarea și aprobarea bugetului de securitate pentru cercetare și dezvoltare, asigurându-se că resursele adecvate sunt dedicate programului SDLC 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.

Ca parte a programului Secure SDLC, pe lângă cursurile generale de conștientizare în materie de securitate ale companiei, toate persoanele implicate în dezvoltarea securizată sunt obligate să urmeze cursuri de securitate specifice fiecărui rol. Toate instruirile sunt urmărite în instrumentele de instruire ale companiei. Programele de formare și conștientizare sunt revizuite periodic pentru a încorpora noile tendințe în materie de securitate și pentru a asigura conformitatea permanentă cu standardele de securitate.

OPSWAT se angajează să își îmbunătățească continuu programul SDLC Secure prin măsurarea structurată a performanței, evaluări ale maturității ș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 situația securității aplicațiilor, OPSWAT evaluează echipele utilizând indicatori structurați. Maturitatea securității produsului este evaluată pentru fiecare echipă pe baza cadrului SAMM, oferind o măsură cuantificabilă a progresului în materie de securitate. În plus, produsele sunt supuse unei evaluări a conformității ASVS pentru a asigura respectarea cerințelor de verificare a securității. Conformitatea cu Secure SDLC Process este monitorizată îndeaproape, evaluată, iar atingerea obiectivelor KPI se bazează pe dovezi, asigurând că poziția de securitate și îmbunătățirile de securitate sunt atât măsurabile, cât și realizabile. Toate echipele de produse trebuie să atingă 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 efectuează o revizuire anuală a cadrului Secure SDLC, încorporând informații din analizele cauzelor profunde ale incidentelor de securitate din trecut, evaluări ale tendințelor în materie de vulnerabilitate și îmbunătățiri ale 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 SDLC Secure operaționalizează în continuare programul SDLC Secure prin definirea controalelor de securitate pe care echipele trebuie să le urmeze, inclusiv activități specifice, cum ar fi controalele de securitate automatizate și mecanismele de verificare la fiecare fază de dezvoltare. Acest proces este aliniat cu alte programe-cheie de cercetare și dezvoltare, cum ar fi programul de asigurare a calității și programul privind experiența utilizatorului, asigurând o abordare coerentă a dezvoltării de software sigur, de înaltă calitate și orientat către client. 

Procesul SDLC Secure este detaliat în următoarele secțiuni:

• Proiectare Secure și evaluare a riscurilor
• Implementare, construcție și implementare Secure
• Testarea și verificarea securității aplicațiilor
• Eliberare Secure
• Operațiuni și întreținere Secure

Procesul SDLC Secure este un proces de nivel înalt, pe care echipele îl pot implementa într-un mod personalizat extins, cu condiția ca securitatea procesului să fie menținută la același nivel minim. Abaterile de la Secure SDLC Process trebuie documentate și aprobate.

Programul Secure SDLC cuprinde diverse politici care trebuie aprobate și recunoscute oficial de echipele de produs pentru a asigura conformitatea cu cerințele acestuia. Aderarea la aceste politici este obligatorie la nivel intern, iar fiecare echipă este responsabilă de revizuirea, semnarea și punerea în aplicare a acestora ca parte a proceselor 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.

Ca parte a procesului Secure SDLC, cerințele de securitate sunt urmărite, documentate și menținute pe tot parcursul ciclului de viață al dezvoltării. Furnizorii terți sunt obligați să recunoască și să respecte ASVS, asigurând consecvența așteptărilor în materie de securitate și respectarea politicii de respectare a confidențialității produselor în toate componentele software. 

Securitatea este încorporată în fiecare fază a ciclului de viață al dezvoltării. Este responsabilitatea campionilor de securitate să țină seama de așteptările procesului SDLC Secure și să le reprezinte în cadrul echipelor lor. 

Setul de cerințe privind proiectarea Secure include cerințe de securitate funcționale și nefuncționale bazate pe ASVS. Modelele de referință sunt furnizate de R&D Operations pentru a sprijini deciziile de proiectare, împreună cu ajustări documentate ale cerințelor ASVS, dacă este necesar (de exemplu, cerințe de criptare mai stricte).

Modelarea amenințărilor este un proces structurat pentru identificarea amenințărilor și vulnerabilităților în primele etape ale ciclului de viață al dezvoltării. Este o parte integrantă a procesului SDLC Secure , realizat în mod regulat - cel puțin o dată pe an sau ori de câte ori sunt introduse noi caracteristici sau modificări arhitecturale. Echipele de produs realizează modelarea amenințărilor prin definirea obiectivelor de securitate, identificarea activelor ș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 SDLC Secure , care include implementarea, construirea și implementarea, se urmărește prevenirea vulnerabilităților și a defectelor, pe baza concepției 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, dezvoltarea sigură și metodologia de testare bazată pe mediul de dezvoltare Secure .  

În timpul implementării, trebuie aplicate cele mai bune practici de codare Secure , revizuirea codurilor Secure și detectarea timpurie a deficiențelor de securitate. Echipele trebuie să adere la politica de securitate a Supply Chain (inclusiv la subiectele privind integrarea furnizorilor și software-ul open source), la politica de utilizare a IA și la politica de gestionare a mostrelor de malware. În timpul construirii și implementării este necesară construirea și implementarea Secure cu utilizarea centralizată a conductei CI/CD ș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.

Ca parte a analizelor de securitate impuse de politica de verificare a securității aplicațiilor, analiza codului securizat este importantă și executată în funcție de tehnologia de dezvoltare, fiind aplicate diverse liste de verificare a analizei codului Secure pe baza serieiOWASP 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.

Ca parte a procesului SDLC Secure , utilizarea unei conducte CI/CD centralizate și orchestrate este obligatorie pentru a impune compilări sigure și pentru a evita atacurile din lanțul de aprovizionare. Jurnalele de audit, construcție și implementare sunt generate, păstrate și revizuite în conformitate cu 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.

În conformitate cu politica noastră de verificare a securității aplicațiilor, implementăm documentația formală și urmărirea problemelor descoperite și atribuim instrumente automate pentru verificarea continuă. Ca parte a procesului Secure SDLC, verificările de securitate sunt aplicate și urmărite în fiecare etapă a SDLC pentru a îndeplini cerințele de conformitate. Scopul acestora este de a găsi în mod eficient posibilele deficiențe de securitate. Problemele de securitate apărute sunt investigate de echipe și abordate în termenele stabilite. Termenele fac parte din KPI-urile de securitate definite.

• 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 SDLC Secure , procesul de lansare pune în aplicare criteriile de lansare, asigurând atât respectarea procesului SDLC Secure , cât și securitatea generală a produsului, pe baza constatărilor din cadrul testării și verificării securității aplicațiilor. Versiunea produsului joacă un rol crucial în menținerea îmbunătățirilor de securitate în cadrul versiunilor, în prevenirea regresiei legate de securitate și în menținerea posturii de securitate obținute, ca o 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ă aibă informații de proveniență și să provină dintr-o sursă validată. Instrumentele utilizate în conducta CI/CD sunt în număr limitat; sunt instalate numai instrumentele necesare. Numai software-ul LTS este permis pentru etapele de compilare și de construire din pipeline. În funcționarea serviciilor centralizate, sunt definite perioade regulate de întreținere și de rotație a cheilor. Instrumentele dezvoltate intern intră sub incidența procesului SDLC 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 pentru încălcările Secure SDLC: Orice încălcare a acestei politici este tratată la nivel intern, începând cu operațiunile de cercetare și dezvoltare și ajungând până la Chief Product Officer (CPO), după caz.

Furnizorii care furnizează componente sau servicii pentru produsele care intră în domeniul de aplicare al ISO 27001, SOC2, NIST SSDF trebuie să respecte cerințele prezentate mai jos din Secure SDLC Framework. Conformitatea face obiectul auditurilor periodice de securitate, al evaluărilor efectuate de terți și al obligațiilor fiecărei părți în temeiul contractelor î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 și biblioteci de produse trebuie să creeze medii de dezvoltare aliniate la practicile noastre, astfel cum sunt descrise în secțiunea Mediul de dezvoltare Secure . Aceștia trebuie să efectueze teste de securitate pentru componentele și bibliotecile lor, astfel cum este descris în secțiunea Testarea și verificarea securității aplicațiilor. 

Furnizorii de componente pentru conducte trebuie, de asemenea, să creeze medii de dezvoltare aliniate la practicile noastre, astfel cum sunt descrise în secțiunea Mediul de dezvoltare Secure . În plus, procesele lor de dezvoltare trebuie să se alinieze la procesul SDLC Secure al OPSWAT. 

Se așteaptă ca furnizorii de servicii să utilizeze medii bazate în SUA care oferă o poziție de securitate comparabilă cu serviciile OPSWAT. SDLC-ul lor Secure trebuie să includă atât un program SDLC Secure , cât și un proces SDLC Secure care să reflecte așteptările OPSWAT.