SBOM Harmonization Plugfest 2024

SBOM Plugfest 2024 FAQ

1. Are there specific CDX and SPDX format specification versions that you are looking for?
   • SPDX version 2.2 or greater
   • CycloneDX version 1.4 or greater
2. I saw XML listed as the file format in the example, is JSON acceptable as well or just XML?
   Yes, JSON is also an acceptable file format
    
3. Will you share the kickoff slides?
   Slide content on Plugfest directions and expectations is available at https://resources.sei.cmu.edu/news-events/events/sbom/participate.cfm
    
4. Do you want vulnerability and license info embedded in the SBOMs as well, or should it just be a list of components?
   Please include vulnerability and license info.
    
5. CISA has released the SBOM Framing doc v3. Will this be the baseline of minimum SBOM elements?
   We will use the SBOM Framing doc v3 as a baseline for minimum SBOM elements. Gaps from the baseline will be noted. Please note any enrichment in the README file.
    
6. For scanning binary builds, are you only requiring one architecture (e.g. x86_64), or multiple?
   • x86_64, amd64 are preferred
   • i386, arm also accepted
7. Are there any guidelines on the expected file size of SBOM?
   We are providing no guidelines on expected file size.
    
8. I’m seeing that there are requested package versions via git commit (e.g. Gin @ Commit: f05f966 · Sept 2024 )… if these versions do not line up with an already distributed package/binary/image then is the expectation to build one ad-hoc? Or should we only be using already distributed build artifacts from the projects?
   The expectation is to build one ad-hoc. Documenting the differences in build process and any adjustments made must be included in the submission README.
    
9. Surely everyone will be building with different tools, with different libraries?
   The intent is to see how different tools may generate SBOMs with differences for the same software. We provided links to the software packages to help ensure all use the same source.
    
10. Any restrictions on package scope? Looking to model distributed packages or all packages in use? Should we ignore dev/test deps?
    • For source SBOMs, scope dependencies as large as possible (so include dev/test deps).
    • For build SBOMs, scope dependencies to be dependencies at build time per definition of build SBOMs.
11. Would the research be made publicly available by CISA?
    CISA will try to make the basic results public, that is the goal. But we also don’t want to presuppose that everyone wants to have their inputs public.
     
12. How do you know what the ground truth is for each project? Syft, Trivy and Microsoft BOM often produce different results for the same target.
    We are not claiming a philosophical ground truth, rather we are using Syft, Trivy, and MS SBOM generated SBOMs as a baseline for purposes of comparison. We will also compare SBOMs against each other. The focus is on what is different between various SBOMs submitted for the same software.
     
13. Will there be an email sent out with a link to the plugfest Google drive containing targets/where to dump SBOMs?
    See question #3 for webpage with link to instructions and Google drive.
     
14. My tool takes existing SBOMs and enhances and improves on them. Can we submit our SBOMS?
    Yes. Our goal is to understand how automation is being used. Combining tools is acceptable. Please explain how your SBOMs was generated in your README file.