[smu]

I've done more than my fair share of vendor due diligences (and audits, action plans and contract reviews,..)

To me this is a non-issue, because customers almost always ask for types of security checks, not for specific tooling (ie: asking for source code analysis vs asking for veracode). As a rule, compliance/government folks will be concerned about the types of security measures you have in place and not about the specific implementation. Commercial source code analysis tools have varying support depending on language (as others have mentioned: some languages are harder than others). A very valid alternative is to use a linter with security checks (and potential custom rules). The advantage will be that checking will go much faster so you can do it more often (every PR instead of nightly for example). Many security conscious companies have something like this in place.

In general when you're answering security due diligence, it's your job to convince the customer you're going to keep their data safe. They will ask about certain things you don't have and it's your job to explain how you're still solving the underlying problem. Typical example: customers asking for antivirus on all systems and you using (immutable) docker containers.

By the way, the interesting thing here is not the answers to the questions, but how you organise your company to quickly and effectively (as in: no follow up meetings or worse: action plans) answer them. My pet peeve here is "customer guided security": You start from what you think you need (baseline) and you add the security measures that take the longest to explain why you don't have them. That way, you're skating through most of the due diligences and sales velocity goes up, which will make your bosses very happy.

[pc86]

Just as a counterpoint, about 2/3 of the enterprise contracts I've either helped fulfill or reviewed has specified the tool (and sometimes a minimum version but that was only twice out of ~25-30 contracts I've seen). That being said, for the mast majority of those (90%+) the client was very reasonable, and if we had a good reason to remove a specific reference to Veracode, for example, they would probably be fine with it. But I could definitely see it becoming an issue if you just sign the contract to close the deal and try to get out of using Veracode later, especially with whatever the client's internal approvals/review process is.

[masonhensley]

My experience - primarily in healthcare data as a vendor... Employers & Insurance.

Client security teams have been very reasonable on deviations to their massive spreadsheet checklists.

On one hand, I think that if you, as a vendor, reply back with a few "well, we do X instead of Y in the same spirit" they will probably believe & trust your answers more than a spreadsheet returned in 2 hours with "yes/in compliance" for each question.

[tensor]

This is not my experience. I've had buyers push on specific software. E.g. I've had one push back and arbitrary state that we must use "paid" source code analysis vs an open source solution. No reason given. I've had another say that vendor supplied antivirus is not good enough (e.g. Windows Defender or Apple Xprotect). Again, no reason given.

[smu]

That's very interesting! What sectors were those buyers in? I've mostly worked with fortune 5000 and financial institutions.

It doesn't surprise me in the least that you didn't get any feedback. The default option for these companies is to make you accept their specific blend of security requirements... Of course, you then have to support that forever...

I've had good luck setting up a meeting with both the due diligence person and the actual buyer/champion present. It's often easier to explain your stance in person and the buyer is going to stop the due diligence person when he's getting into the weeds.