When I left PANW in the late 2010s the platform team was still on Python 2.6, I think, and the snippets in this write-up are valid 2.x code. It's very possible that this hasn't been touched in a decade beyond whatever was necessary to get to 3.6, which is itself 2+ years past its shelf date. That's a bigger and slightly more abstract problem than not running a mediocre linter.
Oof. That sounds in dire need of some dev resources.
I disagree with that last bit though. First, I think bandit's more than a "mediocre linter". More importantly, it's a free, open source, CI-friendly app that could be plugged into any reasonably normal build pipeline. It would have caught that. If bandit would have, I'm sure any number of other more advanced tools would too. The equally free ruff checker reports: "S604 Function call with `shell=True` parameter identified, security issue". What I take from that is that there's no reasonable amount of code analysis at all. If they don't even run linters, I'm sure something like mypy is out of the question. Are there unit tests? I don't have confidence of it based on this code alone.
I've tried Bandit on a few codebases and each time it's yielded thousands of false positives and no actual findings. In the best cases it's something like hashlib.sha1, where you should set usedforsecurity=False anyway. That's at least an actionable, if ineffectual, alert. You can make the code clearer, and the warning goes away. But in the worst cases it's something like having a variable named "token" (You idiot! Is that a password in your source?), or constructing SQL queries, which by design may never accept user input but, you know, Bandit can't determine that statically, so it goes ahead and throws an absolute fit anyway.
Conversely, I apply Pylint and mypy aggressively, because what they find almost always should be changed. But Bandit's findings are overwhelmingly wrong in context, so all you can do is litter your code with ignore directives. For reference, in my current codebase of 175k lines, there are 52 Pylint and 66 mypy ignores (with mypy at max strictness). Bandit would need 1,823.
Palo Alto absolutely should do better, but Bandit, or probably any "security" linter, isn't the answer.
I've had a vastly different experience. Filtering only high level and high confidence findings can get rid of lots of chaff.
But regardless, even ruff looks for that specific setting. And even if there were only 2 real findings out of 1,823, if it's in a product that you're selling to enterprise security customers, there's not an excuse for not having had someone look at the results of bandit or something like it and ruling out the false positives. They have $89B worth of reputation to lose with things like this.
I think you're making a base rate error here. To reconfigure your example, if Palo Alto themselves blocked 1,821 good files for every 2 bad files they caught, we wouldn't be having this conversation. Nobody would buy that product. The company wouldn't exist.
Enterprise security is a game that balances protecting the business against letting people get work done. IT giveth, and SECURITY taketh away. If all you care about is the security part, then you can just turn all the computers off and send everyone home. But nobody actually wants that.
To be clear, the very specific case I'm making is:
1) Against Bandit, at a pretty fundamental level, given the kind of tool it is. On the rare occasions I have to silence mypy, it's because there's a bug in mypy. On the frequent occasions I'd have to silence Bandit, it's because that's the nature of Bandit. Ruff is different.
2) That Palo Alto needs a pretty serious shakeup of its engineering culture. I think we agree on this part.
