Minutes from July 8 Telecon

Dan presented on the prototype data collection architecture he has been building

· Dan noted that the parameters of the calls between components are only roughly sketched out and have yet to be standardized.

· The architecture Dan developed is just the set of components and very simple queries and events moving between them. He listed several areas that could be the targets of work to add greater detail. The group did not identify any preferences.

· Dan noted that, currently, his architecture sends all results to the Application as soon as those results are available and it is the Application's job to collate multiple results corresponding to a single assessment. He asked if this was a good design. The group felt that this was best answered by further development and testing and that this part of the design should be retained for now.

· Dan noted that there is currently a single results queue to which an Application listens. Thus, every assessment result is published to this queue and Applications would need to examine each to determine whether the result was relevant to it. The group felt that it would be better to avoid delivery of results that were not of interest to the Application.

· It was noted that Collectors used a query to send results to the Repository, but an event to distribute results to the Application. It was suggested that an event be used in both cases.

Adam shared the OCA project request form

· Adam noted the form is still in development and that use by the SCAP team would help OCA refine it.

· Adam noted that the advantage of developing the prototype under OCA is that it will expose the work to a broader group of vendors than would otherwise be easily achieved. This might result in greater interest in SCAP in general.

David discussed some OpenC2 work (https://github.com/oasis-tcs/openc2-usecases/tree/master/SBOM-PoC)

· He noted that the OpenC2 effort is looking at how to connect with both OCA and OASIS CACAO.

· In the OpenC2 architecture he noted that there is a box for "collect SBOMs", which he felt was very well aligned with the architecture we are developing for SCAP.

· He noted that OpenC2 is a framework and that profiles are defined to support specific uses. As such, there could be an SCAP OpenC2 profile that captures all of the commands and parameters needed for SCAP architecture activities but do so within the general OpenC2 framework.

Next steps

· Charles will create a draft OCA proposal for the SCAP data collection architecture prototype project

· Dan will continue to refine the SCAP architecture addressing the feedback from the group and then working on fleshing out the targeting and applicability portions, which are most closely aligned with the SBOM use case of OpenC2.

Reply all

Reply to author

Forward

0 new messages