-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exclusion Reasons #202
Comments
@dclayton-godaddy would adding a exclude-signatures=[
"dfg99df8g0d98fg0s9d8fg09d8sfgd90sfg8s0df9" # characters in google doc url
]
exclude-entropy=[
"file1.md::^[a-zA-Z0-9]{40}$" # git sha in a markdown file
] |
@jakeswenson I certainly think that your suggestion is the "good enough" path for now, and that's what I generally do myself. I do also think that @dclayton-godaddy may have hit on a good idea, and this is something I've been ruminating about for some time myself. I've been considering, perhaps with v3.0, switching to a new pattern for exclusion signatures. Something like: exclude-signatures = [
"tartufo:blake2:dfg99df8g0d98fg0s9d8fg09d8sfgd90sfg8s0df9:characters in google doc url"
] The pattern here is the static string This accomplishes a number of things, of varying levels of importance. Some perhaps even mostly useless, but just sound shiny and neat to me. In no particular order:
Of course, I'm sure there are many reasons not to go this route that I haven't thought of yet. And I would love to hear them! |
Agree with all of the goals you've mentioned, however why come up with a custom string format? What about instead just allowing strings or nested TOML objects, like so: exclude-signatures = [
{ match = "tartufo", algo = "blake2", signature = "dfg99df8g0d98fg0s9d8fg09d8sfgd90sfg8s0df9", reason = "characters in google doc url" }
] OR (the beauty of TOML) [[exclude-signatures]]
match = "tartufo"
algo = "blake2"
signature = "dfg99df8g0d98fg0s9d8fg09d8sfgd90sfg8s0df9"
reason = "characters in google doc url" This feels like a better approach to achieve the great goals you've mentioned @tarkatronic What do you think? |
Oh yeah I totally forgot about that. I like that much better. 😄 I'm just wondering... is this becoming an over-engineered solution? Fixing a problem that doesn't exist? |
Hmmm also I think the TOML table syntax makes the first point much harder. The struggle I've had with trying to figure out a fix for #201 is that, in order to effectively solve the problem, we would have to reconstruct the entire history of the config file from git history, and collect all exclusion signatures that were ever configured. If we go with the TOML table syntax, do we run the risk of a similar issue? We can always exclude matches that look like |
Some form of structured signature will be required to version the signature algorithm (efficiently.) So there is definitely a forward-looking benefit to thinking about this. If those are the goals, it would be better to have structure and not require someone to write some fragile string split approach.
Not sure I understand, and maybe this discussion is better had in #201, but are you suggesting it would be an issue to parse every config version? (and thus you're looking for creative ways to avoid it?)
I understand the thinking that a specific string structure lowers the probability of falsely matching a secret. Happy to chat more tomorrow about #201 |
Ideally we run a scan and the results of the scan should output all the information to audit the scan. If the exclusions can read from multiple formats, that would allow the exclusions be in a structured format as well as a string delimited format. |
Fixed in #286 |
Feature Request
Is your feature request related to a problem? Please describe.
It took me a while to generate an exclusion report that explains what is excluded and why. One thing I’d love to see in tartufo is the ability to specify the reason along-side the exclusion and have a report produced that we can easily provide to a security team. When someone adds an exclusion, it might not be front-and-center we need to track the reason until it’s time to create an exclusion report. We need to reverse engineer the exclusions to determine the reason.
Describe the solution you'd like
A reason field along-side any exclusion.
Describe alternatives you've considered
tartufo --json ...
along with manually generating the report.Teachability, Documentation, Adoption, Migration Strategy
Files
Config
The text was updated successfully, but these errors were encountered: