(Sorry about the substantial edit after you apparently already read my comment. Most of the time people don't see it that fast ^^') > at a big US pentest firm

(Sorry about the substantial edit after you apparently already read my comment. Most of the time people don't see it that fast ^^') > at a big US pentest firm I think it'd be hard to do public reports any other way [...] You'd have to let [clients] see the report before you could write a version of the report for the public, so you can scrub out the findings that don't pan out. We do let them see before, also because there is indeed time needed to roll out fixes, but we aren't often asked to make substantial changes (and if they ask, whether we can oblige depends). Sometimes we make a real mistake and then it just looks silly for both parties so that would be removed, but usually things are just factually correct. For example, we can't always know about backports when we see an old version (and PoCs / detailed info is notoriously missing from CVEs, one of my pet peeves), so we recommend they check that the thing is up to date and implement an update procedure if it's not. That advice is valid no matter the actual state. We can mark it as checked and OK as part of a retest (if we got ssh to see for ourselves, or we would write something like "$customer checked and says it was up to date" as the retest description alongside a 'resolved' marker). > Another obvious issue is that reports often include tentative findings, Is this like an int overflow that you're not yet sure is exploitable or so? Or do you have an example of this? I'm not familiar with the concept of a tentative finding unless it's like a little note "this search function at /search.php produces a weird error with input {{1+1}} but I haven't found a useful bug yet, todo investigate more". If it's the latter, we don't report those if we couldn't find anything clearly wrong with it. If it's just not following the spec (HTML entity encoding issues are a common example) but we don't find a security flaw, then it's an informational note at best. Maybe we should be more pushy with these in case it turns out to be exploitable. > the question that started this thread was whether having Google breathing down your neck would make this a hard engagement to deliver, and I think the answer to that is almost certainly "no". I mostly agree there. It's definitely a bit more work with our process because what the test team sends out for internal review is supposed to be basically ready to publish, so they'll do more double checking of the facts before git committing the finding and such. But at the same time, because the routine is almost identical for private and public reports, it's not very special even for big customers that people here would recognize. Is the engagement harder? Slightly, because you don't want to make the firm look stupid by doing something wrong. Does it qualify for the statement "hard to deliver"? Nah, I agree that this answer is "no". > the stressful part of this engagement would be coming up with a report that never gets anything more than a sev:med This. Or even nothing above 'low' if the attack surface is small and the devs are up to date on the relevant security best practices.