Explanation of various JSON schema items?

[munntjlx]

I was wondering if the "Finding ID" is invariant across scans, repos, and results in a cardindality of 1:1 with rule types?

[bradlarsen]

Hi @munntjlx, good question.

Finding ID is a content-based identifier that should indeed be invariant across scans, repos, and results. It's computed as the hex-encoded sha1 digest of a content-based rule ID, a NUL character, and the capture groups of the finding:

noseyparker/crates/noseyparker/src/match_type.rs

Lines 194 to 200 in 3ab5860

	pub fn finding_id(&self) -> String {
	let mut h = Sha1::new();
	write!(&mut h, "{}\0", self.rule_structural_id).expect("should be able to write to memory");
	serde_json::to_writer(&mut h, &self.groups)
	.expect("should be able to serialize groups as JSON");
	h.hexdigest()
	}

The content-based rule ID is computed as the sha1sum of the rule's pattern:

noseyparker/crates/noseyparker-rules/src/rule.rs

Lines 96 to 99 in 3ab5860

	/// Compute the content-based structural ID of this rule.
	pub fn structural_id(&self) -> String {
	sha1_hexdigest(self.pattern.as_bytes())
	}

A similar content-based Match ID is also computed (code).

So indeed, these so-called "structural" IDs should be invariant across scans and inputs. They will change when a rule's pattern changes (which is relatively rare).

[bradlarsen]

These structural IDs are used for efficiently grouping equivalent matches together.

I added them a long while back specifically to make it simpler to match up findings from across runs. That's actually a hard problem in general (some static analysis companies hire multiple full-time people to address the problem).