◇ Could this help me?
Yes on the practice, no on the urgency. Scanning repositories for committed secrets and vulnerability patterns is a genuinely valuable habit and the tools for it are cheap to run, so the underlying advice is good. Skip the framing that a free plugin costs nothing to install, since plugin names are easy to imitate and a security tool by definition gets broad access to the code, so confirming the publisher first is the whole safety step. Also note that removing a leaked key from a file does not unleak it, so rotation is mandatory. This is a general practice.
Scan this repository for security problems and report before changing anything: committed API keys, tokens, or other secrets anywhere in the current tree and in git history, hardcoded credentials, unsafe input handling, and dependency versions with known vulnerabilities. For each finding, tell me the severity, the file and line, and whether the value should be treated as already compromised and rotated. Do not install any third-party plugin as part of this. If a dedicated scanner would help, name the exact package and publisher so I can verify it myself first.