• When does it make sense, or is it common to not be given access to security audit resuts/reports when dealing with large companies who use your software?

  • How can a case be made for the benefits of sharing documentation on security gaps, and what are the risks of failing to disclose this information?

Hypothetical Scenario:

The company MediumSizedSoftwareCorp was recently approached by one of its customers, SuperGiantMegaCorp to conduct a security audit of MediumSizedSoftwareCorp's platform (which they use).

The audit was conducted in relative secrecy by a security and compliance team at SuperGiantMegaCorp and managers at MediumSizedSoftwareCorp were informed that their software platform had "failed" the audit. Managers are both companies are in a tizzy because the security issues threaten to derail future contract growth.

Engineers at MediumSizedSoftwareCorp desperately want to remedy the security issues, but SuperGiantMegaCorp will only discuss the vulnerabilities by phone, leaving out specifics and discussing only in vague, general terms. Compounding this is the fact that auditors at SuperGiantMegaCorp refuse to share detailed audit report documents because of the "sensitive" nature of the documents.

This scenario seems antithetical to closing gaps in security. Transparency and cooperation seem like better options, but how does one build an evidence-based case for this?

  • 6
    Unfortunately, I think in the provided scenario, the horse is already out of the barn, and it's very difficult to persuade or compel SuperGiantMegaCorp to change. The better option would be to make MediumSizedSoftwareCorp's permission for SuperGiantMegaCorp to audit contingent upon an agreement to share the results.
    – Jesse K
    Aug 1, 2017 at 16:40
  • 3
    I think Jesse brings up a good point. It also hilights that this isn't really a security problem, it's a business problem. The motivations of SuperGiantMegaCorp may be more political than real security concerns. SuperGiantMegaCorp's in general are often extremely political in nature, and motivations aren't simple or obvious. Aug 1, 2017 at 17:17
  • 3
    For example. SuperGiantMegaCorp may be trying to CYA in some way, or someone in the organization doesn't like MediumSizedSoftwareCorp. To understand it, you'd need to work at SuperGiantMegaCorp. Frankly, just chalk this up the the difficulties of dealing with large corporations, and do as Jesse suggests and make any future audits contingent on sharing results. Some corporations are just notoriously sleazy. Aug 1, 2017 at 17:20

2 Answers 2


Indeed, the situation you describe does not lend itself to speedy resolution of any vulnerabilities found by the mega corp audit. However, beware that may not be the point. Even if the real purpose of the audit is to fix security flaws, there are some reasons that the mega corp can't share specifics.

What other purposes does a security audit have other than fixing security holes? Well, read your contract and think through everyone's motivations. As others have said there may be contractual or political motivations. Off the top of my head:

  1. Mega Corp may want to break or renegotiate your contract, or a contract with someone else. They're using the audit as leverage.
  2. Mega Corp is doing a risk assessment of their product, and they just want to understand what kind of risk your software poses to their business.
  3. Mega Corp is following a rule or regulation that says they need to make regular audits and that's all they've decided to do.
  4. Mega Corp doesn't want to start a paper trail that documents potentially damaging vulnerabilities, or they don't want the paper trail to leave their physical control.
  5. They might be legally prohibited from (or legally concerned about) sharing information from a classified/controlled environment to an unclassified/uncontrolled environment.

They might feel they have legitimate security reasons for not sharing specific vulnerabilities as well.

  1. They might not trust your company and giving you a list of specific test cases will tell you a lot about what kinds of issues they've had in the past, as well as issues they predict to be problems for them in the future.
  2. They might not want you to just fix whatever bugs they found but instead do a more comprehensive review. If they tell you they can slip strings X, Y, and Z through your input validation then you'll be tempted to just fix those specific cases. If they just tell you that your input validation is a piece of crap and to fix it or else you'll lose your contract then your company is going to take a really careful look at the whole software from top to bottom.

What the others have said, this is a business problem, not a technical one. It may be as simple as the fact that MegaCo paid for the audit, and sees no reason to share that info with you. The solution might be as simple as asking who did the audit for MegaCo and see if you can hire them yourself for your own audit.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .