Az OPSWAT Secure SDLC keretrendszere:A rugalmasság és a mélyreható védelem iránti elkötelezettség

A rosszindulatú szereplők nyereségvágyból vagy a rendszer megzavarása céljából veszik célba a rendszereket, ami a szervezetek számára költségeket, üzleti kockázatokat és hírnevük romlását eredményezi. 

Egy nemrégiben készült felmérés szerint egy biztonsági hiba javításának költsége 30-szor magasabb, ha azt a gyártás során fedezik fel, mint az elemzési és követelményfázisban.

Az OPSWAT Secure SDLC keretrendszere strukturált módszertanokat és biztonsági elveket határoz meg, amelyek a biztonságos szoftverfejlesztést irányítják. 

OPSWAT az agilis Software életciklust követi. Annak érdekében, hogy teljes mértékben megfeleljünk ügyfeleink követelményeinek, a Secure SDLC keretrendszert a szabályozási követelményeknek és a nemzetközi szabványoknak megfelelően fogadtuk el. Ez a megközelítés megerősíti elkötelezettségünket a folyamatos fejlesztés és a rugalmasság iránt a fejlődő kiberbiztonsági környezetben.

Az OPSWAT Secure SDLC keretrendszere a NIST SP 800-218 SSDF-reSecure Software Development Framework) épül, biztosítva, hogy a biztonság strukturált, mérhető és következetesen alkalmazott legyen a szoftverfejlesztési folyamat minden szakaszában.  

Az SSDF legjobb gyakorlatainak integrálásával az OPSWAT proaktív biztonsági hozzáállást tart fenn, és a biztonságot a szoftverfejlesztés minden fázisába beágyazza - a tervezéstől és kialakítástól a megvalósításig, az ellenőrzésig és a folyamatos felügyeletig. 

Az egyes termékek megfelelőségének tanúsítását igény szerint biztosítjuk amerikai szövetségi kormányzati ügyfeleink számára. Lásd az alábbi elérhetőségeket.

Mivel a kiberbiztonsági előírások folyamatosan fejlődnek, OPSWAT továbbra is elkötelezett a Secure SDLC keretrendszerének a globális szabályozási követelményekkel való összehangolása mellett, kezdve az EU kiberbiztonságról szóló törvényével és a NIS2 irányelvvel. A kialakulóban lévő szabványokhoz való proaktív alkalmazkodással az OPSWAT biztosítja, hogy a Secure SDLC átfogó, megfelelő és rugalmas maradjon az egyre összetettebb szabályozási környezetben.

A megbízható információbiztonság fenntartása kritikus fontosságú mind a működési integritás, mind a jogszabályi megfelelés szempontjából. Az OPSWAT Secure SDLC keretrendszere magában foglalja az ISO 27001 ISMS (Information Security Management System) elveit, biztosítva, hogy a biztonsági ellenőrzések, kockázatkezelési stratégiák és megfelelőségi intézkedések zökkenőmentesen integrálódjanak felhőtermékeink működésébe. 

Biztonsági megoldásaink szolgáltatójaként és fogyasztójaként OPSWAT a vállalaton belül érvényesített biztonsági irányelveket alkalmazza, így biztosítva, hogy tanúsított termékeink a telepítés előtt megfeleljenek a vállalati szintű biztonsági elvárásoknak.  

További részletek a Megfelelés és tanúsítványok oldalon.

A legmagasabb szintű szoftverminőség biztosítása érdekében az OPSWAT Secure SDLC keretrendszerét az ISO 9001 QMS (minőségirányítási rendszer) rendszerébe integrálták. A QMS auditált minőségellenőrzéseket hoz létre az irányítás, a változáskezelés és a funkcionalitáson átívelő folyamatok tekintetében, támogatva a termék- és támogatási kínálat meghatározását, tervezését, fejlesztését, gyártását és karbantartását, a kutatás-fejlesztésen túlmenően olyan területekre is kiterjedően, mint az értékesítés, az ügyféltámogatás, az informatika és a humán erőforrás.  

Ez a megközelítés megerősíti elkötelezettségünket a minőségirányítás strukturált, kockázatalapú megközelítése mellett, biztosítva, hogy az alkalmazásbiztonság továbbra is szerves részét képezze az összes üzleti funkciónak.

További részletek a Megfelelés és tanúsítványok oldalon.

Az OWASP Software Assurance Maturity Model (SAMM) egy olyan átfogó keretrendszer, amelynek célja, hogy segítse a szervezeteket a hatékony szoftverbiztonsági stratégiák értékelésében, kialakításában és megvalósításában a meglévő SDLC-n belül.

Nyílt forráskódú keretrendszerként a SAMM globális hozzájárulásokból profitál, így biztosítva az alkalmazások biztonságának közös, folyamatosan fejlődő megközelítését. Strukturált módszertana lehetővé teszi a szervezetek számára, hogy hatékonyan és mérhető módon elemezzék és javítsák fejlesztési életciklusukat. A SAMM támogatja a teljes fejlesztési életciklust. A SAMM technológia- és folyamatfüggetlen. A SAMM fejlődőképes és kockázatalapú. A SAMM kihasználásával a csapatok használható betekintést nyernek a biztonsági hiányosságokba, és a fejlesztési életciklus során szisztematikusan javíthatják biztonsági helyzetüket.

Az OWASP Application Security Verification Standard (ASVS) egy világszerte elismert keretrendszer, amelynek célja a webes alkalmazások biztonságának strukturált, mérhető és megvalósítható megközelítése. A fejlesztők és a biztonsági csapatok számára átfogó biztonsági követelményrendszert és ellenőrzési irányelveket biztosít, hogy az alkalmazások megfeleljenek az iparági legjobb gyakorlatoknak. 

Nyílt forráskódú keretrendszer lévén az ASVS a globális biztonsági közösség széleskörű hozzájárulásából profitál, ami biztosítja, hogy naprakész maradjon az újonnan megjelenő fenyegetésekkel és a fejlődő biztonsági szabványokkal.

Az OPSWAT Secure SDLC programja a Secure SDLC keretrendszert strukturált irányítássá alakítja át, biztosítva a biztonsági követelmények dokumentálását, karbantartását, mérését és folyamatos fejlesztését, valamint azt, hogy minden érintett fél megfelelő képzésben részesüljön. Meghatározza a fejlesztési, tesztelési és termelési környezetek szerepeit, felelősségi körét és biztonsági intézkedéseit, valamint a csővezeték biztonságát, meghatározza a Secure fejlesztési környezetet, és előírja a biztonsági irányelvek alkalmazását a Secure SDLC-folyamaton belül.

Magas szintű vezetés - Chief Product Officer (CPO)

A Chief Product Officer (CPO) felelős a Secure SDLC program stratégiai felügyeletéért és érvényesítéséért az összes termékcsapatban, valamint más kutatási és fejlesztési (K+F) programokban, mint például a minőségbiztosítási (QA) program és a felhasználói élmény (UX) program, biztosítva a biztonságos, magas minőségű és felhasználó-központú szoftverfejlesztés egységes megközelítését.

Az összes termék és K+F folyamat elsődleges kockázattulajdonosaként a CPO megbízza a K+F műveleteket, hogy a Secure SDLC-programot sajátítsák el, és biztosítja, hogy a termékvezetők érvényre juttassák a Secure SDLC-program alkalmazását és a Secure SDLC-folyamat hatékony végrehajtását a termékcsapatokban. Ebben a szerepkörben a CPO jóváhagyja a Secure SDLC program módosítását és a Secure SDLC folyamattól való eltéréseket.

A CPO felügyeli a Secure SDLC program eredményeit is, nyomon követi a biztonsági érettséget, a sebezhetőségeket, a megfelelőséget és a fejlesztési tevékenységeket a termékek erős biztonsági helyzetének fenntartása érdekében.

A CPO felel továbbá a K+F biztonsági költségvetés elosztásáért és jóváhagyásáért, biztosítva, hogy a megfelelő erőforrások a Secure SDLC programhoz legyenek rendelve.

Stratégiai prioritások

OPSWATalkalmazásbiztonsági stratégiai terve összhangban van az üzleti prioritásokkal és a kockázatvállalási hajlandósággal, figyelembe véve az egyes termékek érettségi szintjét és a biztonsági fenyegetéseknek való kitettségét. Az elsődleges hangsúly a magas kockázatú termékek védelmére helyeződik, különösen a nagy ügyfélkörrel rendelkező, a nyilvánosság számára elérhető vagy a kritikus infrastruktúrába integrált termékek esetében.

A Secure SDLC program részeként a vállalat általános biztonságtudatossági képzései mellett a biztonságos fejlesztésben részt vevő összes munkatárs számára szerepkör-specifikus biztonsági képzést írnak elő. Minden képzést nyomon követnek a vállalat képzési eszközeiben. A képzési és tudatossági programokat rendszeresen felülvizsgálják az új biztonsági trendek beépítése és a biztonsági szabványoknak való folyamatos megfelelés biztosítása érdekében.

OPSWAT elkötelezett a Secure SDLC program folyamatos fejlesztése mellett, amely strukturált teljesítménymérés, érettségi értékelések és rendszeres frissítések révén biztosítja a folyamatos biztonsági hatékonyságot.  

Az erős biztonsági helyzet fenntartása érdekében OPSWAT szisztematikus megközelítést alkalmaz a biztonsági teljesítmény nyomon követésére és javítására. Ez magában foglalja a negyedéves termékbiztonsági érettségi értékeléseket, a legjobb gyakorlatok betartásának ellenőrzésére szolgáló belső biztonsági felülvizsgálatokat, valamint az éves kulcsfontosságú teljesítménymutatók (KPI-k) meghatározását, amelyeket negyedévente mérnek.  

Az alkalmazásbiztonsági helyzet hatékony mérése érdekében OPSWAT strukturált mérőszámok segítségével értékeli a csapatokat. A termékbiztonsági érettséget csapatonként értékelik a SAMM keretrendszer alapján, ami a biztonsági fejlődés számszerűsíthető mérőszámát adja. Ezen túlmenően a termékek ASVS-megfelelőségi értékelésen is átesnek a biztonsági ellenőrzési követelmények betartásának biztosítása érdekében. A Secure SDLC-folyamatnak való megfelelést szorosan nyomon követik, értékelik, és a KPI-célok elérését bizonyítékokon alapuló módon ellenőrzik, biztosítva, hogy a biztonsági helyzet és a biztonsági fejlesztések mérhetőek és megvalósíthatóak legyenek. Minden termékcsapatnak teljesítenie kell a biztonsági érettségi célokat az éves teljesítményértékelés részeként. 

A folyamatos fejlesztésre irányuló erőfeszítések részeként OPSWAT rendszeresen új termékbiztonsági kezdeményezéseket vezet be az érettségi szint növelése és az alkalmazásbiztonság megerősítése érdekében. Ezek a kezdeményezések magukban foglalják a biztonsági irányelvek frissítését az újonnan megjelenő fenyegetések kezelése érdekében, új biztonsági eszközök integrálását a fokozott észlelés és megelőzés érdekében, valamint a KPI-célkitűzések bővítését a folyamatos fejlődés előmozdítása érdekében. 

A biztonsági irányítás további megerősítése érdekében OPSWAT évente felülvizsgálja a Secure SDLC keretrendszert, beépítve a korábbi biztonsági incidensek gyökeres okainak elemzéséből, a sebezhetőségi trendek értékeléséből, valamint a meglévő folyamatok és irányelvek finomításából származó felismeréseket.  

Ez a folyamatos fejlesztésre irányuló strukturált megközelítés biztosítja, hogy OPSWAT proaktív és rugalmas termékbiztonsági helyzetet tartson fenn, hatékonyan alkalmazkodva a változó kiberbiztonsági kihívásokhoz, miközben megfelel mind a szabályozási, mind az üzemeltetési biztonsági célkitűzéseknek.

A Secure SDLC folyamat tovább operacionalizálja a Secure SDLC programot azáltal, hogy meghatározza a csapatok által követendő biztonsági ellenőrzéseket, beleértve az olyan konkrét tevékenységeket, mint az automatizált biztonsági ellenőrzések és ellenőrzési mechanizmusok minden egyes fejlesztési fázisban. Ez a folyamat összhangban van más kulcsfontosságú K+F programokkal, például a Minőségbiztosítási programmal és a Felhasználói élmény programmal, biztosítva a biztonságos, magas minőségű és ügyfélközpontú szoftverfejlesztés egységes megközelítését. 

A Secure SDLC folyamatot a következő szakaszok részletezik:

• Secure tervezés és kockázatértékelés
• Secure megvalósítás, építés és telepítés
• Alkalmazásbiztonsági tesztelés és ellenőrzés
• Secure kiadás
• Secure üzemeltetés és karbantartás

A Secure SDLC folyamat egy magas szintű folyamat, a csapatok kibővített, testreszabott módon is megvalósíthatják, azzal a feltétellel, hogy a folyamat biztonságát a minimális szinten kell tartani. A Secure SDLC-folyamtól való eltérést dokumentálni és jóváhagyni kell.

A Secure SDLC program különböző irányelveket tartalmaz, amelyeket a termékcsapatoknak hivatalosan jóvá kell hagyniuk és el kell ismerniük, hogy biztosítsák a program követelményeinek való megfelelést. Ezeknek a szabályzatoknak a betartása belsőleg kötelező, és minden csapat felelős ezek felülvizsgálatáért, aláírásáért és végrehajtásáért a fejlesztési folyamatok részeként. 

Az alábbiakban felsoroljuk a legfontosabb irányelveket és azok céljait. A külső jelentőséggel bíró politikák esetében további részletek szerepelnek ebben a dokumentumban.

A Secure SDLC-folyamat részeként a biztonsági követelményeket a fejlesztési életciklus során nyomon követik, dokumentálják és karbantartják. A harmadik fél beszállítóktól megkövetelik az ASVS elismerését és betartását, biztosítva a biztonsági elvárások következetességét és a termék adatvédelmi megfelelőségi politikájának betartását minden szoftverkomponensben. 

A biztonságot a fejlesztési életciklus minden fázisába beépítjük. A biztonsági bajnokok felelőssége, hogy szem előtt tartsák a Secure SDLC-folyamat elvárásait, és képviseljék azokat a csapatukban. 

A Secure tervezés követelménykészlete ASVS-alapú funkcionális és nem funkcionális biztonsági követelményeket tartalmaz. A K+F műveletek referencia-modelleket biztosítanak a tervezési döntések támogatására, valamint szükség esetén az ASVS követelmények dokumentált módosítására (pl. erősebb titkosítási követelmények).

A fenyegetésmodellezés egy strukturált folyamat a fenyegetések és sebezhetőségek azonosítására a fejlesztési életciklus legkorábbi szakaszaiban. Ez a Secure SDLC-folyamat szerves részét képezi, és rendszeresen - legalább évente egyszer, illetve új funkciók vagy architektúrális változások bevezetésekor - végzik. A termékcsapatok a fenyegetések modellezését a biztonsági célok meghatározásával, az eszközök és függőségek azonosításával, a lehetséges támadási forgatókönyvek elemzésével és az azonosított fenyegetések mérséklésével végzik.  

A továbbfejlesztett megközelítés magában foglalja az adatáramlás elemzését és a bevált veszélymodellezési gyakorlatokat (pl. a STRIDE-modell), biztosítva a termékek átfogó értékelését. Szükség esetén biztonsági felülvizsgálatokat kezdeményeznek a biztonsági követelményeknek való megfelelés érvényesítésére és a potenciális kockázatok proaktív kezelésére. A tervezési döntéseket gondosan dokumentálják, és a fennmaradó kockázatokat a termék életciklusa során folyamatosan nyomon követik.

Az alkalmazásbiztonsági kockázatokat több forrásból értékelik, beleértve a fenyegetések modellezése során azonosított maradék fenyegetéseket, a széles körben elismert biztonsági réseket, például az OWASP Top 10 és a SANS Top 25 listáján szereplő réseket, valamint az ASVS-irányelvek alapján hiányzó biztonsági ellenőrzéseket. További kockázati tényezők közé tartoznak a titokkezelés gyengeségei az építési, telepítési és kiadási folyamatok során, valamint a nyílt forráskódú és harmadik féltől származó komponensek sebezhetőségei. 

A kockázatértékelést követően az azonosított kockázatok súlyosságának csökkentésére enyhítési terveket dolgoznak ki, figyelembe véve mind a hatást, mind a valószínűséget. Ezeket a terveket, valamint a megfelelő kockázatokat és a kockázatcsökkentési lépéseket alaposan dokumentálják. 

A fennmaradó kockázatokat a termék teljes életciklusa során nyomon követik, és időszakosan felülvizsgálják, és a kockázat tulajdonosainak hivatalosan el kell ismerniük. A láthatóság és az elszámoltathatóság fenntartása érdekében ezeket a belső kiadási jelentésekbe is beépítik. 

Szükség esetén biztonsági felülvizsgálatokat kezdeményeznek a biztonsági követelményeknek való megfelelés biztosítása és a potenciális kockázatok proaktív kezelése érdekében, megerősítve a termék általános biztonsági helyzetét.

A Secure SDLC folyamat részeként, beleértve a megvalósítást, az építést és a telepítést, a cél a sebezhetőségek és hibák megelőzése a Secure tervezés és kockázatértékelés alapján. A követelményrendszer tartalmazza az ASVS-alapú funkcionális és nem funkcionális biztonsági követelményekre, a biztonságos fejlesztésre és a Secure fejlesztési környezetre támaszkodó tesztelési módszertanra vonatkozó elvárásokat.  

A megvalósítás során a Secure kódolás legjobb gyakorlatait, a Secure kód felülvizsgálatát és a biztonsági hibák korai felismerését kell alkalmazni. A csapatoknak be kell tartaniuk az Supply Chain biztonsági szabályzatát (beleértve a szállítók felvételét és a nyílt forráskódú szoftverekkel kapcsolatos témákat) , a mesterséges intelligencia felhasználási szabályzatát és a rosszindulatú szoftverek mintáinak kezelési szabályzatát. Az építés és telepítés során Secure építés és telepítés szükséges, központosított CI/CD csővezeték használatával és a feladatok szétválasztásával.

A termékcsapatoknak a megvalósítás során a nyelvfüggetlen biztonságos kódolási legjobb gyakorlatokat kell követniük. Kötelesek validálni a bemeneti adatokat, szanálni a más rendszereknek küldött adatokat, kiküszöbölni a fordítói figyelmeztetéseket, biztonságos hibaüzeneteket beállítani, adott esetben kimeneti kódolást alkalmazni, biztonságos naplózást megvalósítani anélkül, hogy érzékeny adatokat fednének fel, és követni a megfelelő hibakezelési és kivételkezelési irányelveket. A csapatoknak azt is biztosítaniuk kell, hogy a kriptográfia, ha használják, jóváhagyott algoritmusokra és biztonságos véletlenszám-generálásra támaszkodjon, és biztonságosan kezeljék a rendszer erőforrásait a memória biztonságos kezelésével, a versenyfeltételek megelőzésével és a holtpontok megfelelő szinkronizálással történő elkerülésével. 

A termékcsapatoknak ajánlott a nyelvspecifikus biztonságos kódolási irányelvek követése is, amelyeket a SAST-eszközök kényszerítenek ki, amint azt az alábbiakban példaként bemutatjuk: 

A Java esetében a csapatoknak biztosítaniuk kell, hogy az összehasonlítási műveletekben használt kulcsok megváltoztathatatlanok legyenek, a Random helyett SecureRandom-ot használjanak, és a bemeneti osztályok validálásával vagy korlátozásával kerüljék el a nem biztonságos deserializálást.

C++-ban ajánlott a memória kiosztási hibák felismerése és kezelése, a puffer túlcsordulásának megakadályozása a határok ellenőrzésével és az intelligens mutatók, például az std::unique_ptr() használatával, valamint az olyan nem biztonságos függvények, mint a strcpy() és a sprintf() elkerülése. 

A Python esetében a fejlesztőknek kerülniük kell az olyan függvények használatát, mint az eval() vagy az exec(), hogy csökkentsék a kódbefecskendezési kockázatokat, és a nem megbízható adatok feldolgozásakor a biztonságos szerializációs formátumokat, például a json modult kell előnyben részesíteniük a pickle helyett.

Az alkalmazásbiztonsági ellenőrzési politika által előírt biztonsági felülvizsgálatok részeként a biztonságos kód felülvizsgálata fontos, és a fejlesztési technológiától függően különböző Secure kód felülvizsgálati ellenőrző listákat alkalmaznakaz OWASP csalólevél-sorozatalapján.

Az alkalmazásbiztonsági ellenőrzésre vonatkozó szabályzat előírásai szerint a biztonsági hibák korai felismerése a fejlesztési folyamat kritikus eleme. A potenciális biztonsági problémák minimalizálása érdekében kötelező a "fail to build" megközelítés, amely biztosítja, hogy a nem biztonságos kód ne haladjon tovább a csővezetéken. Emellett a "fail to merge" megközelítés is érvényesül, amely megköveteli a csapatoktól, hogy a változások integrálása előtt orvosolják az észlelt problémákat. Az észlelt hibák megoldása elengedhetetlen a kiadási kritériumok teljesítéséhez.

A Secure SDLC folyamat részeként a biztonságos építkezések kikényszerítése és az ellátási láncot érő támadások elkerülése érdekében kötelező a központosított, összehangolt CI/CD csővezeték használata. Az audit-, build- és telepítési naplókat a vállalati biztonsági irányelvekben meghatározottak szerint generálják, megőrzik és felülvizsgálják. 

Minden termékcsapat felelős a biztonságos építési és fordítói konfigurációk követéséért, ahol ez alkalmazható. Biztonságos fordítóopciókat kell használniuk, letiltaniuk a hibakódot, keményíteniük kell a futási időt az értelmezett nyelvek esetében, a függőségi verziókat, biztosítaniuk kell a reprodukálható buildeket, és keményíteniük kell a konténerképeket. Az alkalmazott konfigurációkat dokumentálni kell, és rendszeresen felül kell vizsgálni. 

A feladatok szétválasztásának elvével összhangban a fejlesztők és a csapat más, kód- vagy építési hozzáféréssel rendelkező tagjai nem férhetnek hozzá a termelési környezethez. Felhőalapú termékek esetében csak a termék telephelyi megbízhatósági mérnökei telepíthetnek a termelési környezetbe.

Alkalmazásbiztonsági ellenőrzési szabályzatunknak megfelelően hivatalos dokumentációt és nyomon követést vezetünk be a felfedezett problémákra vonatkozóan, és automatizált eszközöket rendelünk a folyamatos ellenőrzéshez. A Secure SDLC-folyamat részeként a biztonsági ellenőrzéseket az SDLC minden szakaszában érvényesítjük és nyomon követjük a megfelelőségi követelmények teljesítése érdekében. Ezek célja a lehetséges biztonsági hibák hatékony felderítése. A felmerülő biztonsági problémákat a csapatok kivizsgálják és határidőn belül kezelik. Az időkeretek a meghatározott biztonsági KPI-k részét képezik.

• Építészeti és tervezési vélemények: A vezető mérnökök és az alkalmazásbiztonsági virtuális csapat tagjai értékelik a tervezési változtatások biztonsági szempontjait, beleértve a titkosítást, hitelesítést, engedélyezést, ellenőrzést, a rendszer keményítését, a rendszer- és hálózati architektúrát. 
• Kódexellenőrzések: a kollégák és vezető mérnökök által végzett rendszeres kódellenőrzéseken felül az Application Security Virtual Team tagjai felülvizsgálják a változtatásokat, hogy megelőzzék az olyan gyakori hibákat, mint az injektálás, a hibakezelés és a bizonytalan konfigurációk.

• Titokvizsgálat a titok kiszivárgásának elkerülése, valamint a titokkezelés megfelelő tervezésének és biztonságos végrehajtásának biztosítása érdekében.
• SAST (Static Application Security Testing) eszközök a sebezhetőségek (pl. SQL Injection, Buffer Overflow) felderítésére.
• Az SCA (Software Composition Analysis) a nyílt forráskódú sebezhetőségek felderítésére szolgál.
• A DAST (Dynamic Application Security Testing) a futásidejű (pl. memóriahibák) és környezeti problémák keresésére szolgál.

A biztonsági problémák korai észlelése szakaszban meghatározott eszközöket kötelező használni a CI/CD-csatornában. Minden azonosított sebezhetőséget a termék Vulnerability Management szabályzatának megfelelően kell kijavítani.

A biztonsági tesztelési tervet végrehajtó minőségbiztosítási programmal összhangban automatizált és manuális biztonsági tesztelési módszereket egyaránt alkalmaznak.

• A DAST eszközöket a futási idejű sebezhetőségek felderítésére, az alapértelmezett konfigurációk tesztelésére és a rendszer ellenálló képességének tesztelésére használják, miután alkalmazták a keményítési javaslatokat. A tesztek mind a szoftverre, mind a mögöttes infrastruktúrára irányulnak. 
• A biztonsági követelmények és funkciók visszafejlődésének elkerülése érdekében automatizált tesztelési eszközöket használunk a biztonsági funkciók és ellenőrzések integritásának folyamatos ellenőrzésére. 
• A kézi tesztelést ott alkalmazzák, ahol az automatizált eszközök nem elégségesek, például az információszivárgás ellenőrzésénél, az üzleti logikai hibák és a kontextuális sebezhetőségek azonosításánál. 
• A fejlesztési életciklusban lévő artefaktumok automatikus rosszindulatú szoftverek vizsgálata szintén része azoknak a lépéseknek, amelyek a biztonsági problémák megelőzésére összpontosítanak.

A Secure SDLC folyamat részeként a kiadási folyamat a kiadási kritériumokat érvényesíti, biztosítva mind a Secure SDLC folyamat betartását, mind a termék általános biztonságát, az alkalmazásbiztonsági tesztelés és ellenőrzés eredményei alapján. A termékverzió meghatározó szerepet játszik a biztonsági fejlesztések fenntartásában a kiadások között, a biztonsággal kapcsolatos visszafejlődés megelőzésében és az elért biztonsági helyzet megőrzésében, ami minden kiadás alapvető követelménye. 

A kiadási folyamat magában foglalja a belső kiadási jelentések készítését, amelyek dokumentálják a fennmaradó kockázatokat és a fennálló biztonsági problémákat. Ezeket a jelentéseket a termék vezetőjének hivatalosan jóvá kell hagynia. Emellett a külső kiadási jegyzetek a termék hivatalos kiadásának részeként közlik a biztonsággal kapcsolatos változásokat és javításokat. 

A felhőalapú termékek esetében a telepítés a "fail to deploy" automatizálási megközelítést követi, biztosítva, hogy csak biztonságos buildek kerüljenek kiadásra. Az alkalmazásbiztonsági tesztelés és ellenőrzés integrálva van a telepítési csővezetékbe, és nem push, hanem pull stratégiával működik, ami megerősíti a biztonsági érvényesítést a gyártói telepítés előtt. 

Az SBOM-kezelési szabályzat szerint minden egyes kiadás tartalmaz egyBill of Materials (SBOM) ) az alkatrészek eredetének nyomon követhetősége érdekében, támogatva az átláthatóságot és az ellátási lánc biztonságát. Minden szükséges kiadási fájlt biztonságosan archiválnak a hosszú távú hozzáférhetőség biztosítása érdekében.

A kiadási integritási politika szerint a termékkiadások integritásának és biztonságának fenntartása érdekében strukturált verziókezelési rendszert (pl. szemantikus verziókezelést) alkalmaznak, amely biztosítja a változások egyértelmű nyomon követhetőségét és meghatározott megőrzési időszakot minden kiadott műtárgyra, beleértve a dokumentációt is. A biztonság további fokozása érdekében a szoftver leletek digitális aláírása a vállalat neve alatt történik, a közzétett SHA ujjlenyomatok segítségével a felhasználók ellenőrizhetik a hitelességet és felderíthetik a hamisítási kísérleteket. 

Minden egyes kiadást verziószámozott dokumentáció kísér, amely részletes útmutatást nyújt az integritásellenőrzési módszerekről, a biztonságos telepítési eljárásokról, a konfiguráció legjobb gyakorlatairól és a rendszer keményítését célzó intézkedésekről. Ezek az erőforrások segítik a felhasználókat a biztonsági ellenőrzések hatékony végrehajtásában, csökkentve a potenciális támadási felületeket. Emellett a végfelhasználói licencszerződés (EULA) is megtalálható a megfelelőségi kötelezettségek megállapítása és a jogi átláthatóság fenntartása érdekében. 

Az egyes termékek SBOM-ját ügyfeleink igény szerint megkapják. Vegye fel velünk a kapcsolatot.

A fejlesztési, tesztelési és termelési környezetek biztonságosan elkülönülnek egymástól, hogy megakadályozzák az illetéktelen hozzáférést. Mindegyik környezet szigorú keményítési alapvonalakat és végpontbiztonsági protokollokat követ. A fejlesztési környezeteknek meg kell felelniük a vállalati biztonsági irányelveknek.

A végpontok védelmének részeként az OPSWAT tulajdonában lévő összes eszközt figyelemmel kísérik a sebezhetőségek, a telepített szoftverek, a telepített javítások és a vállalati biztonsági irányelveknek való megfelelés szempontjából. Meg nem felelés esetén korlátozó intézkedéseket hoznak a vállalati erőforrásokhoz való hozzáférés korlátozása érdekében. 

A magas kockázati kategóriába sorolt erőforrások csak ellenőrzött hozzáférési útvonalakon (VPN) keresztül érhetők el. A vállalati hálózaton kívüli eszközöknek biztonságos csatornákat kell használniuk a K+F erőforrásokhoz való hozzáféréshez.

A CI/CD csővezeték biztonsága szigorú biztonsági irányelveket követ a fejlődő fenyegetések mérséklése érdekében. A fenyegetések forrása lehet az elavult infrastrukturális elemek (például operációs rendszerek, elemzőeszközök stb.), a gyenge jogosultsági ellenőrzésekből adódó jogosulatlan hozzáférések és a rosszul elszigetelt környezetek. A CI/CD infrastruktúra naprakészen tartása, alapos átvilágítása és szigorú ellenőrzése a biztonságos SDLC egyik sarokköve. 

Regionálisan az Egyesült Államokban található szervereket használnak minden központosított szolgáltatáshoz, beleértve a kódtárolást, a CI/CD csővezetéket, az elemző és tesztelő eszközöket, valamint a biztonságos artefaktumok aláírását. Az összes központosított eszköz konfigurációja a K+F Operations ellenőrzése alatt áll. 

Erős hitelesítési mechanizmusokat (többtényezős hitelesítés - MFA) és jogosultsági ellenőrzéseket (szerepkör-alapú hozzáférés-szabályozás - RBAC) alkalmazunk. Legkevesebb jogosultságot és rendszeres hozzáférési felülvizsgálatokat végzünk. 

Pipeline-aink számos elemzési és tesztelési automatizálási eszközt tartalmaznak, beleértve a statikus alkalmazásbiztonsági tesztelést (SAST), a Software (SCA), a dinamikus alkalmazásbiztonsági tesztelést (DAST), a titkos szkennelést és a rosszindulatú szoftverek szkennelését. 

Biztonságos kódaláírási megoldásunkban Hardware biztonsági modulokat (HSM) használunk a kulcsanyag jogosulatlan hozzáférés elleni védelmére és az aláírás létrehozására. Az aláírási megoldás a CI/CD-infrastruktúra része, de hálózati szegmentációval. A HSM-ekhez csak a K+F műveleti részleg jogosult rövid időre hozzáférni. Minden aláírási művelet naplózásra kerül, és egy ellenőrzési nyomvonal során áttekinthető. 

A szoftver létrehozásához, fordításához vagy teszteléséhez használt eszközkészletnek rendelkeznie kell a származásra vonatkozó információkkal, és hitelesített forrásból kell származnia. A CI/CD csővezetékben használt eszközök száma korlátozott; csak a szükséges eszközök kerülnek telepítésre. A csővezeték fordítási és építési lépéseihez csak LTS szoftverek használhatók. A központosított szolgáltatások működtetése során rendszeres karbantartási és kulcsrotációs időszakokat határoznak meg. A belső fejlesztésű eszközök a Secure SDLC Process alá tartoznak.

Az összes központosított szolgáltatás környezetének keményítése folyamatos, és ezeket a biztonsági követelményeket rendszeresen felülvizsgálják. A keményítési irányelveket közlik a termékcsapatokkal, hogy biztosítsák felkészültségüket, és ennek megfelelően alakíthassák fejlesztési folyamataikat. Biztonsági incidens esetén RCA-t végeznek a megelőző intézkedések megtétele és e követelmények frissítése érdekében.

A forráskód védelme a szoftverfejlesztés alapvető fontosságú része, hogy a vállalaton belül garantálni lehessen a forráskód titkosságát és sértetlenségét. 

A forráskód tárolása a legkisebb jogosultság elvét követi, és csak az arra jogosult személyek és eszközök számára engedélyezi a hozzáférést. A forráskód verzióellenőrzés alatt áll. A verziókezelő rendszer garantálja a kódváltozások nyomon követhetőségét és elszámoltathatóságát. A forráskód tárolását FIPS 140-3 szabványnak megfelelő titkosítással titkosítják, és megfelelő hosszúságú kulccsal védik.

E szabályzat betartása minden belső csapat számára kötelező. Ez a dokumentum a vállalati irányelveknek alárendelt, ami azt jelenti, hogy ellentmondás esetén a vállalati irányelvek elsőbbséget élveznek, és azokat kell követni. 

Escalációs folyamat a Secure SDLC megsértése esetén: A K+F műveletekkel kezdve, és szükség esetén a Chief Product Officer (CPO) szintjére emelve, belsőleg kezeljük a szabályzat megsértését.

Az ISO 27001, SOC2, NIST SSDF hatálya alá tartozó termékekhez komponenseket vagy szolgáltatásokat nyújtó szállítóknak meg kell felelniük a Secure SDLC Framework alábbiakban ismertetett követelményeinek. A megfelelés az időszakos biztonsági auditok, a harmadik fél által végzett értékelések és az egyes felek által a végrehajtott szerződések alapján vállalt kötelezettségek függvénye. 

Minden szállító köteles a kiadási integritás szakaszban meghatározottak szerint a származásra és integritásra vonatkozó információkat, valamint az ezt alátámasztó dokumentációt megadni. 

A termékkomponensek és könyvtárak szállítóinak olyan fejlesztési környezeteket kell létrehozniuk, amelyek összhangban vannak a Secure fejlesztési környezet szakaszban leírt gyakorlatainkkal. Komponenseik és könyvtáraik biztonsági tesztelését az Alkalmazásbiztonsági tesztelés és ellenőrzés szakaszban leírtak szerint kell elvégezniük. 

A csővezeték-összetevők beszállítóinak a Secure fejlesztési környezet szakaszban leírtak szerint a mi gyakorlatunkhoz igazodó fejlesztési környezeteket is létre kell hozniuk. Ezenkívül fejlesztési folyamataiknak összhangban kell lenniük az OPSWAT Secure SDLC-folyamatával. 

A szolgáltatásnyújtóknak olyan amerikai székhelyű környezetet kell használniuk, amely az OPSWATszolgáltatásaihoz hasonló biztonsági helyzetet biztosít. Secure SDLC-jüknek tartalmaznia kell egy Secure SDLC programot és egy Secure SDLC folyamatot, amelyek tükrözik az OPSWATelvárásait.