Skip to content
UPSTREAM
TRUST CHECK · SELF-ASSESSMENT · AUTOMATED EVALUATION

Free Trust Check.

Know what you use. Verify what you trust.

Seven questions about your software inventory and your evidence. Your answers are evaluated automatically; you immediately receive a one-page Trust Snapshot with up to three evidence gaps and next steps that can be derived from your answers. No call, no code upload, no manual approval.

See an example
Scope
Seven dimensions, a few minutes
Result
Trust Snapshot, shown immediately
Basis
Your self-assessment, not technically verified
Cost
Free, no obligation
WHAT THE TRUST CHECK IS AND IS NOT

Orientation based on your answers. Not a review.

01

Automatically generated orientation

An AI model classifies only your answers and formulates a clearly limited snapshot. Statements without evidence never appear as technically verified.

02

No technical scan

No penetration test, no vulnerability analysis, no security certificate, no statement on CRA conformity and no trust score.

03

Not checked is not secure

Unknown or missing answers are visibly marked as unknown and are not filled in.

04

Separate from the paid assessment

A Trust Assessment with Trust Report is commissioned separately, scoped and delivered with its own quality gates. The free check does not replace it.

Free Trust Check.

A / CONTEXT

Your situation

Please do not enter confidential information, credentials, source code, customer data or files. No personal data is required.

Appears in the snapshot, otherwise “not given”.

B / SEVEN DIMENSIONS

Your self-assessment

Choose one status per question. “Unknown or not checked” is a valid answer. The type of evidence is optional and is recorded as your statement, not verified.

  1. 01Component inventory *

    Is there a reliable component and dependency inventory for the affected release?

  2. 02SBOM maturity *

    Does a current, release-specific SBOM exist, and is it defined who creates and updates it?

  3. 03Vulnerability management *

    Are advisories for affected versions checked, prioritised and tracked?

  4. 04Provenance and integrity *

    Can source, version, build artefact and, where applicable, signatures or hashes be evidenced?

  5. 05OSS governance *

    Are licence review, policies, approvals and responsibilities defined?

  6. 06Responsiveness *

    Are there named owners, escalation paths and a process for critical reports and upstream fixes?

  7. 07Evidence capability *

    Can customers or auditors trace the review status, measures and open risks?

* Required

EXAMPLE

What a Trust Snapshot looks like.

An entirely fictional example with the same structure as your result: header data, key insight, up to three evidence gaps, seven dimensions, next steps and an optional recommendation.

Open fictional example

FICTIONAL EXAMPLEAll details are invented. The example shows the structure of a Trust Snapshot; it is not a real result, not customer data and not based on any AI call.

ALVPHA Trust Snapshot

Company
Example Ltd (fictional)
Date
23/10/2026
Generation
fictional example, no AI call
Snapshot ID
TS-EXAMPLE-0001
Version
snapshot-v1
Scope
Product “Example App”, release 2.4
Trigger
Customer requirement (e.g. SBOM requested)
Role
Technical decision-maker (CTO, engineering)

Method: structured self-assessment with automated AI evaluation.

Evidence status: all details come from an invented self-assessment and are not technically verified.

Overview

KEY INSIGHT

The requested SBOM lacks a link to release 2.4: according to the answers a component list exists, but a release-specific SBOM and bundled evidence do not.

EVIDENCE GAPS DERIVABLE FROM YOUR ANSWERS
  • SBOM maturity: According to the answers there is no SBOM for release 2.4.
  • Component inventory: The component list is not clearly mapped to the release.
  • Provenance and integrity: No information was given on provenance or integrity evidence.

Seven dimensions

All status entries are self-assessments, not independently verified. Unknown or not checked is not evidence.

  1. 1. Component inventory
    Partially evidenced
    Source: fictional answer to question 1; Type of evidence as fictionally stated: „Component list from the build“
  2. 2. SBOM maturity
    Not evidenced
    Source: fictional answer to question 2; no type of evidence given
  3. 3. Vulnerability management
    Partially evidenced
    Source: fictional answer to question 3; Type of evidence as fictionally stated: „Tickets in the issue tracker“
  4. 4. Provenance and integrity
    Unknown or not checked
    Source: fictional answer to question 4; no type of evidence given
  5. 5. OSS governance
    Partially evidenced
    Source: fictional answer to question 5; Type of evidence as fictionally stated: „Draft OSS policy“
  6. 6. Responsiveness
    Evidenced according to self-assessment
    Source: fictional answer to question 6; Type of evidence as fictionally stated: „Reporting address and named role“
  7. 7. Evidence capability
    Not evidenced
    Source: fictional answer to question 7; no type of evidence given

Prioritised next steps

  1. 01No release-specific SBOM — Choose a format (SPDX or CycloneDX) and generate the SBOM in the build for release 2.4.
  2. 02Release mapping unclear — Map the component list to the release and document known coverage gaps.
  3. 03Provenance not stated — Collect existing signature and provenance evidence and record open points.
OPTIONAL RECOMMENDATION

A separately commissioned, paid Trust Assessment with Trust Report can examine the gaps listed for one scoped release. Scope, permissions and price are agreed beforehand.

Fictional example. A real snapshot is automatically generated orientation based on your answers: no technical scan, no penetration test, no security certificate, no CRA conformity guarantee and no statement of freedom from risk. Not checked is not secure.

Start your own Trust Check

A paid, scoped Trust Assessment with Trust Report is commissioned separately and delivered with its own quality gates. Scope, permissions and price are agreed beforehand.