Normally, these kind of audits require an executive summary to be disclosed.
While security by obscurity is a universally recognized anti-pattern, it doesn’t mean you have to disclose full details of your vulnerabilities.
Problem 1: the self assessment
I trust the professionality of your DevOps guy. Without having to offend his skills, most external companies demand a reputable third party to perform the security assessment.
Your DevOps guy can be honest and professional, and provide real insights on the security. Or your DevOps guy can be insufficiently educated on security and miss important vulnerabilities. Or your DevOps guy can be a former Volkswagen employee (please, please, allow me some humour sometimes) and pretend there are no vulnerabilities just to make a good impression.
This is why companies demand an external trusted and reputable party
Problem 1.5: the cheap assessment to save money is a clear indicator that this penetration test is unlikely to work, irregardless that it found real security holes.
If you hire a reputable security company, they will do a more thorough test.
Problem 2: what to disclose
In general, these external suppliers/customers want to get an indication of your security levels to have business with your company.
An executive summary (that is, literally, a summary made to be read by high-level executives that don’t work with technical things) contains a list of known vulnerability types associated to a severity score.
It doesn’t contain details on how to exploit those.
Problem 3: mitigation
Please expect the suppliers to demand you to fix high-level vulnerabilities and re-assess the sytem.
Often they require to fix vulnerabilities rated >= 6 or 7, depending on the requirements. And then you will have to go through another scan and confirm the agreed vulnerabilities are not present anymore in the system
Source: I was directly involved in such an activity.
In the past years, we had a code scan from Veracode as requested by one of our US customers before deploying our code on their premises.
Veracode is not a penetration test, it is an automated code static analysis tool. We had real pen-tests but they are out of the scope of this example.
It was part of the contract to share the full report with the customer, as they happened to sponsor the scan.
Later, we had an audit request from a Swiss bank we wanted to have business with, but they didn’t request to perform a security scan, they just demanded that we did and provided an executive summary.
We responded with the front page of that Veracode audit, displaying their logo and our company name. A few pages later, a table showed the list of remaining vulnerabilities (yes, we had, and yes, we fixed high-priority ones!) that were all scored < 6 out of 10. We gave that to our prospect as well.
We knew exactly where our vulnerabilities were, because Veracode highlighted file name and line number of suspect code. We never had to disclose such details to Swiss customer.
I don’t know what happened next, but probably we got the contract. I should ask my Sales Account Manager for details