[feature] IsDeployed

[ridhoq]

Is your feature request related to a problem? Please describe.

The GUAC ontology represents a graph of software artifacts, actors, and actions taken by actors. One of the most important actions that an actor can perform on a software artifact is deploying it to a production environment. Software artifacts running in production are exposed to users, either directly or indirectly, and thus vulnerable to attacks by malicious actors. When a vulnerability is present or detected in a software artifact running in production, software operators need to know the location of the vulnerable artifact, so they can either mitigate the risk or attest that the artifact is not actually vulnerable.

Consider an organization that uses Kubernetes clusters to deploy container artifacts. The organization has many teams that manage their own clusters, increasing the attack surface. Suppose a new critical vulnerability affects many of the running container images. The organization can use GUAC to query collected SBOMs and identify the affected images and registries. However, they cannot query which images are running on which clusters. A monitoring system based on GUAC may report false positives, as not all vulnerable images are in use. If GUAC could show the cluster location of the images (e.g., Deployment or DaemonSet), the teams could mitigate the vulnerability more effectively.

Describe the solution you'd like

IsDeployed is a new node that can have edges to Package nodes to denote when a particular package has been deployed. Generally, only top level packages with types such as oci or swid will have edges to IsDeployed.

Here's what the GraphQL schema might look like:

type IsDeployed {
  id: ID!
  "Package that is deployed"
  package: Package!
  "Timestamp when the package was deployed and became active"
  deployedSince: Time!
  "Timestamp when the package was no longer deployed and became inactive"
  deployedUntil: Time
  "List of deployment metadata"
  deploymentMetadata: [DeploymentMetadata!]!
  "Document from which this attestation is generated from"
  origin: String!
  "GUAC collector for the document"
  collector: String!
}

type DeploymentMetadata {
  id: ID!
  timestamp: Time
  key: String!
  value: String!
  origin: String
  collector: String
}

The associated Query and Mutation is not proposed here but would follow similar patterns to the rest of the schema.

This proposal centers on two key timestamps: deployedSince (required) for when a package becomes active, and deployedUntil (optional) for when it's no longer active. An unpopulated deployedUntil implies ongoing activity. IsDeployed will also feature a DeploymentMetadata list for detailed deployment descriptions, allowing users to tailor metadata to their specific deployment environments.

One proposal for how to collect this data would be to receive cdevents from the deployment system that are pushed to a collector via NATS. Another proposal for Kubernetes is to create an admission webhook that can send events about when a deployment occurred. The collection side will have many different options and will ultimately depend on the deployment target for the package.

A major consideration for this proposal is how to effectively prevent data growth. As deployments happen frequently in many organizations, the IsDeployed nodes will grow indefinitely. There should be a mechanism for pruning stale data or archiving data for future use. While this data growth issue exists for GUAC broadly, it will be particularly problematic for in this case. Please feel free to provide feedback on how this can be addressed.

Describe alternatives you've considered

An alternative is to simply not include this in GUAC. Packages that are actively deployed could be tracked by another system altogether. If such a system existed, GUAC can be used to join package and vulnerability data with this system to determine if a user needs to take action on their environments. However, this joining could also be expensive and prone to failure. Since GUAC's charter is to create a graph of the entire software supply chain, including data about where a package is deployed seems fitting and necessary to make actionable decisions.

Additional context

This is still not a comprehensive proposal so any feedback is welcome! If there is positive feedback about this proposal, a separate document can be written to delve into this more in depth.

[sozercan]

I like this idea! It might be good to collect/consume this info from KBOM (and/or pluggable other sources) instead of querying cluster(s) directly. An operator running in cluster(s) (like trivy-operator) can produce these results and guac can consume them.

cc @itaysk

[janwillies]

Nice writeup! I've always wondered how this fits into guac / how people are solving this

[itaysk]

Thanks for the ping @sozercan . While I think the gist of your comment makes sense, I just need to mention that Trivy KBOM does not include information about workloads, but rather information about the Kubernetes cluster components.

[pxp928]

We had a quick discussion about this with @ridhoq during the community meeting. Overall, this is a great feature that would add value. There are a few points that need discussion:

1. Should we store this information in GUAC or would it be better as an integration due to the dynamic nature of the data?
2. If stored in GUAC, how often would it need to be updated? As Ridwan stated, it would cause lots of data build-up and would require pruning.
3. What is the most effective way to obtain this information?
4. As discussed in the call, this would need to be in the form of an "attestation" (preferably an in-toto attestation). This could be signed and verified later down the line to ensure the trustworthiness of the data.

[toddysm]

@ridhoq and I have been discussing this offline. Our view is that we would like to have one single place where we can store all information related to the supply chain (of containers), not only the composition. The reason being if that information is stored in two (or more) separate systems, joining the information becomes more problematic.
We do see the supply chain as a graph (that we would like to search bi-directionally) that starts from acquisition of the base container images and any external packages and ends with deployment and eventually termination of the running container on the runtime nodes.
Two main scenarios we are targeting at the moment are:

• Inventory/impact assessment scenario
  In this scenario, we would like to identify all assets that are impacted by a certain vulnerability and what is the relation between them (including deployed/running assets), i.e. what is the flow through the supply chain
• Remediation sequence scenario
  In this scenario, we would like to understand what are the steps for remediating vulnerability that is discovered at runtime (or any other stage of the supply chain). This should answer questions like, what base image needs to be updated, what library needs to be updated, what applications/containers need to be redeployed, etc.

Hope this helps steer the conversation further.

[pxp928]

New Deployment attestation being developed: in-toto/attestation#341

Will need to determine if this fits into this discussion or not.