Software trust evidence
Evidence for software security reviews
The problem
A software security review ends in a decision, but the evidence behind it scatters the moment the meeting closes — a scanner output here, a CI run there, a thread where someone said "we accept this for now." When the buyer, the auditor, or your own team asks six months later why a finding was let through, the reasoning is gone and the original risk is invisible.
Why current tools miss it
Scanners produce findings but throw away the human decision that followed; SBOMs list components without the review context; GRC platforms track control status but not the dependency, CI, and AI-agent signals a reviewer actually weighed; trust centers publish a polished summary that buries what disagreed. None of them keep the original finding and the decision around it side by side, so the record reads as a verdict instead of evidence.
How OpenSoyce records the evidence
OpenSoyce observes the dependency, CI, package, and AI-agent evidence that a review draws on, then records the human risk decision next to it without hiding the finding. It binds each item to its source, surfaces where sources contradict each other as review signals, and packs the result into a signed evidence packet with a buyer-readable dossier. Risk-acceptance entries carry an owner and an expiry and leave the underlying finding standing. A JSON export API, signed webhook events, and CI pull-request comments carry the same evidence — and the signature and artifact binding attest integrity and origin, with the review history recorded for the reader.
The boundary
OpenSoyce preserves and explains the evidence and the decision around it; the verdict stays with you. The signature proves integrity and origin, not that a finding was resolved — your policy decides trust.