Upload process

[davaya]

The upload process diagram https://github.com/nyph-infosec/daggerboard/blob/main/.attachments/readme_db_diagram.png starts with a step "CycloneDX/SPDX SBOM imported", which implies that some person finds an SBOM file and uploads it to the Daggerboard system.

Many networks have ITAM systems that track nodes on the network and software installed on those nodes. Is discovery of software installed on a network and discovery of SBOMs that apply to that software within scope of development? Open Cybersecurity Alliance has a security attribute collection and evaluation project (PACE) that addresses this problem space and is in need of use cases to drive further progress. The bulk of Daggerboard performs the "Evaluation" part of that problem, and also has a placeholder for data collection. If collection automation is within Daggerboard's scope, this looks like an opportunity for collaboration.

[namtarb]

Thanks @davaya - This is a great idea on how Daggerboard could be used to meet real-world use cases. Network discovery is not in scope for Daggerboard, but theoretically it could ingest this information from an ITAM system or nmap scan result. API functionality is currently on the roadmap of items to add to Daggerboard, and could be used to make this possible. However, at this point the Daggerboard team is focusing efforts on implementing items from the roadmap.

Once the API has been implemented, this type of feature could be possible. At a high level, there are two scenarios:

• Open source SBOMs (with docker containers): This could be automated once the Daggerboard API has been implemented.
  • What it requires: Daggerboard would need to ingest list of software and identify Docker image name and tag. Support for SBOM generation would also need to be added somewhere.
  • Ex workflow: The ITAM system sends a list of products to Daggerboard via API, ITAM or Daggerboard finds their docker image name and tag, a tool (like Syft) is used to generate an SBOM, uploads via the Daggerboard API, uses Daggerboard API to send results back to ITAM.
• Commercially available products - This area will be tougher to achieve, as, at least to our knowledge, there is not currently a publicly available repository of private SBOMs. We found that some manufacturers were hesitant to make this information public since they are just now adapting the SBOM standard.

[sparrell]

The PACE project is attempting to standardize the API's mentioned. Since this is an open source project, would the "Daggerboard team" be open to pull requests from "outside" the team to add features not necessarily on their roadmap (e.gl adding PACE-compliant interfaces)?

Note complying with PACE interfaces would at least allow interaction with compliant commercial SBOM systems. Admittedly there are no compliant commercial systems at the moment but this is a nascent field and senior DoD officials saying it will be in procurement requirements (e.g. https://youtu.be/cWL8wiSi-Rs?t=1177) will drive adoption.

[namtarb]

We are absolutely open to collaboration and external pull requests. The only hurdle right now is that we don’t have a Daggerboard API, but we are aiming to release this feature in early 2023.