{
  "id": 6772363,
  "title": "Everything is a Trust Decision",
  "url": "https://urgent.news/2026/09/11/everything-is-a-trust-decision",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-11T15:41:04.000Z",
  "source": {
    "name": "Lobsters",
    "slug": "lobsters",
    "url": "https://nrd.sh/blog/everything-is-a-trust-decision.html"
  },
  "original_language": "en",
  "account": "Everything is a Trust Decision\n\nTrust is a fundamental concept that extends far beyond software packages and digital signatures. It is a theorem that applies to any system that keeps a record and seeks validation. In this post, we explore the boundaries of verification, the consequences of what lies beyond those boundaries, and the different types of trust that emerge in this context.\n\nTo illustrate the concept, let's consider a few examples. A lockfile pins the dependencies of a software project, indicating what code has been explicitly chosen and vouched for. A signed commit represents someone's word that the code meets certain standards. A CA root in a trust store is a declaration of trust in a particular entity or authority. Finally, the transitive dependencies of a project, which are often overlooked, are a collection of code that is neither vouched for nor checked.\n\nEvery piece of software can be broken down into parts, each of which falls into one of four categories: closed, vouched for, anonymous, or self-vouched. The closed parts are those for which a re-runnable check has been performed and the results are verified. The vouched-for parts are those that have been confirmed by someone who is trusted. The anonymous parts are those for which no trust has been established or claimed. The self-vouched parts are those that the software itself declares as trustworthy.\n\nThis classification system allows us to understand the nature of trust in software development. Trust is not something that is actively sought after or actively verified. Instead, it is something that emerges from the boundaries of verification. Once the boundary is reached, the remaining parts of the software system are those that are either self-vouched or anonymous. These parts require a different level of trust and must be carefully considered in the design and implementation of software systems.\n\nThe implications of this theorem are far-reaching. It suggests that trust is not a binary concept, but rather a spectrum that can be named, counted, and managed. By understanding the different types of trust and how they propagate through a system, developers can make more informed decisions about how to build and manage their software. This approach can help mitigate the risks associated with software vulnerabilities, supply chain attacks, and other security threats.\n\nIn conclusion, trust is a complex and multifaceted concept that extends beyond the realm of software packages and digital signatures. By recognizing trust as a theorem, we can better understand its boundaries, consequences, and the different types of trust that exist in software development. This knowledge can empower developers to make more informed decisions and build more secure, reliable systems.",
  "summary": "A machine checked proof of the exhaustive boundaries of trust. I'll let the text carry the rest. Comments",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}