Would you take a pull-request security scan workflow?

[ralyodio]

Would a pull-request security scan be useful here, or is this already covered?

One workflow. On each pull request it scans the checked-out repository for
hardcoded credentials, injection, SSRF and unsafe deserialisation, and writes
findings to the Security tab. Report-only — findings never fail the build.

Two files under .github/, a pinned @profullstack/threatcrush@0.11.2 whose tarball is hashed before
install, and pull_request rather than pull_request_target.

A pull request is open alongside this with the diff, if reading it is easier
than discussing it.

Disclosure: I maintain ThreatCrush;
MIT and free. Written with AI assistance. Closing this is a fine answer and I
will not ask again.

[alexanderradahl]

Thanks for asking first and for the maintainer disclosure. The idea is useful in principle, and I reviewed the concrete implementation on #7 rather than duplicating the technical discussion here. I requested a much smaller read-only/native-SARIF first pass before we run or merge it: #7 (review)

I’ll keep this issue open while that shape is being worked through.

[ralyodio]

will get back to you in a minute..

[ralyodio]

Understood, and thanks — the review on #7 was specific enough to act on directly,
so I have kept the discussion there rather than splitting it.

#7 is updated to the shape you asked for: contents: read and nothing else,
native SARIF with the converter deleted, one file, 286 lines. Full reply is
#7 (comment).

One thing worth surfacing here rather than only in the diff: two of the six
findings on main are my scanner's false positives, not something for you to
suppress. Both js-uninitialized-buffer hits on the PTY ring are correct code —
the buffer is fully written before it escapes in one case, and unreachable
beyond retained in the other. I am fixing the rule.

No rush from my side, and closing either of these is still a fine answer.