Security Score and Verified Fixed

The score starts at 100 and subtracts weighted penalties from detected findings. Severity, confidence, finding status and repeated findings influence the result. It is bounded from 0 to 100.

• Open and acknowledged findings contribute; ignored findings still have a reduced weight.
• Fixed and false-positive findings do not contribute a penalty.
• A high score does not establish complete coverage, compliance or freedom from vulnerabilities. Compare scores only with equivalent scanner scope and successful completion.

A successful fix must apply to the exact source revision, pass patch policy, complete the required scanners, remove the original detected finding and avoid new Critical or High findings in the verification scope. The published tree must match the validated files and an unmerged PR must exist.

• Check the proposed commit, not only the branch name.
• The original finding check matches scanner, rule and file; regression checks compare finding identities within the required scanner results.
• The status does not mean the default branch is fixed, the PR is merged or a deployment has occurred.

In the validated weak-hash example, the initial scan uses Semgrep, Gitleaks and Trivy. Verification uses Semgrep and Gitleaks. A difference between aggregate finding totals would not show how many issues were fixed, because Trivy coverage differs.

Patch policy and syntax checks do not prove business behavior. The worker does not run the repository's test suite or application. Review hash compatibility and run your normal CI before deciding to merge.