COTS vs. Custom Software: Security Vulnerabilities, Zero Trust, and the Risks Organizations Overlook

COTS vs. Custom Software: Security Vulnerabilities, Zero Trust, and the Risks Organizations Overlook

Convenience Does Not Automatically Mean Security

Organizations often choose commercial off-the-shelf (COTS) software for its established functionality, faster deployment, vendor support, and predictable initial implementation costs.

Software-as-a-Service (SaaS) makes adoption even easier by allowing organizations to access applications without managing much of the underlying infrastructure.

These advantages are valuable, but they can create a dangerous assumption: because a software product is widely used and professionally maintained, it must be more secure than a custom-developed application.

That assumption is not necessarily correct.

Commercial software and custom software both introduce cybersecurity risks. However, the nature of those risks, the organization's ability to address them, and the degree of control available can differ significantly.

A secure software strategy should evaluate more than the vendor's reputation or the number of security certifications displayed on a website.

Organizations should understand their attack surface, software dependencies, vulnerability exposure, access controls, patching responsibilities, and ability to implement Zero Trust principles.

Why Popular Software Can Become an Attractive Target

Commercial software is often deployed across thousands or even millions of organizations.

This widespread adoption creates an economic incentive for cybercriminals.

When attackers discover an exploitable vulnerability in a popular application, the same weakness may exist across many customer environments.

Instead of developing a unique attack for every organization, attackers can exploit a common vulnerability across many installations.

Examples of commonly targeted commercial technologies include:

• Content management systems

• Remote access platforms

• Enterprise resource planning systems

• File transfer applications

• Email servers

• Network security appliances

• Collaboration platforms

• Identity management systems

A vulnerability in a widely deployed product can therefore have consequences extending far beyond one organization.

The larger the installed base, the greater the potential reward for attackers who discover a reusable vulnerability.

However, popularity does not automatically make software insecure. Mature commercial products may also benefit from extensive security research, professional development teams, coordinated vulnerability disclosure, and regular security updates.

The relevant question is whether the organization's security capabilities and the vendor's practices adequately manage the associated risks.

The Shared Vulnerability Problem

One fundamental difference between COTS and custom software is how widely vulnerabilities may be shared across unrelated organizations.

Commercial software commonly uses standardized application components, codebases, interfaces, and deployment patterns.

When a vulnerability affects one of those shared components, multiple customers may need to remediate it before it is resolved.

For example, a vulnerability in a widely used authentication component could potentially affect numerous installations of the same product.

An attacker who understands that weakness may be able to reuse the exploitation technique against other vulnerable installations.

Custom software can have a different exposure profile.

A custom application may contain unique workflows, interfaces, configurations, and security controls that are not replicated across a large customer base.

This can reduce exposure to certain mass-exploitation campaigns targeting a specific commercial product.

However, uniqueness does not replace security.

Custom applications can still contain common vulnerabilities such as SQL injection, broken access control, insecure authentication, cross-site scripting, and vulnerable third-party libraries.

A custom application is not secure simply because fewer people use it.

Security depends on architecture, development practices, testing, maintenance, and operational controls.

Who Controls the Vulnerability Response?

When a vulnerability is discovered, the organization must decide how quickly it can be corrected.

With commercial software, customers often depend on the vendor to:

• Investigate the vulnerability

• Develop a correction

• Test the update

• Release a patch

• Communicate remediation instructions

• Maintain compatibility with existing functionality

For vendor-managed SaaS platforms, the provider may control the entire remediation process.

Customers may have limited visibility into the underlying application or the ability to accelerate remediation.

A vendor might provide temporary mitigations, but customers generally cannot directly modify proprietary source code.

Custom software can offer greater control.

When the organization owns or has appropriate rights to the source code, it may prioritize a security correction, modify vulnerable functionality, restrict an affected interface, or deploy a targeted update without waiting for a commercial vendor's product roadmap.

That flexibility matters most when the application supports mission-critical operations.

However, custom software also places greater responsibility on the organization and its development partner.

Without qualified developers, secure maintenance procedures, and reliable testing, a custom application may remain vulnerable longer than a well-supported commercial product.

SaaS Introduces Shared Responsibility

Cloud-hosted SaaS applications often reduce the customer's responsibility for infrastructure maintenance, operating system updates, and certain application security functions.

That does not eliminate the customer's cybersecurity responsibilities.

Organizations generally remain responsible for areas such as:

• User access

• Account provisioning

• Authentication configuration

• Data classification

• User permissions

• Approved integrations

• Endpoint security

• Data retention settings

• Employee training

The precise division of responsibility depends on the provider and service agreement.

A SaaS vendor may secure the hosting environment, but a customer may inadvertently grant excessive permissions, expose sensitive information, or connect an insecure third-party integration.

Therefore, evaluate security across the entire service, not just the infrastructure the vendor manages.

Third-Party Dependencies Expand the Attack Surface

Modern applications rarely operate independently.

Both commercial and custom software may rely on:

• Open-source libraries

• External APIs

• Authentication providers

• Cloud infrastructure

• Payment processors

• Database technologies

• Software development frameworks

• Monitoring platforms

• Third-party integrations

Each dependency introduces potential risk.

A vulnerability in a third-party component may affect an application even when the organization's own code is functioning as designed.

COTS customers may have limited visibility into the vendor's complete software supply chain.

Custom software can provide greater transparency when development agreements require documented dependencies, source code access, vulnerability scanning, and software bills of materials.

However, custom development does not eliminate supply chain risk. It simply gives the organization more direct oversight.

Organizations should evaluate how dependencies are identified, monitored, updated, and replaced regardless of the software model selected.

Zero Trust Changes How Software Security Should Be Evaluated

Traditional network security often assumed that users and systems inside an organization's network could be trusted more than external connections.

Zero Trust challenges that assumption.

NIST SP 800-207 describes Zero Trust as an approach that does not grant implicit trust based solely on network location or asset ownership. Authentication and authorization are evaluated before access to protected resources is established.

Under Zero Trust principles, organizations should not automatically trust a user, device, application, or service simply because it is already connected to the network.

Instead, access decisions should consider identity, authorization, device condition, resource sensitivity, and applicable security policies.

Zero Trust is not a product you can simply purchase and install.

It is an architectural and operational approach to controlling access and limiting the consequences of compromise.

How Zero Trust Applies to COTS Software

Commercial applications can support Zero Trust when they provide the necessary security capabilities.

Important features may include:

• Integration with enterprise identity providers

• Multi-factor authentication

• Role-based or attribute-based access controls

• Granular permissions

• Centralized logging

• Session management

• API authorization

• Device-aware access policies

• Administrative activity monitoring

However, not every COTS product provides the same level of control.

Some products reserve advanced security capabilities for higher-priced subscription tiers.

Others may offer only broad user roles, limited logging, or restricted integration with external security systems.

An organization may find that the software meets its functional requirements but cannot support the access-control policies its security architecture requires.

This creates a difficult choice: accept the limitation, purchase a more expensive license, introduce compensating controls, or replace the application.

Evaluate security requirements before purchasing the software, not after deployment.

How Zero Trust Applies to Custom Software

Custom software lets you design security controls around the organization's actual requirements instead of adapting business operations to predefined vendor permissions; developers can design access controls around specific users, roles, workflows, data classifications, and operational needs.

For example, a custom application can be designed so that:

• Employees access only the records required for their duties.

• Supervisors approve sensitive transactions.

• Administrators have separate privileged accounts.

• Applications authenticate before accessing APIs.

• Sensitive data is restricted by role or attribute.

• Security-relevant actions are logged.

• Access can be revoked centrally.

• Critical transactions require additional verification.

These controls can be integrated into the application architecture rather than added later.

However, implementing Zero Trust correctly requires expertise.

Poorly designed custom authorization logic can create serious vulnerabilities. Organizations should use established identity standards, proven security components, independent testing, and disciplined change management.

Custom development offers flexibility, but that flexibility must be supported by secure engineering practices.

Least Privilege Is Easier When Requirements Are Clearly Defined

Least privilege is a foundational security principle.

Users, applications, and services should have only the access they need to perform authorized functions.

COTS applications frequently use predefined roles such as:

• Administrator

• Manager

• Editor

• Standard User

• Viewer

These roles may be sufficient for many organizations.

However, specialized operations may require more granular access.

For example, a government contractor may need a user to update a project's schedule without viewing contract financial information.

A healthcare organization may need employees to access certain operational records without exposing unrelated patient information.

A custom application can be designed around those distinctions.

The advantage is not that custom software automatically implements least privilege more effectively. Instead, the organization can define the exact permissions required rather than relying exclusively on the vendor's available roles.

A Larger Feature Set Can Mean a Larger Attack Surface

Commercial applications are frequently designed to serve many industries and business models. To appeal to a broad customer base, vendors may include extensive functionality. An organization might purchase a platform containing:

• Messaging

• File sharing

• Automation

• External integrations

• Public forms

• API endpoints

• Customer portals

• AI assistants

• Reporting services

• Administrative tools

Even when an organization uses only a small portion of these features, unnecessary functionality can increase complexity and create additional configuration responsibilities.

Some unused features may be disabled or isolated. Others remain part of the application environment.

Custom software can be designed to include only the capabilities the organization requires.

A smaller, well-defined application may present fewer exposed interfaces and reduce the number of components that must be maintained.

However, fewer features do not guarantee fewer vulnerabilities. A small application with poor authentication or unsafe database queries can be more dangerous than a complex, well-engineered commercial platform.

The goal is to minimize unnecessary functionality while maintaining strong security controls.

Security Patches Can Introduce Operational Risk

Software updates are essential, but they can also affect operations.

A commercial vendor may release an update that changes:

• Application behavior

• User interfaces

• API compatibility

• Integrations

• Authentication requirements

• Reporting functionality

For SaaS applications, customers may have limited control over the deployment schedule.

An organization may need to adjust internal procedures or connected systems after a vendor introduces changes.

Custom software can provide greater control over release planning, testing, and deployment timing.

Organizations may schedule changes around operational requirements, conduct regression testing, and coordinate releases with stakeholders.

That control should not excuse delaying critical security patches.

A secure change-management process must balance operational stability with timely vulnerability remediation.

The Security Cost of Vendor Lock-In

Vendor lock-in is often discussed in terms of subscription pricing and data portability.

It also has cybersecurity implications.

An organization may become dependent on a platform that no longer satisfies its security requirements.

Possible concerns include:

• Limited audit logging

• Inadequate access controls

• Slow vulnerability remediation

• Unsupported integrations

• Insufficient data protection

• Unacceptable hosting arrangements

• Changes to vendor security practices

Migrating away from the platform may require significant effort because employees, workflows, databases, and integrations have become dependent on it.

Organizations should evaluate exit strategies before adopting mission-critical software.

The ability to retrieve data, transition users, replace integrations, and discontinue a service is an important part of technology risk management.

Custom Software Has Security Risks Too

Custom software should not be presented as inherently more secure than COTS.

A poorly developed custom application can introduce serious vulnerabilities, especially when security is an afterthought.

Common problems include:

• Insecure authentication

• Excessive user privileges

• SQL injection

• Cross-site scripting

• Insecure APIs

• Weak encryption

• Hardcoded credentials

• Unpatched dependencies

• Inadequate logging

• Missing security testing

Custom software also requires continued maintenance.

If the original developer leaves, documentation is incomplete, or the organization does not fund ongoing support, vulnerabilities may remain unresolved.

The security advantages of custom software depend on disciplined development, documentation, testing, and operational governance.

Secure Development Must Be Part of the Contract

Organizations purchasing custom software should establish security requirements before development begins.

The contract and project requirements should address:

• Secure coding standards

• Threat modeling

• Authentication and authorization

• Data encryption

• Dependency management

• Vulnerability scanning

• Code review

• Penetration testing, where appropriate

• Configuration management

• Security documentation

• Incident response

• Patch management

• Source code rights

• Maintenance responsibilities

NIST's Secure Software Development Framework, SP 800-218, provides practices that organizations can use to reduce vulnerabilities and improve software development security.

The framework can also help organizations evaluate commercial software suppliers' security practices.

Security should be a contractual deliverable, not an assumption.

Comparing COTS and Custom Software Security

Neither approach wins every category.

The better choice depends on the organization's requirements, available resources, risk tolerance, and ability to maintain the selected solution.

Security Requirements Should Come Before Product Selection

Organizations should document security requirements before evaluating commercial software or commissioning custom development.

Important questions include:

1. What information shall the system process?

2. How sensitive is that information?

3. Which users and systems require access?

4. What authentication methods are required?

5. How granular must permissions be?

6. Which security events must be logged?

7. What third-party integrations are necessary?

8. Who is responsible for vulnerability remediation?

9. How quickly must critical patches be deployed?

10. What happens if the vendor or application becomes unavailable?

11. Can the system support the organization's Zero Trust architecture?

12. How shall security controls be tested and maintained?

These requirements help prevent organizations from selecting an application that satisfies functional needs while creating unacceptable security limitations.

Total Cost of Ownership Includes Security

Software costs should include more than licenses, development, and hosting.

Organizations should also consider:

• Security assessments

• Vulnerability management

• Monitoring

• Identity integration

• Compliance support

• Patch testing

• Incident response

• Backup and recovery

• Employee training

• Vendor oversight

• Security-related upgrades

A low-cost SaaS application may require expensive add-ons to meet enterprise security requirements.

A custom application may provide the required controls without recurring per-user security licensing, but the organization must still fund development, testing, monitoring, and maintenance.

The correct financial comparison considers both security capabilities and the long-term cost of maintaining them.

How SingTone Technologies Can Help

SingTone Technologies helps government agencies and commercial organizations evaluate, develop, modernize, and manage technology environments with cybersecurity governance and operational requirements in mind.

Our capabilities include:

• Custom application development

• Cybersecurity governance

• Security requirements documentation

• Configuration management

• Database administration

• IT modernization

• Project management

• Quality assurance and testing

• Technical documentation

• Policy and procedure development

• Cloud and hosting solutions

• Ongoing application support

We shall work with organizational stakeholders to evaluate functional and security requirements, identify technology risks, assess commercial and custom alternatives, and develop solutions aligned with operational needs.

When commercial software meets the organization's requirements and security expectations, it may be the appropriate choice.

When standardized applications introduce unnecessary exposure, restrict critical access controls, limit integration, or prevent the organization from implementing required security policies, custom development may provide greater flexibility and control.

The Best Software Is the Software You Can Secure and Control

Don't base the decision between COTS and custom software solely on purchase price, deployment speed, or the number of available features.

Cybersecurity requires organizations to understand what they are deploying, which vulnerabilities may affect it, who controls remediation, and how access to sensitive resources shall be protected.

Commercial software benefits from established development resources and widespread security research, but shared vulnerabilities and vendor dependencies can introduce significant risks.

Custom software can provide greater architectural flexibility, tighter alignment with business requirements, and more direct control over security decisions. Those benefits depend on secure development and continued maintenance.

Zero Trust provides a useful foundation for evaluating both approaches.

Do not assume a system is trustworthy because it comes from a major vendor. Do not assume a custom application is trustworthy because it was developed specifically for your organization.

Require every application to demonstrate that it can protect data, enforce appropriate access, support monitoring, and remain secure throughout its lifecycle.

At SingTone Technologies, we believe software should support an organization's operational and security requirements—not force the organization to compromise those requirements to fit the software.