Säkert ramverk för mjukvaruutveckling för att säkerställa kodens korrekthet

Ett säkert ramverk för programvaruutveckling (SSDF) är NIST:s strukturerade metod för att integrera säkerhet i programvaruutvecklingslivscykeln (SDLC), definierad i NIST SP 800-218. Det konsoliderar långvariga rekommendationer för bästa praxis i fyra resultatbaserade praktikgrupper och tillhandahåller det ramverk som alla organisationer, oavsett SDLC-modell eller teknikstack, kan använda för att minska sårbarheter, minimera exploateringspåverkan och åtgärda bakomliggande orsaker till återkommande svagheter. SSDF är viktigt eftersom attacker i programvaruleveranskedjan har visat att osäkra utvecklingsmetoder skapar systemrisker som sträcker sig långt bortom den ursprungliga leverantören; EO 14028 gjorde SSDF-efterlevnad i praktiken obligatorisk för leverantörer som levererar programvara till amerikanska federala myndigheter, och federala upphandlingskrav driver kommersiellt införande. Den rekommenderade åtgärden: kartlägg er nuvarande SDLC mot de fyra SSDF-praktikgrupperna, identifiera luckor i områdena Skydda programvaran (PS) och Producera välsäker programvara (PW) och prioritera implementering av kodsignering och SBOM-metoder som de två kontrollerna med den bredaste säkerhetspåverkan på leveranskedjan. För implementering av kodsignering, se CodeSign Secure . För information om SolarWinds leveranskedjeincident som direkt påverkade SSDF:s utveckling, se SolarWinds: Should Security Live in InfoSec or DevOps.

Snabbt svar: Vad är SSDF och varför är det viktigt?

SSDF (Secure Software Development Framework), definierat i NIST SP 800-218 (februari 2022), är en uppsättning resultatbaserade säkra programvaruutvecklingsmetoder organiserade i fyra grupper: Förbered organisationen (PO), Skydda programvaran (PS), Producera välsäker programvara (PW) och Svara på sårbarheter (RV). Den föreskriver inte specifika verktyg eller implementeringssteg; istället identifierar den de säkerhetsresultat som utvecklingsmetoder måste uppnå och mappar dem till etablerad vägledning. Efterlevnad av SSDF blev ett upphandlingskrav för federala programvaruleverantörer efter EO 14028, och CISA utvecklade ett självintygsformulär som programvaruproducenter måste fylla i för att intyga att de följer SSDF. Icke-federala organisationer som antar SSDF minskar risken i leveranskedjan, visar säkerhetsmognad för företagsköpare och bygger en strukturerad grund för DevSecOps-integration.

Programvaruutvecklingslivscykel (SDLC) och argumenten för säker utveckling

Programvaruutvecklingslivscykeln (SDLC) är en systematisk process för att utveckla programvara som säkerställer kodens kvalitet och korrekthet. Syftet är att producera högkvalitativ programvara inom den angivna tiden och budgeten enligt kundernas förväntningar. Varje fas av SDLC har sin egen process och sina egna leveranser, som leder till nästa fas. Några populära SDLC-modeller inkluderar vattenfall, spiral, iterativ och agil.

Det finns bara ett fåtal SDLC-modeller som explicit behandlar programvarusäkerhet i detalj. Det är dock nödvändigt att införliva säkra programvaruutvecklingsmetoder i varje SDLC-modell. Det finns olika skäl till varför organisationer bör planera att implementera säkra programvaruutvecklingsmetoder:

• För att minska antalet sårbarheter i släppt programvara
• För att minimera den potentiella effekten av utnyttjandet av oupptäckta sårbarheter
• Att åtgärda grundorsakerna till sårbarheter för att förhindra upprepningar

Sårbarheter inkluderar inte bara buggar orsakade av kodningsfel utan även svagheter orsakade av felaktiga säkerhetskonfigurationsinställningar, felaktiga förtroendeantaganden och föråldrad riskanalys. En sårbarhet i ett beroende som aldrig granskades före integrationen är lika farlig som en bugg i förstapartskod, och SSDF behandlar båda kategorierna lika allvarligt genom sin praktikgrupp för att producera välsäker programvara (PW).

Vad är SSDF?

National Institute of Standards and Technology (NIST) utvecklade Secure Software Development Framework (SSDF), publicerad som NIST SP 800-218, för att stärka programvarans motståndskraft mot sårbarheter och tillhandahålla ett gemensamt ordförråd för säkra utvecklingsmetoder. SSDF definierar inga nya terminologier utan konsoliderar långvariga rekommendationer om bästa praxis från befintlig vägledning, inklusive BSIMM, SAFECode, OWASP och ISO/IEC-standarder för säker programvaruutveckling. I SSDF ligger tonvikten på att identifiera de metoder som ger säkra resultat, inte på att föreskriva specifika verktyg, tekniker eller mekanismer. Detta gör det brett tillämpligt oavsett programmeringsspråk, plattform, SDLC-modell eller distributionsmiljö.

Enligt NIST delas SSDF:s metoder in i fyra huvudkategorier:

1. Förbered organisationen (PO)

   Organisationer bör säkerställa att deras personal, processer och teknik är förberedda för att utföra säker programvaruutveckling på organisationsnivå. Detta inkluderar att fastställa säkerhetskrav, definiera roller och ansvar för säkerhetsaktiviteter, implementera säkerhetsutbildning för utvecklare och säkerhetsteam, och säkerställa att de verktygskedjor och miljöer som används för utveckling i sig är säkra. Många organisationer kommer också att hitta vissa PO-metoder att tillämpa på delmängder av sin programvaruutveckling, som enskilda utvecklingsgrupper eller projekt.

2. Skydda programvaran (PS)

   Organisationer bör skydda alla programvarukomponenter från manipulation och obehörig åtkomst under hela utvecklings-, bygg- och distributionsprocessen. PS-rutiner inkluderar att skydda källkodsförråd, signera byggartefakter för att möjliggöra integritetsverifiering, underhålla programvarulistor (SBOM) för all släppt programvara och säkra byggmiljön mot kompromisser. Kodsignering är en direkt implementering av PS-rutiner: det ger kryptografisk försäkran om att programvaruversioner inte har ändrats efter signering och att de kommer från den identifierade utgivaren. För organisationer som hanterar kodsignering i stor skala, se CodeSign Secure.

3. Producera välsäker programvara (PW)

   Organisationer bör producera välsäker programvara med minimala säkerhetsproblem i sina utgåvor. PW-metoder täcker hela omfattningen av säkerhetsaktiviteter under programvaruutveckling: hotmodellering för att identifiera säkerhetskrav innan kodning påbörjas; säker design och arkitektur; kodgranskning och statisk analys för att hitta brister innan de levereras; dynamisk testning och penetrationstestning; analys av programvarusammansättning (SCA) för att identifiera sårbarheter i tredjepartsberoenden; och verifiering av att säkerhetskraven är uppfyllda före lansering. PW-metoder är där den mesta säkerhetsautomationen för SDLC implementeras.

4. Reagera på sårbarheter (RV)

   Organisationer bör identifiera kvarvarande sårbarheter i sina programvaruversioner och agera på lämpligt sätt för att åtgärda dessa sårbarheter och förhindra att liknande inträffar i framtiden. RV-praxis omfattar processer för att avslöja sårbarheter, intern och extern sårbarhetsspårning, snabb patchning och omdistribution, samt retrospektiv rotorsaksanalys som matar tillbaka till PO- och PW-praxis för att förhindra upprepning. En formell policy för avslöjande av sårbarheter (VDP) är en viktig RV-praxis som gör det möjligt för säkerhetsforskare att rapportera sårbarheter på ett ansvarsfullt sätt.

Varje SSDF-praxisdefinition innehåller följande element

SSDF strukturerar varje praxis konsekvent så att organisationer kan kartlägga sina befintliga kontroller mot den och identifiera luckor. Varje praxisdefinition innehåller fyra element:

1. Öva: Namnet på metoden och en unik identifierare (till exempel PW.4.1 för att utföra kodgranskningar), följt av en kort förklaring av vad metoden är och varför den är fördelaktig.
2. uppgifter: En eller flera åtgärder som kan krävas för att genomföra en övning. Uppgifter beskriver de specifika aktiviteter som behövs för att uppnå övningens resultat utan att föreskriva hur dessa aktiviteter ska implementeras.
3. Exempel på teoretiska implementeringar: Ett eller flera exempel på typer av verktyg, processer eller metoder som kan användas för att genomföra en uppgift. Inga exempel eller kombinationer av exempel krävs, och de angivna exemplen är inte de enda möjliga alternativen. Vissa exempel kanske inte är tillämpliga på vissa organisationer och situationer.
4. Referenser: Pekare på ett eller flera etablerade dokument för säker utvecklingspraxis och deras mappningar till en specifik uppgift. Alla referenser gäller inte alla fall av programvaruutveckling. Referenserna inkluderar bland annat OWASP SAMM, BSIMM, SAFECode och ISO/IEC-standarder.

NIST rekommenderar att man väger risk mot kostnad, genomförbarhet och tillämpbarhet när man bestämmer vilka metoder som ska implementeras. SSDF är inte en checklista; snarare vägleder den organisationer att planera och implementera en riskbaserad metod för säker programvaruutveckling.

Fördelar med SSDF

1. Det kan hjälpa organisationer inom alla sektorer eller samhällen, oavsett storlek, eftersom det är resultatfokuserat snarare än föreskrivande om verktyg eller tekniker.
2. Det kan tillämpas på programvara som utvecklats för att stödja informationsteknik (IT), industriella styrsystem (ICS), cyberfysiska system (CPS) eller sakernas internet (IoT), vilket gör det till ett av få säkerhetsramverk som explicit täcker alla dessa implementeringskontexter.
3. Den kan integreras i alla befintliga arbetsflöden och automatiserade verktyg för mjukvaruutveckling; den är utformad för att inte ha en negativ inverkan på organisationer som redan har starka säkra rutiner för mjukvaruutveckling på plats, eftersom befintliga rutiner mappas till SSDF-resultat snarare än ersätts.
4. Det gör metoderna brett tillämpliga snarare än att vara specifika för specifika tekniker, plattformar, programmeringsspråk, SDLC-modeller, utvecklingsmiljöer, operativsystemmiljöer eller verktyg, vilket möjliggör sektorsövergripande implementering utan anpassning.
5. Det tillhandahåller en gemensam vokabulär och struktur för programvaruproducenter och -köpare, vilket gör det möjligt för programvaruköpare, inklusive amerikanska federala myndigheter, att specificera SSDF-anpassade säkerhetskrav vid upphandling och utvärdera leverantörers efterlevnad med hjälp av CISA:s självattesteringsformulär.

SSDF-implementering: Beslutstabell efter organisationstyp

Följande tabell kartlägger de mest brådskande utgångspunkterna för SSDF per organisationstyp och sammanhang. SSDF kräver inte att alla metoder implementeras samtidigt; en riskbaserad prioritering rekommenderas uttryckligen.

Organisations typ	Högst prioriterade SSDF-grupp	Rekommenderade första praxis	Huvudrisk som åtgärdas
Programvaruleverantör som säljer till amerikanska federala myndigheter	PS (Skydda programvaran)	Kodsignering av alla utgåvor; SBOM-generering; CISA-självcertifiering	EO 14028-efterlevnad; behörighet för federal upphandling
SaaS-produktföretag	PW (Producera välsäker programvara)	Hotmodellering för nya funktioner; SAST och SCA i CI/CD; skanning av beroendens sårbarheter	Sårbarhet i tredjepartsberoenden som når produktion; kända CVE:er i komponenter med öppen källkod
Företag med intern mjukvaruutveckling	Förbered organisationen (PO)	Definiera säkerhetskravsprocessen; tilldela säkerhetsroller i SDLC; säkerhetsutbildning för utvecklare	Inkonsekventa säkerhetsrutiner mellan utvecklingsteam; inget definierat ägarskap för säkerhetsaktiviteter
Organisation med aktiv sårbarhetsrapportering	RV (Reagera på sårbarheter)	Formell VDP; sårbarhetsspårning; rotorsaksanalysprocess; patchlansering inom definierat SLA	Okoordinerad sårbarhetsrespons; återkommande sårbarhetsklasser från oadresserade grundorsaker
IoT- eller inbyggda systemutvecklare	PS + PW	Implementering av säker start; signering av firmware; hotmodellering för begränsade miljöer; granskning av komponenter i leveranskedjan	Manipulering av firmware; komprometterad leveranskedja; lång livslängd på fältet med fördröjd patchning

Checklista för implementering av SSDF

Använd den här checklistan för att bedöma beredskap och identifiera luckor inom de fyra SSDF-övningsgrupperna:

• Definierad säkerhetskravprocess som genererar säkerhetskrav innan designen påbörjas (PO.1)
• Roller och ansvarsområden för säkerhetsaktiviteter som tilldelats utvecklings-, säkerhets- och driftsteam (PO.2)
• Säkerhetsutbildningsprogram för utvecklare på plats som omfattar hotmodellering, säker kodning och principer för säker design (PO.3)
• Källkodsförråd åtkomstkontrollerade med lägsta behörighetsnivå och granskningsloggning (PS.1)
• Kodsignering implementerad för alla programvaruversioner; privata nycklar skyddade i FIPS 140-3-validerade HSM:er (PS.1)
• Programvaruförteckning (SBOM) genererad för varje utgåva som dokumenterar alla tredjepartsberoenden (PS.1)
• Hotmodellering utförd för alla nya funktioner och större arkitekturförändringar (PW.1)
• Statisk applikationssäkerhetstestning (SAST) integrerad i CI/CD-pipelinen med policygrindar som blockerar allvarliga resultat (PW.4)
• Programvarukompositionsanalys (SCA) implementerad för att identifiera kända CVE:er i tredjepartsberoenden före lansering (PW.4)
• Dynamisk applikationssäkerhetstestning (DAST) och penetrationstestning utförd före större utgåvor (PW.4)
• Hemlig skanning implementerad för att förhindra att inloggningsuppgifter, nycklar och tokens sparas i databaser (PW.4)
• Policy för sårbarhetsrapportering (VDP) publicerad och funktionell för externa säkerhetsforskare (RV.1)
• System för spårning av sårbarheter på plats med definierade servicenivåavtal för svar och patchar efter allvarlighetsgrad (RV.2)
• Process för rotorsaksanalys av bekräftade sårbarheter som återkopplar till PO- och PW-rutiner för att förhindra återfall (RV.3)

Slutsats

I och med att NIST publicerar SSDF som SP 800-218 och EO 14028, vilket gör SSDF-efterlevnad till ett federalt upphandlingskrav, blir säker programvaruutveckling snabbt en obligatorisk prioritet i stor skala. Om organisationer antar SSDF hjälper det dem att förbli skyddade från SDLC-sårbarheter och försvara sina programvaruleveranskedjor. Ramverkets resultatbaserade design gör det kompatibelt med alla befintliga SDLC-modeller och alla befintliga verktygskedjor, så implementeringen kräver inte att man börjar om; det kräver att befintliga metoder mappas till SSDF-resultat, att luckor identifieras och att åtgärder prioriteras efter risk. För organisationer som hanterar kodsignering som en implementering av PS-praxis tillhandahåller Encryption Consultings CodeSign Secure HSM-baserad signering med fullständiga revisionsspår. För det bredare säkerhetskontextet för leveranskedjan, se SolarWinds: Should Security Live in InfoSec or DevOps.

NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1: Rekommendationer för att minska risken för programvarusårbarheter. Publicerad februari 2022. Tillgänglig på csrc.nist.gov.

Vanliga frågor om partihandel med mat och dryck

Vad är NIST SSDF och vilket dokument definierar det?

NIST Secure Software Development Framework (SSDF) definieras i NIST Special Publication 800-218 (SP 800-218), som först publicerades i februari 2022. Det är en uppsättning resultatbaserade metoder för säker programvaruutveckling organiserade i fyra grupper: Förbered organisationen (PO), Skydda programvaran (PS), Producera välsäker programvara (PW) och Svara på sårbarheter (RV). SSDF konsoliderar långvariga rekommendationer för bästa praxis från BSIMM, SAFECode, OWASP och ISO/IEC-standarder utan att definiera nya terminologier.

Är SSDF obligatoriskt för alla organisationer?

SSDF blev i praktiken obligatoriskt för programvaruleverantörer som levererar programvara till amerikanska federala myndigheter efter EO 14028 (maj 2021). CISA utvecklade ett säkert formulär för attestering av programvaruutveckling som programvaruproducenter som säljer till den federala regeringen måste fylla i. Även om det inte är ett lagstadgat krav för rent kommersiell programvara, förväntas införandet i allt högre grad av företagsköpare och det hänvisas till det i regelverk, inklusive DORA för finanssektorn.

Hur relaterar SSDF till DevSecOps?

SSDF är det praxisramverk som definierar vilka säkra resultat som ska uppnås; DevSecOps är den operativa modellen för att integrera säkerhetsaktiviteter i programvaruleveranspipelinen för att kontinuerligt uppnå dessa resultat. SSDF:s PW-metoder mappas direkt till säkerhetsgrindar i en DevSecOps CI/CD-pipeline (SAST, DAST, SCA, hemlig skanning), och SSDF:s RV-metoder är i linje med DevOps princip för kontinuerlig feedback. Organisationer som implementerar DevSecOps utan att referera till SSDF riskerar att bygga automatisering utan strukturerade resultat.

Vad är förhållandet mellan SSDF och säkerhet i programvaruleveranskedjan?

SSDF hanterar säkerhet i leveranskedjan för programvara genom sina PS- och PW-kategorier. PS-metoder kräver att skydda integriteten hos programvaruversioner genom att signera utgåvor, verifiera komponenternas ursprung och underhålla SBOM:er. PW-metoder kräver att komponenter analyseras för kända sårbarheter före integration. SSDF:s betoning på proveniensverifiering, integritetsskydd och sårbarhetsanalys på komponentnivå är direkt responsiv mot de attackmönster i leveranskedjan som föranledde EO 14028.

Hur passar kodsignering in i en SSDF-implementering?

Kodsignering är en direkt implementering av SSDF:s kategori Protect the Software (PS), specifikt den praktikgrupp som kräver att organisationer skyddar alla programvarukomponenter från manipulering och obehörig åtkomst. Signering av programvaruversioner ger kryptografisk garanti för äkthet, integritet och ansvarsskyldighet. Utan kodsignering finns det ingen teknisk mekanism för att skilja legitima programvaruversioner från versioner som modifierats av angripare.