💻 computer science

On the Figures of Merit for Quantum Software Security: Toward a Benchmarking Rubric

This paper addresses the lack of standardized security metrics for quantum software by proposing a structured set of Security Figures of Merit (S-FoMs) aligned with ISO/IEC 25010 and a benchmarking rubric to calculate a unified Quantum Software Security Posture (QSSP) score.

Original authors: Badhon Rahman, Majid Haghparast, Tommi Mikkonen

Published 2026-08-07

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Badhon Rahman, Majid Haghparast, Tommi Mikkonen

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a world where computers don't just crunch numbers with tiny switches, but dance with the very fabric of reality using particles that can be in two places at once. This is the realm of quantum computing, a field that is rapidly shifting from a theoretical dream to a real engineering practice. Today, most people don't own these powerful machines; instead, they rent time on them through the cloud, a service known as Quantum-as-a-Service (QaaS). It's like renting a super-fast race car: you get to drive it, but you don't own the engine, and you have to trust the garage that built it.

Right now, when we talk about how good these quantum computers are, we have a very clear checklist. We measure their Speed (how fast they run), their Scale (how many quantum bits, or "qubits," they have), and their Quality (how reliably they keep their quantum state). It's like judging a car by its top speed, horsepower, and how smoothly it handles corners. But there's a huge blind spot: security. While we know how fast the car goes, we don't really have a standardized way to measure how well it's protected against hackers, spies, or sneaky neighbors in the cloud who might try to steal your secrets or sabotage your race. We have a few scattered tools to check for specific tricks, but no unified system to say, "This software is safer than that one."

This is exactly where the paper "On the Figures of Merit for Quantum Software Security" steps in. The authors, Badhon Rahman, Majid Haghparast, and Tommi Mikkonen, argue that it's time to stop guessing and start measuring quantum software security with the same precision we use for performance. They propose a new "report card" system called Security Figures of Merit (S-FoMs).

Think of the current situation like a group of people trying to compare the strength of different shields. One person holds up a shield and says, "It's 28.83% effective!" while another says, "Mine is 1.92!" The problem is, they are using different rulers and different definitions of "effective." One is measuring how much the shield distorts a picture, while the other measures how much it cracks under pressure. You can't compare them directly. The authors point out that this confusion is currently the norm in quantum security. Some tools measure how well they hide a program's logic (obfuscation), while others try to measure if a hacker can steal the code, but they all speak different languages.

To fix this, the team builds a structured framework based on a famous international standard for software quality (ISO/IEC 25010). They break down security into familiar categories like Confidentiality (keeping secrets), Integrity (making sure no one tampers with the results), Authenticity (proving who you are), and Resistance (fighting off attacks). Then, they map these categories to the different stages of the quantum journey, from the moment a developer writes the code to the moment the result comes back from the cloud.

The paper suggests a three-step process to create a single, comparable score for any quantum software:

Declare the Enemy: You can't measure safety without saying who you are protecting against. Is it a hacker trying to reverse-engineer your code? Or a neighbor on the same cloud server trying to spy on your data? The authors insist that every security score must come with a clear "threat model."
Normalize the Numbers: They propose a mathematical way to convert all those confusing, incompatible measurements (like the 28.83% vs. 1.92% example) into a standard score from 0 to 1. In this new system, 1 means "super secure" and 0 means "wide open." This allows you to compare a tool that hides secrets with a tool that prevents tampering on the same scale.
Create a Composite Score: Finally, they suggest combining these normalized scores into a single number called the Quantum Software Security Posture (QSSP). This gives you a "health score" for the software's security. However, they are careful to note that security often comes with a cost (like slower speeds or more complex code). So, they also track this "security overhead" separately, ensuring that a tool isn't just rated on how safe it is, but also on how much it slows you down.

To prove their point, the authors took two existing methods for hiding quantum code and re-analyzed them using their new system. They showed that under the old, messy rules, the results were impossible to compare fairly. But once they applied their new "ruler" and standardized definitions, they could clearly see which method offered better protection and at what cost.

The paper doesn't claim to have solved every security problem in the quantum world. Instead, it offers a blueprint. It suggests that we need to move away from ad-hoc, one-off measurements and toward a unified, standardized way of talking about security. By doing this, developers and users can finally make informed decisions, knowing exactly how secure their quantum software is and how it stacks up against the competition. It's the first step toward a future where we can trust the quantum cloud as much as we trust the speed of the quantum engine.

Technical Summary: On the Figures of Merit for Quantum Software Security

Problem Statement

Quantum software is rapidly transitioning from theoretical research to engineering practice, increasingly deployed via multi-tenant, cloud-based Quantum-as-a-Service (QaaS) stacks. While the community has established mature Figures of Merit (FoMs) for performance (e.g., Quantum Volume, CLOPS) and is emerging in software quality metrics (e.g., circuit complexity, understandability aligned with ISO/IEC 25010), quantum software security remains largely unmeasured and unstandardized.

Current security indicators are fragmented and incompatible. Existing metrics, such as Total Variation Distance (TVD) and Degree of Functional Corruption (DFC), were introduced ad hoc for specific circuit obfuscation techniques. They operate on different scales and definitions, rendering them incomparable. Consequently, there is no shared rubric to determine if one quantum software tool is more secure than another, nor is there a framework to quantify security across the broader QaaS pipeline (e.g., authentication, multi-tenant isolation, accountability). This creates a "three-layer measurement gap" where performance and quality are standardized, but security metrics are absent or non-uniform.

Methodology

The paper proposes a structured approach to bridge this gap through three primary methodological steps:

Characterization of the Measurement Gap: The authors analyze the current state of metrics across three layers:
- Layer 1 (Performance): Mature, standardized, and supported by tools.
- Layer 2 (Software Quality): Emerging, adapting classical metrics (e.g., lines of code, cyclomatic complexity) to quantum programs.
- Layer 3 (Security): Fragmented or absent, with metrics currently limited to specific obfuscation techniques and lacking a unified framework.
Proposal of Security Figures of Merit (S-FoMs): The authors define S-FoMs as quantities that measure security characteristics or overheads, calculated via stated protocols against declared attack models, and normalized to a common [0,1] scale. They organize a candidate set of S-FoMs based on:
- ISO/IEC 25010:2023 Security Sub-characteristics: Confidentiality, Integrity, Authenticity, Non-repudiation/Accountability, and Resistance.
- QaaS Pipeline Mapping: Aligning metrics with six stages: Developer Environment (S1), Authentication & Submission (S2), Cloud Orchestration & Compilation (S3), Quantum Hardware Execution (S4), Result Return Path (S5), and Hybrid Iteration Loop (S6).
- Measurement Maturity: Categorizing metrics as Established (E), Adaptable (A), or Proposed (P).
Development of a Benchmarking Rubric: To make S-FoMs comparable, the paper proposes a three-step rubric:
- Attack-Model Declaration: Every S-FoM must be reported against a specific adversary (capabilities, access, stage) to ensure reproducibility.
- Normalization: Raw metric values ( $m_i$ ) are mapped to orientation-corrected scores ( $\hat{m}_i \in [0,1]$ ) using min-max scaling. This handles metrics where "lower is better" (e.g., DFC) by inverting the scale, ensuring 1 represents the strongest security.
- Weighted Aggregation: A composite Quantum Software Security Posture (QSSP) score is calculated as a weighted sum of normalized S-FoMs. The paper notes that to avoid masking weaknesses (the "weakest-link" problem), the QSSP should be published alongside a score vector and a geometric mean (conservative alternative). Additionally, Security Overhead (SO) is tracked separately to allow for Pareto-frontier analysis of security vs. resource cost.

Key Contributions

Identification of the Security Measurement Gap: The paper explicitly characterizes the disparity between mature performance benchmarks and the fragmented state of security metrics in quantum software.
Structured S-FoM Taxonomy: It proposes a comprehensive set of candidate security metrics organized by ISO/IEC 25010 sub-characteristics and mapped to the QaaS pipeline, distinguishing between established, adaptable, and proposed metrics.
Standardized Benchmarking Rubric: The authors define a protocol to normalize disparate metrics and aggregate them into a single, comparable QSSP score, including mechanisms to handle trade-offs with security overhead.
Illustrative Reanalysis: The paper reanalyzes two published obfuscation techniques (Dummy CNOT gate insertion and randomized reversible gate techniques). It demonstrates that their original reporting (using incompatible TVD definitions) is non-comparable. By applying the proposed rubric, these metrics are normalized, allowing for a valid, interpretable comparison of their confidentiality sub-scores.

Results and Findings

Current State: The analysis reveals that quantitative security research is currently concentrated on Confidentiality (specifically at the S3 compilation stage) and is the only well-instrumented property. Other critical properties like Accountability (Provenance Completeness, Audit-log Tamper-evidence) are labeled as "Proposed" (P), indicating a lack of existing quantum-specific metrics.
Incompatibility of Existing Metrics: The reanalysis confirms that without standardization, metrics like TVD cannot be compared across different studies due to differing definitions and scales.
Restoration of Comparability: The application of the proposed rubric successfully transforms scattered, non-comparable numbers into a structured, interpretable comparison, enabling practitioners to evaluate tools based on a unified security posture.

Significance

The paper asserts that quantum software security deserves the same level of attention and standardization as performance. Just as performance is measured via agreed-upon FoMs (like Quantum Volume), security requires an explicit set of Security Figures of Merit (S-FoMs).

The significance of this work lies in providing the first step toward security-aware benchmarking of the Quantum Software Stack (QSS). By moving from ad hoc indicators to a structured, normalized framework, the paper aims to enable practitioners to:

Quantify security defenses rather than relying on qualitative claims.
Compare different quantum software tools and obfuscation techniques on a level playing field.
Make informed trade-off decisions between security strength and operational overhead (e.g., gate depth, runtime).

The authors conclude that this framework is a foundational step, with future work planned to develop actual benchmarking tools to compute these S-FoMs over real quantum programs (e.g., Qiskit, Cirq) and define protocols for currently unmeasured metrics.