Fixed rule_id being inserted into finding_id field

[andrecsilva]

No description provided.

[drdavella]

Can you explain the reason for this change? This behavior is intentional.

EDIT: fwiw my main objection is with making finding ID optional. If you are concerned about falling back on rule_id then we should just make it an error to not properly populate finding ID

[andrecsilva]

Can you explain the reason for this change? This behavior is intentional.

EDIT: fwiw my main objection is with making finding ID optional. If you are concerned about falling back on rule_id then we should just make it an error to not properly populate finding ID

Finding id is optional as per the codetfv2 spec:

codemodder-python/src/codemodder/codetf/v2/codetf.py

Lines 143 to 145 in 05bbefc

	class Finding(BaseModel):
	id: Optional[str] = None
	rule: Rule

The spec also expects the finding_id to be unique an thus falling back to rule_id may cause problems. Since we expect sarif (and similar formats) to have some unique id (i.e. guid in sarif) the fallback is not really necessary. Honestly, the rule_id fallback seems to be used by internal semgrep codemods, so we can safely ditch it.

I'll implement your suggestion and make it throw an error.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud