Verifiqueu què entra a la versió publicada

Pregunteu si la dependència és necessària

Un agent pot suggerir un paquet que sembli resoldre un problema. El suggeriment és una proposta, no una evidència que el paquet existeixi o sigui adequat. Verifiqueu el registre, l’editor, el nom del paquet i la versió exactes abans d’instal·lar-lo.

Per a una exportació CSV fictícia, l’entorn d’execució potser ja proporciona el comportament requerit. Un paquet nou encara pot ser adequat, però afegeix manteniment i recorreguts d’execució. Compareu l’esforç d’implementació amb les responsabilitats continuades de la dependència.

Reviseu la llicència i l’entorn d’execució admès. Inspeccioneu l’activitat de manteniment i els avisos rellevants. Un nom conegut pot correspondre a un paquet diferent en un altre registre. Una instal·lació satisfactòria només mostra que la instal·lació s’ha completat.

Inspeccioneu el comportament d’instal·lació i construcció

Les dependències poden executar codi durant la instal·lació o la construcció. Limiteu les credencials i l’accés de xarxa en aquests entorns. No exposeu secrets de producció a una tasca que processi una pull request no fiable.

Utilitzeu un fitxer de bloqueig de dependències versionat quan l’ecosistema ho admeti. Exigiu que la construcció respecti aquest fitxer. Reviseu els canvis del fitxer de bloqueig juntament amb el canvi de codi, inclosos els paquets transitius inesperats. Fixar versions millora la reproduïbilitat, però no fa segura una versió vulnerable.

El SSDF de NIST cobreix la protecció del programari i les pràctiques de desenvolupament durant tot el cicle de vida. Utilitzeu aquesta perspectiva més àmplia quan dissenyeu l’entorn de construcció. Llegiu el marc.

Distingiu l’inventari de la procedència

Una llista de materials de programari, o SBOM, registra els components d’un programari. Ajuda a identificar les versions afectades quan un component esdevé motiu de preocupació. No acredita per si sola que els components siguin segurs.

La procedència descriu com s’ha produït un artefacte. SLSA defineix un format de procedència per a la informació de la construcció i les seves entrades. La verificació ha de relacionar aquesta informació amb un productor fiable i amb l’artefacte que voleu utilitzar. Un fitxer anomenat «provenance» no és suficient. Procedència SLSA.

Per al servei d’exportació, registreu una cadena que pugueu inspeccionar:

1. El commit revisat identifica el codi font acceptat.
2. La construcció identifica les entrades i l’entorn d’execució.
3. L’artefacte té una empremta criptogràfica estable.
4. Les comprovacions identifiquen l’artefacte o el codi font que han examinat.
5. El desplegament registra l’artefacte col·locat a l’entorn de destinació.

Eviteu reconstruir de manera diferent després de l’aprovació sense un procés de verificació definit. Una etiqueta mutable com ara latest pot referir-se a una imatge diferent més endavant.

Decidiu què significa un problema detectat

Una vulnerabilitat detectada necessita context: la versió afectada, si es pot arribar al comportament vulnerable, l’exposició, la correcció disponible i la conseqüència. Registreu les evidències de qualsevol excepció temporal. Assigneu-hi un responsable, una caducitat i una condició de revisió.

No desactiveu un escàner sencer perquè un dels problemes detectats no sigui aplicable. No afirmeu que no hi ha problemes quan l’anàlisi no s’ha pogut completar. Un temps d’espera excedit, un paquet no admès o una font d’avisos no disponible signifiquen que falten evidències.

Finalment, planifiqueu les actualitzacions després de la publicació. Els avisos nous poden afectar l’artefacte acceptat ahir. El responsable del servei necessita un inventari, un procés de resposta i capacitat per produir una versió corregida.

Continueu amb la gestió contínua de vulnerabilitats per relacionar les anàlisis repetides amb correccions verificades en producció.