Buongiorno, Damiano Verzulli <damiano@verzulli.it> writes:
Il 18/09/24 12:52 PM, 380° via nexa ha scritto:
[...] ...poi l'articolo si trasforma in uno SPROLOQUIO sulla "software supply chain" (con soluzioni ridicole tipo gli SBOM - Software Bill Of Material)
Come tante medicine, la SBOM non è certamente la soluzione di tutti i mali (del software).
[...]
la SBOM ci porterebbe piu' in la. Sensibilmente. Non a 100... ma almeno a 30/40 (che sarebbe gia' un risultato gigantesco, dato il punto di partenza attuale)
Quindi, IMO, ben vengano le SBOM...
alcuni, tra cui me, sostengono invece che gli SBOM sono _ingannevoli_ esempi di implementazioni di sistemi SBOM: 1. https://en.wikipedia.org/wiki/Software_Package_Data_Exchange esempi: https://github.com/spdx/spdx-examples/tree/master/software 2. https://cyclonedx.org/ 3. https://nvd.nist.gov/products/swid le _etichette_ date al software in modo del tutto analogo ai codici dei componenti fisici che compongono la "bill of material" (BOM) degli artefatti _fisici_ sono *solo* fuorvianti; quelle etichette danno l'illusione di avere sotto controllo la supply chain del sofware e _quindi_ sono pericolose non si deve /ridurre/ la sicurezza della software supply chain a una FATICOSA operazione _burocratica_ di /compilazione/ di documenti (JSON, XML, YAML...) pieni di etichette... senza /ricadute pratiche/; tra l'altro solo per "star dietro" a uno SBOM ci vogliono un sacco di risorse (sprecate) i motivi per cui sostengo quanto sopra sono illustrati in un articolo che segnalai su questa lista nel Marzo scorso [1]: «Identifying software» Ludovic Courtès, Maxim Cournoyer, Jan Nieuwenhuizen, Simon Tournier — March 4, 2024 https://guix.gnu.org/en/blog/2024/identifying-software/ il nocciolo super-sintetico della critica agli SBOM è questo: --8<---------------cut here---------------start------------->8--- The Common Platform Enumeration (CPE) standard has been designed to fill that role; it is used to identify software as part of the well-known Common Vulnerabilities and Exposures (CVE) process. But CPE is showing its limits as an extrinsic identification mechanism: the human-readable identifiers chosen by CPE fail to capture the complexity of what “software” is. [...] mere package name/version pairs such as gcc 11.3.0 fail to capture the breadth and depth elements that lead to a binary artifact. This is a shortcoming of systems such as the Common Platform Enumeration (CPE) standard: it fails to express whether a vulnerability that applies to gcc 11.3.0 applies to it regardless of how it was built, patched, and configured, or whether certain conditions are required. [...] Again, a software bill of materials (SBOM) written as a mere list of package name/version pairs would fail to capture as much information. The Artifact Dependency Graph (ADG) of OmniBOR (https://omnibor.io/), while less ambiguous, falls short in two ways: it is too fine-grained for typical cybersecurity applications (at the level of individual source files), and it only captures the alleged source/binary correspondence of individual files but not the process to go from source to binary. --8<---------------cut here---------------end--------------->8--- l'articolo ricalca quanto gli autori hanno scritto in un loro commento a seguito di una RFC (request for comment) [2] della CISA (Cybersecurity and Infrastructure Security Agency) in merito al loro documento intitolato «Software Identification Ecosystem Option Analysis» [3]; il commento non è arrivato in tempo per essere pubblicato, ma è disponibile negli archivi del progetto Guix in PDF [4]. detto in altre parole: un sistema /estrinseco/ (al processo di build) per (tentare di) identificare tutti i "componenti" di un software binario è inadatto allo scopo di garantire un «effective vulnerability management» (cit. da [3]); un «effective vulnerability management» è possibile solo utilizzando un sistema /intrinseco/ (al processo di build). Last BUT NOT least, il processo di build _deve_ includere il c.d. full-source bootstrap [5], altrimenti il «vulnerability management» è /ineffective/. --8<---------------cut here---------------start------------->8--- In other words, because Guix itself defines how artifacts are built, the revision of the Guix source coupled with the package name unambiguously identify the package’s binary artifact. As scientists, we build on this property to achieve reproducible research workflows, as explained in this 2022 article in Nature Scientific Data; as engineers, we value this property to analyze the systems we are running and determine which known vulnerabilities and bugs apply. --8<---------------cut here---------------end--------------->8--- (https://guix.gnu.org/en/blog/2024/identifying-software/) per approfondimenti segnalo il paper «Building a Secure Software Supply Chain with GNU Guix» pubblicato il 2022-06-15 su «The Art, Science, and Engineering of Programming, 2023, Vol. 7, Issue 1, Article 1» disponibile qui: https://programming-journal.org/2023/7/1/ saluti, 380° [1] Message-id: 87plvwsmkj.fsf@xelera.eu [2] https://www.regulations.gov/document/CISA-2023-0026-0001 [3] https://www.cisa.gov/resources-tools/resources/software-identification-ecosy... [4] https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/doc/cisa-2023-0... [5] https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-so... -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.