WIP: sbom#317
Conversation
|
Thanks. 🎉 I'll hopefully have a look this week. |
jkloetzke
left a comment
jkloetzke
left a comment
There was a problem hiding this comment.
If I understood correctly, there are two kinds of SBOMs that shall be generated. A design SBOM that is derived from the recipes only and the build SBOM which is based on the audit trail. Is that correct?
Fundamentally, I think the generator API is just too constrained for the task. I'll propose a plugin API shortly that allows to define a new command that does not necessarily need to build anything. So a hypothetical bob design-sbom command could generate the design SBOM just from the parsed package graph.
OTOH, I would imagine to have a separate tool that takes the audit.json.gz as input and outputs the (Cyclone-DX) build SBOM. Would that be feasible?
I'm afraid I did not get why a separate "sbom-deploy" class is needed. Could you try to explain it in other words?
The other comments are just things that I noticed. I did not do a thorough review, though.
| from bob.audit import Audit, Artifact | ||
| from bob.errors import BobError, BuildError, ParseError | ||
| from bob.input import Step, PluginSetting | ||
| from bob.intermediate import StepIR |
There was a problem hiding this comment.
This is not part of the official plugin API and may break. AFAICT, it's not really needed.
| cpe_type = meta_env.get('PKG_CPE_TYPE','a') | ||
| cpe_vendor = meta_env.get('PKG_CPE_VENDOR','*') | ||
| cpe_product = meta_env.get('PKG_CPE_PRODUCT', | ||
| SBOMGeneratorBase._shorten_package_name(meta_data.get('recipe'))) | ||
| cpe_version = meta_env.get('PKG_VERSION','*') | ||
| cpe_update = meta_env.get('PKG_CPE_UPDATE','*') | ||
| cpe_edition = meta_env.get('PKG_CPE_EDITION','*') | ||
| cpe_lang = meta_env.get('PKG_CPE_LANG','*') | ||
| cpe_sw_edition = meta_env.get('PKG_CPE_SW_EDITION','*') | ||
| cpe_target_sw = meta_env.get('PKG_CPE_TARGET_SW','*') | ||
| cpe_target_hw = meta_env.get('PKG_CPE_TARGET_HW','*') | ||
| cpe_other = meta_env.get('PKG_CPE_OTHER','*') |
There was a problem hiding this comment.
Why can't we just add a full PKG_CPE to the recipes? Is it really just because of the PKG_VERSION that would be repeated?
There was a problem hiding this comment.
I did not have this idea... But it would make it much easier 👍
|
|
||
| import re | ||
| from bob import BOB_VERSION | ||
| from bob.audit import Audit, Artifact |
There was a problem hiding this comment.
The audit module is not part of the plugin API. But I guess we can make it official if needed.
Yes- this matches my interpretation of the BSI document. I only need the build-SBOM but the design SBOM was easy to add as well..
Sure, but it would require to copy some code and maintain compatibility... I need the audit parsing as well as the package graph. The later is unfortunately required as from the audit I can not see if it is a tool dependency or a tgt-dependency. I like the new plugin API, as I (mis)used the generator plugins in the past for many tasks which do not require a build. But for the build SBOM we need the build result. Can we add some
This is because not all files are added to the containers. E.g. the
|
The content of the audit trail is guaranteed to stay backwards compatible. A parser should ignore data it doesn't understand to maintain forward compatibility, though. But fields that are defined today will stay in future versions. So having separate parsing code does not impact compatibility. OTOH, exposing the Audit classes to plugins would force Bob to keep those classes and their behaviour eternally around. Given that they don't offer much functionality today, I'm hesitant to add them to the public API.
Hmm, why is that? Dependencies of a step are classified as "args" (direct or indirect dependency), "tools" (tool dependency) and "sandbox" (the used sandbox). in the audit trail. So I think the information is there. If this is not sufficient, then I would rather extend the audit trail In it's original conception, the audit trail should be something like an SBOM. It should describe the artifact completely.
I'm afraid that, when you need to build something, the new API won't be of much help. This case stays for project generators to be used. Having a build workspace is the major distinction between the existing project generators and the new command plugins. So do you need a project generator just because you need the package graph? |
2 participants
Add some classes and a plugin to build a cyclonedx sbom from audit + recipe information.
Depends on: BobBuildTool/bob#700 , BobBuildTool/bob#687
Refers to: #287
Open / Todo:
filter-keyword for the generator?License-Ref- Licenses? Should we move them up to the root package-dist? Or include them in the audit of the package already?