Pith. sign in

REVIEW 4 major objections 6 minor 50 references

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

T0 review · 4 major / 6 minor · reviewed 2026-08-01 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Across 97,940 generated AIBOMs from Hugging Face model repositories, the mean completeness score is 54.31/100, and model-card documentation covers only 19.51% of fields.

desk verdict A genuinely large empirical baseline for AIBOM completeness, but the headline numbers are tool-output measurements, not repository-documentation measurements, so the paper needs a validation step before the conclusions can be trusted. read the letter →

arxiv 2607.17242 v1 pith:ULC37EYE submitted 2026-07-19 cs.SE cs.AI

Md Erfan , Ahmed Ryan , Md Rayhanur Rahman This is my paper · ORCID
classification cs.SEcs.AI
keywords AIBOMcompletenessHuggingFacemachinelearningsupplychainmodeldocumentationcardsrepositoryminingCycloneDXAIgovernance
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish that AIBOMs — machine-readable bills of materials for AI models — generated at scale from public Hugging Face repositories are structurally complete but substantively weak: every required CycloneDX field appears in all artifacts, yet the average completeness score is 54.31/100, dragged down by metadata at 40% and model-card documentation at 19.51%. It further shows that AI-specific transparency fields — intended use, ethical considerations, safety-risk assessment, environmental impact — are absent in over 90% of artifacts, and that field presence can mask placeholder content: only 0.22% of descriptions are meaningful. The paper argues this matters because AIBOMs are proposed as the traceability and governance layer of the AI supply chain; if they are complete in form but empty in content, downstream audits, reuse decisions, and compliance checks may rest on a false sense of transparency.

What carries the argument

The central mechanism is an open-source AIBOM generator that turns a model repository's public metadata, model-card text, and configuration files into a CycloneDX-formatted JSON artifact, plus the tool's weighted completeness scoring scheme. The score sums five category scores — required fields (20), metadata (20), component-basic information (20), model-card documentation (30), external references (10) — and applies a penalty factor when critical or important fields are missing. This identity converts repository documentation into a single comparable number between 0 and 100, which is what allows the study to measure completeness at scale; the accompanying field-level parser reveals which s

What would settle it

Take a random sample of, say, 200 of the repositories whose generated AIBOMs report zero for 'intended use' and read the model-card text directly; if a substantial share contain an intended-use statement that the generator failed to map, the claimed documentation gaps are partly an artifact of the extraction tool rather than of the repositories.

Watch

Extended reading notes

Core claim

Generated AIBOMs from nearly 98,000 Hugging Face models achieve a mean completeness score of 54.31/100 with a tight distribution (sd 4.44, range 46.6–68.7). Required CycloneDX fields (bomFormat, specVersion, serialNumber, version) and core component-identification fields are present in 100% of artifacts, and licensing appears in 73.14%. The main deficits are concentrated in metadata (40%, almost constant) and model-card documentation (19.51%), with several responsible-use fields — ethical considerations, intended use, model explainability, metrics — appearing in 0% of artifacts and environmental fields nearly absent. Paper references appear in only 13.50% of artifacts. The paper also shows f

Load-bearing premise

The generator's field-extraction logic faithfully captures what each Hugging Face repository actually documents — an assumption the paper itself flags in its threats-to-validity section as a possible influence on which fields appear.

Editorial extensions

If this is right

  • A structurally valid AIBOM does not imply substantive transparency; users must inspect category- and field-level detail before relying on an artifact for audits or compliance.
  • AIBOM completeness is driven primarily by model-card documentation and external references (correlations 0.888 and 0.662), so improving model-card practices is the highest-leverage fix for completeness scores.
  • Repositories that provide paper references and dataset declarations show markedly stronger traceability and limitation coverage (e.g., VCS references appear in ~99% of paper+dataset models vs. ~55% without), making these signals useful markers of documentation readiness.
  • Even the highest-scoring artifacts, concentrated among well-known LLM families and their quantized GGUF variants, reach only 68.7/100, so the most documented public models remain only moderately complete.
  • Because only 0.22% of artifacts contain a meaningful description, AIBOM tooling should add semantic quality checks rather than equating field presence with documentation quality.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because field-absence counts come solely from the generator's extraction logic, they may overstate documentation gaps: model-card text is free-form, and a field the tool cannot map may still exist in the repository. A manual reading of a sample of model cards would quantify this tool effect.
  • The near-total absence of environmental fields (0.02% of artifacts) suggests that if model providers adopt standardized energy reporting, this category alone could lift overall scores noticeably — a measurable prediction for a future snapshot of the same ecosystem.
  • The 0.888 correlation between model-card coverage and overall completeness implies that aligning AIBOM field definitions with the current Hugging Face model-card template would likely raise scores more than any other single change, a hypothesis an AIBOM tool developer could test directly.
  • The study's 100-download filter means the completeness distribution reflects only reused models; the long tail of low-download repositories is plausibly even less documented, which matters if governance applies to all public models rather than only popular ones.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper conducts a large-scale repository-mining study of Hugging Face model repositories to measure the completeness of AI Bills of Materials (AIBOMs) generated by the OWASP GenAI Security Project AIBOM Generator. The authors collect metadata for 2,942,466 HF models, retain 97,940 with more than 100 downloads, generate AIBOMs for each, and compute completeness scores using the generator's built-in scoring scheme. They report a mean completeness score of 54.31/100, with required CycloneDX fields at 100%, metadata at 40%, model-card documentation at 19.51%, and many AI-specific fields (e.g., intendedUse, ethicalConsiderations, modelExplainability, energyQuantity, standardCompliance) absent in all artifacts. They also analyze how coverage varies with paper references, dataset declarations, licenses, tasks, and model families. The paper concludes that generated AIBOMs are structurally valid but weak in AI-specific documentation, and it recommends improved model-card practices and AIBOM tooling.

Significance. If the measurements faithfully reflect the documentation content of HF repositories, this would be the largest empirical characterization of AIBOM completeness to date, with a public dataset and a reproducible pipeline. The paper's decomposition into score, category, field, and repository-characteristic levels is useful, and the emphasis on distinguishing syntactic presence from substantive content is important. The main strength is scale: 97,940 artifacts and 2.94M repository records. The central weakness is that the OWASP generator is the sole measurement instrument, and its extraction fidelity is never validated against actual repository content. This makes the headline percentages, and any conclusions about 'documentation gaps' in HF repositories, currently unsupported. The paper's significance is therefore conditional on a validation study that the current manuscript does not provide.

major comments (4)
  1. [§III-C, §III-D, §IV-B, Table III, §VI] The central inference—that a field absent from a generated AIBOM is absent from the HF repository—is not established. The OWASP AIBOM Generator is the only field-extraction instrument; the manual check in §III-E only verifies that the authors' parser preserved the generator's score reports, not that the generator's fields match repository content. Table III's 0.00% fields (intendedUse, ethicalConsiderations, modelExplainability, informationAboutTraining, informationAboutApplication, metric, SensitivePersonalInformation, energyQuantity, energyUnit, standardCompliance, autonomyType) are consistent with the generator having no code path that maps model-card text to these fields, rather than with 97,940 repositories genuinely lacking such information. Conversely, the 100% 'required fields' and 'website'/'downloadLocation' are CycloneDX scaffolding and repository URLs, not documentation conte
  2. [§IV-B, Table III, Finding 5] The 'meaningfulDescription' diagnostic is an ad hoc, unvalidated heuristic. The paper reports that only 211/97,940 (0.22%) artifacts have a meaningful description, and this result is load-bearing for the claim that field presence overestimates documentation quality (Finding 5). However, the rule itself is never defined: the paper does not state what counts as 'meaningful,' what thresholds were used, or whether the heuristic was validated on a labeled sample. Without this information, the 0.22% number is not reproducible and cannot be interpreted. The authors should either fully specify and validate the heuristic, or remove it and avoid drawing conclusions based on it.
  3. [§III-D, §III-E, Eq. (1)] The study is not reproducible as reported. The paper does not specify the version or commit of the OWASP AIBOM Generator, the exact invocation parameters, or the generation dates (only that the tool page was accessed on 2026-06-25). The scoring formula in Eq. (1) is also ambiguous: 'FinalScore = Subtotal × P' where P is called a 'penalty factor,' but a penalty factor would normally reduce the score; the text describes penalties as subtracting 10%, 20%, or 5%, so P presumably is (1 - penalty) or similar, but this is not defined. Provide the exact tool version, command-line invocation, generation timestamps, and a precise definition of P and how critical/important field penalties are applied.
  4. [§IV-C, Fig. 2, Tables IV–V] RQ3's hierarchical audit tables use aggregate columns 'Resp./Safe.' and 'Env.' without defining which AIBOM fields compose them. For example, Table IV reports 'responsible/safety coverage' percentages but never states whether this combines safetyRiskAssessment, ethicalConsiderations, intendedUse, or other fields, nor how the union is computed. The 'Env.' column is likewise undefined. Without these definitions, the RQ3 results cannot be audited or compared with the field-level results in Table III. Define the exact field sets and, ideally, report per-field coverage for the aggregates.
minor comments (6)
  1. [Abstract and §IV-B] The abstract says 'approximately 97.5K AIBOM artifacts' while the body uses 97,940. Use a consistent number throughout.
  2. [Eq. (1)] The formula labels 'Subtotal' as the sum of category scores and 'FinalScore' as 'Subtotal × P'. If P includes penalties, the notation should be clarified (e.g., P = 1 - penalty_rate) so readers can reproduce score calculations.
  3. [Table III] The row 'SensitivePersonalInformation' appears in the Model Card section, but the text in §IV-B refers to 'useSensitivePersonalInformation'. Unify the field naming to match the generated AIBOM schema.
  4. [Fig. 1] Figure 1 is referenced in the introduction but not described in the text; its content is vague. Add a caption or a short explanation of what information is being transformed and how the completeness evaluation works.
  5. [References] Several references contain extraneous spaces inside URLs (e.g., ref [17] 'OW ASP-AIBOM-Generator' and ref [23]). These should be fixed to point to the correct resources.
  6. [§III-F] The near-zero Pearson correlation with metadata (0.003) is expected because metadata is almost constant (40.00%). The text should note this low-variance caveat rather than interpreting the correlation alone.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the AIBOM completeness scores are direct measurements from an external, parameter-free tool, and the main risk is construct validity, not circular reasoning.

full rationale

The paper does not present a derivation or prediction that reduces to its inputs. It explicitly adopts the OWASP AIBOM Generator's scoring method ('We used the completeness scoring method from the OWASP AIBOM Generator to measure AIBOM completeness... We did not define a new completeness metric'), so the reported 54.31 mean and category percentages are descriptive measurements of generated artifacts, not results derived from fitted parameters. The 20/20/20/30/10 weights and field lists come from the external tool, not from the data, and the paper does not treat the tool's scores as if they were independently discovered laws. The strongest circularity-adjacent concern is that a field may be absent because the generator cannot extract it rather than because the repository lacks it; the paper itself flags this in Section VI ('limitations in the generator's extraction logic may influence which fields appear in AIBOMs'), which is an acknowledged validity threat, not a hidden circular step. The 100% required-fields result is partly an artifact of the authors' validation filter (they explicitly exclude artifacts that lack CycloneDX-level fields), but the paper discloses this filter and does not use that single result as the load-bearing derivation for its central claims. Self-citations in the related work are not load-bearing. Accordingly, no specific circular step can be quoted and reduced; the appropriate score is 0.

Assumptions & free parameters 3 free parameters · 5 assumptions · 0 invented entities

No new theoretical entities are introduced. The AIBOM artifacts are outputs of an existing published tool; the only new artifact is the dataset at figshare, which is not an 'invented entity' in the sense of a new scientific object.

free parameters (3)
  • AIBOM category weights = 20/20/20/30/10
    The overall completeness score is a weighted sum over five categories in the OWASP generator. The weights are fixed by the tool, not by the authors, and are not justified or varied. The paper's main metric depends on these arbitrary weights.
  • Download threshold = 100 downloads
    Models with <=100 downloads are excluded to reduce cost; this is a hand-chosen value that biases the sample toward popular models and affects all downstream percentages.
  • Meaningful description rule = unspecified
    The diagnostic that only 211/97,940 descriptions are 'meaningful' relies on an unstated rule. The count is central to Finding 5's claim that field presence overestimates quality, but the rule cannot be reproduced or audited.
assumptions (5)
  • domain assumption The OWASP AIBOM Generator correctly maps repository content into AIBOM fields.
    Invoked when generating all artifacts (Section III-C) and when interpreting missing fields as missing documentation (Findings 5-6, Section IV-B).
  • domain assumption The HF Hub API snapshot is an accurate, unbiased view of public model repositories.
    Used in Section III-A to collect metadata; if the API omits or misreports fields, the generated AIBOMs inherit those errors.
  • domain assumption The >100 download filter is a valid operationalization of 'observable reuse.'
    Section III-B; this excludes the majority of the 2.9M models and limits external validity, acknowledged in Section VI.
  • standard math Pearson correlation appropriately summarizes the association between category scores and overall score.
    Section IV-A3 uses Pearson correlations without significance tests; valid as descriptive statistics but labeled as 'association-oriented,' not causal.
  • ad hoc to paper The 'meaningful description' check accurately distinguishes substantive from placeholder text.
    Introduced in Section IV-B2 as a diagnostic; no rule, implementation, or validation is given, so it functions as an untested ad-hoc measure.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Large-Scale Measurement of AI Bill of Materials Completeness in Hugging Face Models." pith.science (2026). https://pith.science/paper/ULC37EYE

@misc{pith2026260717242,
  author       = {Pith},
  title        = {Pith review of: A Large-Scale Measurement of AI Bill of Materials Completeness in Hugging Face Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ULC37EYE}},
  note         = {Machine review of arXiv:2607.17242}
}
read the original 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 supply-chain 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, responsible-use, environmental, limitation, and meaningful-description fields remain weakly represented or missing across generated artifacts. Our findings motivate improved model-card practices, repository-level traceability, and automated AIBOM validation to advance the generation and adoption of more complete AIBOMs.

Figures

Figures reproduced from arXiv: 2607.17242 by the authors.

Figure 1
Figure 1. Motivating example showing how information from a [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Audit-style tree of AIBOM documentation coverage by [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

50 extracted references · 3 linked inside Pith

  1. [1]

    Peerachai Banyongrakkul, Mansooreh Zahedi, Christoph Treude, Haoyu Gao, and Patanamon Thongtanunam. 2026. When AI Models Become Dependencies: Studying the Evolution of Pre-Trained Model Reuse in Downstream Software Systems.arXiv preprint arXiv:2604.17940 (2026)

    arXiv 2026

  2. [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)

    2023

  3. [3]

    Jacob Benesty, Jingdong Chen, Yiteng Huang, and Israel Cohen. 2009. Pearson correlation coefficient. InNoise reduction in speech processing. Springer, 1–4

    2009

  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. InProceedings of the 2023 CHI conference on human factors in computing systems. 1–17

    2023

  5. [5]

    Sumon Biswas and Hridesh Rajan. 2023. Fairify: Fairness verification of neural networks. In2023 ieee/acm 45th international conference on software engineering (icse). IEEE, 1546–1558

    2023

  6. [6]

    Beatrice Casey, Joanna Santos, and Mehdi Mirakhorli

  7. [7]

    Joel Casta ˜no, Silverio Mart ´ınez-Fern´andez, and Xavier Franch. 2024. Lessons learned from mining the hugging face repository. InProceedings of the 1st IEEE/ACM International Workshop on Methodological Issues with Empirical Studies in Software Engineering. 1–6

    2024

  8. [8]

    Joel Casta˜no, Silverio Mart´ınez-Fern´andez, 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

    2023

Show all 50 references
  1. [9]

    Kouider Chadli, Goetz Botterweck, and Takfarinas Saber

  2. [10]

    Joymallya Chakraborty, Suvodeep Majumder, Zhe Yu, and Tim Menzies. 2020. Fairway: a way to build fair ML software. InProceedings of the 28th ACM joint meet- ing on European software engineering conference and symposium on the foundations of software engineering. 654–665

    2020

  3. [11]

    InProceed- ings of the 4th Workshop on Machine Learning and Systems

    The environmental cost of engineering machine learning-enabled systems: a mapping study. InProceed- ings of the 4th Workshop on Machine Learning and Systems. 200–207

  4. [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. InProceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering. 929–937

    2025

  5. [13]

    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

    2022

  6. [14]

    Andy Donald, Edward Curry, Ihsan Ullah, Huan Chen, Talha Iqbal, Emir Mu ˜noz, Apostolos Galanopoulos, and Sagar Saxena. 2026. Towards Standardised AI Documen- tation: A Knowledge Graph Approach for Model and Data Cards. InSeventh International Workshop on Knowledge Graph Const...

    2026

  7. [15]

    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 Repos- itories. In2025 IEEE Security and Privacy Workshops (SPW). IEEE, 260–264

    2025

  8. [16]

    Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, and Jie M Zhang

  9. [17]

    Vasisht Duddu, Lachlan J Gunn, and N Asokan. 2024. Laminator: Verifiable ML property cards using hardware- assisted attestations. InProceedings of the Fifteenth ACM Conference on Data and Application Security and Privacy. 317–328

    2024

  10. [18]

    Daniel M German and Ahmed E Hassan. 2009. License integration patterns: Addressing license mismatches in component-based development. In2009 IEEE 31st in- ternational conference on software engineering. IEEE, 188–198

    2009

  11. [19]

    Md Wasiul Haque, Md Erfan, Sagar Dasgupta, Md Ray- hanur Rahman, and Mizanur Rahman. 2025. Security Vulnerabilities in Software Supply Chain for Autonomous Vehicles.arXiv preprint arXiv:2509.16899(2025)

    2025

  12. [20]

    GenAISecurityProject. 2026. OW ASP-AIBOM-Generator. https://huggingface.co/spaces/GenAISecurityProject/O W ASP-AIBOM-Generator. Accessed: 2026-06-25

    2026

  13. [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)

    2026

  14. [22]

    Hugging Face. 2026. Hugging Face Hub. https://huggin gface.co/docs/hub/index. Accessed: 2026-06-25

    2026

  15. [23]

    Stephen Hendrick. 2022. Software Bill of Materials (SBOM) and Cybersecurity Readiness.The Linux Foun- dation(2022)

    2022

  16. [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. In2023 IEEE/ACM 45th International Co...

    2023

  17. [25]

    Yo Kanemoto, Reika Nishimura Arakawa, and Mitsuaki Akiyama. 2026. An Empirical Study of SBOM Usage through GitHub Actions.IEEE Access(2026)

    2026

  18. [26]

    JFrog Security Research. 2024. Data Scientists Targeted by Malicious Hugging Face ML Models with Silent Back- door. https://jfrog.com/blog/data-scientists-targeted-by-m alicious-hugging-face-ml-models-with-silent-backdoor/. Accessed: 2026-06-30

    2024

  19. [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. InProceedings of the confer- ence on fairness, accountability, and transparency. 220– 229

    2019

  20. [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

    2026

  21. [29]

    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)

    2026 arXiv

  22. [30]

    OWASP Foundation and Ecma International. 2026. OW ASP 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

    2026

  23. [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. InPro- ceedings of the 32nd IEEE/ACM International Conference on Progr...

    2024

  24. [32]

    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 Ma- terials.ACM Transactions on Software Engineering and Methodology(2025)

    2025

  25. [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 Science8 (2026), 1735919

    2026

  26. [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)

    2025

  27. [35]

    Petar Radanliev, Omar Santos, and Alistair Brandon- Jones. 2026. Capability hardware enhanced instructions and artificial intelligence bill of materials in trustworthy artificial intelligence systems: analyzing cybersecurity threats, exploits, and vulnerabilities in new softwa...

    2026

  28. [36]

    Nicholas M Synovic, Karolina Ryzka, Alessandra V Vel- lucci Solari, Kenny Lyons, James C Davis, and George K Thiruvathukal. 2026. An Empirical Investigation of Pre- Trained Deep Learning Model Reuse in the Scientific Process.arXiv preprint arXiv:2603.13584(2026)

    2026

  29. [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. InProceedings of the 2026 CHI Conference on Human Factors in Computing Systems. 1–19

    2026

  30. [38]

    Marcin Spoczynski, Marcela S Melara, and Sebastian Szyller. 2025. Atlas: A framework for ml lifecycle prove- nance & transparency. In2025 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, 448–461

    2025

  31. [39]

    Wiebe Vandendriessche, Jordi Thijsman, Laurens D’hooge, Bruno V olckaert, 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 Accep...

    2026 doi

  32. [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)

    2026

  33. [41]

    Jason Tsay, Alan Braz, Martin Hirzel, Avraham Shinnar, and Todd Mummert. 2020. Aimmx: Artificial intelligence model metadata extractor. InProceedings of the 17th international conference on mining software repositories. 81–92

    2020

  34. [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 Methodology35, 7 (2026), 1–30

    2026

  35. [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 Engineering22, 3 (2017), 1194–1222

    2017

  36. [44]

    Zichong Wang, Zhou Yang, David Lo, and Wenbin Zhang

  37. [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

    2026

  38. [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 & Privacy21, 2 (2023), 82–88

    2023

  39. [48]

    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. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 2630–2642

    2023

  40. [2023]

    In2023 IEEE/ACM Interna- tional Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE)

    Large language models for software engineering: Survey and open problems. In2023 IEEE/ACM Interna- tional Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE). IEEE, 31–53

  41. [2024]

    A large-scale exploit instrumentation study of AI/ML supply chain attacks in hugging face models.arXiv preprint arXiv:2410.04490(2024)

    2024 arXiv

  42. [2026]

    Towards fair machine learning software: Under- standing and addressing model bias through counterfactual thinking.AI and Ethics6, 2 (2026), 181

    2026

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.