If you’re a CISO, IT director, or procurement lead evaluating a custom software development vendor (or managing an existing relationship with one), this is for you. When the application handles financial data, protected health information, or other sensitive records, accepting a vendor’s security claims at face value isn’t enough.
Every custom software development vendor will tell you they take security seriously. They’re not being dishonest; most genuinely believe it. They’ve built internal practices they trust, hired people they believe in, and shipped products that satisfied their customers' needs.
But belief isn’t evidence.
Security claims are easy to make and extremely difficult to verify before a contract is signed. Much like a job interview, you can ask a candidate all the right questions and they might give you all the right answers, but you won't truly know their qualities or capabilities until you've had a chance to work together. Similarly, the polished responses in a sales cycle don't always reflect what's happening in the codebase.
This matters most when the stakes are high. If your applications handle financial data, protected health information, or other sensitive records, the cost of misplaced trust could be regulatory, reputational, and financial. Custom software vendors are also a specific form of supply chain risk that many security programs don’t assess as rigorously as traditional third-party vendors.
We see this gap firsthand in our web application penetration testing work. Our reports are often eye-opening for clients because we regularly uncover critical vulnerabilities in applications that vendors assured them were secure. Not because those vendors were negligent or dishonest, but because security is a discipline that requires independent validation. Confidence in internal policies and procedures is not a substitute for external verification.
When we help customers with vendor due diligence, there's a long list of security questions worth asking. But one question consistently reveals more about a vendor's maturity than any other:
"How do you handle a vulnerability discovered in production after go-live?"
This question works because it moves the conversation past policy documents and into operational reality.
A mature vendor will answer without hesitation. They'll describe a defined process: a responsible disclosure policy, a severity classification framework, SLAs for remediation timelines, and a clear communication workflow that keeps you informed from discovery to resolution.
A less mature vendor will give you something vague. They'll talk about "handling things case by case" or subtly suggest that some of the remediation burden falls on you, the customer. These aren't necessarily red flags that disqualify a vendor outright, but they do tell you where security falls in their list of priorities.
The vendors who can walk you through their incident response process without scrambling for an answer are the ones worth continuing the conversation with. It’s the same signal that reveals maturity when evaluating any security vendor for your broader program.
Mature vendors run independent pen tests at least annually and after major releases. They won’t share the full report—and shouldn’t—but an executive summary tells you whether critical findings were identified and how quickly they were resolved. A vendor who has never been independently tested, or who claims none is necessary, is a significant concern.
Ask for specific timelines: how long does a critical vulnerability have before it’s remediated? How long for high? Medium? A vendor with a defined SLA treats security operationally. A vendor who answers “as quickly as possible” doesn’t.
Some vendors test their core platform but not custom implementations. Scope gaps are where the risk lives. Confirm that whatever testing they conduct covers the specific application and integrations you’re deploying in your environment.
Static analysis tools are a core tenant of software security and allow for identifying known vulnerability patterns earlier in the development lifecycle. But they only see the code at rest. They can miss entire categories of issues that only surface when the application is actually running. For example, broken access controls or server misconfigurations may emerge when components interact at runtime.
Dynamic testing assesses the live application, probing it the way an attacker would, and catches what static analysis leaves on the table. If a vendor tells you they "run security scans" but can't speak to dynamic testing, there's a meaningful gap in their secure software development lifecycle.
Alternatively, if vendors say they do dynamic testing but can’t speak to how they’ve integrated static reviews into their development lifecycle, there’s cause for concern.
If your vendor-built application has never been independently tested, your confidence in that application relies on the vendor's claims rather than evidence.
A trust-but-verify approach doesn’t require an adversarial relationship with your vendor. It means pairing their assurances with independent validation, so your confidence is grounded in evidence rather than assumption.
For applications handling sensitive data, this means:
Web application penetration testing before go-live and after major changes
Code review for high-risk functionality (authentication, authorization, data handling)
Vendors who welcome external scrutiny are usually the ones with nothing to hide. A vendor that resists or discourages independent testing is telling you something important.
SEVN-X performs web application penetration testing and application security assessments that give organizations independent verification of vendor security claims. We also support vendor due diligence engagements for organizations evaluating third-party software prior to deployment or acquisition. If you’re deploying a vendor-built application and want to verify its security posture before or after go-live, talk to our team.