Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upExtension Schema: Services #22
Comments
This comment has been minimized.
This comment has been minimized.
|
Proposed namespace is: |
This comment has been minimized.
This comment has been minimized.
|
Thoughts on fields that would be beneficial to capture: <svc:services>
<svc:service bom-ref="b2a46a4b-8367-4bae-9820-95557cfe03a8">
<svc:provider>
<svc:organization>Example Inc</svc:organization>
<svc:url>http://www.example.com</svc:url>
<svc:email>support@example.com</svc:email>
</svc:provider>
<svc:license>
<svc:name>Example, Inc enterprise license</svc:name>
<svc:quota>10,000,000 requests per month</svc:quota>
</svc:license>
<svc:endpoint>URI or some other location description</svc:endpoint>
<svc:authenticated>true/false - Whether or not authentication is required</svc:authenticated>
<svc:x-trust-boundary>true/false - Whether or not communication with service cross a trust boundary</svc:x-trust-boundary>
<svc:data>
<svc:classification flow="inbound/outbound/both">What kind</svc:classification>
<svc:classification flow="outbound">PII</svc:classification>
<svc:classification flow="inbound">PHI</svc:classification>
</svc:data>
</svc:service>
</svc:services> |
This comment has been minimized.
This comment has been minimized.
|
Note: Like BOM components themselves, the service definition should be limited to factual/verifiable data. Weaknesses, threats, countermeasures, and vulnerabilities should not be part of the service definition. |
This comment has been minimized.
This comment has been minimized.
|
In microservice deployments, having some way to track which version of what other microservices are used is critical for stable deployments. Ideally there would be some way to automagically generate that bom-like information (monitoring the service mesh?). But, even if it were manually maintained somewhere, it could help validate that a deployment environment is 'sufficient' to run a new microservice instance. |
This comment has been minimized.
This comment has been minimized.
|
Would something like this work? <svc:deployments>
<svc:deployment>
<svc:version>1.0.0</svc:version>
<svc:published>2020-01-01T13:15:30Z</svc:published>
<svc:buildid>53341</svc:buildid>
</svc:deployment>
<svc:deployment>
<svc:version>1.0.1.canary0</svc:version>
<svc:published>2020-01-02T10:06:10Z</svc:published>
<svc:buildid>53349</svc:buildid>
</svc:deployment>
</svc:deployments>The deployments node would appear inside the service node. As such, this would describe two deployments of a single service, all of which are optional. Of course, there's nothing preventing you from creating more than one service of the same type, and creating a single deployment for each. In that regard it would specify a unique endpoint for each version of a given service. So it should be flexible that way. |
Initial conversation started April 2019 but failed to get traction
https://groups.io/g/CycloneDX/message/3
This ticket is to document using external services using a schema extension.
Currently, CycloneDX allows users to track:
application
framework
library
operating-system
device
file
This schema extension is to provide support for documenting services.
For example:
There are a few things about service components that interest me:
I don't think the creation of BOMs with service components could be automated in any way. But I do think that known services could be documented in an XML fragment and appended to the BOM when it's created without much issue.