Chunk.Verify is an odd field - it originally conveys whether a source is going to run with verification, but then, at a certain point in the scanning pipeline, is mutated such that it instead indicates whether the chunk should be scanned with verification - which is not solely dependent on the source's verify flag. This is unnecessarily difficult to understand and maintain. This commit separates those two pieces of information into two flags:
- Chunk.Verify has been renamed to Chunk.SourceVerify
- It is no longer mutated; instead "should this chunk's secrets be verified?" is now captured by a new field on detectableChunk
* Added instrumented transport to docker source api calls to include API call metric emissions
* removed once used variable assignment and setting with transport directly
Now you can scan an image directly after building it with docker build by using the docker:// prefix. This is ideal for local development and CI/CD pipelines that want to ensure images do not contain leaked secrets before pushing to an image registry.
This resolves "Add support for scanning images from the Docker daemon" #4275.
This reverts commit 562dd7242b, which reverted the original version of this change that had some issues with its tests that we did not notice until after we merged it.
* optimize chunking
* use file size for Docker
* refactor: update chunk size reference in Jenkins test case
- Changed the reference from sources.ChunkSize to sources.DefaultChunkSize for clarity and consistency in the TestJenkinsVariousSizes function.
- Reformatted struct field declarations for improved readability.
---------
Co-authored-by: Kashif Khan <70996046+kashifkhan0771@users.noreply.github.com>
- Now you can scan an image directly after building it with `docker build` by using the `docker://` prefix.
This is ideal for local development and CI/CD pipelines that want to ensure images do not contain leaked secrets before pushing to an image registry.
- Resolves#4275
Description:
Add support for excluding paths in Docker source scanning:
Add ExcludePaths field to Docker protobuf
Implement path exclusion logic in docker.go
Add comprehensive test coverage for exact and wildcard path matching
Update engine to pass exclude paths configuration
Add CLI support for --exclude-paths flag
The implementation supports:
Exact path matching (e.g., /var/log/test)
Wildcard path matching (e.g., /var/log/test/*)
Multiple exclude paths
Tests ensure proper handling of:
Exact path exclusions
Wildcard exclusions
Edge cases and similar paths
References:
https://github.com/trufflesecurity/trufflehog/issues/2216?utm_source=chatgpt.com
* feat: support docker image history scanning
* refactor: collapse error handling into return
Style suggestion from review feedback.
* fix: associate layers with history entries
Where possible, add the associated layer to the history entry record. This may help tracing any issues discovered.
This also changes the entry reference format to `image-metadata:history:%d:created-by` which _may_ be more self-explanatory.
The previous implementation used int64 for both, which can be mixed up
easily. Using distinct types adds a layer of type safety checked by the
compiler.
* added functionality to scan docker images with digests instead of tags
* cleaned import statement
* added unit test for baseAndTag parsing + remote digest scan
* Implement CommonSourceUnitUnmarshaller
* Add SourceUnitUnmarshaller to all sources using
All sources, with the exception of git, will use the CommonSourceUnit as
they only contain a single type of unit to scan.
* Fix method comments to adhere to Go's style guide
Cody Rose
Nabeel Alam
Kashif Khan
Stephen Aghaulor
ahravandKashif Khan
Tanner Jones
Martin Locklear
Richard Gomez
James Telfer
Miccah
joeleonjr
Dustin Decker