Supply chain modeling is hard

[j---]

Based on a discussion with @thomas-proell and @bs37208. However, I have digested their comments, so should not be taken to represent their views directly.

"supplier" is not the best way to model this kind of stakeholder, because every supplier is in the middle of a supply chain and they will always be absorbing fixes from their dependencies.

This is addressed briefly here.
https://github.com/CERTCC/SSVC/blob/82363313b2f0c17308bce829753641bda77e73e3/doc/md_src_files/040_stakeholders-scope.md?plain=1#L16C1-L24C93

I'd like to use this discussion to ask a more fundamental question:
What actually is the difference between a supplier and a deployer? Is the fact that it is a spectrum of information about how a system or piece of software will be used mean that we eliminate the distinction but instead provide 3-6 example trees and say something more along the lines of "use whatever one you have the information for" with a bit of a caveat that there are some decision points that folks could gather information on as their mature their asset management and vulnerability management processes? So provide more example trees, with some being "starter" trees with fewer decision points and a growth pattern for how it might look as the stakeholder gathers more information?

This is related to a maturity process for stakeholders that I have discussed with @jeroenh .
@ahouseholder probably also related to Vultron and MPCVD.

[laurie-tyz]

A supplier does not know how or where the product will be utilized.

The deployer is fully aware of the where and may also be aware of how the product will be utilized as they are applying the update.

[laurie-tyz]

OR maybe the suppler is deploying the fix (so acting as a deployer for the patch for the product in-house); but doesn't know the how and where the product will be utilized.

[thomas-proell]

Regarding the question, where and how the product will be utilized:

The question not binary. The farther down you go the supply chain, the better your understanding gets where your product will end up. There is no hard boundary where you (position n on the chain) have no clue and n+1 knows it precisely.

But suppose there was such a boundary. Then we have a certain set of qualifiers which determine the urgency of patching for all 20 upstream developers – and another set of qualifiers for the one deployer.

Here all developers work with low speed on non-exploited vulns -- while the deployer is waiting for his safety- and mission critical patch.

[j---]

I think agreeing with Thomas, there are different levels of information a supplier knows. For example, a developer of a crypto library knows that their library will be used for cryptography, which is a security critical process, even if they don't know where exactly. In general, folks have a relationship with their immediate next-user. That's why we changed the text about safety from v1 (where it asked for multiple supply chain hops to be considered) to just one supply chain hop and very broad bins in public safety impact. So there are certain kinds of libraries that folks should probably patch and distribute faster than others. There are a few ways of capturing that. We might go to "criticality" (#216) rather than safety for representing that. But I don't think we should let suppliers say they know nothing just because they know less than everything about how something is used.

[ahouseholder]

What actually is the difference between a supplier and a deployer?

Gut reaction to just this question:

• A supplier is making a decision about whether to produce a revision to their product for release into its distribution channels. This decision may be driven by either (notional concepts in italics)
  • development - recognizing the potential need to modify their code in response to a report received
  • integration - receiving an update from an upstream supplier about an available or forthcoming revision to a product on which their product depends
• A deployer is making a decision about whether to update an existing instance(s) of a product to a newer version of that product. The deployer is making a decision about changing a service.

Obviously, the line blurs because Product-as-a-service is a thing.

[ahouseholder]

I need to think about the broader point more though.

One not entirely unrelated thought I've had recently is that I'm starting to think of SSVC as including:

1. A catalog of enumerated decision points
2. A collection of trees assembled from those decision points to model various stakeholder process decisions

Partly because I've been messing with python enums way to much lately, I've had the idea that the SSVC "parts catalog" could include things like CVSS vector elements too, or the criticality concept from #216 for example. We could potentially define and manage an entire library of decision points independently of which trees they are used in. Like defining a formal vocabulary encoding of vulnerability-management-relevant features.

[ahouseholder]

Just noting that this idea is a conceptual ancestor to

• Add building block analogy explainer #447

[j---]

instead provide 3-6 example trees and say something more along the lines of "use whatever one you have the information for"

We could potentially define and manage an entire library of decision points independently of which trees they are used in. Like defining a formal vocabulary encoding of vulnerability-management-relevant features.

I think we are saying pretty similar things here. I would like to see us also manage some different example trees for different supply chain points and information gathering maturity levels. But in respect of the supply chain position being, shall we say, fluid, we could move away from rigidly defined stakeholder roles along the supply chain. Coordinators remain somewhat separate in a different way, though, and we shouldn't lose that.