+++
title = "Evidence"
description = "Threat models, a self-audited SSDL, requirement-to-code traceability, and SBOMs: the artifacts that let you verify LockWire instead of trusting it."
weight = 5
sort_by = "weight"
+++

A security framework should be judged on artifacts, not adjectives. Every LockWire
repository ships its evidence with the source, so the claim and the code can be
checked against each other:

- **Threat models** — authored, versioned abuse-case matrices, updated with the
  code they describe. Read them before you trust us.
- **A self-audited SSDL** — a secure software development lifecycle based on
  IEC 62443-4-1, targeting the technical requirements of IEC 62443-3-3 and -4-2 at
  Security Level 4. These are engineering baselines we self-assess against in the
  open — not third-party certifications, and we say so plainly.
- **Traceability** — requirement-to-code-to-test records, kept by the same tooling
  (`lockwire-ssdl`) that gates every change.
- **FIPS posture** — cryptography is routed exclusively through AWS-LC FIPS: no
  home-rolled primitives, no curve step-downs.
- **SBOMs** — software bills of materials for every release.

This section explains the artifacts and links to them where they live — in the
repositories — rather than forking them into a second copy that could drift. The
artifacts go public with their repositories as each tier reaches release; their
canonical homes are `github.com/lockwire-org/lockwire`, `lockwire-sec`,
`lockwire-ai`, and `lockwire-ssdl`.