A Large-Scale Measurement of AI Bill of Materials Completeness in Hugging Face Models

A Large-Scale Measurement of AI Bill of Materials Completeness in Hugging Face Models Md Erfan, Ahmed Ryan, and Md Rayhanur Rahman†

arXiv:2607.17242v1 [cs.SE] 19 Jul 2026

Department of Computer Science, The University of Alabama, Tuscaloosa, USA Email: {merfan, aryan9}@crimson.ua.edu, [email protected] † Corresponding Author: Md Rayhanur Rahman

Abstract—Pretrained machine learning (ML) models help developers build ML-intensive software systems without training models from scratch. However, model repositories often provide incomplete machine-readable documentation about model provenance, licenses, datasets, limitations, and external references, creating transparency and governance gaps across the AI supply chain. Artificial Intelligence Bills of Materials (AIBOMs) address these gaps by documenting AI artifacts, including models, metadata, licenses, datasets, model-card information, and external references. Taking public Hugging Face (HF) model repositories as a case study, this paper empirically investigates AIBOM completeness, defined as the extent to which repositories provide AIBOM-relevant information for machine-readable AI supplychain documentation. We examine approximately 97.5K AIBOM artifacts to assess the extent to which generated AIBOMs: (i) contain required structural and metadata fields, (ii) represent model identity, license, and external-reference information, (iii) capture model-card documentation such as datasets, limitations, safety-risk assessment, and environmental information, and (iv) vary in documentation coverage across repository and artifact characteristics such as task, license availability, dataset declaration, model family, and paper reference. Results indicate that generated AIBOMs provide complete coverage of required AIBOM structure but limited AI-specific documentation completeness. Required fields are fully represented, but model-card, metadata, responsibleuse, environmental, limitation, and meaningful-description fields remain weakly represented or missing across generated artifacts. Our findings motivate improved model-card practices, repositorylevel traceability, and automated AIBOM validation to advance the generation and adoption of more complete AIBOMs. Index Terms—AI Bill of Materials, Hugging Face, Machine Learning Models, AI Supply Chain, Model Transparency, Model Documentation, Repository Mining, AIBOM Completeness

Fig. 1: Motivating example showing how information from a public HF model repository is transformed into a structured AIBOM and evaluated for completeness and readiness.

its ingredients, where it was produced, how it was processed, or whether it is safe and suitable for use.

AI models are reused in high-impact domains such as healthcare, finance, education, scientific research, and public services, where model behavior can affect decisions across downstream software systems. Therefore, downstream users I. I NTRODUCTION need to know a model’s provenance, training or referenced The rapid growth of Large Language Models (LLMs) and datasets, license, version, documented limitations, safety risks, generative AI is changing how software systems are built, and external references. Figure 1 illustrates this motivation: reused, and deployed. Instead of developing every model from information about a public HF model may be available, scratch, developers increasingly rely on pretrained models but it is often scattered across model-card text, repository shared through public model hubs such as Hugging Face metadata, files, and external links; AIBOM generation organizes (HF) [16, 24]. These repositories now host millions of models this information into machine-readable fields and exposes across tasks such as text generation, image generation, classifi- which transparency fields remain missing. This transparency cation, speech recognition, robotics, and multimodal reasoning. need has security and governance implications. Prior work As the number and variety of models continue to grow, AI has shown that public model repositories can expose users development increasingly depends on pretrained models that to supply-chain risks, including unsafe model serialization, are downloaded, fine-tuned, integrated into applications, and malicious model files, suspicious configuration files, and redistributed across downstream pipelines. To use a food- repository-level attack vectors [6, 13, 23, 34]. An Artificial supply-chain metaphor, selecting a pretrained AI model without Intelligence Bill of Materials (AIBOM) provides machinedocumentation is like selecting a food product without knowing readable information for AI model supply-chain transparency

at development time [32, 33]. Without such information, public AI-specific transparency and readiness fields, including model reuse becomes difficult to audit, govern, and trust. documented limitations, safety-risk assessment, intended Existing research has examined HF model reuse [24], use, ethical considerations, environmental information, repository evolution and maintenance, carbon-footprint reportdatasets, licenses, and scholarly paper references. ing [8], user perceptions of multimodal LLMs [26], model-card • We examine how AIBOM documentation coverage varies documentation [4, 11, 27, 38], fairness and responsible-AI conacross repository and artifact characteristics, including cerns [5, 10, 41], licensing and model transparency [18, 31, 43], task, license availability, dataset declaration, paper refSBOM adoption and tooling [19, 20, 42, 44, 46], and emerging erence, model family, architecture, parameter size, and AIBOM frameworks [2, 12, 15, 35, 39]. These studies provide format, and discuss the implications of these gaps for AI evidence about how public model repositories grow, how supply-chain transparency, traceability, governance, and models are documented, and how supply-chain transparency reuse. We make experimental data and analysis available mechanisms are being proposed for AI systems. However, AIat: https://figshare.com/s/185c21d7bf411fa4b952 BOM completeness, meaning field-level information coverage, The paper is organized as follows. Section II presents key remains underexplored at scale. This limitation is consequential concepts and related work. Section III describes the study because AIBOMs can facilitate governance, traceability, and design, including dataset construction, AIBOM generation, reuse only when generated artifacts contain sufficient infor- completeness scoring, artifact parsing, and analysis procedures. mation about models, licenses, datasets, limitations, external Section IV presents results and key findings. Section V references, and AI-specific transparency fields. discusses implications for AIBOM tooling, model reuse, and The goal of this study is to support model publishers, AIBOM supply-chain governance. Section VI discusses threats to tool developers, researchers, and end users in advancing AI validity. Section VII concludes the paper with future work. supply-chain transparency by evaluating AIBOMs generated II. K EY C ONCEPTS AND R ELATED W ORK from Hugging Face models, measuring their completeness and readiness across model repositories, and informing machineWe provide key concepts with related work discussion in readable AI governance, traceability, and reuse. this section to position our study. We address the following research questions (RQs). RQ1. How complete are AIBOMs generated from A. Key Concepts Hugging Face model repositories at scale? This section provides background on the HF Hub, AIBOMs, RQ2. Which granular AIBOM fields are most frequently and the OWASP AIBOM Generator. These concepts frame our present or missing in generated AIBOM artifacts? study of AIBOM completeness across HF model repositories. RQ3. How does AIBOM documentation coverage vary 1) The Hugging Face Hub: Training and deploying Machine across model repository and artifact characteristics? Learning (ML) models requires substantial computational We answer these RQs through a large-scale repository- resources, domain knowledge, and engineering effort [24, 45]. mining study of HF model repositories. We collect a snapshot Model reuse therefore plays an important role in modern AI of 2,942,466 public HF model records and retain 97,940 models development, because pretrained models can be downloaded, with more than 100 downloads for AIBOM generation and fine-tuned, integrated, and redistributed across downstream analysis. We then generate AIBOM artifacts using the OWASP software systems [36]. The HF Hub facilitates model reuse by GenAI Security Project AIBOM Generator and extract overall providing a public platform for hosting, sharing, versioning, and category-level completeness scores. Finally, we parse the and accessing machine learning models and datasets [22]. AIBOM artifacts to measure individual field availability and Each model repository can include model files, configuracompare documentation coverage across repository and artifact tion files, tokenizer files, tags, license information, dataset characteristics, including task, license, dataset declaration, references, evaluation results, external links, and model-card paper reference, model family, architecture, parameter size, documentation. The repository structure allows model files and and format. This methodology evaluates AIBOM completeness documentation artifacts to be versioned and updated over time. at the score, category, field, and repository-characteristic levels Model cards are central to documentation on the HF Hub. across generated artifacts for downstream transparency. A model card can describe model purpose, training data, In summary, our paper makes the following contributions: evaluation metrics, intended use, limitations, and potential • We generate a large-scale empirical dataset of 97,940 biases [27]. End users often rely on such repository-level AIBOM artifacts and corresponding completeness score documentation to assess whether a model is suitable for records from HF model repositories for downstream reuse, fine-tuning, deployment, or governance review [14]. transparency analysis and evaluation. Model cards and AIBOMs are related, but they serve different • We empirically evaluate AIBOM completeness across five purposes. Model cards primarily document model behavior and major documentation categories: required fields, metadata, intended use, whereas an AIBOM organizes AI supply-chain component-basic information, model-card documentation, information into a machine-readable format. Therefore, modeland external traceability references. card information can provide important input for AIBOM • We analyze whether individual AIBOM fields are present generation, while the resulting AIBOM can support broader or missing in generated artifacts and identify gaps in transparency, traceability, governance, and reuse.

2) Artificial Intelligence Bill of Materials: A Software pretrained ML model reuse, repository evolution, documentaBill of Materials (SBOM) provides a structured inventory tion, sustainability, and user-facing challenges. Prior work has of software components, dependencies, licenses, and meta- examined how practitioners select and reuse pretrained models, data [25, 40, 42]. SBOMs support software supply-chain which repository attributes support reuse, and what risks transparency by helping organizations identify dependencies, arise from incomplete provenance, inconsistent performance evaluate security risks, and respond to security and compliance claims, and limited documentation [24]. Repository-mining issues. An AIBOM extends this idea to AI and machine learning studies have further analyzed model-card descriptions, metadata, systems. AI systems can depend on pretrained models, datasets, commit activity, task trends, framework usage, maintenance framework libraries, configuration files, training environments, signals, carbon-reporting practices [8, 9], user discussions [26], evaluation artifacts, and documentation. These assets create and downstream pre-trained models dependency evolution [1], a broader supply-chain surface than conventional software showing that HF functions as an evolving software ecosystem dependencies. An AIBOM captures AI-specific assets in a rather than only a model-hosting platform for AI reuse and machine-readable format, enabling consistent examination of governance workflows [7, 8, 24, 26, 31]. model provenance, licensing, dataset usage, external references, Other empirical work has focused on specific transparency and transparency information for downstream governance tasks, concerns in the HF ecosystem. Castaño et al. [8] studied audits, and reuse decisions [12, 29, 30]. carbon-emission reporting and carbon-efficiency factors, while The need for AIBOMs increases as AI models move Liu et al. [26] analyzed user discussions around generalthrough reuse, fine-tuning, integration, and redistribution before purpose and multimodal LLMs, identifying concerns such as deployment in software systems. Model users need to know access barriers, generation quality, deployment complexity, which datasets influenced a model, which license governs documentation limitations, and resource constraints. These reuse, which base model was used, which external resources studies characterize model reuse, maintenance, sustainability, are linked, and whether limitations or evaluation information and user-facing concerns. Our work builds on this repositoryare available [27]. Incomplete documentation can limit security mining perspective but shifts the analysis target to whether review, compliance assessment, reproducibility analysis, and public HF repositories contain sufficient structured information downstream governance [37]. A structured AIBOM can reduce to support complete CycloneDX-based AIBOM generation. 2) ML Model Documentation, Transparency, and Responthis uncertainty by organizing available model information into sible AI: Model documentation has been widely studied as a machine-readable representation [28, 33]. 3) OWASP AIBOM Generator: The OWASP GenAI Security a mechanism for improving transparency, accountability, and AIBOM Generator is an open-source tool for generating responsible reuse of ML models. Mitchell et al. [27] introduced AIBOMs for models hosted on HF [17]. The tool accepts model cards as structured documentation for reporting model a HF model identifier as input and extracts available repository details, intended uses, evaluation conditions, and limitations. information, including model metadata, model descriptions, Later work examined how model documentation is produced, model-card content, license information, configuration details, maintained, extracted, and presented in practice across reposiand external references when available. The extracted infor- tory settings. Bhat et al. [4] analyzed model descriptions from mation is organized into a machine-readable SBOM using the Hugging Face, GitHub, and industrial sources, and proposed DocML to guide model-card creation and maintenance. Tsay CycloneDX JSON format [30]. The tool also reports an AIBOM completeness score et al. [38] proposed AIMMX for extracting AI model metadata that measures field-level information coverage across five from repositories. Crisan et al. [11] studied interactive model categories. Required fields capture the minimal CycloneDX cards and examined how interactive documentation affects structure needed for model identification, while metadata understandability, interpretability, and trust. These studies focus captures information about the AIBOM and model purpose. on improving, extracting, or presenting model documentation, Component-basic information represents model identity and while our study examines how available documentation is licensing details. Model-card documentation captures AI- represented in generated CycloneDX AIBOM artifacts. Transparency studies on HF have examined dataset, bias, specific transparency information, including model description, parameters, evaluation, limitations, and ethical considerations, and license documentation. Pepe et al. [31] analyzed how while external references capture links to source code, datasets, HF models document training datasets, fairness limitations, documentation, model files, and traceability artifacts. Together, and licenses, showing limited exposure of training datasets, these categories produce a completeness score out of 100. bias information, and licensing details. Their work motivates automated support for AI model transparency and AIBOM Section III-D describes the weights and scoring procedure. generation. Our study extends this line of work by measuring AIBOM completeness across 97,940 AIBOM artifacts. B. Related Work Responsible-AI research further motivates the need for fields This section positions work in relation to repository mining, related to bias, safety, limitations, ethical considerations, and model documentation, and AI supply-chain governance. intended use. Prior work on fairness and bias mitigation has 1) Empirical Studies on Hugging Face Model Repositories: proposed methods such as fairness-aware re-ranking, fair ML HF has become an important empirical setting for studying construction, counterfactual bias analysis, and neural-network

fairness verification [5, 10, 41]. These techniques address fairness at the algorithmic, testing, or verification level. Our work does not propose a fairness-mitigation method; instead, our work examines whether generated AIBOMs contain the structured documentation needed to make responsible-use and safety-related information visible to downstream users. 3) SBOMs, AIBOMs, and Software Supply-Chain Transparency: SBOMs provide structured inventories of software components, dependencies, licenses, and related metadata. SBOM research has examined cybersecurity readiness, practitioner adoption, SBOM completeness, tool limitations, and ecosystem readiness [20, 42, 44, 46]. These studies show that SBOM generation and consumption involve content, tooling, maintenance, interoperability, and adoption issues. AI systems introduce additional requirements because models depend on datasets, training procedures, model cards, hyperparameters, evaluation information, and external resources. AIBOMs extend SBOM concepts to AI and ML systems. CycloneDX and SPDX have begun incorporating AI-specific metadata, while AIBOM-related work emphasizes model identity, datasets, licenses, dependencies, intended use, ethical considerations, and provenance information. AIBOMs are therefore relevant for AI supply-chain transparency, compliance review, reuse, and governance. Our study focuses on the empirical question of how complete generated CycloneDX-based AIBOMs are when created from Hugging Face repositories. Tool-based AIBOM work is related to our study. ALOHA generates AIBOMs for HF models by parsing model-card metadata and mapping extracted information to CycloneDX fields [12]. ALOHA evaluates AIBOMs on a 312-model sample and reports limitations related to metadata completeness and model-card standardization. Our study follows the same motivation, but expands the scale and analyzes completeness across 97,940 generated AIBOM artifacts. Other AIBOM frameworks emphasize verifiability, provenance, and attestation. AIBoMGen generates signed AIBOMs during model training and captures datasets, model metadata, environment details, hashes, signatures, and in-toto attestations [39]. Atlas captures ML lifecycle provenance using trusted execution environments and transparency logs [35]. Laminator generates verifiable ML property cards through hardware-assisted attestations [15]. AICert binds training configuration, dataset hashes, and model outputs into hardware-rooted proof artifacts. These frameworks strengthen provenance and integrity guarantees. Our study addresses a complementary repository-level question: whether public model repositories provide sufficiently complete information for standardized AIBOM artifacts. 4) Licensing, Provenance, and Reuse of Open-Source AI Artifacts: Licensing and provenance have long been studied in open-source software. Prior work has examined license adoption, license compatibility, license-integration patterns, license inconsistency, license recommendation, and licensing bugs in software ecosystems [18, 43]. These studies show that reuse decisions depend not only on component availability, but also on license clarity, compatibility, and provenance. AI model reuse raises related concerns because pretrained models can

carry model-specific licenses, dataset restrictions, responsibleuse terms, and downstream redistribution constraints. HF transparency studies extend these concerns to AI artifacts. Pepe et al. [31] studied dataset declarations, bias documentation, model licenses, and possible incompatibilities between HF models and GitHub client projects, showing that incomplete licensing information or dataset provenance can create legal and transparency risks. Provenance also connects licensing, dataset declarations, paper references, repositories, and version-control links, which downstream users need for reuse, compliance, traceability, and auditability [21, 33, 39]. AIBOMs provide a machine-readable representation for these signals, but their quality depends on the information available in source repositories. Our RQ3, therefore, complements prior licensing and provenance work by analyzing how AIBOM documentation coverage varies across license, dataset declaration, paper reference, task, and traceability signals. III. M ETHODOLOGY This section describes our methodology, including HF metadata collection, model filtering, AIBOM generation, completeness scoring, artifact parsing, and data analysis. A. Hugging Face Metadata Collection We implemented a Python-based data collection pipeline to retrieve metadata from HF, a widely used model hub for pretrained ML and generative AI models. The pipeline uses the HF Hub API to collect model-level information available from model repositories. For each model, we collected metadata such as the model identifier, author, task, library name, number of downloads, likes, creation date, last modification date, commit SHA, license, languages, datasets, evaluation metrics, base model information, model type, and architecture information. Initially, we collected all available HF model entries returned by the API, regardless of whether they contained metadata or model-card documentation. This allowed us to first characterize the broader HF model ecosystem and then apply filtering criteria for the AIBOM analysis. Since AIBOM generation is intended to assess documentation completeness, we did not manually fill missing fields in the model repositories. Instead, we preserved missing, incomplete, or inconsistent metadata as part of the empirical signal, because such gaps directly affect AIBOM completeness and AI supply-chain transparency. B. Data Filtering and Preprocessing Generating AIBOMs for all HF repositories is computationally expensive and constrained by API rate limits. Therefore, we retained models with more than 100 downloads for the AIBOM generation stage. This threshold focuses the analysis on repositories with observable reuse while keeping the study computationally feasible and preserving a large sample across tasks, libraries, licenses, and model families. Models with very low or no downloads were excluded because they provide limited evidence of reuse and would substantially increase the cost of large-scale AIBOM generation.

We organized the filtered dataset into multiple CSV files, each containing approximately 10,000 model entries, to support scalable and incremental AIBOM generation. This batching strategy allowed us to run the AIBOM generation pipeline incrementally and reduced the risk of losing progress because of API rate limits, network interruptions, or tool execution failures. For model-size information, we extracted parameter counts where available, using metadata derived from safetensors files when such information was present in the repository. C. AIBOM Generation and Validation For all filtered models, we generated an AIBOM using the OWASP GenAI Security Project AIBOM Generator [17]. The tool accepts a HF model identifier or model URL as input. The generator then accesses publicly available repository information, including model metadata, model-card content, license information, configuration details, and external references when available. The extracted information is organized into a CycloneDX-based AIBOM in machine-readable JSON format [30]. In this format, the AIBOM represents the model as a component and records associated metadata, licenses, documentation fields, and external references. We validated each AIBOM against the CycloneDX JSON structure to ensure that only parseable and analyzable artifacts were used for completeness analysis. This validation checked whether each artifact could be parsed as valid JSON and whether it contained expected CycloneDX-level fields, such as bomFormat, specVersion, metadata, and components. Artifacts that failed parsing or lacked score information were excluded from the completeness dataset. D. AIBOM Completeness Score Calculation We used the completeness scoring method from the OWASP AIBOM Generator to measure AIBOM completeness for each HF repository. We did not define a new completeness metric. As described in Section II-A 3, the generator computes a score out of 100 across five documentation categories: required fields, metadata, component-basic information, modelcard documentation, and external references. Required fields, metadata, and component-basic information each contribute 20 points; model-card documentation contributes 30 points; and external references contribute 10 points. Following the OWASP AIBOM Generator scoring method [17], we compute each category score, subtotal, and final score as follows: Fpresent,i Si = × Wi , Ftotal,i 5 X (1) Subtotal = Si , i=1

FinalScore = Subtotal × P where Si represents the score for category i, Fpresent,i and Ftotal,i denote the number of present fields and total fields in category i respectively, Wi is the specific category weight, and P represents the penalty factor.

The penalty factor accounts for missing critical or important fields. Under the tool-defined scoring method, two to three missing critical fields receive a 10% penalty, four or more receive a 20% penalty, and five or more missing important fields receive a 5% penalty. These penalties are cumulative when both critical and important field penalties apply. E. Score Extraction and Artifact Parsing We developed a Python-based pipeline to integrate AIBOM generation, score extraction, and artifact parsing into our analysis workflow. The pipeline reads the filtered HF model identifiers from CSV files and invokes the OWASP GenAI Security Project AIBOM Generator for each model through its command-line interface. For each model identifier, the pipeline specifies an output path for the generated AIBOM artifact. This process links each model to both a machine-readable AIBOM file and a corresponding completeness assessment. The pipeline was designed for scalable and recoverable execution across long-running batch jobs. The pipeline divides the input models into multiple shards, with each shard representing a smaller partition of the dataset processed independently. Each shard writes its own result file and stores generated AIBOM artifacts in a shard-specific output directory. The pipeline also saves progress after each processed model, allowing execution to resume without repeating completed models. For each generated AIBOM, the pipeline extracts the overall completeness score and the category-level scores reported by the generator. The extracted categories include required fields, metadata, component-basic information, model-card documentation, and external references. For each category, the pipeline records the achieved score, total possible score, and percentage score. The pipeline also records the completeness level, AIBOM profile, tool-reported license, generation status, return code, and error message when generation fails. To check the consistency of the automated score extraction, we inspected a sample of 100 generated AIBOM artifacts and compared the extracted score records with the corresponding score reports produced by the generator. This validation checked whether the overall completeness score, category-level scores, field checklist status, and generated artifact path were consistently recorded in our dataset. The manual check helped confirm that the automated extraction pipeline preserved the score information reported by the generator. F. Analysis Procedure We analyzed the AIBOM artifacts and score records in relation to the three research questions. The analysis proceeds from overall completeness, to individual field availability, to documentation coverage across repository characteristics. For RQ1, we analyzed overall and category-level AIBOM completeness using the AIBOM score dataset, which contains 97,940 score records. Each row corresponds to one generated AIBOM and includes the completeness score, completeness level, and category-level scores reported by the generator. For each category, we used three score columns: achieved score, total possible score, and percentage score. We computed

TABLE I: Score summary for generated HF model AIBOMs. All metrics are computed over 97,940 AIBOM artifacts. Metric Mean Median Min Max Std. Q1 Q3 Completeness Score 54.31 54.10 46.60 68.70 4.44 50.90 58.10 Required Fields (%) 100.00 100.00 100.00 100.00 0.00 100.00 100.00 Metadata (%) 40.00 40.00 40.00 60.00 0.13 40.00 40.00 Component Basic (%) 81.75 85.50 71.50 85.50 6.20 71.50 85.50 Model Card (%) 19.51 16.67 6.00 50.00 10.48 11.00 31.67 External Refs (%) 68.02 75.00 50.00 100.00 17.11 50.00 75.00

ecosystem is dominated by transformers, safetensors, peft, and diffusers, while the largest task groups are text-generation, text-classification, text-to-image, reinforcement-learning, and automatic-speech-recognition. These descriptive results show that HF is a large and rapidly expanding model-reuse platform, motivating our subsequent AIBOM completeness analysis for models with observable reuse. A. RQ1. How complete are AIBOMs generated from Hugging Face model repositories at scale?

descriptive statistics for the completeness score and for each category-level percentage, including count, mean, median, 1) Overall completeness-score distribution: Table I summaminimum, maximum, standard deviation, first quartile, and rizes the completeness-score distribution across 97,940 valid third quartile. We also computed Pearson correlations [3] AIBOM score records. The generated AIBOMs achieved a between each category-level percentage and the completeness mean completeness score of 54.31 out of 100, with a median score. Required fields were excluded from correlation analysis of 54.10. The first and third quartiles are 50.90 and 58.10, because the category remained constant at 100% across valid respectively, and the standard deviation is 4.44. The observed score records. These correlations are interpreted as contributionscores range from 46.60 to 68.70. This narrow distribution oriented associations rather than causal relationships because indicates that most generated AIBOMs are moderately complete the final score is computed from weighted category scores. but do not reach high-completeness levels. For RQ2, we analyzed granular field-level availability in the parsed AIBOM artifacts. This analysis measured whether Finding 1. Generated AIBOMs are moderately complete overall. required fields, metadata fields, component-basic fields, modelThe mean score is 54.31 out of 100, indicating that public HF card documentation fields, and external-reference fields were model repositories can be converted into AIBOM artifacts at scale, but the resulting artifacts remain far from complete. present in each generated AIBOM. We also checked whether model descriptions contained substantive content rather than placeholder values. This field-level analysis explains which 2) Category-level completeness: The category-level results specific AIBOM fields are commonly represented, rarely show substantial variation across the five OWASP AIBOM represented, or absent across generated artifacts. completeness categories. Required fields achieve complete For RQ3, we analyzed how AIBOM documentation coverage coverage, with a mean and median of 100.00% across valid varies across repository characteristics. Because RQ3 covers records. Component-basic information is also comparatively documentation signals, we divided the analysis into four strong, with a mean of 81.75% and a median of 85.50%. subquestions. RQ3.1 asks whether models with paper references External references show moderate but uneven coverage, with and dataset declarations show different field coverage than a mean of 68.02% and a standard deviation of 17.11. models without these signals. RQ3.2 asks how AIBOM In contrast, metadata and model-card documentation are documentation coverage varies across model tasks. RQ3.3 asks much weaker. Metadata has a mean of 40.00%, with almost how combined license–dataset–paper availability is associated no variation across records. Model-card documentation has with stronger or weaker AIBOM documentation coverage. the lowest coverage, with a mean of 19.51% and a median of RQ3.4 asks which model families and artifact characteristics 16.67%. This result indicates that generated AIBOMs usually appear among the highest-scoring AIBOMs. For each subques- contain the basic structure needed for identification, but they tion, we compared the coverage of AIBOM fields related to lack richer AI-specific documentation for transparency. traceability, limitations, safety-risk assessment, environmental documentation, dataset disclosure, license information, versionFinding 2. AIBOM completeness is uneven across categories. control references, and paper references. We interpret these Required fields and component-basic information are well represented, while metadata and model-card documentation are the comparisons as associations between repository documentation main sources of incompleteness in generated artifacts. practices and AIBOM coverage, rather than as causal effects. IV. R ESULTS

3) Categories associated with overall completeness: Table II This section reports the results by first summarizing the shows the correlation between category-level completeness and scale and composition of the HF metadata snapshot and then the AIBOM completeness score. Model-card documentation answering the three research questions. has the strongest association with overall completeness, with We begin with the collected HF metadata snapshot. a Pearson correlation of 0.888. External references show a The snapshot contains 2,942,466 public model records, strong association at 0.662. Component-basic information has a with repository creation increasing sharply from 100,576 weaker association at 0.351, while metadata has no association models in 2022 to 1,145,805 in 2025; the 2026 count is at 0.003. Required fields are excluded because they are constant 632,358 because the snapshot covers only part of the year. The at 100.00% across valid records.

TABLE II: Correlation between AIBOM category-level scores and overall completeness across generated artifacts. Category Model-card documentation External references Component-basic information Metadata

Correlation 0.888 0.662 0.351 0.003

TABLE III: AIBOM Field Availability across Artifacts. Category Required Fields Required Fields Required Fields Required Fields Metadata Metadata Metadata Metadata Metadata Component Basic Component Basic Component Basic Component Basic Component Basic Component Basic Diagnostic Model Card Model Card Model Card Model Card Model Card Model Card Model Card Model Card Model Card Model Card Model Card Model Card Model Card Environmental Environmental Environmental External Refs External Refs External Refs External Refs

Field Present bomFormat 97,940 specVersion 97,940 serialNumber 97,940 version 97,940 primaryPurpose 97,940 suppliedBy 97,940 standardCompliance 0 domain 4 autonomyType 0 name 97,940 type 97,940 version 97,940 purl 97,940 description 97,940 licenses 71,640 meaningfulDescription 211 datasets 38,542 hyperparameter 24,884 technicalLimitations 16,393 safetyRiskAssessment 9,555 ethicalConsiderations 0 intendedUse 0 modelExplainability 0 informationAboutTraining 0 informationAboutApplication 0 metric 0 SensitivePersonalInformation 0 57,785 vocab size tokenizer class 60,382 energyConsumption 19 energyQuantity 0 energyUnit 0 paper 13,228 vcs 57,496 website 97,940 downloadLocation 97,940

Present (%) 100.00 100.00 100.00 100.00 99.99 99.99 0.00 < 0.01 0.00 100.00 100.00 100.00 100.00 99.99 73.14 0.22 39.35 25.40 16.74 9.76 0.00 0.00 0.00 0.00 0.00 0.00 0.00 58.99 61.65 0.02 0.00 0.00 13.50 58.70 99.99 99.99

These correlations indicate that variation in the final score is driven by model-card documentation and external-reference coverage. Metadata contributes little to score variation because most records have nearly identical metadata coverage. Finding 3. Overall AIBOM completeness is driven primarily by model-card documentation and external references. Improving these categories is likely to produce the largest increase in final completeness scores across the analyzed models.

B. RQ2. Which granular AIBOM fields are most frequently present or missing in generated AIBOM artifacts? We parsed 97,940 generated AIBOM artifacts and measured the presence of individual fields in order to explain the categorylevel results. Table III reports field-level results.

1) Structural and component-identification fields: Required CycloneDX fields are fully represented in the parsed artifacts. The fields bomFormat, specVersion, serialNumber, and version appear in all 97,940 artifacts. Componentidentification fields are also highly complete: name, type, version, and purl appear in all parsed artifacts. These results explain why required fields and component-basic information receive comparatively strong category-level scores. Finding 4. Generated AIBOMs are structurally complete at the CycloneDX level. Required fields and core model-identification fields are almost universally represented.

2) Metadata, licensing, and description fields: Basic metadata fields are common, but governance-oriented metadata is largely missing in the generated AIBOMs. The fields primaryPurpose and suppliedBy are present in 99.99% of artifacts. However, standardCompliance and autonomyType are absent from all parsed artifacts, and domain appears in only four artifacts. Licensing information is present in 71,640 artifacts, corresponding to 73.14%. The description field requires separate interpretation in AIBOM completeness analysis. Although description is present in 99.99% of artifacts, only 211 artifacts contain a meaningful description beyond placeholder content. This corresponds to only 0.22% of parsed artifacts and shows that field presence can overestimate documentation quality. Finding 5. Basic metadata and descriptions are often syntactically present, but governance metadata and meaningful descriptions are largely missing.

3) Model-card and AI-specific transparency fields: Modelcard fields show the largest documentation gaps. Dataset information appears in 38,542 artifacts, corresponding to 39.35%. Hyperparameter information appears in 25.40%, technical limitations in 16.74%, and safety-risk assessment in 9.76%. Responsible-use and explanation fields are absent: ethicalConsiderations, intendedUse, modelExplainability, informationAboutTraining, informationAboutApplication, metric, and useSensitivePersonalInformation appear in 0.00% of artifacts. Environmental documentation is also nearly absent: energyConsumption appears in only 19 artifacts, while energyQuantity and energyUnit are absent. Finding 6. AI-specific transparency fields are weakly represented or absent. Dataset declarations, limitations, safety information, responsible-use fields, and environmental fields remain major documentation gaps in generated AIBOMs.

4) External-reference and traceability fields: External references are unevenly represented. Repository-oriented links are nearly complete: website and downloadLocation appear in 99.99% of artifacts. However, richer traceability fields are less consistent. Version-control references appear in 57,496 artifacts, corresponding to 58.70%, and paper references appear in 13,228 artifacts, corresponding to 13.50%. This indicates

that generated AIBOMs usually provide links back to the model repository for downstream users, but fewer artifacts connect models to source-code repositories or research papers.

Has license 6,373 (74.20%) Has dataset 8,589 (64.93%)

Finding 7. External references support basic repository traceability, but traceability through version-control links and especially paper references remains uneven across all artifacts.

RQ3 examines whether AIBOM documentation coverage varies across repository-level and artifact-level characteristics in the analyzed dataset. We focus on paper reference, dataset declaration, task, license availability, model family, architecture, parameter size, and format because these characteristics are directly connected to traceability, reuse, governance, top-score patterns, and model readiness. Rather than reporting each field independently, we use hierarchical audit views and top-score categorization to show how documentation signals and artifact characteristics combine across repository groups. 1) RQ3.1: Paper and dataset availability: Figure 2 presents an audit-style tree of AIBOM documentation coverage by paper-reference and dataset availability. Paper references are present in 13,228 artifacts, representing 13.50% of the 97,940 parsed AIBOM artifacts. Among models with paper references, 64.93% also include dataset information. In contrast, among models without paper references, only 35.35% include dataset information. This pattern indicates that paper-linked models are more likely to provide dataset declarations. The same pattern appears for traceability and limitation fields. Among models with both paper references and dataset declarations, 99.59% include VCS references and 49.04% include technical limitations. Among models without paper references and without dataset declarations, VCS coverage drops to 55.04%, and technical-limitation coverage drops to 7.16%. These results suggest that paper and dataset information are signals of stronger AIBOM documentation readiness. Finding 8. Models with paper references and dataset declarations provide stronger traceability and limitation coverage than models without these documentation signals.

Has tech limitations 4,212 (49.04%)

Has paper ref. 13,228 (13.50%)

Has license 4,018 (86.61%) No dataset 4,639 (35.07%)

C. RQ3: How does AIBOM documentation coverage vary across model repository and artifact characteristics?

Has VCS ref. 8,554 (99.59%)

Has VCS ref. 4,601 (99.18%) Has tech limitations 952 (20.52%)

Total models 97,940

Has license 25,147 (83.95%) Has dataset 29,953 (35.35%)

Has VCS ref. 14,194 (47.39%) Has tech limitations 7,309 (24.40%)

No paper ref. 84,722 (86.50%)

Has license 36,102 (65.92%) No dataset 54,769 (64.65%)

Has VCS ref. 30,147 (55.04%) Has tech limitations 3,920 (7.16%)

Fig. 2: Audit-style tree of AIBOM documentation coverage by paper-reference and dataset availability.

information show 99.25% VCS coverage, 61.59% technicallimitation coverage, and 66.67% responsible/safety coverage. In contrast, text-generation models without paper or dataset information show lower coverage, with 49.38% VCS coverage, 6.66% technical-limitation coverage, and 9.56% responsible/safety coverage. Environmental documentation remains nearly absent across task branches. Finding 9. Task-level AIBOM coverage varies across documentation branches, but paper and dataset availability consistently correspond to stronger traceability, limitation, and responsibleuse coverage across model tasks. However, environmental documentation remains weak across all task groups.

3) RQ3.3: Combined license, dataset, and paper-reference coverage: Table V combines license availability, dataset declaration, and paper reference to show how multiple documentation 2) RQ3.2: Task-level documentation coverage: Table IV signals shape AIBOM readiness across repository groups. The reports task-level AIBOM documentation coverage across strongest traceability pattern appears when dataset and paper paper-reference and dataset branches. The largest task group information are both present. For licensed models with both is text-generation, with 82,591 parsed AIBOM artifacts datasets and paper references, VCS coverage reaches 99.53%. within the analyzed sample. This task dominates the gener- For unlicensed models with both datasets and paper references, ated AIBOM dataset, but the hierarchical table also shows VCS coverage is similarly high at 99.77%. coverage differences across multimodal, image-generation, textHowever, responsible-use and limitation coverage differ classification, and image-classification tasks. sharply across branches. Models without license, dataset, or Across tasks, models with both paper references and paper information show the weakest documentation profile: dataset declarations generally provide stronger coverage for only 2.87% include technical limitations, 1.33% include safetyVCS references, technical limitations, safety-risk assess- risk assessment, and 3.66% include responsible/safety-related ment, and responsible/safety-related fields. For example, in information. These results show that AIBOM completeness text-generation, models with both paper and dataset is not only determined by the generator; the quality of the

TABLE IV: Task-Paper-Dataset-level hierarchical audit table of AIBOM documentation coverage. Task text-generation text-generation text-generation text-generation image-text-to-text image-text-to-text image-text-to-text image-text-to-text text-to-image text-to-image text-to-image text-to-image text-classification text-classification text-classification text-classification image-classification image-classification image-classification image-classification

Paper Has paper Has paper No paper No paper Has paper Has paper No paper No paper Has paper Has paper No paper No paper Has paper Has paper No paper No paper Has paper Has paper No paper No paper

Dataset Has dataset No dataset Has dataset No dataset Has dataset No dataset Has dataset No dataset Has dataset No dataset Has dataset No dataset Has dataset No dataset Has dataset No dataset Has dataset No dataset Has dataset No dataset

Models 4,653 2,990 26,325 48,623 412 389 603 1,686 104 104 226 1,214 266 89 454 457 740 27 174 141

License 2,986 (64.17%) 2,568 (85.89%) 22,113 (84.00%) 31,437 (64.65%) 351 (85.19%) 367 (94.34%) 552 (91.54%) 1,480 (87.78%) 86 (82.69%) 85 (81.73%) 153 (67.70%) 802 (66.06%) 146 (54.89%) 65 (73.03%) 379 (83.48%) 306 (66.96%) 717 (96.89%) 27 (100.00%) 152 (87.36%) 114 (80.85%)

VCS 4,618 (99.25%) 2,952 (98.73%) 10,566 (40.14%) 24,011 (49.38%) 412 (100.00%) 389 (100.00%) 603 (100.00%) 1,686 (100.00%) 104 (100.00%) 104 (100.00%) 226 (100.00%) 1,214 (100.00%) 266 (100.00%) 89 (100.00%) 454 (100.00%) 457 (100.00%) 740 (100.00%) 27 (100.00%) 174 (100.00%) 141 (100.00%)

generated artifact also depends on documentation practices in the source repository.

Tech. Lim. 2,866 (61.59%) 708 (23.68%) 6,213 (23.60%) 3,238 (6.66%) 227 (55.10%) 63 (16.20%) 224 (37.15%) 110 (6.52%) 74 (71.15%) 22 (21.15%) 32 (14.16%) 53 (4.37%) 147 (55.26%) 6 (6.74%) 172 (37.89%) 130 (28.45%) 102 (13.78%) 1 (3.70%) 75 (43.10%) 36 (25.53%)

Safety 1,228 (26.39%) 500 (16.72%) 3,705 (14.07%) 2,338 (4.81%) 195 (47.33%) 65 (16.71%) 208 (34.49%) 192 (11.39%) 56 (53.85%) 22 (21.15%) 23 (10.18%) 20 (1.65%) 59 (22.18%) 11 (12.36%) 75 (16.52%) 15 (3.28%) 30 (4.05%) 0 (0.00%) 10 (5.75%) 3 (2.13%)

Resp./Safe. 3,102 (66.67%) 1,005 (33.61%) 7,189 (27.31%) 4,647 (9.56%) 275 (66.75%) 90 (23.14%) 253 (41.96%) 263 (15.60%) 74 (71.15%) 24 (23.08%) 42 (18.58%) 58 (4.78%) 160 (60.15%) 13 (14.61%) 195 (42.95%) 140 (30.63%) 120 (16.22%) 1 (3.70%) 79 (45.40%) 38 (26.95%)

Env. 0 (0.00%) 0 (0.00%) 10 (0.04%) 1 (< 0.01%) 0 (0.00%) 0 (0.00%) 7 (1.16%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 0 (0.00%) 1 (0.14%) 0 (0.00%) 0 (0.00%) 0 (0.00%)

repository text. Our results show that generated AIBOMs are valid, but AI-specific documentation remains incomplete, especially for model-card fields, limitations, safety-risk assessment, Finding 10. AIBOM readiness is strongest when repositories intended use, ethical considerations, environmental information, combine multiple documentation signals, including license inforand meaningful descriptions. More complete model cards, mation, dataset declarations, paper references, and VCS links. license declarations, dataset references, paper links, and versionRepositories lacking these signals provide weaker evidence for control references can directly improve the quality of generated AI supply-chain transparency during model reuse. AIBOMs. Publishers should provide structured and machine4) RQ3.4: What types of models appear among the highest- readable documentation for model identity, training data, scoring AIBOM artifacts, and how do they differ by origin, limitations, safety risks, and environmental information. architecture, parameter size, and format?: We selected all Software developers, downstream users, and software artifacts with the highest observed completeness score to engineering researchers. Developers and downstream users examine the upper end of AIBOM completeness. We found should not treat the existence of an AIBOM as evidence of that 269 models reach the maximum score of 68.7, and completeness. Our findings show that many AIBOMs contain all remain classified as moderate. The top-scoring AIBOM required CycloneDX structure and basic model-identification artifacts are dominated by large language model families fields, while transparency fields remain missing. Therefore, and their redistributed or quantized variants, as shown in users should inspect category-level and field-level completeness Table VI. Many top models originate from well-known base before relying on AIBOMs for reuse, compliance, auditing, or families such as Llama, Gemma, Qwen, Granite, Phi, Falcon, security review. For software engineering researchers, AIBOM CodeLlama, BioMistral, and StableLM. A large share of these completeness offers an empirical lens for studying AI supply repositories use the GGUF format, indicating that quantized or chains, model reuse, documentation evolution, semantic validadeployment-oriented model variants can still provide enough tion, provenance tracking, license compliance, reproducibility, repository metadata and external references to achieve the and responsible AI governance. highest observed AIBOM score. However, these models remain AIBOM tool developers. AIBOM tool developers should only moderately complete because metadata and model-card move beyond artifact generation and provide actionable diagdocumentation remain limited. nostics about documentation quality. This need is evident in our Finding 11. Top-scoring AIBOMs are concentrated among wellresults, which show that field presence alone can overestimate known LLM families such as Llama, Gemma, Qwen, Granite, Phi, transparency when fields contain placeholder values, such as Falcon, CodeLlama, BioMistral, and StableLM. These artifacts non-informative model descriptions. To address this limitation, achieve strong structural and traceability coverage, but remain future AIBOM tools should distinguish between syntactic only moderately complete because metadata and model-card completeness and substantive documentation quality. Such documentation are still limited. tools should report which fields are missing, where missing V. I MPLICATIONS information should be added, how each missing field affects We discuss implications for model publishers, software de- the completeness score, and which gaps are most relevant velopers, downstream users, AIBOM tool developers, software for licensing, traceability, safety, environmental reporting, and governance. They could also integrate validation checks for engineering researchers, and educators. Model publishers. Model publishers should treat documenta- model-card quality, license consistency, dataset traceability, tion as part of the released model artifact rather than as optional paper-reference availability, and external-resource links.

TABLE V: Hierarchical audit table of AIBOM documentation coverage across 97,940 generated AIBOM artifacts. License Has license Has license Has license Has license No license No license No license No license

Dataset Has dataset Has dataset No dataset No dataset Has dataset Has dataset No dataset No dataset

Paper Has paper No paper Has paper No paper Has paper No paper Has paper No paper

Models 6,373 25,147 4,018 36,102 2,216 4,806 621 18,667

VCS 6,343 (99.53%) 12,182 (48.44%) 3,991 (99.33%) 19,697 (54.56%) 2,211 (99.77%) 2,012 (41.86%) 610 (98.23%) 10,450 (55.98%)

TABLE VI: Categorization of top-scoring AIBOM models. Origin Llama / Meta

Architecture Decoderonly LLM

Size 1B–405B

Format GGUF

/

Decoderonly LLM

270M– 27B

GGUF/HF

Qwen / Alibaba

Decoderonly LLM Decoderonly LLM

3B–27B

GGUF

1B–20B

GGUF

Decoderonly LLM Domain LLM Code LLM

Mini–14B

GGUF/HF

4B–27B

GGUF

3B–70B

GGUF

Gemma Google

Granite / IBM

Phi / Microsoft Bio/Medical Code LLMs

Examples Llama-2, Llama-3.1, Llama-4 Gemma-2, Gemma-3, ShieldGemma Qwen3, Qwen2.5-VL Granite code/base models Phi-3.5, Phi-4 BioMistral, MedGemma CodeLlama, Stable-Code

Tech. Lim. 2,359 (37.02%) 5,778 (22.98%) 828 (20.61%) 3,384 (9.37%) 1,853 (83.62%) 1,531 (31.86%) 124 (19.97%) 536 (2.87%)

Safety 1,821 (28.57%) 3,841 (15.27%) 600 (14.93%) 2,437 (6.75%) 148 (6.68%) 387 (8.05%) 72 (11.59%) 249 (1.33%)

Resp./Safe. 2,742 (43.03%) 6,732 (26.77%) 1,160 (28.87%) 4,874 (13.50%) 1,889 (85.24%) 1,668 (34.71%) 155 (24.96%) 683 (3.66%)

Env. 0 (0.00%) 16 (0.06%) 0 (0.00%) 1 (< 0.01%) 1 (0.05%) 1 (0.02%) 0 (0.00%) 0 (0.00%)

the generator’s extraction logic may influence which fields appear in AIBOMs. We also inspected 100 AIBOM artifacts and score reports to check the consistency of the pipeline. External validity. Our dataset is based on a snapshot of 2,942,466 HF repositories and focuses on models with more than 100 downloads. This filter supports analysis of models with observable reuse, but findings may not generalize to lowdownload models, private repositories, gated models, enterprise registries, or models hosted outside HF. The HF ecosystem changes rapidly as model-card templates, repository practices, and AIBOM tools evolve. Therefore, completeness patterns may change in later snapshots or model-hosting ecosystems. VII. C ONCLUSION AND F UTURE W ORK

This paper studied the completeness of AI Bills of Materials Educators. Educators should teach future software engineers generated from pretrained machine learning models hosted and data scientists that using pretrained AI models involves on the HF Hub. We analyzed approximately 97.5K generated supply-chain, legal, and governance responsibilities. To support AIBOM artifacts and examined completeness at the score, this understanding, students should learn how to inspect model category, granular-field, and repository-characteristic levels for cards, licenses, dataset declarations, limitations, external refer- AI supply-chain transparency. Results indicate that generated ences, and AIBOM artifacts. Courses on software engineering, AIBOMs are structurally valid but only moderately complete ML engineering, secure software development, and responsible overall. Required CycloneDX fields are consistently present, AI should include practical exercises on documenting models, and component-basic information is comparatively well repgenerating AIBOMs, interpreting completeness scores, and resented. However, metadata and model-card documentation identifying missing transparency fields. remain limited, with model-card documentation showing the weakest coverage. At the field level, important AI-specific transVI. T HREATS TO VALIDITY parency information is often missing or weakly represented, The threats to validity are organized into three types. including intended use, ethical considerations, safety-risk Construct validity. Our study measures AIBOM completeassessment, environmental information, technical limitations, ness using the scoring method implemented by the OWASP and meaningful descriptions. In future work, we aim to analyze GenAI Security Project AIBOM Generator [17]. This score capfurther dimensions of AIBOM quality beyond field presence, tures field-level information coverage, but field presence does including the semantic quality of descriptions, limitations, not always indicate substantive documentation quality and may intended-use statements, and safety-risk assessments. reflect vague, incomplete, outdated, or non-informative content. To reduce this threat, we complement score-level analysis with D ECLARATION OF G ENERATIVE AI T ECHNOLOGIES granular field analysis and a diagnostic check for meaningful During manuscript preparation, the authors used ChatGPT descriptions. Therefore, our results should be interpreted as only to improve flow, grammar, and clarity. The tool was not evidence of AIBOM documentation completeness, not as a full used to generate technical content, synthesize citations, or assessment of model quality, safety, fairness, or performance. verify experimental facts. The authors reviewed and verified Internal validity. Our pipeline depends on the HF API, all outputs and take full responsibility for the final manuscript. the OWASP AIBOM Generator, and our parsing scripts. API changes, unavailable repositories, rate limits, tool failures, or R EFERENCES inconsistent metadata could affect artifacts and extracted scores. To reduce this threat, we preserved missing values, stored [1] Peerachai Banyongrakkul, Mansooreh Zahedi, Christoph JSON artifacts locally, linked each score record to its artifact, Treude, Haoyu Gao, and Patanamon Thongtanunam. 2026. removed duplicate identifiers, and excluded artifacts that failed When AI Models Become Dependencies: Studying the parsing or lacked score information. However, limitations in Evolution of Pre-Trained Model Reuse in Downstream

Software Systems. arXiv preprint arXiv:2604.17940 (2026). [2] Daniel Bardenstein, Nitish Kulkarni, Jakob Frick, Marc Frankel, Tiff Hsieh, and Amy Villasenor. 2023. Driving AI transparency: The AI bill of materials. Manifest, Tech. Rep. (2023). [3] Jacob Benesty, Jingdong Chen, Yiteng Huang, and Israel Cohen. 2009. Pearson correlation coefficient. In Noise reduction in speech processing. Springer, 1–4. [4] Avinash Bhat, Austin Coursey, Grace Hu, Sixian Li, Nadia ¨ Nahar, Shurui Zhou, Christian K”astner, and Jin LC Guo. 2023. Aspirations and practice of ml model documentation: Moving the needle with nudging and traceability. In Proceedings of the 2023 CHI conference on human factors in computing systems. 1–17. [5] Sumon Biswas and Hridesh Rajan. 2023. Fairify: Fairness verification of neural networks. In 2023 ieee/acm 45th international conference on software engineering (icse). IEEE, 1546–1558. [6] Beatrice Casey, Joanna Santos, and Mehdi Mirakhorli. 2024. A large-scale exploit instrumentation study of AI/ML supply chain attacks in hugging face models. arXiv preprint arXiv:2410.04490 (2024). [7] Joel Castaño, Silverio Martı́nez-Fernández, and Xavier Franch. 2024. Lessons learned from mining the hugging face repository. In Proceedings of the 1st IEEE/ACM International Workshop on Methodological Issues with Empirical Studies in Software Engineering. 1–6. [8] Joel Castaño, Silverio Martı́nez-Fernández, Xavier Franch, and Justus Bogner. 2023. Exploring the carbon footprint of hugging face’s ml models: A repository mining study. In 2023 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 1–12. [9] Kouider Chadli, Goetz Botterweck, and Takfarinas Saber. 2024. The environmental cost of engineering machine learning-enabled systems: a mapping study. In Proceedings of the 4th Workshop on Machine Learning and Systems. 200–207. [10] Joymallya Chakraborty, Suvodeep Majumder, Zhe Yu, and Tim Menzies. 2020. Fairway: a way to build fair ML software. In Proceedings of the 28th ACM joint meeting on European software engineering conference and symposium on the foundations of software engineering. 654–665. [11] Anamaria Crisan, Margaret Drouhard, Jesse Vig, and Nazneen Rajani. 2022. Interactive model cards: A human-centered approach to model documentation. In Proceedings of the 2022 ACM Conference on Fairness, Accountability, and Transparency. 427–439. [12] Riccardo D’Avino, Sabato Nocera, Daniele Bifolco, Federica Pepe, Massimiliano Di Penta, and Giuseppe Scanniello. 2025. ALOHA: A (IBoM) tooL generatOr for Hugging fAce. In Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering. 929–937.

[13] Ziqi Ding, Qian Fu, Junchen Ding, Gelei Deng, Yi Liu, and Yuekang Li. 2025. A Rusty Link in the AI Supply Chain: Detecting Evil Configurations in Model Repositories. In 2025 IEEE Security and Privacy Workshops (SPW). IEEE, 260–264. [14] Andy Donald, Edward Curry, Ihsan Ullah, Huan Chen, Talha Iqbal, Emir Muñoz, Apostolos Galanopoulos, and Sagar Saxena. 2026. Towards Standardised AI Documentation: A Knowledge Graph Approach for Model and Data Cards. In Seventh International Workshop on Knowledge Graph Construction@ ESWC2026. [15] Vasisht Duddu, Lachlan J Gunn, and N Asokan. 2024. Laminator: Verifiable ML property cards using hardwareassisted attestations. In Proceedings of the Fifteenth ACM Conference on Data and Application Security and Privacy. 317–328. [16] Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, and Jie M Zhang. 2023. Large language models for software engineering: Survey and open problems. In 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE). IEEE, 31–53. [17] GenAISecurityProject. 2026. OWASP-AIBOM-Generator. https://huggingface.co/spaces/GenAISecurityProject/O WASP-AIBOM-Generator. Accessed: 2026-06-25. [18] Daniel M German and Ahmed E Hassan. 2009. License integration patterns: Addressing license mismatches in component-based development. In 2009 IEEE 31st international conference on software engineering. IEEE, 188–198. [19] Md Wasiul Haque, Md Erfan, Sagar Dasgupta, Md Rayhanur Rahman, and Mizanur Rahman. 2025. Security Vulnerabilities in Software Supply Chain for Autonomous Vehicles. arXiv preprint arXiv:2509.16899 (2025). [20] Stephen Hendrick. 2022. Software Bill of Materials (SBOM) and Cybersecurity Readiness. The Linux Foundation (2022). [21] Richard Hohensinner, Belgin Mutlu, Inti Gabriel Mendoza Estrada, Matej Vukovic, Simone Kopeinik, and Roman Kern. 2026. Tracing the Data Trail: A Survey of Data Provenance, Transparency and Traceability in LLMs. arXiv preprint arXiv:2601.14311 (2026). [22] Hugging Face. 2026. Hugging Face Hub. https://huggin gface.co/docs/hub/index. Accessed: 2026-06-25. [23] JFrog Security Research. 2024. Data Scientists Targeted by Malicious Hugging Face ML Models with Silent Backdoor. https://jfrog.com/blog/data-scientists-targeted-by-m alicious-hugging-face-ml-models-with-silent-backdoor/. Accessed: 2026-06-30. [24] Wenxin Jiang, Nicholas Synovic, Matt Hyatt, Taylor R Schorlemmer, Rohan Sethi, Yung-Hsiang Lu, George K Thiruvathukal, and James C Davis. 2023. An empirical study of pre-trained model reuse in the hugging face deep learning model registry. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2463–2475.

[25] Yo Kanemoto, Reika Nishimura Arakawa, and Mitsuaki Akiyama. 2026. An Empirical Study of SBOM Usage through GitHub Actions. IEEE Access (2026). [26] Yujian Liu, Xiao Yu, Jacky Keung, Xing Hu, Xin Xia, and Xiaoxue Ma. 2026. An Empirical Study of Perceptions of General LLMs and Multimodal LLMs on Hugging Face. arXiv preprint arXiv:2604.05782 (2026). [27] Margaret Mitchell, Simone Wu, Andrew Zaldivar, Parker Barnes, Lucy Vasserman, Ben Hutchinson, Elena Spitzer, Inioluwa Deborah Raji, and Timnit Gebru. 2019. Model cards for model reporting. In Proceedings of the conference on fairness, accountability, and transparency. 220– 229. [28] Jacob Hedegaard Mortensen, Jonas Drewsen Andersen, Niels Henrik Mortensen, and Mads Bejlegaard. 2026. Beyond the Traditional BoM: Challenges of Bill of Materials in Global Industrial Companies. Procedia CIRP 142 (2026), 434–439. [29] Sabato Nocera, Massimiliano Di Penta, Fatima Ahmed, Simone Romano, and Giuseppe Scanniello. 2025. What We Know about AIBOMs: Results from a Multivocal Literature Review on Artificial Intelligence Bill of Materials. ACM Transactions on Software Engineering and Methodology (2025). [30] OWASP Foundation and Ecma International. 2026. OWASP CycloneDX Software Bill of Materials (SBOM) Standard: Full-Stack Bill of Materials (BOM) Standard. https://cyclonedx.org/. Standard ECMA-424, 2nd Edition. Accessed: 2026-06-25. [31] Federica Pepe, Vittoria Nardone, Antonio Mastropaolo, Gabriele Bavota, Gerardo Canfora, and Massimiliano Di Penta. 2024. How do hugging face models document datasets, bias, and licenses? an empirical study. In Proceedings of the 32nd IEEE/ACM International Conference on Program Comprehension. 370–381. [32] Petar Radanliev, Omar Santos, and Alistair BrandonJones. 2026. Capability hardware enhanced instructions and artificial intelligence bill of materials in trustworthy artificial intelligence systems: analyzing cybersecurity threats, exploits, and vulnerabilities in new software bills of materials with artificial intelligence. The Journal of Defense Modeling and Simulation 23, 1 (2026), 147–175. [33] Petar Radanliev, Omar Santos, Carsten Maple, and Kayvan Atefi. 2026. Operationalising artificial intelligence bills of materials for verifiable AI provenance and lifecycle assurance. Frontiers in Computer Science 8 (2026), 1735919. [34] Ahmed Ryan, Junaid Mansur Ifti, Md Erfan, Akond Ashfaque Ur Rahman, and Md Rayhanur Rahman. 2025. Unveiling Malicious Logic: Towards a Statement-Level Taxonomy and Dataset for Securing Python Packages. arXiv preprint arXiv:2512.12559 (2025). [35] Marcin Spoczynski, Marcela S Melara, and Sebastian Szyller. 2025. Atlas: A framework for ml lifecycle provenance & transparency. In 2025 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE,

448–461. [36] Nicholas M Synovic, Karolina Ryzka, Alessandra V Vellucci Solari, Kenny Lyons, James C Davis, and George K Thiruvathukal. 2026. An Empirical Investigation of PreTrained Deep Learning Model Reuse in the Scientific Process. arXiv preprint arXiv:2603.13584 (2026). [37] Ningjing Tang, Megan Li, Amy Winecoff, Michael Madaio, Hoda Heidari, and Hong Shen. 2026. Navigating uncertainties: How GenAI developers document their models on open-source platforms. In Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems. 1–19. [38] Jason Tsay, Alan Braz, Martin Hirzel, Avraham Shinnar, and Todd Mummert. 2020. Aimmx: Artificial intelligence model metadata extractor. In Proceedings of the 17th international conference on mining software repositories. 81–92. [39] Wiebe Vandendriessche, Jordi Thijsman, Laurens D’hooge, Bruno Volckaert, and Merlijn Sebrechts. 2026. AIBoMGen: Generating an AI Bill of Materials for Secure, Transparent, and Compliant Model Training. arXiv preprint arXiv:2601.05703 (2026). doi:10.48550/arX iv.2601.05703 Accepted at CAIN 2026 Research Track (ICSE 2026 Series). [40] Chengjie Wang, Jingzheng Wu, Hao Lyu, Xiang Ling, Tianyue Luo, Yanjun Wu, and Chen Zhao. 2026. A Large Scale Empirical Analysis on the Adherence Gap between Standards and Tools in SBOM. ACM Transactions on Software Engineering and Methodology (2026). [41] Zichong Wang, Zhou Yang, David Lo, and Wenbin Zhang. 2026. Towards fair machine learning software: Understanding and addressing model bias through counterfactual thinking. AI and Ethics 6, 2 (2026), 181. [42] Menghan Wu, Yukai Zhao, Xing Hu, Xian Zhan, Shanping Li, and Xin Xia. 2026. More than meets the eye: On evaluating SBOM tools in Java. ACM Transactions on Software Engineering and Methodology 35, 7 (2026), 1–30. [43] Yuhao Wu, Yuki Manabe, Tetsuya Kanda, Daniel M German, and Katsuro Inoue. 2017. Analysis of license inconsistency in large collections of open source projects. Empirical Software Engineering 22, 3 (2017), 1194–1222. [44] Boming Xia, Tingting Bi, Zhenchang Xing, Qinghua Lu, and Liming Zhu. 2023. An empirical study on software bill of materials: Where we stand and the road ahead. In 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2630–2642. [45] Jerin Yasmin, Wenxin Jiang, James C Davis, and Yuan Tian. 2026. Software dependencies 2.0: An empirical study of reuse and integration of pre-trained models in open-source projects. Empirical Software Engineering 31, 6 (2026), 173. [46] Nusrat Zahan, Elizabeth Lin, Mahzabin Tamanna, William Enck, and Laurie Williams. 2023. Software bills of materials are required. are we there yet? IEEE Security & Privacy 21, 2 (2023), 82–88.