Verificați ce intră în versiunea lansată

Întrebați dacă dependența este necesară

Un agent poate sugera un pachet care pare să rezolve o problemă. Sugestia este o propunere, nu o dovadă că pachetul există sau este potrivit. Verificați registrul exact, editorul, numele pachetului și versiunea înainte de instalare.

Pentru un export CSV fictiv, mediul de execuție poate oferi deja comportamentul necesar. Un pachet nou poate fi totuși potrivit, dar adaugă mentenanță și căi de execuție. Comparați efortul implementării cu responsabilitățile continue ale dependenței.

Verificați licența și mediul de execuție acceptat. Inspectați activitatea de mentenanță și notificările relevante. Un nume familiar poate desemna un alt pachet într-un alt registru. O instalare reușită arată doar că instalarea s-a încheiat.

Inspectați comportamentul instalării și al procesului de build

Dependențele pot executa cod în timpul instalării sau al procesului de build. Limitați credențialele și accesul la rețea în aceste medii. Nu expuneți secrete de producție unui job care procesează un pull request care nu este de încredere.

Folosiți un lockfile inclus în commit acolo unde ecosistemul îl acceptă. Cereți procesului de build să respecte acel fișier. Verificați modificările lockfile-ului împreună cu modificarea sursei, inclusiv pachetele tranzitive neașteptate. Fixarea versiunilor îmbunătățește reproductibilitatea, dar nu face sigură o versiune vulnerabilă.

SSDF de la NIST acoperă protecția software-ului și practicile de dezvoltare pe întregul ciclu de viață. Folosiți această perspectivă mai amplă când proiectați mediul de build. Citiți cadrul.

Deosebiți inventarul de proveniență

O listă de materiale software, sau SBOM, consemnează componentele software-ului. Vă ajută să identificați versiunile afectate când o componentă devine problematică. Nu dovedește independent că acele componente sunt sigure.

Proveniența arată cum a fost produs un artefact. SLSA definește un format de proveniență pentru informații despre build și intrările sale. Verificarea trebuie să lege aceste informații de un producător de încredere și de artefactul pe care intenționați să îl folosiți. Un fișier numit „provenance” nu este suficient. Proveniența SLSA.

Pentru serviciul de export, consemnați un lanț pe care îl puteți inspecta:

1. Commit-ul verificat identifică sursa acceptată.
2. Procesul de build identifică intrările și mediul său de execuție.
3. Artefactul are un hash stabil.
4. Verificările identifică artefactul sau sursa examinate.
5. Instalarea consemnează artefactul plasat în mediul țintă.

Evitați refacerea diferită a build-ului după aprobare fără un proces definit de verificare. O etichetă modificabilă precum latest poate desemna ulterior o altă imagine.

Stabiliți ce înseamnă o constatare

O constatare de vulnerabilitate necesită context: versiunea afectată, comportamentul care poate fi executat, expunerea, corecția disponibilă și consecința. Notați dovezile din spatele oricărei excepții temporare. Atribuiți-i un responsabil, o expirare și o condiție de reevaluare.

Nu dezactivați un scaner întreg deoarece o constatare nu se aplică. Nu raportați un rezultat fără probleme când scanarea nu s-a terminat. Depășirea timpului, un pachet neacceptat sau un flux indisponibil de notificări de vulnerabilitate înseamnă dovezi lipsă.

În final, planificați actualizări după lansare. Notificări noi pot afecta artefactul acceptat ieri. Responsabilul serviciului are nevoie de un inventar, un proces de răspuns și capacitatea de a produce o versiune corectată.

Continuați cu gestionarea continuă a vulnerabilităților pentru a lega scanările repetate de corecțiile verificate în producție.