What can go wrong in QaaS? A STRIDE map for the whole pipeline, from orchestration to execution.
4 comments
When they say the pipeline has six stages, is the main point that a compromise in one layer can only distort results, or can it actually leak the submitted circuit or data as it moves through the classical parts too?
> a compromise in one layer can only distort results
No, the classical bits are part of the attack surface too, so a bad SDK, transpiler, or result path can leak the submitted circuit, parameters, or even optimizer state, not just perturb the final counts. The excerpt actually calls out inverse-transpilation and QML theft at S3/S5, which is more than a bad answer coming back.
> the classical bits are part of the attack surface too
Sure, but that part is hardly a revelation, and the paper seems to inflate it by padding the matrix with generic SDK/IAM/transpiler failures as if that were quantum-specific insight. The useful bit is the circuit, parameter, and optimizer leakage paths, the rest is just cloud security with a quantum sticker on it.
The six-stage split feels more useful than just slapping MITRE ATT&CK onto QaaS, because it forces you to ask where the circuit, parameters, and results can be touched, not just which generic tactic applies. I do think it loses a bit when the matrix starts counting ordinary SDK/IAM/transpiler failures as quantum-specific risk, thats where the boundary gets mushy fast.