Thank you so much for writing and sharing this. The software supply chain security domain appears to resist formalization at times. I struggle with the question of what's a software supply chain attack vs. a deficiency in code, a DAST finding, a VA finding, etc., ever since I started contributing to some of the public catalogs (particularly for open source, e.g., the CNCF one) that rely heavily on an implicit criteria.
I have observed a number of reasons why practitioners resist this formalization (I'm biased as my experiences are heavily skewed towards open source) largely involving competing priorities (e.g., we should have an up-to-date catalog _first_, and maybe then we'll have a properly classified catalog)
As you allude to, the Venn of software supply chain, "shift left", AppSec, DevSecOps, vendor risk management, etc., is quite rich, keeps expanding, and the boundaries are fuzzy. I've found proper formalization to be quite important for remediation: the responsible individual for a mitigation of a software supply chain risk or weakness can defy organizational charts and boundaries, and having a clear taxonomy helps cut down the noise and increase efficiency.
On the other hand, my sense about the prevailing winds is that organizations generally see upside in attributing a certain "shape" of issues to "software supply chain". At first, there was a certain "smell" in the risks and incidents, for example well-known dependency confusion attacks. Then it got a bit more complicated. Today, I think even if we can have the intellectual honesty to call out things that aren't supply chain, there are a few attributes to consider that effectively make them (in my opinion) worth of living under the software supply chain umbrella.
Those attributes are all variant of trust, IMHO. Attacks that rely on/reap the benefits of implicit or explicit trust in a supply chain, are all IMHO worth examining under a supply chain lens. For example, an attack that has a high amplification factor, propagates and taints downstream chains. To that extent I would consider a typosquatting event as potentially different from a phishing event. If we're talking about one user typing the wrong npm install command in their Codespaces, I don't think of that as a supply chain. If this is in a pull request, it passes pre-commit hooks, SAST, SCA, etc., the attacker goes out of their way to operate "normally" for a time to avoid detection and then activates malicious behavior selectively depending on usage patterns, and that goes undetected by RASP, then it does sound more like a supply chain vector even if none of these pieces are "new" or can be claimed exclusively by supply chain. A problem with those attacks is that they invalidate the trust assumptions we had on the chain so that's where their impact in velocity comes from, beyond the specific blast radius of the payload itself.
I've also noticed that attacks that hop around practices and disciplines tend to be better understood with a supply chain security lens. Think for example of the Venn diagram in https://medium.com/product-cybersecurity/the-defense-in-layers-enterprise-framework-b84912985a3f - trying to read for example the nuances of provenance distribution only through the lens of cryptography of digital signatures loses part of the perspective.
Here's to an evolved framing that helps with a common language and broader understanding. In the meantime, I agree we need to avoid diluting the domain if we can avoid it, and one of the ways I can think of right now is to accept some level of duality (particularly in presence of attributes such as amplification, high interconnectedness, trust invalidation), making our rationale more explicit and recognize that sometimes it can be in the best interest of security to read a certain risk, weakness, vector or finding with a broader software supply chain security lens.
Thanks for the comment. I think you made an important point that "Attacks that rely on/reap the benefits of implicit or explicit trust in a supply chain, are all IMHO worth examining under a supply chain lens."
I agree with this framing, but the problem for me is the inability to draw a bright line between different types of attacks using this rubric. An organization "trusts" its developers to not be malicious, so when they prove otherwise, I think it's hard to call that a "supply chain attack" (not that this is what you are saying).
I made my definition very tight to avoid this ambiguity, but it's quite possible that I left out some things from my definitions that should qualify from a practical sense.
Thank you so much for writing and sharing this. The software supply chain security domain appears to resist formalization at times. I struggle with the question of what's a software supply chain attack vs. a deficiency in code, a DAST finding, a VA finding, etc., ever since I started contributing to some of the public catalogs (particularly for open source, e.g., the CNCF one) that rely heavily on an implicit criteria.
I've seen a number of taxonomies and catalogues in the past (see https://github.com/bureado/awesome-software-supply-chain-security#:~:text=A%20few%20resources%20to%20understand%20supply%20chain%20compromises%3A) of which Ladisa et al. (https://arxiv.org/abs/2204.04008) is one of the latest.
I have observed a number of reasons why practitioners resist this formalization (I'm biased as my experiences are heavily skewed towards open source) largely involving competing priorities (e.g., we should have an up-to-date catalog _first_, and maybe then we'll have a properly classified catalog)
As you allude to, the Venn of software supply chain, "shift left", AppSec, DevSecOps, vendor risk management, etc., is quite rich, keeps expanding, and the boundaries are fuzzy. I've found proper formalization to be quite important for remediation: the responsible individual for a mitigation of a software supply chain risk or weakness can defy organizational charts and boundaries, and having a clear taxonomy helps cut down the noise and increase efficiency.
On the other hand, my sense about the prevailing winds is that organizations generally see upside in attributing a certain "shape" of issues to "software supply chain". At first, there was a certain "smell" in the risks and incidents, for example well-known dependency confusion attacks. Then it got a bit more complicated. Today, I think even if we can have the intellectual honesty to call out things that aren't supply chain, there are a few attributes to consider that effectively make them (in my opinion) worth of living under the software supply chain umbrella.
Those attributes are all variant of trust, IMHO. Attacks that rely on/reap the benefits of implicit or explicit trust in a supply chain, are all IMHO worth examining under a supply chain lens. For example, an attack that has a high amplification factor, propagates and taints downstream chains. To that extent I would consider a typosquatting event as potentially different from a phishing event. If we're talking about one user typing the wrong npm install command in their Codespaces, I don't think of that as a supply chain. If this is in a pull request, it passes pre-commit hooks, SAST, SCA, etc., the attacker goes out of their way to operate "normally" for a time to avoid detection and then activates malicious behavior selectively depending on usage patterns, and that goes undetected by RASP, then it does sound more like a supply chain vector even if none of these pieces are "new" or can be claimed exclusively by supply chain. A problem with those attacks is that they invalidate the trust assumptions we had on the chain so that's where their impact in velocity comes from, beyond the specific blast radius of the payload itself.
I've also noticed that attacks that hop around practices and disciplines tend to be better understood with a supply chain security lens. Think for example of the Venn diagram in https://medium.com/product-cybersecurity/the-defense-in-layers-enterprise-framework-b84912985a3f - trying to read for example the nuances of provenance distribution only through the lens of cryptography of digital signatures loses part of the perspective.
Here's to an evolved framing that helps with a common language and broader understanding. In the meantime, I agree we need to avoid diluting the domain if we can avoid it, and one of the ways I can think of right now is to accept some level of duality (particularly in presence of attributes such as amplification, high interconnectedness, trust invalidation), making our rationale more explicit and recognize that sometimes it can be in the best interest of security to read a certain risk, weakness, vector or finding with a broader software supply chain security lens.
Thanks for the comment. I think you made an important point that "Attacks that rely on/reap the benefits of implicit or explicit trust in a supply chain, are all IMHO worth examining under a supply chain lens."
I agree with this framing, but the problem for me is the inability to draw a bright line between different types of attacks using this rubric. An organization "trusts" its developers to not be malicious, so when they prove otherwise, I think it's hard to call that a "supply chain attack" (not that this is what you are saying).
I made my definition very tight to avoid this ambiguity, but it's quite possible that I left out some things from my definitions that should qualify from a practical sense.