Ellenőrizze, mi kerül a kiadásba

Vizsgálja meg, szükséges-e a függőség

Az agent javasolhat olyan csomagot, amely látszólag megoldja a problémát. A javaslat nem bizonyítja, hogy a csomag létezik vagy alkalmas a feladatra. Telepítés előtt ellenőrizze a pontos csomagtárat, a közzétevőt, a csomagnevet és a verziót.

Egy fiktív CSV-exportnál a futtatókörnyezet már biztosíthatja a szükséges működést. Egy új csomag ettől még lehet indokolt, de karbantartást és további végrehajtási útvonalakat hoz magával. Vesse össze a megvalósítás ráfordítását a függőség folyamatos fenntartási feladataival.

Vizsgálja meg a licencet és a támogatott futtatókörnyezetet. Ellenőrizze a karbantartási aktivitást és a releváns biztonsági közleményeket. Egy ismerős név másik csomagtárban eltérő csomagot jelölhet. A sikeres telepítés csak azt mutatja, hogy a telepítés befejeződött.

Vizsgálja meg a telepítés és a build működését

A függőségek telepítés vagy build közben kódot futtathatnak. Korlátozza ezekben a környezetekben a hitelesítő adatokat és a hálózati hozzáférést. Ne adjon éles titkos értékeket olyan feladatnak, amely nem megbízható pull requestet dolgoz fel.

Ahol az ökoszisztéma támogatja, használjon commitolt lockfile-t. Követelje meg, hogy a build ezt a fájlt kövesse. A forrás módosításával együtt ellenőrizze a lockfile változásait, a váratlan tranzitív csomagokat is. A verziók rögzítése javítja a reprodukálhatóságot, de nem tesz biztonságossá egy sérülékeny verziót.

A NIST SSDF a szoftver védelmével és a fejlesztési gyakorlatokkal a teljes életciklus során foglalkozik. A buildkörnyezet tervezésekor alkalmazza ezt a tágabb nézőpontot. A keretrendszer elolvasása.

Különböztesse meg az összetevőjegyzéket az eredetigazolástól

A szoftverösszetevő-jegyzék, azaz SBOM, a szoftver komponenseit rögzíti. Segít azonosítani az érintett kiadásokat, amikor valamelyik komponens problémássá válik. Önmagában nem bizonyítja a komponensek biztonságát.

Az eredetigazolás, vagyis provenance, azt írja le, hogyan készült az artifact. A SLSA formátumot határoz meg a buildről és bemeneteiről szóló eredetadatokhoz. Az ellenőrzésnek ezeket az információkat megbízható előállítóhoz és a használni kívánt artifacthoz kell kötnie. Egy „provenance” nevű fájl nem elegendő. SLSA-eredetigazolás.

Az exportszolgáltatáshoz rögzítsen ellenőrizhető láncot:

1. A review során ellenőrzött commit azonosítja az elfogadott forrást.
2. A build azonosítja a bemeneteit és a végrehajtási környezetét.
3. Az artifactnak stabil hashértéke van.
4. Az ellenőrzések azonosítják a vizsgált artifactot vagy forrást.
5. A telepítés rögzíti a célkörnyezetbe helyezett artifactot.

Jóváhagyás után ne készítsen eltérő buildet meghatározott ellenőrzési folyamat nélkül. Egy módosítható tag, például a latest, később másik image-re mutathat.

Értelmezze a találatot

Egy sérülékenységi találathoz kontextus kell: érintett verzió, az érintett működés elérhetősége, kitettség, rendelkezésre álló javítás és következmény. Minden ideiglenes kivételnél rögzítse a bizonyítékot, amelyre a döntés épül. Adjon hozzá felelőst, lejáratot és felülvizsgálati feltételt.

Ne kapcsoljon ki egy teljes scannert azért, mert egyetlen találat nem alkalmazható. Ne állítson tiszta eredményt, ha a vizsgálat nem fejeződött be. Az időtúllépés, a nem támogatott csomag vagy az elérhetetlen biztonságiközlemény-forrás hiányzó bizonyítékot jelent.

Végül tervezze meg a kiadás utáni frissítéseket. Új biztonsági közlemények a tegnap elfogadott artifactot is érinthetik. A szolgáltatás felelősének összetevőjegyzékre, reagálási folyamatra és a javított kiadás elkészítéséhez szükséges kapacitásra van szüksége.

Folytassa a folyamatos sérülékenységkezeléssel, és kapcsolja össze az ismételt vizsgálatokat az éles környezetben ellenőrzött javításokkal.