specification
specification copied to clipboard
CycloneDX
Support for Cloud Primitives
This is probably a duplicate of #77. However, I didn't want to comment to add to it in case there is a divergence from the feedback provided here.
Currently, component types are limited to:
- Application
- Framework
- Library
- Container
- Operating System
- Device
- Firmware
- File
Is there a path to add Cloud Primitives to this list.
For example, AWS AMI could be a good addition because both Firmware and Operating System do not cover the entirety of the scope. I also don't think this specification should be aligned to specific cloud vendors' terminology.
e.g AWS AMI == Azure Image == GCP Images
I think it makes sense to add Image as a generic type to the components type. Potentially, there is room for it to eventually replace Container unless I'm missing some context.
In here - I mentioned Cloud Primitives. Does it make sense to continue that conversation here, or should I create a new issue for each primitive?
The definition of container is:
A packaging and/or runtime format, not specific to any particular technology, which isolates software inside the container from software outside of a container through virtualization technology. Refer to https://en.wikipedia.org/wiki/OS-level_virtualization
This definition covers both container images (packaging) and runtime containers. So, for SBOMs, you'll know that container refers to an image whereas for OBOMs you'll know that it refers to the running container.
If you wanted to specify the image file itself, you could use the file type along with the mime-type property.
For example: application/vnd.oci.image.layer.v1.tar.
I also don't think this specification should be aligned to specific cloud vendors' terminology.
100% agree.
What types of primitives do you envision including support for?
Hey @stevespringett - Thank you for the reply, and I, unfortunately, read too much into the overloaded term of container. Thank you for correcting me.
What types of primitives do you envision including support for?
- Roles
- DNS Records
- Policies
- S3/Blob Storage
My mental model is that these are software-defined resources and as such should be managed just like any other software entity.
Checkov actually does provide a cyclonedx output, but it focuses on the terraform files for example
<bom xmlns="http://cyclonedx.org/schema/bom/1.3" xmlns:v="http://cyclonedx.org/schema/ext/vulnerability/1.0" version="1" serialNumber="urn:uuid:ad455c91-501e-4ff7-87c7-13373b011405">
<metadata>
<timestamp>2022-04-16T05:52:35.254483+00:00</timestamp>
<tools>
<tool>
<vendor>CycloneDX</vendor>
<name>cyclonedx-python-lib</name>
<version>0.12.3</version>
</tool>
<tool>
<vendor>bridgecrew</vendor>
<name>checkov</name>
<version>2.0.1050</version>
</tool>
</tools>
</metadata>
<components>
<component type="file" bom-ref="pkg:generic/[email protected]">
<name>/certificate.tf</name>
<version>0.0.0-a14dc8700e97</version>
<hashes>
<hash alg="SHA-1">a14dc8700e97a9aa2907cf9ac95cd947cc565be3</hash>
</hashes>
<purl>pkg:generic/[email protected]</purl>
<v:vulnerabilities>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_233">
<v:id>CKV_AWS_233</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_acm_certificate.this. Ensure Create before destroy for ACM certificates</v:description>
<v:advisories>
<v:advisory/>
</v:advisories>
</v:vulnerability>
</v:vulnerabilities>
</component>
<component type="file" bom-ref="pkg:generic/[email protected]">
<name>/permissions.tf</name>
<version>0.0.0-cbca58cfb2ec</version>
<hashes>
<hash alg="SHA-1">cbca58cfb2ec54d4caee629c70fb3b585dd815eb</hash>
</hashes>
<purl>pkg:generic/[email protected]</purl>
</component>
<component type="file" bom-ref="pkg:generic/[email protected]">
<name>/route53.tf</name>
<version>0.0.0-4cca24ccaad6</version>
<hashes>
<hash alg="SHA-1">4cca24ccaad640ce5127953f249352adb1c7c4d8</hash>
</hashes>
<purl>pkg:generic/[email protected]</purl>
</component>
<component type="file" bom-ref="pkg:generic/[email protected]">
<name>/api_gateway_config.tf</name>
<version>0.0.0-c8e0844be5fa</version>
<hashes>
<hash alg="SHA-1">c8e0844be5fa61b3af15dfdbc9ecbceaf6398727</hash>
</hashes>
<purl>pkg:generic/[email protected]</purl>
<v:vulnerabilities>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_237">
<v:id>CKV_AWS_237</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_rest_api.this. Ensure Create before destroy for API GATEWAY</v:description>
<v:advisories>
<v:advisory/>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_217">
<v:id>CKV_AWS_217</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_deployment.this. Ensure Create before destroy for API deployments</v:description>
<v:advisories>
<v:advisory/>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_120">
<v:id>CKV_AWS_120</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_stage.this. Ensure API Gateway caching is enabled</v:description>
<v:advisories>
<v:advisory/>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_73">
<v:id>CKV_AWS_73</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_stage.this. Ensure API Gateway has X-Ray Tracing enabled</v:description>
<v:advisories>
<v:advisory>https://docs.bridgecrew.io/docs/logging_15</v:advisory>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_76">
<v:id>CKV_AWS_76</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_stage.this. Ensure API Gateway has Access Logging enabled</v:description>
<v:advisories>
<v:advisory>https://docs.bridgecrew.io/docs/logging_17</v:advisory>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_225">
<v:id>CKV_AWS_225</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_method_settings.this. Ensure API Gateway method setting caching is enabled</v:description>
<v:advisories>
<v:advisory/>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_206">
<v:id>CKV_AWS_206</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_domain_name.this. Ensure API Gateway Domain uses a modern security Policy</v:description>
<v:advisories>
<v:advisory/>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_4">
<v:id>CKV2_AWS_4</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_stage.this. Ensure API Gateway stage have logging level defined as appropriate</v:description>
<v:advisories>
<v:advisory>https://docs.bridgecrew.io/docs/ensure-api-gateway-stage-have-logging-level-defined-as-appropiate</v:advisory>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_29">
<v:id>CKV2_AWS_29</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_stage.this. Ensure public API gateway are protected by WAF</v:description>
<v:advisories>
<v:advisory>https://docs.bridgecrew.io/docs/ensure-public-api-gateway-are-protected-by-waf</v:advisory>
</v:advisories>
</v:vulnerability>
</v:vulnerabilities>
</component>
<component type="file" bom-ref="pkg:generic/[email protected]">
<name>/api_gateway_resources.tf</name>
<version>0.0.0-b057c6710adb</version>
<hashes>
<hash alg="SHA-1">b057c6710adb62cc746a83d963320e7e543598b6</hash>
</hashes>
<purl>pkg:generic/[email protected]</purl>
<v:vulnerabilities>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_59">
<v:id>CKV_AWS_59</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_method.proxy_root. Ensure there is no open access to back-end resources through API</v:description>
<v:advisories>
<v:advisory>https://docs.bridgecrew.io/docs/public_6-api-gateway-authorizer-set</v:advisory>
</v:advisories>
</v:vulnerability>
<v:vulnerability ref="pkg:generic/[email protected]_AWS_59">
<v:id>CKV_AWS_59</v:id>
<v:source name="checkov"/>
<v:description>Resource: aws_api_gateway_method.proxy_other. Ensure there is no open access to back-end resources through API</v:description>
<v:advisories>
<v:advisory>https://docs.bridgecrew.io/docs/public_6-api-gateway-authorizer-set</v:advisory>
</v:advisories>
</v:vulnerability>
</v:vulnerabilities>
</component>
</components>
Thanks for the clarification and Checkov example. S3 can easily be defined using services today, however, what may be missing is what the services do with the data. For example, you can define an S3 service and define the data flow classifications and directional flow of data to and from the service, but there's no way to know what the services do with the data. So a possible direction would be to add support for:
- Data creation
- Data storage
- Object storage
- File storage
- Block storage
- Data processing
- Data analysis
- Data sharing
- Data archiving
In the case of S3, specifying object storage as a property of the service would likely provide insight into recommended security controls as well as any data compliance requirements.
Roles, DNS records, and policies are all examples of different types of configurations. DNS records are self-explanatory. What do you envision for roles and policies in a cloud agnostic way? Can you give a few use cases?