Scoring Methodology¶

Overview¶

Choosing where to focus vulnerability research effort requires balancing many factors: how widely deployed a target is, how much attack surface it exposes, how severe a compromise would be, and how tractable the codebase is for analysis. A purely qualitative approach (gut feel, reputation) introduces bias and is difficult to communicate or reproduce. A purely quantitative approach demands data that is often unavailable or unreliable across heterogeneous software projects.

This framework takes a semi-quantitative middle path. Each target is scored on seven criteria using a simple 1-to-5 scale, with each criterion carrying an explicit weight that reflects its relative importance to security impact. The resulting composite score provides a defensible, comparable ranking without overstating precision.

Scoring Criteria¶

The table below defines all seven dimensions. Each criterion is scored from 1 (lowest relevance) to 5 (highest relevance), then multiplied by its weight.

Total weight: 3 + 1 + 3 + 2 + 2 + 1 + 2 = 14

Criterion Rationale¶

Deployment Scale (3x): The number of installations directly determines how many systems are affected by a vulnerability. A flaw in software running on billions of devices has categorically more impact than one in a niche tool. This criterion receives the highest weight alongside Protocol/Input Exposure.

Cross-Platform Presence (1x): Software that runs across operating systems and architectures broadens the potential attack surface and complicates patching. However, cross-platform presence alone does not make software more exploitable, so it receives a lower weight.

Protocol/Input Exposure (3x): Network-facing software that parses untrusted input is the primary entry point for remote exploitation. This criterion shares the highest weight with Deployment Scale because exposure determines reachability, and reachability determines blast radius.

Privilege Level (2x): A vulnerability in kernel or hypervisor code can lead to full system compromise, while a bug in an unprivileged process may be contained by OS-level isolation. Privilege level shapes the severity ceiling of any discovered vulnerability.

Dependency Footprint (2x): Libraries consumed by thousands of downstream projects (such as OpenSSL or zlib) multiply impact through transitive dependency chains. A single flaw propagates across every project that links against the library.

Codebase Complexity (1x): Large, legacy codebases with complex control flow are harder to audit and more likely to harbor latent bugs. This criterion is weighted lower because complexity affects research tractability more than it affects impact.

Historical CVE Density (2x): A track record of frequent, high-severity vulnerabilities signals ongoing risk and suggests that additional undiscovered flaws are likely. Past CVE density is an imperfect but useful proxy for current attack surface quality.

Composite Score and Priority Tiers¶

The composite score is the sum of all weighted criterion scores:

Composite = (Deployment Scale x 3) + (Cross-Platform x 1) + (Protocol/Input Exposure x 3) + (Privilege Level x 2) + (Dependency Footprint x 2) + (Codebase Complexity x 1) + (Historical CVE Density x 2)

With every criterion scored at 1, the minimum composite is 14. With every criterion scored at 5, the maximum is 70.

Targets are assigned to priority tiers based on their composite score:

Worked Example: curl/libcurl¶

To illustrate the scoring process, consider curl/libcurl, the ubiquitous data transfer library and command-line tool.

Composite Score: 15 + 5 + 12 + 4 + 10 + 4 + 8 = 58 (Critical tier)

curl/libcurl lands in the Critical tier, which aligns with its status as one of the most widely deployed and actively researched open-source projects.

Scoring Workflow¶

The following diagram summarizes the end-to-end process for scoring a target.

flowchart TD
    A[Identify Target] --> B[Score Each Criterion\n1 to 5]
    B --> C[Apply Weights\nto Each Score]
    C --> D[Sum Weighted Scores\nComposite Total]
    D --> E{Assign Priority Tier}
    E -->|55-70| F[Critical]
    E -->|40-54| G[High]
    E -->|25-39| H[Medium]
    E -->|Below 25| I[Low]

Limitations and Caveats¶

This scoring methodology is designed for practical use, not theoretical precision. Several limitations apply:

• Scores are best-effort estimates, not precise measurements. Criteria like "Deployment Scale" and "Historical CVE Density" rely on publicly available data that may be incomplete or outdated. Scores should be treated as informed approximations.
• The rubric is designed for comparative ranking, not absolute assessment. A score of 58 does not have inherent meaning in isolation. Its value comes from enabling consistent comparison across targets scored with the same framework.
• Weights reflect general security priorities and may not apply to every context. An organization focused exclusively on kernel security, for example, might weight Privilege Level more heavily. The weights chosen here optimize for broad vulnerability research prioritization.
• Temporal sensitivity is not captured. A target's score can shift as deployment patterns change, new CVEs emerge, or codebases are rewritten. Scores represent a snapshot and should be revisited periodically.

Applying the Rubric to New Targets¶

To score a target not already covered in this section:

1. Gather baseline data. Identify the software's deployment footprint, supported platforms, input parsing surface, typical privilege context, downstream dependents, codebase size, and CVE history.
2. Score each criterion independently. Use the 1-to-5 anchors in the criteria table as reference points. When in doubt, compare against targets that have already been scored to maintain consistency.
3. Apply weights and sum. Compute the composite score using the formula above.
4. Assign the priority tier. Use the tier boundaries to classify the target.
5. Document rationale. Record brief justifications for each criterion score, as shown in the worked example. This ensures the score is reproducible and can be challenged or updated by others.

When scoring, aim for consistency across targets rather than precision on any single score. The framework's value lies in producing a defensible, comparable ranking across the full set of prioritized targets.

tags: - glossary

Glossary¶