DocumentationSoftware AuditAudit Consolidation & Risk Scoring

Audit Consolidation & Risk Scoring

How CodeDD synthesizes findings into actionable risk scores

Audit Consolidation & Risk Scoring

Overview

After analyzing thousands of files and identifying hundreds of findings, CodeDD consolidates everything into clear, actionable risk scores. This stage transforms raw data into strategic insights for investment decisions and technical planning.

Consolidation Process

The Code Health Score

After analyzing individual files and repositories, CodeDD consolidates everything into a single Code Health Score (0–100) β€” the primary metric for investment decisions. It is composed of four components, each scored independently and then combined using a weighted debt model:

Code Quality (40% of the Health Score)

  • Overall quality score: readability, consistency, modularity, maintainability, reusability, redundancy, and technical debt
  • Assessed per repository via static analysis and LLM-assisted scoring
  • Reflects how easy the codebase is to understand, change, and extend

Security & Dependencies (30% of the Health Score)

  • Vulnerability counts by severity (critical, high, medium) from dependency and SAST analysis
  • Scored per-repository-average so portfolio size does not distort the result
  • Reflects immediate business risk from exploitable issues

Test Coverage (20% of the Health Score)

  • Average test coverage percentage across all repositories
  • Reflects change risk β€” poorly covered code is harder to safely modify
  • Configurable target coverage threshold (typically 80 %)

Maintenance Indicators (10% of the Health Score)

  • Validated code-quality finding density: confirmed Orange/Red static analysis flags per 1,000 lines of code
  • Reflects accumulated quality debt and the day-to-day burden on the engineering team
  • Scale-normalized, so small and large codebases are judged equally

Scoring Methodology

Vulnerability Severity Weights

Not all vulnerabilities are equal. CodeDD assigns different weights to severity levels when assessing vulnerability exposure:

SeverityWeightTypical examples
CriticalHighest priorityRCE, SQL injection, auth bypass, exposed secrets
HighSignificant riskXSS, insecure cryptography, authorization flaws
MediumModerate riskMissing input validation, outdated dependencies
LowMinorStyle issues, minor refactoring opportunities

Category-Specific Scoring

Code Quality Score

Derived from the Overall Quality Score computed during static analysis, which aggregates:

  • Readability and naming consistency
  • Modularity and separation of concerns
  • Maintainability and cyclomatic complexity
  • Code reuse and redundancy
  • Adherence to language/framework best practices

For older audits where the Overall Quality Score is unavailable, the Technical Debt Score is used as a fallback.

Code Quality Score = Overall Quality Score (0–100)
Code Quality Debt  = 100 βˆ’ Code Quality Score

Security & Dependencies Score

Measures vulnerability exposure normalized per repository, so a large portfolio is not automatically penalised more than a small one. Adding clean repositories improves the score.

Step 1 β€” per-repository averages

avg_critical = total critical vulnerabilities Γ· number of repositories
avg_high     = total high vulnerabilities     Γ· number of repositories
avg_medium   = total medium vulnerabilities   Γ· number of repositories

Step 2 β€” graduated severity penalties

Critical penalty = min(60,  avg_critical Γ— 15)   β†’ fully penalised at β‰₯4 avg critical/repo
High penalty     = min(30,  avg_high     Γ— 4)    β†’ fully penalised at β‰₯7.5 avg high/repo
Medium penalty   = min(20,  avg_medium   Γ— 1)    β†’ fully penalised at β‰₯20 avg medium/repo

Step 3 β€” final score

Security Score = max(0, 100 βˆ’ critical penalty βˆ’ high penalty βˆ’ medium penalty)
Security Debt  = 100 βˆ’ Security Score

Eliminating a single critical vulnerability per repository has an outsized impact compared to clearing medium issues. The score directly reflects prioritisation effort.

Test Coverage Score

Test Coverage Score = average test coverage % across all repositories
Test Coverage Debt  = max(0, 100 βˆ’ average coverage %)

The organisation target coverage (configurable in settings, typically 80 %) affects remediation cost estimates but not the health score itself β€” the score always reflects actual vs. 100 % coverage.

Maintenance Indicators Score

Measures confirmed code-quality issue density per 1,000 lines of code β€” making the metric fair regardless of whether the portfolio has 5 or 500 repositories.

Issue density   = (total confirmed Orange/Red flags Γ· total lines of code) Γ— 1,000
Maintenance Score = max(0, 100 βˆ’ density Γ— 5)
Maintenance Debt  = 100 βˆ’ Maintenance Score

Confirmed flags are static-analysis findings (Orange and Red severity) that have been validated as real issues β€” complex methods, missing error handling, high coupling, redundant code, etc.

Density benchmarks:

DensityScoreAssessment
< 2 issues/kLOC> 90Well maintained
5 issues/kLOC75Acceptable
10 issues/kLOC50Needs attention
β‰₯ 20 issues/kLOC0Maximum debt

Aggregated Metrics

Repository-Level Metrics

Code Health Score (0–100)

The Code Health Score is calculated as 100 βˆ’ Composite Debt Ratio, where the Composite Debt Ratio is a weighted average of four components:

Composite Debt Ratio = (Code Quality Debt  Γ— 40%)
                     + (Security Debt       Γ— 30%)
                     + (Test Coverage Debt  Γ— 20%)
                     + (Maintenance Debt    Γ— 10%)

Code Health Score = max(0, 100 βˆ’ Composite Debt Ratio)

Component weights and what they measure:

ComponentWeightWhat it measures
Code Quality40%Overall code quality across readability, modularity, complexity, and best practices
Security & Dependencies30%Vulnerability exposure normalised per repository
Test Coverage20%Gap between actual test coverage and 100 %
Maintenance Indicators10%Validated code-quality issue density per 1,000 LOC

Why this weighting?

  • Code Quality (40 %) is the broadest signal of long-term maintainability and developer productivity
  • Security (30 %) carries high business risk β€” a single critical vulnerability can have immediate financial and reputational impact
  • Test Coverage (20 %) is a leading indicator of change risk; low coverage means changes are riskier
  • Maintenance (10 %) validates that code quality findings are real and accumulated, acting as a ground-truth anchor

Trend Analysis

For repositories with history:

Velocity Metrics:

  • Lines of code growth rate
  • Commit frequency trends
  • Issue introduction rate
  • Debt accumulation speed

Developer Metrics:

  • Active contributor count
  • Commit distribution (equality vs. concentration)
  • Knowledge silos
  • Onboarding difficulty

Portfolio Aggregation

For multi-repository (group) audits, all component calculations aggregate across every repository in the group:

How aggregation works:

  • Code Quality: LOC-weighted average quality score across all repositories β€” larger codebases carry proportionally more weight
  • Security: Severity counts summed across all repositories, then divided by repository count to produce per-repo averages before scoring. This ensures a portfolio of 60 repositories is judged on the average repository's security posture, not the absolute count
  • Test Coverage: Arithmetic average coverage percentage across repositories with coverage data
  • Maintenance: Total validated flags divided by total lines of code across all repositories β€” a single portfolio-wide density figure

Repository Comparison:

  • Relative rankings within the portfolio
  • Outlier identification (repositories dragging down the portfolio score)
  • Best practices leaders
  • High-risk concentrations

Risk Categorization

Code Health Score Bands

Good (Score: 67–100)

  • Low composite debt across all four components
  • Minimal or zero critical/high vulnerabilities
  • Test coverage above target threshold
  • Issue density below 5 per kLOC

Investor Perspective:

  • Low technical diligence burden
  • Code quality supports valuation
  • Minimal remediation costs
  • Strong technical foundation for growth

Fair (Score: 33–66)

  • Moderate debt in one or more components
  • Some high-severity vulnerabilities (no criticals)
  • Test coverage below target but not absent
  • Issue density between 5–15 per kLOC

Investor Perspective:

  • Standard technical diligence recommended
  • Factor remediation into deal terms or earnouts
  • 3–6 month improvement timeline
  • Manageable risk with a clear plan

Poor (Score: 0–32)

  • High debt across multiple components
  • Critical vulnerabilities present
  • Low test coverage with change risk
  • Issue density above 15 per kLOC

Investor Perspective:

  • Deep technical diligence required
  • Significant remediation investment needed
  • 6–18 month improvement timeline depending on scope
  • Price adjustment or phased investment structure warranted

Executive Summary Generation

Auto-Generated Insights

CodeDD creates executive-friendly summaries:

Key Findings:

  • Top 5 critical issues
  • Recommended immediate actions
  • Long-term improvement areas
  • Investment implications

Positive Highlights:

  • Strengths and best practices
  • Well-implemented features
  • Strong areas of the codebase
  • Competitive advantages

Technology Assessment:

  • Stack appropriateness
  • Scalability readiness
  • Hiring implications (skill requirements)
  • Total cost of ownership factors

Monthly & Aggregate Statistics

Time-Based Analysis

For ongoing monitoring:

Monthly Breakdowns:

  • Commits per month (last 12 months)
  • Issues introduced per month
  • Issues resolved per month
  • Net quality change

Developer Activity:

  • Contribution patterns
  • Expertise growth
  • Team velocity
  • Onboarding success

Domain Statistics

Per-Domain Aggregation:

  • Lines of code by domain
  • Issue density by domain
  • Test coverage by domain
  • Risk concentration

Strategic Insights:

  • Which domains need investment?
  • Where to allocate senior engineers?
  • Refactoring priorities
  • Team structure recommendations

Batch Processing Performance

Consolidation Speed

Typical Processing Time:

  • Small repos (<100 files): 2-5 minutes
  • Medium repos (100-1,000 files): 5-15 minutes
  • Large repos (1,000-10,000 files): 15-45 minutes
  • Portfolio (multiple repos): 30-90 minutes

Operations:

  • Finding deduplication
  • Score calculation
  • Metric aggregation
  • Database writes
  • Report generation

Data Storage

Consolidated Results

What Gets Stored:

  • Overall scores (security, quality, debt, architecture)
  • Finding summaries (no source code)
  • Metric aggregations
  • Trend data
  • Recommendations

Database Structure:

Audit Entity
  β”œβ”€β”€ Overall Scores
  β”œβ”€β”€ Domain Statistics
  β”œβ”€β”€ Monthly Metrics
  β”œβ”€β”€ Finding Summaries
  └── Risk Assessment

Batch Operations

Database Efficiency:

  • Batched writes (100 operations per transaction)
  • Parallel processing where possible
  • Optimistic locking for concurrent updates
  • Retry logic for transient failures

Reporting Formats

Investor Reports

PDF Executive Summary:

  • 2-page overview
  • Key risk indicators
  • Investment recommendation
  • Remediation cost estimate

Detailed Technical Report:

  • Full finding list with evidence
  • Remediation guidance
  • Timeline estimates
  • Resource requirements

CTO Dashboards

Interactive Web Dashboard:

  • Drill-down capabilities
  • Filter by severity/domain/type
  • Export to JIRA/GitHub Issues
  • Team assignment workflows

API Access:

  • Programmatic access to findings
  • Integration with CI/CD
  • Custom reporting
  • Automated monitoring

Key Takeaways

For Investors:

  • Single Risk Number: The Code Health Score (0–100) summarises technical quality into one investment-grade signal
  • Transparent Components: Drill into any of the four components to understand exactly what is driving the score
  • Portfolio-Aware: Security and maintenance scores are normalized per repository β€” a larger portfolio does not automatically score worse
  • Remediation Costs: Estimated fix time and cost help you size remediation as part of deal modelling

For CTOs:

  • Actionable Priorities: Security vulnerabilities are broken down by severity and per-repository average β€” you know exactly where to start
  • Density Thinking: Maintenance is expressed as issues per 1,000 lines of code, making it comparable across repositories of different sizes
  • Improvement Leverage: Eliminating critical vulnerabilities has the highest score impact; reducing confirmed code-quality flags improves the maintenance component immediately
  • Configuration: Quality threshold and target test coverage are configurable per organisation, so the score reflects your standards

Next Steps