Good callout. Evidence so far points to `nx --version` itself being safe because this was in a post-install script but we changed the rec in our post.
We took the versions in the Github security advisory and compiled it into a Semgrep rule which is MIT-licensed: https://semgrep.dev/c/r/oqUk5lJ/semgrep.ssc-mal-resp-2025-08.... Semgrep rules can be overkill for these use cases but it can be convenient to have a single command to check for all affected versions across multiple packages, especially for our users who already have Semgrep installed. That's basically what I did on all our internal repos.
We updated the blog post to note the Semgrep rule is MIT licensed. And you can run locally with Semgrep (which is LGPL: https://github.com/returntocorp/semgrep) if you curl it and run `semgrep --config=rule.yaml`
And if you don't read the cheatsheets there's something to be said for using a framework that implements most of the stuff by default. For example web2py tends to secure by default for the owasp stuff: http://www.web2py.com/book/default/chapter/01#Security
Personally I think I'm too dumb to implement all that stuff by hand without screwing something up.
The "model" makes reference of the model injection for memcpy.
The modification made by the team is referenced in John's blog post "Their insight is that we might want to consider byte-swap operations to be sources of tainted data".
As Andy said (and quoted), that's a modification that we need to evaluate overall to look at its impact in term of false positives (FP). It will probably be made available however under some options if it doesn't pass our acceptance tests for FP rate though... a bit too early to say.
Thanks, I was just curious if customers could play with these kind of experiments if they understood the FP potential. I really like Coverity's output and always like new ways to tease out potential bugs.
Good callout. Evidence so far points to `nx --version` itself being safe because this was in a post-install script but we changed the rec in our post.
We took the versions in the Github security advisory and compiled it into a Semgrep rule which is MIT-licensed: https://semgrep.dev/c/r/oqUk5lJ/semgrep.ssc-mal-resp-2025-08.... Semgrep rules can be overkill for these use cases but it can be convenient to have a single command to check for all affected versions across multiple packages, especially for our users who already have Semgrep installed. That's basically what I did on all our internal repos.
We updated the blog post to note the Semgrep rule is MIT licensed. And you can run locally with Semgrep (which is LGPL: https://github.com/returntocorp/semgrep) if you curl it and run `semgrep --config=rule.yaml`