The Code Assurance Index
An open standard for codebase condition.
The Code Assurance Index is a published set of rules for scoring the condition of a codebase from 0 to 100. Software examines the codebase and produces measurements. The CAI rules turn those measurements into a score. CAI is an independent open standard: anyone can read the rules, and the reference program that applies them is open source. Give any conforming implementation the same measurements and the same version of the rules, and it will produce the same score.
What a published score looks like when it arrives:
Why a published standard
The same rules, whoever is asking.
When software is sold, inherited or audited, somebody has to say what condition the code is in. Usually the only person who can is the owner, and their word is the only thing the other side has to go on.
CAI answers that with a number, worked out the same way for every codebase, under rules published in advance. It gives the owner something stronger than their own word, and gives a buyer's adviser, an auditor or a new owner the same measure to read.
The number is the short answer. Behind it, CAI scores ten separate areas of a codebase, each with a reading of its own. An owner can see which area is holding the score down, and a buyer's adviser can see whether the weakness sits where it matters to them.
What the number is made of
A score, the measurements behind it, and the rules used to reach it.
The scale
0 to 100, built from ten broad views of a codebase: how the code reads, how it is put together, how it is tested and released, how it is secured, and more. Five apply to every codebase. Five apply only where they are relevant, and where one does not apply, that is recorded rather than counted as a zero.
The rules
Every rule that turns the measurements into a score is written down and published: what each view looks at, what moves a result up or down, and how the parts are combined into one number. Reading it is how you decide whether you agree with it.
The evidence
The measurements come with the score, and they name the exact version of the code they were taken from. Measure the same project again later and that is a new score, with its own evidence.
Two checks, and one thing they do not settle
Two checks you can run, and one judgement that stays yours.
If somebody hands you a CAI score, two things can be checked without asking them for anything. First, that the file really came from who it says it did, and that nobody has edited it since. Second, that the number genuinely follows from the measurements sent with it. Both checks run here on this site, or on your own computer with a free program that does the same sums.
Redoing the sums shows the number was worked out correctly. It does not show that the measurements behind it describe the code fairly, and the standard does not claim otherwise. That is why the rules are published: anyone who thinks the measuring is wrong can read what it was meant to do and point at the part they disagree with.
The ruler has to hold still
A score means little until you know which version of the ruler produced it.
Change what a good score requires and every score already handed out starts meaning something else. So any change that could move a score for unchanged code becomes a new version of the rules, and every score names the version it was scored under. When a number moves, the record shows why: the code changed, the score was taken under a new version of the rules, or newly disclosed vulnerability data changed a security finding.
A way of scoring that is not in the published rules is rejected before it can ship. There is no private rule to appeal to, so a disagreement lands on something specific: a finding you think was measured wrongly, or a rule you think should not be there. Each of those has its own route.
Every published score carries four things
0 to 100
the score itself
10
broad views the codebase was scored across, with the ones that did not apply recorded as such
Versioned
named on the score, so a number can be traced to the rules that produced it
Signed
so any change made after it was issued shows up
Where scores are kept
A number you can follow back to its record.
A score is handed over as a file that is dated and signed, so whoever receives it can tell that nobody edited it on the way. Those files are kept in a registry, where some are published openly and others are shared only with the people involved. A badge on a project works the same way: it has to link back to the record it claims, or it is decoration.
The same discipline, pointed at the tools
Scanners quote their own false-positive rate. That is the wrong person to ask.
A companion standard, open to any vendor, sets out how to measure how much of what a scanner reports is noise: a sample drawn before anyone runs, one set of verdicts everyone uses, and a result that goes on the record whether it flatters the tool or not. Whoever runs a standard like that also competes in it, which is a conflict of interest, so every safeguard against it is mechanical rather than a promise to behave.
Who controls the ruler
Who decides what the standard says?
Anyone can read the rules and run the program that applies them, and any vendor can publish scores under the standard without asking permission. Deciding what the next version of the rules contains is where that stops: the standard is young and still has a single author. Independent governance is the stated next step, and it has not been built yet.
It says measured, never certified.
A CAI score is a measurement taken under a stated standard. It is evidence you can bring to a decision about security, a purchase or a piece of compliance work, and it stops there: the decision stays with the person making it. Anyone presenting a score as a certificate is claiming more than the standard grants, and the standard says so in writing.
Start from a number, or start from the rules behind it.
If somebody has handed you a CAI score, check it. If you are weighing up whether the standard is worth adopting, read what it asks of you first.