Sälja programvara till den amerikanska regeringen? Känna till säkerhetsintyg först

Sälja programvara till den amerikanska regeringen? Känna till säkerhetsintyg först

Tidsstämpel: 7 augusti 2023 10:00
Sälja programvara till den amerikanska regeringen? Know Security Attestation First PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.

Under de senaste månaderna har den amerikanska regeringen infört flera nya krav som påverkar organisationer som säljer programvara till statliga myndigheter. Eftersom dessa nya krav är komplexa är många ledare ännu inte säkra på hur deras organisation kommer att påverkas. I den här artikeln kommer jag att dela med mig av några av de viktigaste begreppen du behöver förstå så att du kan skydda din statliga verksamhet och följa efterlevnaden.

Nya säkerhetskrav för programvara: Vad har förändrats?

Under de senaste åren har högprofilerade säkerhetsincidenter som de som påverkat Solarwinds och paketet med öppen källkod log4j har ökat regeringens uppmärksamhet på mjukvarusäkerhet. Börjar med Vita husets verkställande order 14028 om att förbättra landets cybersäkerhet i maj 2021, har en rad åtgärder under de senaste två åren lett till en uppsättning tydliga krav som påverkar alla statliga mjukvaruleverantörer.

Framöver kommer alla organisationer som säljer programvara till den amerikanska regeringen att behöva självintyga att den överensstämmer med de metoder för säker programvaruutveckling som beskrivs av regeringen i NIST Secure Software Development Framework.

En av de viktigaste sakerna att förstå är att organisationer inte bara måste intyga att de själva följer dessa rutiner för mjukvarukoden de skriver, utan också att de komponenter med öppen källkod som de drar in i sina applikationer också följer dessa metoder.

I början av juni bekräftade regeringen dessa krav i OMB-memorandum M-23-16 (PDF), och ställ in deadlines för efterlevnad som närmar sig med stormsteg — kommer sannolikt att komma in under fjärde kvartalet i år (för kritisk programvara) och första kvartalet nästa år (för all annan programvara).

Detta innebär att organisationer under de närmaste månaderna kommer att kämpa för att förstå dessa nya intygskrav och bestämma hur deras organisation kommer att följa, både för koden de själva skriver och de komponenter med öppen källkod som de tar med i sina mjukvaruprodukter.

Enligt M-23-16 är straffet för bristande efterlevnad hårt:

"Den [federala] myndigheten måste sluta använda programvaran om byrån finner mjukvarutillverkarens dokumentation otillfredsställande eller om byrån inte kan bekräfta att tillverkaren har identifierat de metoder som den inte kan intyga...”

Särskilt utmanande fall av öppen källkod

När många organisationer dyker djupare in i kraven på intyg, upptäcker de att efterlevnad, särskilt mot snäva deadlines, kan visa sig vara utmanande. NIST SSDF är ett komplext ramverk för säkerhet, och det kommer att ta tid för organisationer att inte bara säkerställa att de följer dessa rutiner, utan också dokumentera sina rutiner i detalj.

Men ännu mer skrämmande är att regeringen ber leverantörer att intyga säkerhetspraxis för hela deras mjukvaruprodukt, som inkluderar komponenterna med öppen källkod i den programvaran. Idag består modern mjukvara ofta till stor del av komponenter med öppen källkod som har klippts ihop, tillsammans med viss anpassad programvara. I vår forskning har vi funnit det över 90 % av applikationerna innehåller komponenter med öppen källkod, och i många fall öppen källkod utgör mer än 70 % av kodbasen.

Din organisation kan intyga sin egen säkerhetspraxis, men exakt hur kan du intyga säkerhetspraxis som följs av underhållare av öppen källkod som skriver och underhåller den öppna källkoden du använder i dina applikationer?

Det är en enorm utmaning, och organisationer letar efter underhållare med öppen källkod för mer information om deras säkerhetspraxis. Tyvärr är många av dessa som underhåller öppen källkod oavlönade frivilliga, som arbetar med öppen källkod som en hobby på nätter och helger. Så det är inte praktiskt att be dem göra det extra arbetet för att validera att deras säkerhetspraxis matchar de höga standarder som ställs av NIST SSDF.

Ett sätt som organisationer kan undvika denna utmaning är att helt enkelt inte använda öppen källkod i sina applikationer. Och även om det låter som en enkel lösning på dess ansikte, är det också ett allt mer livskraftigt alternativ, eftersom öppen källkod på många sätt har blivit den de facto moderna utvecklingsplattformen.

Ett bättre sätt att lösa detta problem är att säkerställa att underhållarna av paketen du litar på får betalt för att utföra detta viktiga säkerhetsarbete.

Detta kan kräva att du gör extra research för att säkerställa att komponenterna med öppen källkod du använder har underhållare bakom sig som får betalt – antingen av företags välgörare, av stiftelser eller av kommersiella ansträngningar – för att validera deras paket uppfyller dessa viktiga säkerhetsstandarder. Eller så kan du till och med nå ut till underhållare själv och bli företagssponsor för deras arbete. När du utformar ditt tillvägagångssätt, kom ihåg att de flesta icke-triviala moderna applikationer har tusentals distinkta beroenden av öppen källkod, var och en skapad och underhållen av en annan individ eller team, så den manuella ansträngningen att skala denna metod är avsevärd.

Ett utmanande men nödvändigt steg framåt

Dessa krav kan vara smärtsamma att följa, men mot bakgrund av att ökande säkerhetssårbarheter skadar offentliga och privata sektorer enormt, är de ett nödvändigt steg framåt. Den amerikanska regeringen är den största köparen av varor och tjänster i världen, och det är lika sant för IT som för andra domäner. Genom att använda sin köpkraft för att tvinga fram förbättringar av den övergripande säkerhetsstandarden för programvara, hjälper regeringen till att säkerställa en säkrare och säkrare framtid.

Tidsstämpel:

Mer från Mörk läsning