Had a chat with @erik-krogh, I'll for now not model streaming APIs. We might choose to do that later.

left to be done:

• implement getResults for rest of DBs. DONE
• query new results on lgtm to evaluate how noisy those sources will be.
• bring test up to current idiom (using comments on lines that should be found). DONE
• performance evaluation. (ACTIVE)

• query new results on lgtm to evaluate how noisy those sources will be.

I've now used lgtm to select all database accesses.
Octobox and strider are the projects with the highest number of database accesses. I've downloaded those locally and am running my changes against them. The result is that there's on average < 1 result per database access (because some database accesses, like data deletions or updates, do not use a result at all).

This means that there's no surprises. Does that make sense to you, @erik-krogh?

This means that there's no surprises. Does that make sense to you, @erik-krogh?

That makes sense to me.
I also took at look at your evaluation where you added these DB reads as taint sources.
Performance seems to be within the margin of error.

But the 4 new results all look like FPs to me.
So I think it's the right decision to have the new source as a heuristic source.