Fix audit report that verifies a secret

[jpdakran]

Problem:

• When running an audit report on a baseline file - we reverse engineer the detect-secrets starting from secrets hashes, filenames, and how it was detected to the actual secret itself.
• After a recent change - we fixed a bug with respect to detect-secrets not persisting the verify result
• As part of this - we were required to pass context in to the process where we analyze a line of code
• Since we are reverse engineering - we must also update the audit to include the context as part of the analyze_line

Solution:

• Add context (code_snippet) when we analyze a line in the audit process.

[lorenzodb1]

So just to clarify, if this doesn't fix #611, what does it fix?

[jpdakran]

@lorenzodb1 This was uncovered while I was investigating #611. When I was investigating #611 I had some AWS secrets in my baseline. These secrets have a verify on them (We can reach out to an external to verify if they are truly secrets). After a recent change in the scan functionality for a regular scan - we pass in our context to lines we analyze so we can verify them.

Since we are reverse engineering a scan - we should pass the context in to analyze lines for an audit as well. This was not a known issue because context is a parameter for the analyze function with None default. So it worked fine until we hit the verify which occasionally requires a context (depending on the dependency injection).

So when it tried to audit a AWS secret - it was receiving a None context - causing an error.

[abdelrahman-thafeer]

@lorenzodb1 This was uncovered while I was investigating #611. When I was investigating #611 I had some AWS secrets in my baseline. These secrets have a verify on them (We can reach out to an external to verify if they are truly secrets). After a recent change in the scan functionality for a regular scan - we pass in our context to lines we analyze so we can verify them.

Since we are reverse engineering a scan - we should pass the context in to analyze lines for an audit as well. This was not a known issue because context is a parameter for the analyze function with None default. So it worked fine until we hit the verify which occasionally requires a context (depending on the dependency injection).

So when it tried to audit a AWS secret - it was receiving a None context - causing an error.

Good catch there! I'm wondering if we should add or modify a test case to better detect similar issues in the future?