Potential impact
What could happen if the underlying issue were exploited: loss of funds, key exposure, code execution, privacy loss, or availability impact.
Transparent by design
How CommitWatch scores changes
Three separate questions: How risky might the change be? How clearly does its public message explain it? And how well does the vendor practice security in public?
A 100-point, evidence-weighted score
The score expresses the security relevance of one public change—not the overall safety of a project. Every point comes from a visible dimension.
Exploitability
Required access, complexity, user interaction, preconditions, and whether exploitation is practical at scale.
Stealth signal
Whether abuse could remain invisible and whether the commit language obscures or clearly states security relevance.
Affected reach
How widely the changed component is deployed and whether vulnerable state persists after a software update.
Classification confidence
How strongly the available commit, diff, tests, issue links, and surrounding context support the classification.
Evidence quality
The directness and completeness of primary-source evidence.
Scores become readable labels
Critical85–100
Immediate, credible risk of catastrophic harm.
High70–84
Serious impact or practical exploitation likely.
Moderate50–69
Meaningful security relevance with limiting conditions.
Low25–49
Defense-in-depth or narrow, hard-to-exploit exposure.
Informational0–24
Security-adjacent change with no credible active risk found.
Can the public history explain the change?
The deterministic 0–100 score evaluates the public commit message—not the code quality, developer skill, or safety of the patch. It is calculated for every captured commit and keeps its reasons and warnings alongside the score.
Baseline
Every message starts at 20 before positive evidence and penalties are applied.
Specific subject and scope
Up to 30 points for a descriptive, concrete subject and 12 for a recognizable type or component scope.
Explanatory body
Context beyond the title earns up to 23 points. Rationale or a described failure mode adds 12 more.
Verifiability
Testing or verification earns 10, issue/advisory references earn 8, and explicit security behavior earns 5.
Opacity penalties
Generic placeholders can lose 45 points, very short subjects 20, two-or-fewer-word subjects 10, and work-in-progress language another 20. The result is clamped from 0 to 100.
80–100
Specific purpose with meaningful supporting context.
60–79
The change is identifiable, though some context may be absent.
40–59
Some purpose is visible, but rationale or evidence is limited.
0–39
The public record does not adequately explain the change.
Opacity is a flag, not a verdict
A message such as “runs” can be poor public evidence even when the patch is harmless. CommitWatch flags the communication gap without adding points to the security-risk score.
Observable practice, not a popularity contest
Five equally weighted dimensions—disclosure quality, researcher acknowledgement, security process, patch clarity, and incident response—are each scored from 0 to 100 and averaged. Missing evidence is not automatically failure; it is labeled insufficient data until a defensible score exists.
The key distinction
A strong product can have weak disclosure practices. A transparent vendor can still ship a flaw. CommitWatch keeps product risk, message clarity, and vendor behavior separate.
Machines publish. Humans strengthen the record.
- 1Capture and score
Fetch the public author string, message, diff, file list, metadata, and verified references. Deterministic triage and message-quality scoring run on every commit.
- 2Analyze and publish
The configured Ollama model produces structured risk dimensions and plain/technical summaries for ranked candidates. Successful output publishes immediately with unavoidable AI provenance.
- 3Challenge
Researchers, vendors, and readers can submit community notes that add evidence, qualify a claim, or identify an error.
- 4Validate and revise
A human moderator validates notes before they appear. Approved context remains visibly separate from raw AI analysis, and material corrections update the public record.
What a commit cannot tell us
Git author names are public strings and may not uniquely identify a person. Message quality measures documentation, not developer competence. A diff is evidence, not omniscience: private reports, unreleased patches, hardware behavior, operational controls, and vendor context may change the conclusion.
Corrections & challenges →