Az OpenSSF szoftverellátási lánc sávokat ad az SLSA-keretrendszerhez

Az OpenSSF szoftverellátási lánc sávokat ad az SLSA-keretrendszerhez

Az OpenSSF szoftverellátási lánc nyomvonalakat ad az SLSA-keretrendszer PlatoBlockchain adatintelligenciájához. Függőleges keresés. Ai.

Az Open Source Security Foundation (OpenSSF) kiadta a Supply-chain Levels for Software Artifacts (SLSA) 1.0-s verzióját, amely speciális rendelkezéseket tartalmaz a szoftverellátási láncra vonatkozóan.

A modern alkalmazásfejlesztő csapatok rendszeresen újra felhasználják más alkalmazások kódját, és számtalan forrásból szerzik be a kódösszetevőket és fejlesztői eszközöket. A Snyk és a Linux Foundation tavalyi kutatása szerint a szervezetek 41%-a nem bízott nagyon a nyílt forráskódú szoftverek biztonságában. Mivel az ellátási lánc támadásai állandóan jelenlévő és folyamatosan fejlődő fenyegetést jelentenek, a szoftverfejlesztő csapatok és a biztonsági csapatok is felismerik, hogy a nyílt forráskódú összetevőket és keretrendszereket védeni kell.

Az SLSA egy közösség által vezérelt ellátási lánc biztonsági szabványok projektje, amelyet olyan nagy technológiai vállalatok támogatnak, mint a Google, az Intel, a Microsoft, a VMware és az IBM. Az SLSA a biztonsági szigor növelésére összpontosít a szoftverfejlesztési folyamaton belül. Az Open Source Security Foundation szerint a fejlesztők követhetik az SLSA irányelveit, hogy biztonságosabbá tegyék szoftverellátási láncukat, a vállalatok pedig az SLSA segítségével dönthetnek arról, hogy megbíznak-e egy szoftvercsomagban.

Az SLSA közös szókincset biztosít a szoftverellátási lánc biztonságáról; egy mód a fejlesztők számára az upstream függőségek felmérésére az alkalmazásban használt forráskódok, buildek és tárolóképek megbízhatóságának értékelésével; végrehajtható biztonsági ellenőrző lista; és egy módszer a közelgő Secure Software Development Framework (SSDF) követelményeinek való megfelelés mérésére.

Az SLSA v1.0 kiadás az SLSA szintű követelményeit több sávra osztja, amelyek mindegyike a szoftverellátási lánc biztonságának egy-egy aspektusát méri. Az OpenSSF szerint az új pályák segítenek a felhasználóknak jobban megérteni és mérsékelni a szoftverellátási láncokkal kapcsolatos kockázatokat, és végső soron biztonságosabb és megbízhatóbb szoftvereket fejlesztenek, demonstrálnak és használnak. Az SLSA v1.0 pontosabb útmutatást ad a származás ellenőrzéséhez, valamint a specifikáció és a származási formátum megfelelő módosításaihoz.

A Pályaépítés Az 1–3. szintek, amelyek nagyjából megfelelnek a korábbi SLSA-verziók 1–3. szintjének, a szoftver felépítése közbeni vagy utáni manipuláció elleni védelmi szinteket írják le. A Build Track követelményei tükrözik a szükséges feladatokat: műtermékek előállítása, összeállítási rendszerek ellenőrzése és műtermékek ellenőrzése. A keretrendszer jövőbeli verziói a szoftverszállítási életciklus egyéb vonatkozásaira vonatkozó követelményekre épülnek.

A Build L1 jelzi a származást, megmutatva, hogyan épült fel a csomag; A Build L2 aláírt eredetet jelöl, amelyet egy hosztolt build szolgáltatás generál; és a Build L3 azt jelzi, hogy a build szolgáltatást megerősítették.

Minél magasabb a szint, annál nagyobb a bizalom abban, hogy egy csomag visszavezethető a forrásáig, és nem manipulálták, mondta az OpenSSF.

A szoftverellátási lánc biztonsága a Biden-adminisztráció kulcsfontosságú eleme Az Egyesült Államok nemzeti kiberbiztonsági stratégiája, mivel ez arra készteti a szoftverszolgáltatókat, hogy nagyobb felelősséget vállaljanak termékeik biztonságáért. A közelmúltban pedig hét ország (Ausztrália, Kanada, Németország, Hollandia, Új-Zéland, az Egyesült Királyság és az Egyesült Államok) 10 kormányzati ügynöksége új irányelveket adott ki:A kiberbiztonsági kockázat egyensúlyának megváltoztatása: a tervezési és az alapértelmezett biztonság elvei és megközelítései”, hogy sürgesse a szoftverfejlesztőket, hogy tegyék meg a szükséges lépéseket annak biztosítására, hogy olyan termékeket szállítsanak, amelyek tervezésük és alapértelmezés szerint is biztonságosak. Ez azt jelenti, hogy el kell távolítani az alapértelmezett jelszavakat, biztonságosabb programozási nyelveken kell írni, és sebezhetőséget feltáró programokat kell létrehozni a hibák jelentésére.

A szoftverellátási lánc biztosításának részeként a biztonsági csapatoknak kapcsolatba kell lépniük a fejlesztőkkel, hogy felvilágosítsák őket a biztonságos kódolási gyakorlatokról, és a biztonsági tudatosság képzését a szoftverfejlesztési életciklussal kapcsolatos kockázatok figyelembevételével alakítsák ki.

Időbélyeg:

Még több Sötét olvasmány