Prodajate programsko opremo vladi ZDA? Najprej spoznajte varnostno potrdilo

V zadnjih nekaj mesecih je vlada ZDA uvedla več novih zahtev, ki vplivajo na organizacije, ki prodajajo programsko opremo vladnim agencijam. Ker so te nove zahteve zapletene, mnogi voditelji še niso prepričani, kako bo to vplivalo na njihovo organizacijo. V tem članku bom delil nekaj najpomembnejših konceptov, ki jih boste morali razumeti, da boste lahko zaščitili svoj vladni posel in ostali skladni.

Nove varnostne zahteve programske opreme: kaj se je spremenilo?

V zadnjih nekaj letih odmevni varnostni incidenti, kot so tisti, ki so prizadeli SolarWinds in odprtokodni paket log4j so povečali pozornost vlade na varnost programske opreme. Začenši z Izvršni ukaz Bele hiše 14028 o izboljšanju nacionalne kibernetske varnosti maja 2021 je vrsta ukrepov v zadnjih dveh letih privedla do niza jasnih zahtev, ki vplivajo na katerega koli vladnega dobavitelja programske opreme.

V prihodnje bo vsaka organizacija, ki prodaja programsko opremo vladi ZDA, morala sama potrditi, da je skladna s praksami varnega razvoja programske opreme, ki jih je vlada opisala v Varno ogrodje za razvoj programske opreme NIST.

Ena od najpomembnejših stvari, ki jih je treba razumeti, je, da organizacije ne smejo samo potrditi, da same sledijo tem praksam za kodo programske opreme, ki jo pišejo, ampak tudi, da odprtokodne komponente, ki jih vključijo v svoje aplikacije, prav tako upoštevajo te prakse.

V začetku junija je vlada te zahteve ponovno potrdila v OMB memorandum M-23-16 (PDF) in določiti roke za skladnost, ki se hitro približujejo – verjetno bodo prispeli v četrtem četrtletju tega leta (za kritično programsko opremo) in v prvem četrtletju naslednjega leta (za vso ostalo programsko opremo).

To pomeni, da se bodo v naslednjih nekaj mesecih organizacije trudile razumeti te nove zahteve glede potrdil in določiti, kako jih bo njihova organizacija izpolnjevala, tako za kodo, ki jo napišejo same, kot za odprtokodne komponente, ki jih vključijo v svoje programske izdelke.

V skladu z M-23-16 je kazen za neupoštevanje stroga:

»[Zvezna] agencija mora prenehajte uporabljati programsko opremo če agencija ugotovi, da je dokumentacija proizvajalca programske opreme nezadovoljiva ali če agencija ne more potrditi, da je proizvajalec identificiral prakse, ki jih ne more potrditi ...«

Posebej zahteven primer odprte kode

Ker se številne organizacije poglabljajo v zahteve glede atestiranja, odkrivajo, da se lahko izkaže, da je skladnost, zlasti v kratkih rokih, izziv. NIST SSDF je zapleteno varnostno ogrodje in potreben bo čas, da bodo organizacije ne le zagotovile skladnost s temi praksami, temveč tudi podrobno dokumentirale svoje prakse.

Toda še bolj zastrašujoče je, da vlada od dobaviteljev zahteva, da potrdijo varnostne prakse njihovega celotnega programskega izdelka, ki vključuje odprtokodne komponente v tej programski opremi. Danes je sodobna programska oprema pogosto sestavljena večinoma iz odprtokodnih komponent, ki so bile sestavljene skupaj z nekaj programske opreme po meri. V naši raziskavi smo to ugotovili več kot 90 % aplikacij vsebuje odprtokodne komponentein v mnogih primerih odprta koda predstavlja več kot 70 % baze kode.

Vaša organizacija lahko potrdi lastne varnostne prakse, toda kako natančno lahko potrdite varnostne prakse vzdrževalcev odprte kode, ki pišejo in vzdržujejo odprtokodno kodo, ki jo uporabljate v svojih aplikacijah?

To je velik izziv in organizacije iščejo vzdrževalce odprte kode za več informacij o svojih varnostnih praksah. Na žalost je veliko teh vzdrževalcev odprte kode neplačanih prostovoljcev, ki se ponoči in ob koncih tedna ukvarjajo z odprto kodo kot hobijem. Zato zahtevati, da opravijo dodatno delo za potrditev, ali se njihove varnostne prakse ujemajo z visokimi standardi, ki jih določa NIST SSDF, ni praktično.

Eden od načinov, kako se lahko organizacije izognejo temu izzivu, je, da v svojih aplikacijah preprosto ne uporabljajo odprte kode. In čeprav se to na prvi pogled sliši kot preprosta rešitev, je tudi vedno bolj neuporabna alternativa, saj je odprtokodna v mnogih pogledih postala de facto sodobna razvojna platforma.

Boljši način za rešitev te težave je zagotoviti, da so vzdrževalci paketov, na katere se zanašate, plačani za opravljanje tega pomembnega varnostnega dela.

To bo morda zahtevalo dodatno raziskavo, da zagotovite, da imajo odprtokodne komponente, ki jih uporabljate, za seboj vzdrževalce, ki jih plačajo – bodisi dobrotniki podjetij, fundacije ali komercialna prizadevanja – za preverjanje skladnosti njihovih paketov s temi pomembnimi varnostnimi standardi. Lahko pa celo sami stopite v stik z vzdrževalci in postanete korporativni sponzor njihovega dela. Pri načrtovanju svojega pristopa upoštevajte, da ima večina netrivialnih sodobnih aplikacij na tisoče različnih odprtokodnih odvisnosti, od katerih vsako ustvari in vzdržuje drug posameznik ali ekipa, zato je ročni trud za prilagajanje tega pristopa precejšen.

Zahteven, a nujen korak naprej

Izpolnjevanje teh zahtev je morda boleče, vendar so v ozadju vse večjih varnostnih ranljivosti, ki povzročajo veliko škodo javnemu in zasebnemu sektorju, nujen korak naprej. Vlada ZDA je največji kupec blaga in storitev na svetu, kar velja tako za IT kot za druga področja. Z uporabo svoje kupne moči za izsiljevanje izboljšav splošnega varnostnega standarda za programsko opremo vlada pomaga zagotoviti varnejšo prihodnost.

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• PlatoData.Network Vertical Generative Ai. Opolnomočite se. Dostopite tukaj.
• PlatoAiStream. Web3 Intelligence. Razširjeno znanje. Dostopite tukaj.
• PlatoESG. Avtomobili/EV, Ogljik, CleanTech, Energija, Okolje, sončna energija, Ravnanje z odpadki. Dostopite tukaj.
• BlockOffsets. Posodobitev okoljskega offset lastništva. Dostopite tukaj.
• vir: https://www.darkreading.com/application-security/selling-software-government-know-security-attestation-first