Verifikoni çfarë hyn në versionin e publikuar

Pyesni nëse varësia është e nevojshme

Një agjent mund të sugjerojë një paketë që duket se zgjidh një problem. Sugjerimi është propozim, jo evidencë se paketa ekziston ose është e përshtatshme. Verifikoni regjistrin, publikuesin, emrin dhe versionin e saktë të paketës para instalimit.

Për një eksport imagjinar CSV, mjedisi i ekzekutimit mund ta ofrojë tashmë sjelljen e kërkuar. Një paketë e re mund të jetë ende e përshtatshme, por shton mirëmbajtje dhe rrugë ekzekutimi. Krahasoni përpjekjen e zbatimit me përgjegjësitë e vazhdueshme që sjell varësia.

Shqyrtoni licencën dhe mjedisin e mbështetur të ekzekutimit. Kontrolloni aktivitetin e mirëmbajtjes dhe njoftimet përkatëse të sigurisë. Një emër i njohur mund t’i referohet një pakete tjetër në një regjistër tjetër. Një instalim i suksesshëm tregon vetëm se instalimi përfundoi.

Shqyrtoni sjelljen gjatë instalimit dhe procesit build

Varësitë mund të ekzekutojnë kod gjatë instalimit ose procesit build. Kufizoni kredencialet dhe aksesin në rrjet në këto mjedise. Mos i ekspozoni sekretet e prodhimit ndaj një pune që përpunon një pull request të pabesueshëm.

Përdorni një lockfile të ruajtur në commit kur ekosistemi e mbështet. Kërkoni që procesi build ta respektojë atë skedar. Shqyrtoni ndryshimet e lockfile bashkë me ndryshimin e kodit burimor, përfshirë paketat e papritura që vijnë nga varësitë e tjera. Fiksimi i versioneve përmirëson riprodhueshmërinë, por nuk e bën të sigurt një version me cenueshmëri.

SSDF i NIST mbulon mbrojtjen e softuerit dhe praktikat e zhvillimit gjatë gjithë ciklit jetësor. Përdoreni këtë këndvështrim më të gjerë kur projektoni mjedisin e procesit build. Lexoni kuadrin.

Dalloni inventarin nga origjina e artefaktit

Një listë përbërësish të softuerit, ose SBOM, regjistron komponentët e softuerit. Ajo ndihmon të identifikoni versionet e prekura kur një komponent bëhet shqetësim. Nuk vërteton në mënyrë të pavarur se komponentët janë të sigurt.

Evidenca e origjinës, ose provenance, trajton mënyrën si u prodhua një artefakt. SLSA përcakton një format provenance për informacionin mbi procesin build dhe hyrjet e tij. Verifikimi duhet ta lidhë këtë informacion me një prodhues të besuar dhe artefaktin që synoni të përdorni. Një skedar i quajtur «provenance» nuk mjafton. SLSA provenance.

Për shërbimin e eksportit, regjistroni një zinxhir që mund ta shqyrtoni:

1. Commit-i i shqyrtuar identifikon kodin burimor të pranuar.
2. Procesi build identifikon hyrjet dhe mjedisin e tij të ekzekutimit.
3. Artefakti ka një digest të qëndrueshëm.
4. Kontrollet identifikojnë artefaktin ose kodin burimor që shqyrtuan.
5. Regjistri i vendosjes identifikon artefaktin e vendosur në mjedisin e synuar.

Shmangni një proces build të ndryshëm pas miratimit pa një proces të përcaktuar verifikimi. Një etiketë e ndryshueshme si latest mund t’i referohet një imazhi tjetër më vonë.

Vendosni çfarë kuptimi ka një gjetje

Një gjetje për cenueshmëri kërkon kontekst: versionin e prekur, sjelljen e cenueshme që mund të arrihet, ekspozimin, korrigjimin e disponueshëm dhe pasojën. Regjistroni evidencën që mbështet çdo përjashtim të përkohshëm. Caktoni një person përgjegjës, një afat skadimi dhe një kusht që nxit shqyrtimin.

Mos çaktivizoni një skaner të tërë sepse një gjetje nuk është e zbatueshme. Mos pretendoni rezultat pa gjetje kur skanimi nuk përfundoi. Skadimi i kohës, një paketë e pambështetur ose një burim i padisponueshëm njoftimesh sigurie përbëjnë mungesë evidence.

Në fund, planifikoni përditësimet pas publikimit. Njoftimet e reja të sigurisë mund të prekin artefaktin e pranuar dje. Personi përgjegjës për shërbimin ka nevojë për inventar, proces reagimi dhe kapacitet për të prodhuar një version të korrigjuar.

Vazhdoni me menaxhimin e vazhdueshëm të cenueshmërive për të lidhur skanimet e përsëritura me korrigjimet e verifikuara në prodhim.