Certainly, we can make the depiction from GOTS (government) and COTS (commercial) applications. Further, COTS auditing is different from GOTS testing. Below are some quotes from the Application Security and Development STIG.
From the glossary:
Application - Software program that performs a specific function directly for a user and can be executed without access to system control, monitoring, or administrative privileges. Examples include office automation, e-mail, web services, and major functional or mission software programs.
Automated Information System (AIS) Application - For DoD IA purposes, an AIS application is the product or deliverable of an acquisition program, such as those described in DoDD 5000.1. An AIS application performs clearly defined functions for which there are readily identifiable security considerations and needs that are addressed as part of the acquisition. An AIS application may be a single software application (e.g., Integrated Consumable Items Support (ICIS)); multiple software applications that are related to a single mission (e.g., payroll or personnel); or a combination of software and hardware performing a specific support function
across a range of missions (e.g., Global Command and Control System (GCCS), Defense
Messaging System (DMS)). AIS applications are deployed to enclaves for operation and have their operational security needs assumed by the enclave. (Note: An AIS application is analogous to a "major application," as defined in OMB A-130; however, this term is not used in order to avoid confusion with the DoD acquisition category of Major Automated Information System (MAIS).)
Government off-the-shelf (GOTS) - software and hardware products developed and tailored specifically for government agencies by a government agency itself or in cooperation with a external vendor or contractor. These products are developed for redistribution to other government agencies. Custom developed code being developed by an external source, does not automatically qualify as GOTS.
Desktop applications, thick client applications, web services, and web applications are pretty easy to understand and relate to the definitions. However, where does a DLL fit in the mix? I have worked with many vendors that design hardware and software for DoD entities. Typically, the application is written to manage or facilitate use of the hardware. But, how about a DLL that is written as an interface for software and distinct hardware? Does the creation of that DLL fall under the guidance of the Application Security and Development checklist?
This is a discussion we are having with one particular client and I would be interested in thoughts, citations and references for either side of the argument.