OpenSSF legger til programvareforsyningskjedespor til SLSA Framework

OpenSSF legger til programvareforsyningskjedespor til SLSA Framework

OpenSSF legger til programvareforsyningskjedespor til SLSA Framework PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

Open Source Security Foundation (OpenSSF) har gitt ut v1.0 av Supply-chain Levels for Software Artifacts (SLSA) med spesifikke bestemmelser for programvareforsyningskjeden.

Moderne applikasjonsutviklingsteam gjenbruker regelmessig kode fra andre applikasjoner og henter kodekomponenter og utviklerverktøy fra utallige kilder. Forskning fra Snyk og Linux Foundation i fjor fant at 41 % av organisasjonene hadde ikke høy tillit til sikkerhet for åpen kildekode. Med forsyningskjedeangrep som utgjør en trussel som alltid er tilstede og i stadig utvikling, erkjenner nå både programvareutviklingsteam og sikkerhetsteam at komponenter og rammeverk med åpen kildekode må sikres.

SLSA er et fellesskapsdrevet forsyningskjede sikkerhetsstandardprosjekt støttet av store teknologiselskaper, som Google, Intel, Microsoft, VMware og IBM. SLSA fokuserer på å øke sikkerheten i programvareutviklingsprosessen. Utviklere kan følge SLSAs retningslinjer for å gjøre programvareforsyningskjeden deres sikrere, og bedrifter kan bruke SLSA til å ta beslutninger om hvorvidt de skal stole på en programvarepakke, ifølge Open Source Security Foundation.

SLSA gir et felles vokabular for å snakke om sikkerhet i programvareforsyningskjeden; en måte for utviklere å vurdere oppstrømsavhengigheter ved å evaluere påliteligheten til kildekode, bygg og beholderbilder som brukes i applikasjonen; en praktisk sikkerhetssjekkliste; og en måte å måle samsvar med det kommende Secure Software Development Framework (SSDF).

SLSA v1.0-utgivelsen deler SLSAs nivåkrav inn i flere spor, som hver måler et bestemt aspekt av programvareforsyningskjedesikkerhet. De nye sporene vil hjelpe brukere til å bedre forstå og redusere risikoen forbundet med programvareforsyningskjeder og til slutt utvikle, demonstrere og bruke sikrere og pålitelig programvare, sier OpenSSF. SLSA v1.0 gir også mer eksplisitt veiledning om hvordan du bekrefter herkomst, sammen med å gjøre tilsvarende endringer i spesifikasjonen og herkomstformatet.

De Bygg spor Nivå 1-3, som omtrent tilsvarer nivå 1-3 i tidligere SLSA-versjoner, beskriver nivåer av beskyttelse mot tukling under eller etter programvarebygging. Byggespor-kravene gjenspeiler oppgavene som kreves: å produsere artefakter, verifisere byggesystemer og verifisere artefakter. Fremtidige versjoner av rammeverket vil bygge på krav for å adressere andre aspekter av programvareleveransens livssyklus.

Bygg L1 indikerer herkomst, viser hvordan pakken ble bygget; Bygg L2 indikerer signert herkomst, generert av en vertsbasert byggetjeneste; og Bygg L3 indikerer at byggetjenesten har blitt hardnet.

Jo høyere nivå, desto høyere er tilliten til at en pakke kan spores tilbake til kilden og ikke har blitt tuklet med, sa OpenSSF.

Sikkerhet i programvareforsyningskjeden er en nøkkelkomponent i Biden-administrasjonens USAs nasjonale cybersikkerhetsstrategi, ettersom det presser programvareleverandører til å ta større ansvar for sikkerheten til produktene deres. Og nylig har 10 offentlige etater fra syv land (Australia, Canada, Tyskland, Nederland, New Zealand, Storbritannia og USA) gitt ut nye retningslinjer, "Forskyvning av balansen mellom cybersikkerhetsrisiko: Prinsipper og tilnærminger for sikkerhet-by-design og -standard,” for å oppfordre programvareutviklere til å ta nødvendige skritt for å sikre at de sender produkter som er både designsikre og som standard. Det betyr å fjerne standardpassord, skrive på sikrere programmeringsspråk og etablere programmer for avsløring av sårbarheter for rapportering av feil.

Som en del av å sikre programvareforsyningskjeden, bør sikkerhetsteam samarbeide med utviklere for å utdanne dem om sikker kodingspraksis og skreddersy opplæring i sikkerhetsbevissthet for å inkludere risikoene rundt programvareutviklingens livssyklus.

Tidstempel:

Mer fra Mørk lesning