If you have been following the evolution of binary exploitation (and the exploit mitigations arms-race) of the past twenty or so years you can detect a certain pattern: where binary exploitation used to be quite straightforward, adding multiple possible layers of defense made it an exercise in chaining multiple exploit primitives in order to get the desired pwnage.
Scoring vulnerabilities is also another area essential to follow: I am going to use CVSS v4 as my North Star here. CVSS properly defines an Environmental metric (CVSS-BE as a bare minimum, CVSS-BTE for the full monty) – allowing vulnerabilities to be ranked on a (subjective, granted) specific per environment impact basis.
As systems became more distributed (your typical Web App these days might have a more complex architecture than your n-tier of the past, multiple components running in transient containers, in elastic infrastructure). While conducting internal penetration tests or while aggregating results from external security audit consultancies, I found the need to describe exploitation chains as a means to properly prioritize resolution of identified vulnerabilities. I am sure that most folks working in product security understand that if you are to maintain a sensible security posture and keep feature velocity moving you need to ruthlessly prioritize. You do not want to compromise your posture on one hand but companies cannot pull the proverbial handbrake and fix each and every vulnerability identified. Vulnerabilities that carry HIGH or CRITICAL ratings (including environmental adjustments, as stated above) but what if you can chain say 2 Mediums with 1 Low and have a synergistic effect and the resulting chain leads of the equivalent of HIGH? Verbally it is easy to communicate in a long format “by combining Medium vuln X with Medium Vuln Y and Low Vuln Z you get an Alpha High”. Doing that a number of times led me to the verbal shorthand of “High Killchain, length of three, maximum single severity Medium”. However, typing this gets old-hat quick so I decided to work a small shorthand for private use – shorthands are great as you can build code tools around them (wink-wink nudge-nudge).
My shorthand, in its simplest form is super simple: Chain Severity (adjusted for environment if needed)/Length of Chain (which is the number of combined vulnerabilities)/Highest Severity encountered in Chain. So the example above becomes H/3/M. Another possible variation is:
H/3/M:M:L – the benefit of the latter is that you can link each specific element of the chain to a standard CVSS v4 vector. The above lend themselves to some nice automation tools, so keep watching that space.
Hegel be my guide, I am throwing these ideas out to trigger discussion – have I missed a standard? Do you have a better idea? Do you like what you see? Drop me a comment so we can all move the needle on distributed system vulnerability classification in the 20s. Now all that is left is coming with a fancy name – thinking cap on.
Athanasios Kostopoulos 
So here is the thing with notations:
1. They have to be of some use and this seems to be addressed here
2. You have to be in some place where the adoption can be sped up
So the best thing to do is to make this a lightning talk and present, refine and make it a talk somewhere and present and through repetead iterations and presentations, you will find a community invested enough that they will either tell you, you have something here, or tell you that a notation already exists, in which case you can see how your view of things can be applied to that established notation too
LikeLike