softwareobservatory 0.3.0 → 0.3.1

package/data/sensors.json

@@ -1,4 +1,5 @@
 {
+  "attribution": "Software Observatory by Justin Abrahms — https://softwareobservatory.com. Licensed CC BY-SA 4.0; adaptations must carry the same license.",
   "families": [
     {
       "count": 9,
@@ -82,6 +83,8 @@
     }
   ],
   "generated_at": "2026-08-24T00:00:00Z",
+  "license": "CC-BY-SA-4.0",
+  "license_url": "https://creativecommons.org/licenses/by-sa/4.0/",
   "sensors": [
     {
       "body_html": "<p>Is the artifact you are about to deploy structurally the one your pipeline\nbuilt? A software bill of materials plus build provenance attestation\n(SLSA-style) answers: these sources, these dependencies, this builder, this\nhash. A structural sensor aimed at the moment of deployment, where the\nartifact leaves the world you control.</p>\n<h2>In practice</h2>\n<p>A reading is two artifacts: the SBOM, and the attestation tying it to\nthe artifact you are about to deploy.</p>\n<pre><code>artifact:   payments-api@sha256:9f1c2b...\nbuilder:    https://ci.internal/builders/release (SLSA level 3)\nbuild:      run 8841, commit a41d2e9, 2026-08-19T14:02Z\nsignature:  verified, sigstore keyless\n\ncomponents:\n  log4j-core        2.14.1  pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1\n  jackson-databind  2.15.2  pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.15.2\n</code></pre>\n<p>Cross-referenced against the vulnerability feed, the same reading says:</p>\n<table>\n<thead>\n<tr>\n<th>Component</th>\n<th>Version</th>\n<th>Finding</th>\n<th>Severity</th>\n<th>Verdict</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>log4j-core</td>\n<td>2.14.1</td>\n<td>CVE-2021-44228, remote code execution</td>\n<td>critical</td>\n<td>block deploy</td>\n</tr>\n<tr>\n<td>jackson-databind</td>\n<td>2.15.2</td>\n<td>no known CVEs</td>\n<td>none</td>\n<td>clear</td>\n</tr>\n</tbody>\n</table>\n<p>Reading it well:</p>\n<ul>\n<li><strong>Verify the signature before reading the contents.</strong> An SBOM you\n  cannot tie to the builder is a claim, not an attestation. The hash\n  comparison is the whole sensor; everything else is commentary.</li>\n<li><strong>Read versions, not names.</strong> Two minor versions can be the\n  difference between clear and critical, and name-only matching misses\n  it.</li>\n<li><strong>Treat &ldquo;not in the SBOM&rdquo; as a finding.</strong> A component present in the\n  artifact but absent from the manifest means the SBOM was generated\n  from the wrong place, usually the source tree instead of the build.</li>\n</ul>\n<h2>Response playbook</h2>\n<p>When the sensor fires:</p>\n<ol>\n<li><strong>Block the deploy on any mismatch.</strong> Unverified signature, hash\n   mismatch, or missing attestation all mean the artifact does not\n   ship. Do not deploy first and reconcile later; the artifact leaves\n   the world you control at deploy time.</li>\n<li><strong>Block on critical vulnerability findings.</strong> A critical CVE in a\n   shipped component is a stop-ship condition. Confirm whether the\n   component is reachable in your build; if it is dead weight,\n   upgrade it anyway, because the next reader of the SBOM will not\n   know.</li>\n<li><strong>Rebuild from the attested source, not from the cached artifact.</strong>\n   A mismatch usually means the build ran somewhere else, or the\n   cache is stale. Re-run the pipeline and compare hashes again.</li>\n<li><strong>Escalate signature failures, not just dependency failures.</strong> A\n   vulnerable dependency is a fix; a bad or missing signature is a\n   possible supply-chain event. Notify security before retrying.</li>\n<li><strong>Record the attestation hash at deploy time.</strong> When a CVE ships\n   next quarter, you need to answer which deployments carry it, from\n   the SBOM, not from memory.</li>\n</ol>\n<h2>What it cannot detect</h2>\n<p>Malice inside the sources themselves, or a compromised builder that signs\nits own output faithfully. Provenance tells you the artifact is the one the\npipeline produced; whether the pipeline was honest is a question for\n<a class=\"body-link\" href=\"/sensors/static-security-analysis/\">static security analysis</a> and dependency\nauditing.</p>\n<p>Supply chain security is a deeper topic than this catalog covers.\nBuild provenance and SBOMs are one sensor in the structural family — they\nverify the artifact matches what the pipeline built — but the broader\npractice of supply chain security (dependency vulnerabilities, artifact\nsigning trust roots, runtime attestation, policy enforcement) deserves its\nown resources. See <a class=\"body-link\" href=\"https://slsa.dev\">SLSA</a> and\n<a class=\"body-link\" href=\"https://sigstore.dev\">Sigstore</a> for dedicated treatment.</p>",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "softwareobservatory",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Query the Software Observatory catalog of epistemic sensors for software correctness. Built for humans and agents: every command emits JSON with --json.",
   "keywords": [
     "observability",