Software trust evidence
SOC 2 Evidence for Your Software Dependencies
The problem
A buyer's security reviewer asks how you govern the open-source packages, CI pipeline, and AI agents your product depends on. You have scan output, a few tickets, and an engineer who once decided a finding was acceptable, but no single record that ties the finding to who reviewed it and why. Reassembling that story by hand for every review burns days and still leaves gaps a reviewer can poke at.
Why current tools miss it
Scanners list dependency findings but throw away the human decision made around each one. GRC platforms track org-level policies and questionnaires, not the change-by-change software evidence chain. SBOM tools inventory what you ship without preserving who reviewed a risk or why it was accepted. A public trust center is a marketing surface, not a signed, buyer-checkable record a reviewer can independently inspect.
How OpenSoyce records the evidence
OpenSoyce observes dependency, CI, package, and AI-agent evidence and binds it into a signed evidence packet plus a buyer-readable dossier. It records the human risk decision alongside each finding, including risk-acceptance entries with an owner and an expiry that document the call without resolving the underlying risk. It maps each item to the control area a reviewer commonly asks about, shows gaps instead of hiding them, and posts CI pull-request comments that flag policy attention from the evidence signals. A JSON export API and signed webhook events carry the record into your own systems, and an installed-AI-agent inventory treats your skills and MCP servers as evidence subjects too.
The boundary
OpenSoyce preserves and explains software-trust evidence that may support a SOC 2-style control review. It does not certify, verify maintainers, or decide anything for you. The signature and artifact binding attest integrity and origin, and your policy decides trust.