Publisher disclosure: Truthlocks is the publisher and a product being compared. Researched and written with AI assistance; reviewed against the primary sources linked below on October 28, 2026. This is a company-authored architectural assessment, not an independent product test.
A signed software artifact can still contain a vulnerable dependency. Conversely, a vulnerability report can be useful even if no portable signed record accompanies it. Kusari and Truthlocks should therefore be evaluated for different jobs: understanding software supply-chain risk and preserving verifiable evidence about records or actions. The word attestation does not make those jobs interchangeable.
Kusari's software supply-chain focus
Kusari currently describes dependency mapping, exploitability prioritization, blast-radius investigation and remediation workflows, alongside pull-request security review. Its positioning connects source and dependency evidence to software risk decisions. This is a specialized software-security proposition, not merely a generic signing endpoint.
For an actual evaluation, request the input formats, source-control and build integrations, SBOM handling and attestation types supported by the proposed deployment. The exact coverage should be demonstrated against your repositories and dependency ecosystems. A broad product description is not proof that every transitive dependency or build artifact is represented correctly.
Truthlocks' broader evidence role
Truthlocks provides signed records and machine action receipts across application workflows. The public receipt example allows a developer to verify a synthetic signature and reject deliberate changes. The public evidence register identifies the limits of scoped hosted checks.
This is relevant to evidence integrity, but it does not demonstrate dependency reachability analysis, vulnerability intelligence or software remediation. A signed assertion that a build passed a check should not be confused with an independent assessment of everything in the build.
Comparison for a software-security team
| Criterion | Kusari | Truthlocks |
|---|---|---|
| Starting input | Software source, dependencies and supply-chain evidence | Issuer records and machine/application assertions |
| Main question | Where is software risk and what should be investigated or fixed? | Does this assertion match accepted signed evidence? |
| Analysis focus | Dependency context and security prioritization | Record integrity and issuer/key context |
| Attestation role | Confirm supported software evidence types during evaluation | Do not assume automatic SLSA or in-toto compatibility |
| Pilot evidence | Known dependency paths and investigation outcomes | Altered payloads, key substitution and status behavior |
Where Kusari may be stronger
If your security team needs to find where a vulnerable package is used and prioritize remediation, a software supply-chain platform is more directly aligned. A generic signed record cannot discover a dependency graph or decide whether an issue is reachable in your application. Those require specialized analysis and current inputs.
Evaluate the graph against known ground truth in a small repository first. Include transitive dependencies, generated artifacts and components introduced during a build. A visually impressive graph is less useful if ownership, versions or deployment associations are incorrect.
Where Truthlocks is a better architectural fit
Truthlocks can fit a broader requirement to issue and verify operational assertions across software and non-software workflows. For example, an engineering approval may need to be referenced by a procurement or governance process that does not consume the full security-analysis system.
Use the receipt workflow or record-verification interface to evaluate that boundary. State exactly what the issuer observed, which artifact was reviewed and which policy applied. Do not claim that the signature itself establishes the artifact is secure.
Example: accepting a release with a known exception
Imagine a team identifies a vulnerable transitive dependency in a release candidate. Security staff determine the affected path is not used in the deployment under review and approve a time-limited exception. The release process needs both the analysis supporting that decision and a traceable approval.
A supply-chain analysis tool is relevant to investigating the dependency and its context. A signed decision record can preserve the approved artifact digest, scope, reviewer and expiry conditions. A later rebuild with a different dependency tree must not inherit the old exception merely because the release name is similar.
This hypothetical scenario does not assert a native Kusari–Truthlocks connector or an audited customer workflow. Integration must bind the decision to an immutable artifact identity and retain the supporting analysis under appropriate access controls.
SBOMs, provenance and evidence semantics
An SBOM describes components; provenance describes aspects of how an artifact was produced; a vulnerability assessment interprets risk; an approval expresses a decision. These records should not be collapsed into one “verified” status. Each can be incomplete, stale or associated with the wrong artifact.
Ask both systems to demonstrate how evidence is bound to the precise build output. Test a changed artifact digest, an outdated SBOM, a forged approval and an expired exception. For software-attestation formats, specify the exact schema and verifier. Compatibility with a standard is not established by using the generic term attestation.
For Truthlocks, verify the signature with an accepted key and inspect supported transparency evidence separately. For Kusari, validate the analysis coverage and the input freshness that support your risk decision. Neither an HTTP success nor a cryptographic PASS means the software has no vulnerabilities.
Operational decision and FAQ
Evaluate Kusari for software supply-chain analysis and prioritization. Evaluate Truthlocks for signed evidence that applications and organizations can check. If both needs exist, connect the analysis and decision records without making either claim more than its evidence supports.
Include access control, retention, integration maintenance and incident response in procurement. This comparison does not establish relative pricing, benchmark performance, legal compliance or independent certification. Request evidence for the exact deployment rather than relying on a category label.
Is signed software necessarily safe?
No. A legitimate signer can distribute vulnerable or malicious code, and an intact artifact can have known defects.
Can Truthlocks replace dependency analysis?
That capability is not established by the reviewed record-verification evidence.
What should an exception record identify?
The specific artifact, applicable policy, scope, supporting evidence and validity conditions, so it cannot be casually reused for a different release.
Explore the comparison collection · Explore Truthlocks for your workflow. Validate required capabilities in a scoped pilot before adopting either product.