SIAX Technology (sax3l)
Repositories
2
 Projects Packages

@siax/sensitivity-scan (0.1.0)

Published 2026-09-16 09:35:08 +00:00 by admin

Installation

@siax:registry=https://git.cloud.siax.io/api/packages/sax3l/npm/
npm install @siax/sensitivity-scan@0.1.0
"@siax/sensitivity-scan": "0.1.0"

About this package

@siax/sensitivity-scan

Read-only, advisory, bounded scanner for a real gap in standard/estate/SIAX_PRODUCT_FIREWALL.yaml: that file is a static, hand-curated snapshot of Simon's 14-name Product Firewall list from 2026-09-02 (see the file's own header). Nothing in the estate ever scanned a repo created — or found sensitive — after that date and proposed it for the list. That is exactly how justit0 (26GB+ active-litigation archive, real PII) and p0lytics (live GDPR Article 9 political-opinion data) sat at the registry's weakest tier (absent = writable=true) until a human sweep found them by hand on 2026-09-14 (see that commit, 557188f, on fix/registry-sensitivity-misclassification). This package makes that sweep repeatable.

What it is not

  • Not a classifier. It never writes to SIAX_PRODUCT_FIREWALL.yaml, never computes a confidence score, never emits a verdict field. It answers exactly one bounded question per repo: does its README, package.json description, siax.repo.v3.json declared fields, or repo-tree paths contain text matching a known sensitivity vocabulary — and if so, what, exactly, matched? Whether that repo deserves Product Firewall protection, and whether "confirmed" or "ambiguous", is Simon's call — the same as it was for f0lk/lag0m/top0/justit0/p0lytics.
  • Not exhaustive. One tree listing per repo, plus README + package.json
    • manifest content. No full-repo grep, no history, no binaries. Silence from this tool means "no signal found in the bounded surface it looked at" — never "verified clean".

Architecture (matches @siax/estate's split exactly)

Two halves, deliberately separable — the same shape as packages/estate/bin/estate-snapshot.mjs / packages/doctor/src/canonical-probe.mjs + siax-doctor canonical:

  • bin/scan-sensitivity.mjs — the one network-touching part. Needs GITEA_TOKEN (or SIAX_CI_TOKEN). Enumerates first-party repos via the same Gitea source @siax/estate's generator uses (createGiteaSource().listAllRepos(), filtered to owner === org && !mirror, byte-for-byte the same filter captureSnapshot() applies), skips every repo already in SIAX_PRODUCT_FIREWALL.yaml and every repo in the fixed NEVER_SCAN_REPOS/NEVER_SCAN_PREFIXES safety list (see below), and bounded-scans the rest. Writes a JSON evidence report (--out).
  • src/scan.mjs / src/signals.mjs — the pure logic, unit-testable against a fake in-memory source (no network in test/).
  • siax-doctor sensitivity (in @siax/doctor) reads that evidence file — it never touches the network itself, exactly like siax-doctor canonical reads canonical-probe.mjs's evidence.

Safety exclusions

NEVER_SCAN_REPOS / NEVER_SCAN_PREFIXES in src/scan.mjs hard-codes the operator's standing "never touch" list (siax/Protosell, justit0, prt-website, b0ts/b0ts-scrapers, pts-*, protosell-*). These repos are never fetched, regardless of firewall-registry membership. justit0 is in this set on purpose even though it is the repo whose omission motivated building this tool: its sensitivity is already documented by hand in SIAX_PRODUCT_FIREWALL.yaml's 2026-09-14 amendment and needs no live re-confirmation that would mean contacting that repo's API endpoint at all.

Signal categories

Three, bilingual (English + Swedish, matching this estate's own docs) — see src/signals.mjs for the full keyword lists:

  • pii — PII-handling terms (personal data / personuppgifter, KYC, …)
  • legal — legal / litigation / evidence terms (litigation / tvist, evidence archive / bevismaterial, compliance, …)
  • gdprSpecial — GDPR Article 9 special-category terms (political opinion, health data, biometric, …)

Plus one structural (non-keyword) signal: a repo whose own siax.repo.v3.json self-declares tier: "product" — which the schema says "runs under Product Firewall discipline" — but is absent from the registry. That was exactly the p0lytics cross-file inconsistency.

Usage

GITEA_TOKEN=… node bin/scan-sensitivity.mjs --out /tmp/sensitivity-scan-report.json
node ../doctor/src/doctor.mjs sensitivity --evidence /tmp/sensitivity-scan-report.json --json

Neither ever fails a build for finding candidates — only for a genuine inability to run (bad token, network down). See packages/doctor/README.md and .gitea/workflows/nightly.yml for how this is wired into the estate's own periodic-check conventions.

Tests

node --test test/*.test.mjs

Fake-source fixtures cover: an obvious-signal README is flagged with real evidence; a clean repo is not flagged; a repo already in the firewall registry is never fetched at all; justit0 is excluded by the fixed safety list even though it is absent from the registry (today's real state); the tier="product" structural signal; an empty repo is reported honestly, not silently marked clean.

Dependencies

Dependencies

ID Version
@siax/estate workspace:*
@siax/write-guard workspace:*
Details
npm
2026-09-16 09:35:08 +00:00
0
UNLICENSED
latest
13 KiB
Assets (1)
sensitivity-scan-0.1.0.tgz 13 KiB
Versions (1) View all
0.1.0 2026-09-16