Ed25519 and Ed448 generate() rules were matching too broadly

[Arijit429]

Fixes #300

The generate() rules for Ed25519 and Ed448 were using withAnyParameters(),
which caused the scanner to match any .generate() call regardless of parameters.

The actual Ed25519PrivateKey.generate() and Ed448PrivateKey.generate() from
pyca/cryptography take no parameters. So withoutParameters() is the correct matcher.

Reproducer from the issue — this was getting flagged as Edwards448 Key Pair Generation:

generated_ids = self.vlm_model.generate(
    **inputs,
    max_new_tokens=self.max_new_tokens,
)

Changed withAnyParameters() to withoutParameters() in both SIGN_ED25519
and SIGN_ED448 rules in PycaSign.java.

[san-zrl]

You claim to fix #300. This is not quite correct.

When scanning https://github.com/docling-project/docling the original version detects 48 assets all of which seem to be false positives (see dockling-cbom-original.json). All detection relates to a "generate" context.

After applying your PR the scan detects 24 assets (see dockling-cbom-with-pr.json). These findings also relate entirely to a "generate" call on some object.

The reduced the number of FPs tells us

• The fix is correct as it solves some of the observed problems.
• Your PR only partially addresses #300. You must have missed some other detection rules with matching conditions which are too general

If you'd like to continue working on this PR please folllow the advice below. I'm happy to review the next version.

1. Follow the description in the issue on how to reproduce the problem in the issue. Good issues should contain such a description. Apply your PR and verify if your claim to fix the targeted issue is correct.
2. Your PR does not contain any regression tests. In this example it should have test cases for the positive case (finding correctly detected) and the negative case (no false positive).

[Arijit429]

You claim to fix #300. This is not quite correct.

When scanning https://github.com/docling-project/docling the original version detects 48 assets all of which seem to be false positives (see dockling-cbom-original.json). All detection relates to a "generate" context.

After applying your PR the scan detects 24 assets (see dockling-cbom-with-pr.json). These findings also relate entirely to a "generate" call on some object.

The reduced the number of FPs tells us

• The fix is correct as it solves some of the observed problems.
• Your PR only partially addresses Python Scanner generates False Positives #300. You must have missed some other detection rules with matching conditions which are too general

If you'd like to continue working on this PR please folllow the advice below. I'm happy to review the next version.

1. Follow the description in the issue on how to reproduce the problem in the issue. Good issues should contain such a description. Apply your PR and verify if your claim to fix the targeted issue is correct.
2. Your PR does not contain any regression tests. In this example it should have test cases for the positive case (finding correctly detected) and the negative case (no false positive).

Thank you for the detailed review and for running the scan yourself.

You're right — I only looked at Ed25519 and Ed448 but didn't check the
other rules using withAnyParameters(). I'll go through all the Python
detection rules, find the remaining ones with overly broad matching,
fix them, and add the regression tests you mentioned.

Will push an update shortly.