Skip to content
GitHub no longer supports this web browser. Learn more about the browsers we support.
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extension Schema: Services #22

Open
stevespringett opened this issue Jan 3, 2020 · 5 comments
Open

Extension Schema: Services #22

stevespringett opened this issue Jan 3, 2020 · 5 comments

Comments

@stevespringett
Copy link
Member

@stevespringett stevespringett commented Jan 3, 2020

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:

  • an application that relies on various FaaS (i.e. something deployed to AWS Lambda)
  • micro-services architectures that have a dependency on each other
  • the use of a freely available web service (which itself has usage restrictions (similar to license restrictions))

There are a few things about service components that interest me:

  • They could document if an application (or component) crosses a trust boundary
  • They could document protocols, ports, and data transfer formats used (not the formats themselves)
  • They could document components which do not have local functionality, but rather are a shim to a service which provides the functionality

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.

@stevespringett

This comment has been minimized.

Copy link
Member Author

@stevespringett stevespringett commented Jan 3, 2020

@stevespringett

This comment has been minimized.

Copy link
Member Author

@stevespringett stevespringett commented Jan 3, 2020

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>
@stevespringett

This comment has been minimized.

Copy link
Member Author

@stevespringett stevespringett commented Jan 3, 2020

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.

@llamahunter

This comment has been minimized.

Copy link

@llamahunter llamahunter commented Jan 3, 2020

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.

@stevespringett

This comment has been minimized.

Copy link
Member Author

@stevespringett stevespringett commented Jan 3, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.