La cybersecurity di CISA alza la soglia di riferimento per gli SBOM, ma inventari migliori lasciano ancora lacune di sicurezza

Le linee guida di CISA sulla cybersecurity hanno sostituito un riferimento federale per le distinte base del software risalente a cinque anni fa, nonostante persistano dubbi sulla capacità delle organizzazioni di utilizzarle in modo efficace.

La Cybersecurity and Infrastructure Security Agency ha pubblicato i Minimum Elements for a Software Bill of Materials 2026 insieme alla National Security Agency, al Federal Bureau of Investigation e a partner internazionali. Le linee guida aggiornano il quadro del National Telecommunications and Information Administration pubblicato nel 2021.

Un SBOM, o software bill of materials, è un inventario leggibile automaticamente dei componenti e delle relazioni all'interno di un prodotto software. Può indicare a un'organizzazione se una vulnerabilità appena divulgata sia presente nelle sue applicazioni o infrastrutture.

La sostituzione è rilevante perché il quadro del 2021 fu scritto quando gli strumenti SBOM si occupavano soprattutto di generare inventari. I sistemi attuali scambiano, combinano, convalidano e analizzano tali inventari anche tra pipeline di sviluppo e ambienti dei clienti.

Questa transizione crea la tensione centrale alla base delle nuove linee guida. CISA vuole dati più ricchi e coerenti che le macchine possano elaborare, ma aggiungere campi non garantisce che l'inventario risultante sia completo o utilizzabile.

Il riferimento originale dell'NTIA ha contribuito a stabilire un vocabolario condiviso. Il nuovo quadro di cybersecurity di CISA chiede a produttori e utilizzatori di software di trattare gli SBOM come dati operativi di sicurezza anziché come documenti statici di conformità.

La cybersecurity di CISA sostituisce il riferimento SBOM del 2021

Il cambiamento più importante è istituzionale e operativo: CISA ora gestisce un riferimento più ampio, pensato per la gestione ordinaria del rischio software.

NTIA ha pubblicato gli elementi minimi originali il 12 luglio 2021, in seguito all'Executive Order 14028. Il suo quadro divideva uno SBOM accettabile in tre categorie: campi dati, supporto all'automazione e pratiche e processi.

I sette campi dati originali coprivano nome del fornitore, nome del componente, versione, identificatori univoci, relazioni di dipendenza, autore dello SBOM e timestamp. I requisiti di automazione incoraggiavano formati leggibili automaticamente, mentre le pratiche operative riguardavano frequenza di generazione, distribuzione, accesso, profondità e lacune note.

Questi elementi erano volutamente essenziali. Definivano il più piccolo inventario utile in un momento in cui molti fornitori non avevano mai generato uno SBOM.

La pubblicazione del 2026 aggiorna e sostituisce quel quadro. Segue una consultazione pubblica che CISA ha aperto nell'agosto 2025 e chiuso il 3 ottobre 2025.

L'avviso di consultazione pubblica affermava che gli strumenti SBOM si erano estesi oltre la generazione, includendo condivisione, analisi e gestione. Rilevava inoltre una partecipazione crescente da parte delle comunità open source, dei governi e di altri settori.

CISA non ha creato una regola federale vincolante per gli appalti tramite queste linee guida. Gli elementi minimi restano un riferimento per generare e richiedere SBOM utilizzabili, non una nuova legge o un obbligo universale.

Questa distinzione è importante per i fornitori. Un cliente può adottare il quadro in un contratto o in una procedura di appalto, ma la sola pubblicazione non obbliga ogni azienda software a produrre uno SBOM.

L'ambito previsto è comunque ampio. Il quadro può applicarsi al software acquisito o sviluppato da agenzie governative, inclusi componenti open source, software as a service e software che coinvolge l'intelligenza artificiale.

CISA riconosce inoltre che servizi complessi possono richiedere informazioni aggiuntive rispetto al minimo generale. Una piattaforma SaaS cambia continuamente, mentre un sistema di IA può dipendere da modelli, dataset, framework e servizi esterni che non assomigliano ai pacchetti convenzionali.

Linee guida separate incentrate sull'IA, pubblicate nel 2026, affrontano alcune di queste differenze. Gli elementi minimi generali dello SBOM restano il punto di partenza alla base di tali inventari specializzati.

Le agenzie stanno quindi fissando una soglia comune, non descrivendo ogni possibile catena di fornitura software. Le organizzazioni necessitano ancora di politiche adeguate alle proprie architetture, ai rischi e agli obblighi normativi.

Si tratta di un cambiamento più significativo di un elenco più lungo di campi. Sposta la discussione sugli SBOM dalla definizione di un documento al mantenimento di evidenze condivise sulla composizione del software.

I nuovi elementi minimi richiedono più contesto

Nome e versione di un componente non sono più sufficienti quando i team di sicurezza devono distinguere pacchetti, verificare artefatti e collegare risultati tra strumenti diversi.

Il riferimento del 2026 conserva la struttura in tre parti stabilita da NTIA. Copre ancora campi dati, formati elaborabili automaticamente e pratiche utilizzate per creare, aggiornare e scambiare uno SBOM.

Tuttavia, il modello aggiornato richiede un contesto più ricco sia sul software sia sull'inventario stesso. Il processo di sviluppo ha evidenziato quattro aggiunte: hash dei componenti, informazioni sulle licenze, identificazione degli strumenti e contesto di generazione.

Un hash di componente è un valore crittografico calcolato dal contenuto software. Può aiutare un utilizzatore a distinguere artefatti che condividono nome e versione ma contengono byte diversi.

Questa distinzione è importante quando i fornitori ricompilano pacchetti, applicano patch private o distribuiscono binari specifici per piattaforma. Una stringa di versione può rimanere invariata anche se l'artefatto effettivo differisce.

Gli hash non sono tuttavia un sistema di identità universale. I risultati dipendono da quale oggetto viene sottoposto a hash, dal fatto che tale oggetto sia compresso e da come un processo di build impacchetti i suoi file.

La Business Software Alliance ha sollevato questa questione durante la consultazione. La sua risposta del settore sosteneva che l'hashing può offrire una convalida utile, ma richiede definizioni più chiare per archivi, file estratti, firmware e altre forme software.

Le informazioni sulle licenze aggiungono un'altra dimensione. Aiutano le organizzazioni a identificare i termini associati ai componenti, comprese le dipendenze open source e proprietarie.

I dati sulle licenze supportano la revisione legale e la governance dei componenti, ma migliorano anche l'identificazione di base. Due pacchetti con nomi simili possono avere condizioni diverse di titolarità o distribuzione.

Il nome dello strumento registra quale sistema ha generato lo SBOM. Questo campo offre agli utilizzatori un modo per indagare risultati incoerenti e capire perché due scanner descrivono diversamente lo stesso artefatto.

Il contesto di generazione descrive come è stato prodotto l'inventario. Uno SBOM creato dal codice sorgente può rilevare componenti diversi da uno creato da un'immagine container, da un sistema installato o da un binario finale.

Questa provenienza influenza ciò che un team di sicurezza dovrebbe dedurre dai dati mancanti. Una scansione del codice sorgente può identificare dipendenze dichiarate che non entrano mai in una build di produzione. Una scansione binaria può trovare codice incluso che il manifest del pacchetto ha omesso.

Il quadro aggiornato precisa anche i campi già consolidati. Gli identificatori univoci sono importanti perché i sistemi automatizzati per le vulnerabilità non possono correlare in modo affidabile un nome di pacchetto in testo libero con i record di sicurezza.

Package URLs, identificatori Common Platform Enumeration e tag SWID offrono modi strutturati per identificare il software. Nessun singolo schema copre ogni componente, pertanto i produttori devono selezionare identificatori adatti all'ecosistema disponibile.

Le relazioni di dipendenza restano centrali. Un inventario diventa più utile quando mostra come un componente includa o dipenda da un altro, anziché presentare ogni elemento come una riga non correlata.

Gli elementi minimi del 2021 richiedevano già informazioni sulle dipendenze. Le linee guida attuali attribuiscono a questo requisito un peso operativo maggiore perché il triage delle vulnerabilità dipende sempre più dai grafi delle relazioni.

Le pratiche aggiornate mantengono anche il concetto di “incognite note”. I produttori dovrebbero identificare le aree in cui gli strumenti disponibili non possono determinare se esistano dipendenze aggiuntive.

Questo linguaggio evita un'assunzione pericolosa. Una relazione assente può significare che non esiste alcuna dipendenza, oppure che il generatore non è riuscito a rilevarla.

La differenza è cruciale durante la risposta agli incidenti. I team di sicurezza devono sapere se un risultato di ricerca negativo rappresenti evidenza di assenza o semplicemente visibilità incompleta.

Di fatto, CISA chiede ai produttori di associare fiducia e contesto ai loro inventari. Questo rende uno SBOM meno ordinato, ma anche più onesto.

I fornitori software affrontano un onere probatorio più elevato

Il nuovo riferimento spinge i fornitori a produrre evidenze di sicurezza ripetibili, mentre gli acquirenti devono costruire sistemi in grado di interpretarle.

Per i produttori di software, uno SBOM non può più essere trattato come un file generato una sola volta prima di una revisione commerciale. Deve accompagnare il prodotto attraverso rilasci, ricompilazioni, modifiche alle dipendenze e divulgazioni di vulnerabilità.

Ciò richiede integrazione con i sistemi di sviluppo e distribuzione. Un produttore deve generare l'inventario sufficientemente vicino al processo di build affinché descriva l'artefatto che i clienti ricevono effettivamente.

I team necessitano inoltre di identificatori stabili dei componenti. Se la stessa dipendenza riceve identificatori diversi nelle build successive, il confronto automatizzato e lo scambio di informazioni sulle vulnerabilità diventano inaffidabili.

La divulgazione dello strumento e il contesto di generazione creano un'aspettativa correlata. I produttori devono capire come operano i loro scanner, quali fonti ispezionano e dove termina la loro visibilità.

Questo può mettere in luce lacune scomode. Un'azienda potrebbe scoprire che il suo scanner di build acquisisce i manifest dei pacchetti ma ignora plugin caricati dinamicamente, firmware incorporato, file sorgente copiati o binari proprietari.

I team di ingegneria devono quindi affrontare una scelta pratica. Possono migliorare la pipeline, documentare l'area sconosciuta oppure ottenere migliori dati di composizione da un fornitore a monte.

Questo lavoro va oltre gli specialisti della sicurezza. I team di procurement necessitano di clausole contrattuali per ricevere SBOM, i team legali necessitano di regole di distribuzione e i team di prodotto necessitano di processi per aggiornare i clienti.

Le organizzazioni che gestiscono molte applicazioni necessitano anche di archiviazione ricercabile. Ricevere migliaia di documenti JSON senza indicizzarne i componenti produce burocrazia, non visibilità operativa.

L'onere ricade quindi tanto sugli acquirenti quanto sui venditori. Gli acquirenti devono normalizzare file diversi, proteggere dati potenzialmente sensibili, monitorare nuove vulnerabilità e decidere quali risultati richiedano interventi.

Una corrispondenza grezza di componenti non stabilisce automaticamente l'esposizione. Il codice vulnerabile potrebbe essere escluso dalla build, disabilitato dalla configurazione o irraggiungibile durante il normale funzionamento.

Vulnerability Exploitability eXchange, o VEX, può fornire dichiarazioni leggibili automaticamente sul fatto che un prodotto sia interessato da una vulnerabilità. Tali dichiarazioni dipendono da identificatori stabili che collegano il record VEX al componente SBOM corretto.

Questa relazione spiega perché la qualità degli identificatori è diventata più importante. Un record di componente ambiguo indebolisce ogni successivo tentativo di descrivere sfruttabilità o correzione.

Mostra inoltre perché gli elementi minimi di CISA non possono operare da soli. Le organizzazioni necessitano di database delle vulnerabilità, dati VEX, proprietà degli asset, contesto di runtime e flussi di risposta attorno all'inventario.

I contraenti federali avvertiranno per primi la pressione, perché le agenzie possono incorporare il riferimento nei requisiti di acquisizione. È inoltre probabile che i clienti enterprise adottino le stesse domande per le valutazioni dei fornitori.

L’allineamento internazionale amplifica questo effetto. Un fornitore che opera in più mercati trae vantaggio dalla produzione di un unico inventario interoperabile anziché dal mantenimento di versioni nazionali separate.

Tuttavia, l’armonizzazione riduce l’onere solo quando i clienti interpretano il riferimento in modo coerente. Campi, formati e regole di consegna aggiuntivi specifici per contratto possono ricreare la frammentazione che gli elementi minimi intendono evitare.

I team software dovrebbero quindi trattare le linee guida come un contratto sui dati. I produttori promettono un livello definito di visibilità e i consumatori promettono di gestire tali dati in modo responsabile.

Una knowledge base ingegneristica può aiutare i team a collegare le decisioni sugli SBOM con i record di build, la documentazione dei fornitori e le note di correzione. Non sostituisce una piattaforma di analisi dei componenti, ma può conservare il ragionamento alla base di ogni risposta.

Il maggiore onere probatorio non è intrinsecamente negativo. Inventari ripetibili possono abbreviare la ricerca dei prodotti interessati quando una dipendenza ampiamente utilizzata diventa vulnerabile.

Il beneficio emerge solo dopo che le organizzazioni collegano la generazione a responsabilità e azioni. Altrimenti, l’SBOM migliorato diventa un altro allegato che nessuno esamina fino all’avvio di un audit.

Dati SBOM Migliori Non Possono Ancora Garantire una Sicurezza Migliore

Il riferimento più ricco di CISA migliora l’input alla gestione delle vulnerabilità, ma grafi delle dipendenze incompleti possono comunque produrre conclusioni pericolosamente sicure di sé.

Un preprint del luglio 2026 ha esaminato 78.612 file SBOM provenienti da un dataset pubblico, di cui 77.092 erano analizzabili. I ricercatori si sono concentrati sugli archi di dipendenza anziché limitarsi a verificare la presenza dei campi dei componenti.

Il loro studio sui grafi delle dipendenze ha rilevato che il 52,9 per cento degli SBOM analizzabili non dichiarava alcun arco di dipendenza. Ogni componente di tali file appariva isolato.

Un ulteriore 8,8 per cento conteneva un blocco delle dipendenze, ma lasciava disconnessa la maggior parte dei componenti. Tra gli inventari più grandi di quel gruppo, la quota mediana di componenti orfani era del 93 per cento.

Solo il 38,3 per cento della popolazione totale formava grafi ben connessi. Lo studio ha inoltre rilevato che la qualità dei grafi variava notevolmente in base al generatore, anche quando gli strumenti esaminavano software comparabili.

Questi risultati provengono da un preprint e non dovrebbero essere considerati una misurazione universale degli inventari aziendali privati. Illustrano comunque il problema di implementazione alla base dell’enfasi di CISA sulle relazioni tra dipendenze e sulle incognite note.

Un inventario piatto può rispondere alla domanda se il nome di un pacchetto compaia da qualche parte. Non può spiegare in modo affidabile quale applicazione lo contenga, cosa dipenda da esso o se un percorso raggiunga il codice vulnerabile.

Questa limitazione influisce sulla definizione delle priorità. Alcuni sistemi di sicurezza sopprimono una segnalazione quando l’SBOM non mostra alcun percorso dal prodotto al componente interessato.

Se il grafo è incompleto, “nessun percorso” non significa “non raggiungibile”. Significa che l’inventario non dispone di prove che colleghino i nodi.

Lo studio ha testato un approccio che convertiva risultati negativi sospetti in uno stato esplicito di sconosciuto. Nel suo esperimento controllato di ricalcolo, il richiamo rispetto al catalogo Known Exploited Vulnerabilities di CISA è salito da 0,600 a 0,950.

Questi numeri descrivono il sistema dei ricercatori, non un risultato garantito per ogni organizzazione. La lezione di fondo è più ampia: l’incertezza deve rimanere visibile lungo l’intero processo di analisi.

È qui che la conformità minima può divergere dalla sicurezza operativa. Un file può contenere ogni campo nominato pur rappresentando in modo errato il prodotto a causa di una scoperta superficiale o di relazioni interrotte.

Anche gli hash dei componenti hanno dei limiti. Un hash può verificare che due oggetti siano identici, ma non spiega se l’oggetto contenga codice vulnerabile o riceva input non sicuri.

Neppure i campi relativi alle licenze stabiliscono la sicurezza. Migliorano la governance dei componenti, ma identificare correttamente una licenza non dice nulla sulla sfruttabilità.

I nomi degli strumenti e il contesto di generazione aiutano i consumatori a valutare la qualità delle prove, ma solo se comprendono gli strumenti. Registrare “source scan” è utile quando il sistema ricevente lo tratta diversamente da una scansione di artefatti post-build.

Gli SBOM possono anche rivelare informazioni sensibili. Inventari dettagliati dei componenti potrebbero esporre scelte architetturali, dipendenze obsolete o obiettivi che un attaccante può analizzare.

Le organizzazioni necessitano di politiche di distribuzione che bilancino accesso e rischio. Un progetto open source pubblico, un dispositivo medico regolamentato e un sistema governativo riservato non richiedono modelli di condivisione identici.

La freschezza dei dati presenta un’altra sfida. Un inventario accurato diventa fuorviante dopo che il software cambia, a meno che i produttori non lo rigenerino e i consumatori non lo associno alla release corretta.

I servizi cloud complicano tale associazione perché i loro componenti distribuiti possono cambiare senza che un cliente scarichi un nuovo pacchetto. I servizi continui necessitano di pratiche di aggiornamento e notifica che gli inventari statici dei prodotti non forniscono.

I sistemi di IA introducono ulteriore ambiguità. Modelli, dataset, adattatori, API remote, framework di orchestrazione e librerie convenzionali possono tutti influenzare il comportamento, eppure non ogni elemento rientra nei tradizionali campi dei componenti.

Il nuovo riferimento riconosce che i sistemi specializzati necessitano di informazioni aggiuntive. Non risolve ogni questione su come inventariare una pipeline di modelli in evoluzione o una dipendenza ospitata esternamente.

Questi limiti non rendono inutili gli SBOM. Definiscono il confine tra visibilità e garanzia.

Un elenco degli ingredienti può aiutare a identificare un ingrediente richiamato, ma non può dimostrare che la cucina abbia seguito procedure sicure. Sviluppo sicuro, test, patching, monitoraggio e risposta agli incidenti restano necessari.

La lettura più solida delle linee guida non è quindi “più campi equivalgono a software sicuro”. È “prove migliori supportano decisioni migliori quando le organizzazioni ne preservano il contesto e l’incertezza”.

L’Allineamento Internazionale Alza la Posta

Il sostegno congiunto trasforma l’aggiornamento di CISA in un punto di riferimento in grado di influenzare l’acquisto di software ben oltre il governo federale statunitense.

Le catene di fornitura del software attraversano i confini nazionali. Un prodotto progettato in un Paese può contenere pacchetti open source gestiti in molti altri ed essere eseguito su infrastrutture operate altrove.

Diverse definizioni di SBOM creano attriti lungo tutta quella catena. I produttori devono tradurre i campi, rigenerare i file o spiegare perché i dati richiesti da un cliente non esistano in un altro formato.

I partner internazionali stanno lavorando verso una visione condivisa di ciò che gli SBOM dovrebbero realizzare. La loro partecipazione alle linee guida del 2026 rafforza la tesi a favore di dati minimi comuni e di uno scambio leggibile dalle macchine.

Tale allineamento non crea un’unica legge globale. Ogni governo conserva le proprie regole di appalto, l’autorità normativa e il calendario di applicazione.

Può comunque plasmare contratti e aspettative tecniche. Gli acquirenti spesso adottano il linguaggio delle linee guida governative perché offre un riferimento difendibile durante le valutazioni dei fornitori.

Il Cyber Resilience Act dell’Unione europea aggiunge urgenza per i produttori che vendono prodotti con elementi digitali. I suoi requisiti creano un quadro giuridico separato, ma l’inventario del software e la gestione delle vulnerabilità occupano un territorio operativo simile.

I produttori di dispositivi medici affrontano anche un altro caso d’uso consolidato. La legge statunitense richiede ai produttori di determinati dispositivi cyber di fornire un SBOM e processi per affrontare le vulnerabilità post-commercializzazione.

Anche gli operatori di infrastrutture critiche necessitano di risposte rapide quando una libreria comune o un componente incorporato diventa un bersaglio. La loro sfida spesso non consiste nell’identificare una dipendenza, ma nel localizzarla in sistemi di lunga durata forniti da più vendor.

Un riferimento condiviso aiuta solo se partecipano i fornitori a monte. Il produttore di un’applicazione finita non può sempre identificare il contenuto di un binario chiuso ricevuto da un’altra azienda.

I requisiti contrattuali possono spingere questa richiesta più in profondità nella catena di fornitura. Possono anche svantaggiare i fornitori più piccoli, privi di team dedicati alla compliance e all’ingegneria della sicurezza.

L’enfasi di CISA sull’automazione mira a ridurre tale onere. I moderni strumenti di sviluppo possono generare inventari durante le build e i formati comuni consentono ai sistemi a valle di elaborarli senza trascrizione manuale.

L’automazione può anche amplificare gli errori. Se uno scanner omette sistematicamente le dipendenze, ogni SBOM generato può ripetere lo stesso punto cieco con un’impressionante coerenza.

Il test di interoperabilità è quindi importante quanto la scelta del formato. I produttori dovrebbero confrontare gli output, convalidare i grafi delle relazioni e confermare che gli strumenti a valle preservino correttamente gli identificatori.

I consumatori necessitano di una disciplina reciproca. Dovrebbero definire in che modo i dati SBOM influenzano acquisti, monitoraggio, correzione e comunicazione con i fornitori prima di richiederli su larga scala.

La Business Software Alliance ha sostenuto aspettative armonizzate durante la consultazione del 2025. Ha inoltre messo in guardia contro requisiti di approvvigionamento quando i destinatari non sono in grado di acquisire e utilizzare le informazioni.

Questa posizione coglie il principale compromesso politico. Richiedere prove può incoraggiare un’ingegneria migliore, ma raccogliere prove inutilizzabili spreca risorse e crea un falso senso di controllo.

L’allineamento internazionale alza la posta perché una pratica debole può diffondersi con la stessa facilità di una buona. Un riferimento riconosciuto a livello globale dovrebbe incoraggiare inventari coerenti e utili, non burocrazia coerente a livello globale.

Tre Segnali Mostreranno se il Riferimento del 2026 Funziona

Le linee guida avranno successo solo se migliorerà la qualità delle dipendenze, gli acquirenti renderanno operativi i dati e le pratiche SBOM specializzate resteranno interoperabili.

Il primo segnale è un miglioramento misurabile nei grafi delle dipendenze. Gli studi futuri dovrebbero rilevare meno inventari piatti, meno componenti disconnessi e un maggiore uso di indicatori espliciti di completezza.

Tale risultato rafforzerebbe la premessa di CISA secondo cui elementi minimi più chiari possono migliorare le decisioni sulle vulnerabilità assistite dalle macchine. Il perdurare di fallimenti nei grafi dimostrerebbe che le definizioni da sole non possono correggere il comportamento dei generatori.

Il secondo segnale riguarda il modo in cui le agenzie federali e gli acquirenti enterprise modificano gli appalti. Un’adozione utile collegherà la consegna degli SBOM con validazione, responsabilità sugli asset, gestione VEX e aspettative di risposta.

Richieste che si limitano ad aggiungere un campo di caricamento a un questionario indeboliranno la tesi. Aumentano il lavoro dei fornitori senza migliorare la rapidità o la qualità delle decisioni di sicurezza.

Il terzo segnale è l’interoperabilità tra inventari convenzionali, cloud e IA. Le linee guida specializzate dovrebbero estendere il riferimento comune senza creare definizioni incompatibili per identificatori, relazioni o timestamp.

Un allineamento riuscito consentirebbe a un’organizzazione di tracciare un pacchetto convenzionale vulnerabile attraverso un servizio cloud o un’applicazione di IA. Schemi frammentati ricreerebbero le lacune di visibilità che l’aggiornamento del 2026 sta cercando di colmare.

I produttori di software non devono attendere tali esiti. Possono esaminare gli inventari attuali, identificare come ciascuno sia stato generato e verificare se le relazioni sopravvivano all’acquisizione nei sistemi rivolti ai clienti.

Gli acquirenti possono svolgere lo stesso esercizio dall’altro lato. Chiedetevi se una vulnerabilità appena divulgata possa essere tracciata da un record di componente a un prodotto interessato, un responsabile, una decisione e uno stato di correzione.

Questo flusso di lavoro è il vero test delle linee guida di cybersecurity di CISA. Se la vostra organizzazione ricevesse oggi un SBOM accurato, riuscirebbe a trasformare tali prove in una decisione di sicurezza tempestiva?

Partite da un prodotto importante e seguite i dati dalla build fino alla risposta. I collegamenti mancanti riveleranno se il vostro programma SBOM è un controllo operativo o soltanto un archivio d’inventario.