Dustin Decker

The whole diff is never scanned, we use a sliding-window-with-overlap chunker to break up data into more manageable chunks: https://github.com/trufflesecurity/trufflehog/blob/333c4f52961bf1d06d04a82fbdea35a796d102db/pkg/sources/chunker.go#L13-L18 Looks like the default max_mem is 8MB, so i'm guessing...

For now, I suggest trying to set the HTTP_PROXY and HTTPS_PROXY variables to point to burp. You will then be able to see what requests are made for reproduction.

I would recommend starting with 16gb and evaluate your memory usage from there. It really depends on what you are scanning.

> > The end position is determined by taking the minimum of the keyword position + maxMatchLength (set to 300) and the length of the chunk data. > > ......

> > I think we can increase the default to 1024 bytes for the multi-part credential case. Should be adequate in most cases. I'd like to see this optimization on...

Working on Postgres+Metabase integration and K8s deployment in k8s branch

For Capsule8 API stuff it's configurable via a ThrottleModifier when subscribing to events: (use local godocs) http://localhost:6060/pkg/github.com/capsule8/capsule8/api/v0/#ThrottleModifier

libbeat integration add output performance stats, but detailed pipeline engine stats and connection stats are still desired