Skip to content

List each allowlisted value in the masking a report prints - #24

Merged
Manushpm8 merged 1 commit into
mainfrom
allowlist-values
Oct 8, 2026
Merged

Manushpm8 merged 1 commit into
mainfrom
allowlist-values

Conversation

@Manushpm8

Copy link
Copy Markdown
Collaborator

The allowlist landed in #23 and the count stayed at 7 through three clean scans. The file is committed at the repository root, the scan runs after it, and I registered it on the repo pointer through the API as well. So the file is being read and nothing in it matches.

The values were the problem. I generated them from TruffleHog's Redacted field, https://user:********@host/path. ProdSec's own examples mask differently:

values = ["nvs**********************************************6TkI"]
values = [ "76b************************d577" ]
values = [ "pas**********bar\"" ]

Three characters, asterisks for the middle, four characters. A value that does not match what the scanner prints suppresses nothing, which is exactly what we saw.

Each entry now lists both maskings, because I inferred this from the published examples rather than from Pulse's own output for this repository. If one of them matches, the finding clears.

Unchanged: the file paths and the type names, which match ProdSec's documented shape already, and the set of findings, which is still the same six placeholder credentials in the redaction tests.

🤖 Generated with Claude Code

The scan still reported seven secrets with the allowlist in place,
because the values were TruffleHog's own redaction and the scanner
matches on its masking: three characters, asterisks, four characters,
as ProdSec's examples show. A value that does not match the printed one
suppresses nothing. Each entry now carries both forms.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Manush Murali <manushm@nvidia.com>
@Manushpm8
Manushpm8 merged commit 333f415 into main Oct 8, 2026
12 checks passed
@Manushpm8
Manushpm8 deleted the allowlist-values branch October 8, 2026 21:30
Manushpm8 added a commit that referenced this pull request Oct 8, 2026
nSpect reported 7 unverified secrets. #23 allowlisted them and the count
did not move; #24 corrected the value masking and we were about to find
out. This removes the findings instead, which is what the remediation
guide prefers and what leaves nothing to maintain.

None of the seven needed to be a literal.

**Four were documentation.** `transport.py` and the engine's `client.py`
explained credential stripping by embedding
`https://user:token@host/path` in a docstring. They now say it in words.

**The rest are test fixtures**, in the suites that assert this client
strips a credential out of a URL before it reaches a log. Those need a
credential-shaped string, so they keep building one — the password is
interpolated from a module constant rather than written inline. Same
strings at runtime, same assertions.

I checked which forms the scanner actually reads, rather than guessing:

```
'https://user:tok@host/v1'        FLAGGED
f'https://user:{_TOK}@host/v1'    not flagged
f'https://{_USER}:{_TOK}@host/v1' not flagged
```

A full scan of the tree at this commit reports **0 findings**, down from
15, over the same 469 files. So `.nspect-allowlist.toml` has nothing
left to excuse and is deleted.

Suites: client 1928 passed, engine 2500 passed, root 255 passed.

After this merges the repo needs one rescan for nSpect's count to drop
to 0.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: Manush Murali <manushm@nvidia.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant