The Difference Between Securing Custom-Developed vs. Commercial Off-the-Shelf Software

Originally published by CrowdStrike.

Modern applications are designed to process, use and store vast amounts of sensitive data. As adversaries seek to infiltrate these applications, IT and security teams must ensure the software they use has the strongest possible security. The first step to implementing strong application security is understanding the type of application you need to protect.

The two types of applications security teams must be familiar with are custom-developed software and commercial off-the-shelf (COTS) software. In this blog, we explain the differences between custom-developed applications and COTS applications and how each type of application is secured.

What Is Custom-Developed Software?

The crucial difference between these two types of applications is who owns the source code — the set of computer instructions that accomplishes some task. Every application is built from source code, and that source code is created by software developers. Modern programming languages you’re likely to encounter in source code include Java, Python, .NET, Node.js and Go.

Custom software consists of proprietary source code, which is typically owned by the developer or company that created it. If you’re interfacing with proprietary source code, then you’re managing custom-developed software — software that is “built in-house” to fulfill a specific business requirement. Companies either sell their custom-developed applications or use them for internal business needs.

Here’s an example. Suppose you work in security at a company called Math Tutors. The company’s developers created the Python code shown below.

def getInt():
  # Get an integer from the user
  return int(input('Enter an integer:'))

def sum(a, b):
  # Add two integers together
    return (a + b)

# Start of program
a = getInt()
b = getInt()

# Show the sum to the user
print(f'Sum of {a} and {b} is {sum(a, b)}')

Customers have purchased version 1.0.0 of your software, and you’re responsible for ensuring the custom-developed Python code is secure.

One day, you realize your “sum” function leaks proprietary data when the user enters a non-integer. Your developers add error handling to the sum function to secure it. The updated source code is shown below.

def getValidInt():
    # Ensure the user supplies a valid integer
    user_value = ''
    while (not isinstance(user_value, int)):
        try:
            user_value = int(input('Enter an integer: '))
        except ValueError:
            print("That's not an integer!")
    return user_value

def sum(a, b):
  # Add two integers together
    return (a + b)

# Start of program
a = getValidInt()
b = getValidInt()

# Show the sum to the user
print(f'Sum of {a} and {b} is {sum(a, b)}')

After securing your custom-developed software, you release version 1.1.0 of your product. When customers purchase your software, it’s their responsibility to upgrade to the latest version, meaning they must now use version 1.1.0 to ensure they’re using the most secure version of your software.

How Are Custom-Developed Applications Secured?

Securing custom software begins before writing the first line of code. Once functional requirements are defined, architects lay out the initial design. The architecture should then go through a threat model where the likely attack vectors are analyzed. After the initial threat model is complete and design changes implemented, software development begins.

Most modern software teams use some form of Agile software development. With Agile development, the software is iterated over time and updates occur on a regular basis. The scope of work is decomposed into stories, which typically include small feature implementations (building a new capability) or bug fixes (fixing problems in existing code). Stories that are not actively being worked on are placed in the backlog. When the security team needs developers to fix a security issue, they create a story that lives in the backlog until the development team is able to resolve the problem.

With the “shift left” approach to security, vulnerable code detection begins during development through software composition analysis (SCA), static application security testing (SAST) and dynamic application security testing (DAST). These tools are effective at isolating unique instances of vulnerable code.

The most challenging aspect of securing custom software is finding the weaknesses that lurk in production. Common issues that plague application security include:

• Unauthenticated APIs
• Unknown sensitive data stores or data flows
• Internet-facing microservices
• Third-party communication

What makes this set of issues particularly challenging is they frequently deviate from the original design. This is why having visibility into what’s deployed in production is essential. When the true architecture is unknown, inferred or outdated, it’s difficult to detect and prioritize security weaknesses. This can lead teams to rely solely on security scanning tools, which tend to provide an overwhelming list of vulnerabilities.

The most effective solution to this problem is application security posture management (ASPM). ASPM provides specific remediation advice based on the real-time status of your software architecture. You not only receive a concise list of the highest priority security weaknesses, but you can also speak clearly to engineering teams about the business impact of vulnerabilities.

What Is Commercial Off-the-Shelf Software?

COTS software is built for commercial use and is readily available for purchase. If you pay for application access but can’t see the source code, you’re working with commercial-off-the-shelf software.

When the application is paid for on a recurring basis, you’re purchasing software as a service (SaaS). SaaS is a revenue model, but the terms COTS and SaaS are often used synonymously.

Now, think back to the Math Tutors example, but this time, imagine you work in security at a different company called Math Learners and you’re using the software that Math Tutors developed. From your perspective, the application is a COTS application. Rather than seeing source code, your view of the application will look like the screen shown below.

When version 1.1.0 of the application is released, your team at Math Learners is responsible for upgrading your systems to ensure the vulnerability is patched and they use the secure version. Even though you don’t notice a visible change, upgrading the version adds security fixes to the software.

Common examples of COTS applications that organizations purchase include Google Workspace, Microsoft Outlook and many others. Each of these applications is considered “custom-developed” by the organizations selling them.

How Are COTS Applications Secured?

Purchasing COTS software introduces several security responsibilities. The steps for initial setup and continuous monitoring are as follows:

• Perform a security review of the COTS vendor and application.
• Provision access to the necessary members of your organization.
• Continuously monitor:
  • Application programming interface (API) connections between internal custom developed applications and the COTS application
  • Individual access permissions and configuration
  • Data transmitted to (and from) the COTS application

From a security perspective, the first step to introducing new COTS software to an organization is to understand the risks. Vendors will not typically share source code, so customers must rely on a limited scope of information. You may consider asking for:

• A recent penetration test
• A software bill of materials (SBOM)
• Documentation on a vendor’s software development lifecycle (SDLC)
• Certifications such as SOC 2 or ISO
• Customer references
• Data access rights in the terms and conditions

Each of these items can give a deeper understanding of the COTS software security posture, but there will always be inherent risk when using another company’s software.

Once the software is approved, the next step is to grant access to the appropriate users. This may be done through role-based access control if entire departments will use the software, or discretionary access control if only certain users need the application.

With access granted, it’s vital to monitor COTS applications continuously. The first area to manage is software-to-software access. This type of access occurs via the APIs that software developers create.

A successful implementation of API management includes an inventory of all API calls to COTS applications. The API inventory should update as software developers create and remove APIs, and note all APIs transmitting sensitive data. ASPM tools automatically generate a comprehensive list of API calls to third-party applications.

Figure 2. A graphical representation of COTS APIs

The second area to manage is user provisioning. Security teams must audit and update user access to COTS applications regularly. Additionally, security teams are responsible for managing the configuration of COTS applications. Both identity access management (IAM) and SaaS security posture management (SSPM) help ensure COTS configurations are correct.

The third area to manage is sensitive data transfer. Detecting and preventing unauthorized data egress requires a data protection solution. The data protection solution should combine content with context to provide deep real-time visibility into what is happening with your sensitive data, including data artifacts, as they move from the source to the destination, which could be COTS applications.

Consider the following scenario, for example

1. A sensitive file is downloaded.
2. The contents are copied to a spreadsheet.
3. Smaller chunks of the data are copied to another sheet and moved to a personal google drive.

Data protection solutions provide the complete flow, along with who performed the actions and where this data landed.