@broberg/secret-scan 0.14.3 → 0.16.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -36,6 +36,25 @@ const { redacted, findings } = redactSecrets("the key is sk-ant-api03-… use it
36
36
  hasSecret("nothing here"); // false
37
37
  ```
38
38
 
39
+ ## CLI — `secret-scan --stdin` (v0.16.1)
40
+
41
+ For a git hook or a CI step, without embedding a script:
42
+
43
+ ```bash
44
+ git diff --cached | npx secret-scan --stdin
45
+ ```
46
+
47
+ Prints `<label> line <n>` for each finding — **never the value** — and exits
48
+ **1** on a finding, **0** when nothing was found, **2** when it could not scan.
49
+ A secret spanning lines (a PEM key) is reported as `(spans several lines)`.
50
+ Same pattern set and defaults as `redactSecrets(text)` (format axis only).
51
+
52
+ v0.16.1 also adds `bearer-token` and `labeled-token-param` (`token=`, `key=`,
53
+ `secret=` …): a value of 24+ characters mixing letters and digits, so
54
+ `Bearer <token>`, `${TOKEN}` and plain words are left alone; and `upmetrics-key`
55
+ now takes 32–64 alphanumerics after `uk_`. The fleet gitleaks config
56
+ (`secret-gate/gitleaks.toml`) carries the same fleet formats (F090.6).
57
+
39
58
  `redactSecrets` is **pure + deterministic**: clean input returns byte-identical
40
59
  with `findings: []`. It replaces every detected secret with `[REDACTED:<label>]`
41
60
  and never blocks the write — the surrounding knowledge survives.
@@ -287,9 +306,17 @@ import { hasPersonalData, findPersonalData, redactPersonalData } from '@broberg/
287
306
 
288
307
  if (hasPersonalData(candidate)) refuse();
289
308
  findPersonalData('tlf 20304050') // → [{ kind: 'phone', start: 4, end: 12 }]
290
- redactPersonalData('Anne 010190-1234') // → { redacted: 'Anne [REDACTED:cpr]', findings: [{ kind: 'cpr', count: 1 }], scanned: ['cpr', 'phone', 'email'] }
309
+ redactPersonalData('Anne 010190-1234') // → { redacted: 'Anne [REDACTED:cpr]', findings: [{ kind: 'cpr', count: 1 }], scanned: ['cpr', 'phone', 'email'], notExamined: ['names', 'addresses', 'health-details'] }
291
310
  ```
292
311
 
312
+ **Both results say what they NEVER look at (0.15.0, F079.6).** `redactSecrets(...).notExamined`
313
+ is always `['personal-data']`: it scans secrets only, and a message full of CPR numbers
314
+ returns `findings: []` from it — correct, and indistinguishable from "clean" until this
315
+ field existed. `redactPersonalData(...).notExamined` is `['names', 'addresses',
316
+ 'health-details']`: «Anne» stays in the example above, because a name cannot be told from
317
+ a word by its shape. **Upgrading:** a consumer that compares the whole result with deep
318
+ equality sees one new field.
319
+
293
320
  - **CPR**: `ddmmyy-xxxx` and `ddmmyyxxxx`, only on a real date. The century
294
321
  comes from the 7th digit, so `290200-4xxx` (2000) matches and `290200-1xxx`
295
322
  (1900) does not. There is no modulus-11 check, because CPR numbers issued