This is a very interesting topic for auditors as well as devs. When you are conducting an audit, you will find different sort of issues, while there will be issues that need to be fixed under all circumstances, there will also be some issues that do not need an immediate fix.
With the time, I've developed a good sense on what issues should be fixed and what issues must not be immediately fixed. Sometimes there are low severity issues which have an impact on the broader scope, these should be fixed because if the stars align, this could further escalate.
Then there are issues that have a limited impact on the broader context.
So what do you recommend as the auditor?
Obviously, the best solution would be to have a perfect contract and while I often see companies/auditors that write a perfect fix examples, it is not rare that these fixes will introduce other side-effects.
(Let alone the fix example is flawed, I just heard of that case a few weeks ago)
Think about the following: You recommend a fix, this fix works perfectly fine for the context of the issue. However, this fix may have an unexpected impact in some other call path or on another scenario.
(Surprise: If you are the one that developed/recommended the fix you will always have bias and potentially blind spots)
So in the best case you have fixed an issue which did not expose a big problem and in the worst case you have introduced a new bug no one thought of.
With all these years auditing and the experiences I have made with different developers, I came to the conclusion that its sometimes better to choose the path of least resistance and just recommend to acknowledge an issue if I identify its impact as limited.
With the time, I've developed a good sense on what issues should be fixed and what issues must not be immediately fixed. Sometimes there are low severity issues which have an impact on the broader scope, these should be fixed because if the stars align, this could further escalate.
Then there are issues that have a limited impact on the broader context.
So what do you recommend as the auditor?
Obviously, the best solution would be to have a perfect contract and while I often see companies/auditors that write a perfect fix examples, it is not rare that these fixes will introduce other side-effects.
(Let alone the fix example is flawed, I just heard of that case a few weeks ago)
Think about the following: You recommend a fix, this fix works perfectly fine for the context of the issue. However, this fix may have an unexpected impact in some other call path or on another scenario.
(Surprise: If you are the one that developed/recommended the fix you will always have bias and potentially blind spots)
So in the best case you have fixed an issue which did not expose a big problem and in the worst case you have introduced a new bug no one thought of.
With all these years auditing and the experiences I have made with different developers, I came to the conclusion that its sometimes better to choose the path of least resistance and just recommend to acknowledge an issue if I identify its impact as limited.
