Those claims are easy to make and hard to verify, especially before a contract is signed. In the short video below, Eric Buck explains why "trust but verify" should be the default posture with any custom software partner, and what we tend to find when we actually put their work under the microscope.
| 0:00 | The challenge of verifying vendor security claims |
| 0:23 | Why trust but verify matters with custom software |
| 0:41 | Finding critical vulnerabilities in vendor-approved builds |
Has your custom application ever been independently tested?
Get in touch to scope a dynamic web application test before your next contract or release.
Eric compares evaluating a software vendor to a job interview. A candidate can give all the right answers to all the right questions, and you still won't know who they really are as a colleague until you've worked alongside them for a while. Custom development partners are the same way. They can describe a secure software development lifecycle, point to certifications, walk you through their internal review process, and still ship an application with serious flaws. By the time the gap shows up, you've already signed the contract.
That's the bind buyers find themselves in. The information you need most is the information you can't easily get before money changes hands.
"Trust but verify" isn't about doubting your vendor's intent. Most development teams genuinely believe their code is secure when they say it is. The point of independent testing is to confirm it.
The way we usually do that is dynamic web application testing. A trained tester sits in front of your running app and tries to break it the way an attacker would. They look at authentication, authorization, business logic, input handling, and access control under realistic conditions. It's a different exercise than the automated scans most dev teams run during the build. Scanners catch the easy stuff. The bigger problems are usually the ones that need a human looking at them.
Some of the clearest examples come from engagements where the vendor had a mature security program in place. They had a documented SDLC. They were implementing accepted best practices. They told the customer everything was fine. And then we found eye-opening critical vulnerabilities anyway. Authentication that could be bypassed. Users who could access other customers' data. API endpoints that were supposed to be internal and weren't.
None of those vendors were lying. They believed what they were saying. They just hadn't seen their own work the way an outside set of eyes would see it. If your applications have never been tested independently, that's the gap worth closing first, ideally before you renew a contract, ship a major release, or hand sensitive data over to a system you've never actually pressure-tested.