SOFTWARE SECURITY DISCOVERY

Abstract

Systems and methods are disclosed for software security discovery. In certain embodiments, a method may comprise executing a third party software security discovery system, including scanning a directory of a client computing system for executable code, and identifying a service request within the executable code. The method may further comprise decomposing the service request into constituent parts, including a target entity of the service request, and generating a catalog of the client computing system, including third party vendors for the client computing system, based on the target entity.

Description

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority to pending U.S. provisional patent application, Application No. 63/326,402, filed Apr. 1, 2022, entitled “SOFTWARE SECURITY ANALYSIS”; to pending U.S. provisional patent application, Application No. 63/314,069, filed Feb. 25, 2022, entitled “SOFTWARE SECURITY DISCOVERY”; and to U.S. provisional patent application, Application No. 63/298,416, filed Jan. 11, 2022, entitled “SOFTWARE SECURITY EVALUATION”, the contents of which are hereby incorporated by reference in their entirety

SUMMARY

In certain embodiments, a method may comprise executing a third party software security discovery system, including scanning a directory of a client computing system for executable code, and identifying a service request within the executable code. The method may further comprise decomposing the service request into constituent parts, including a target entity of the service request, and generating a catalog of the client computing system, including third party vendors for the client computing system, based on the target entity.

In certain embodiments, a system may comprise a processor configured to implement a software security discovery process, including: perform a scan on a directory of a client computing system for executable code, identify a service request within the executable code, and decompose the service request into constituent parts, including a target entity of the service request. The processor may further generate a catalog of the client computing system, including third party vendors for the client computing system, based on the target entity.

In certain embodiments, a memory device may store instructions that, when executed, cause a processor to perform a method comprising executing a software security discovery system to generate a catalog of components of a client computing system. The software security discovery system may include identifying a third party vendor for the client computing system based on a target entity of a service request from the client computing system, determining an executable code library of the client computing system, determining an operating system (OS) library of the client computing system, and generating the catalog to include the third party vendor, the executable code library, and the OS library.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a system configured for software security discovery, in accordance with certain embodiments of the present disclosure;

FIG. 2 depicts a flowchart of an example method for software security discovery, in accordance with certain embodiments of the present disclosure; and

FIG. 3 is a diagram of a system configured for software security discovery, in accordance with certain embodiments of the present disclosure.

DETAILED DESCRIPTION

In the following detailed description of certain embodiments, reference is made to the accompanying drawings which form a part hereof, and in which are shown by way of illustration of example embodiments. It is also to be understood that features of the embodiments and examples herein can be combined, exchanged, or removed, other embodiments may be utilized or created, and structural changes may be made without departing from the scope of the present disclosure.

In accordance with various embodiments, the methods and functions described herein may be implemented as one or more software programs running on a computer processor or controller. Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays, and other hardware devices can likewise be constructed to implement the methods and functions described herein. Methods and functions may be performed by modules or nodes, which may include one or more physical components of a computing device (e.g., logic, circuits, processors, etc.) configured to perform a particular task or job, or may include instructions that, when executed, can cause a processor to perform a particular task or job, or any combination thereof. Further, the methods described herein may be implemented as a computer readable storage medium or memory device including instructions that, when executed, cause a processor to perform the methods.

FIG. 1 depicts a diagram of a system 100 configured for software security discovery, in accordance with certain embodiments of the present disclosure. The system may include a security analysis service provider (SASP) 102, one or more third party software or service vendors 104, one or more cloud service providers 106, one or more client systems 108, and a network 110 over which the components may communicate and exchange data. Each or any of SASP 102, third party vendors 104, cloud service providers 106, and client systems 108 may be implemented via computers, servers, hardware and software modules, or other system components. Software developed or distributed by the third party vendors 104 may be stored or executed at cloud service providers 106 or client systems 108 as part of the software code base for a client's business operations.

Businesses may rely on complex technology ecosystems to operate their business transactions and manage data. These ecosystems may include a digital supply chain involving multiple client computers and servers 116 and 118 (generally, “client machines”), third party software from third party vendors 104, cloud hosting services 106, and data traffic across one or more networks 110 for communication between these components. For example, client systems 108 may include a collection of networked or stand-alone computers and servers 116, 118 operating as user workstations or backend servers running the business' production code for websites, CRM (customer relationship management), etc. Cloud service providers 106 may host software or data for the client business, including hosting websites or databases of records. The third party vendors 104 may provide software for installation or execution at other components (e.g., at cloud hosting systems 106 or client systems 108), may provide cloud-based software-as-a-service (SaaS), and may receive data from, e.g., client systems 108 or cloud service providers 106 for storage or processing. The data that is exchanged between any of the components of system 100 may be proprietary information, personally identifiable information (PII), financial transactions, or any number of other forms of data that may be valuable, sensitive, or subject to industry or legal regulations and requirements, such as HIPAA (Health Insurance Portability and Accountability Act), GDPR (General Data Protection Regulation), CPRA (California Privacy Rights Act) and CCPA (California Consumer Privacy Act), FedRAMP (Federal Risk and Authorization Management Program), PCI (Payment Card Industry) standards, or other data protection regulations.

Due to the complexity of the business technology environment of system 100, it can be difficult for a business to ensure that the components and data traffic are secure and comply with regulatory requirements, and that data is only going to the proper external entities. The system 100 may include numerous software elements using source code and libraries that may be out-of-date or contain vulnerabilities. Due to the often transparent workings of software and components of the technology environment, a business may be providing information to external parties in an unsecured manner, transmitting data that should not be provided to external parties, or providing data to parties that the business does not expect or know about, without even being aware of it. Performing a manual audit of a business ecosystem or supply chain may be extremely difficult, time-consuming, and prone to errors, and infeasible to perform on a constant basis.

Accordingly, a security analysis service provider 102 may implement systems and methods to catalog a business' software ecosystem, monitor data traffic, identify vulnerabilities and security risks, and to generate advice regarding remedial actions based on the overall system analysis. The SASP 102 can produce a comprehensive system catalog of all software components of a client's digital supply chain or software ecosystem, their vulnerabilities, and their interactions. For example, an enterprise business 108 may transfer sensitive customer information to third party vendors 104 for analytics, security, logging, alerting, storage, etc., in a manner that can cause violations of GDPR and CCPA compliance. The SASP 102 can provide digital supply chain management, security, and auditing to identify the sources and causes of such compliance violations and unsafe data practices, enabling the business 108 to update or replace the non-compliant components.

The SASP 102 can identify, secure, and audit the software building blocks of a company's web services. The SASP 102 can identify what pieces are third party, and can catalog every interaction between a business and its vendors. Based on scanning and monitoring the software and communications of a business, the SASP 102 can provide a real-time data flow diagram, as well as generating a catalog of components and their interactions, sometimes referred to as a software bill of materials (SBOM). The SASP 102 can ensure a privacy-focused chain of custody for customer information, and prevent unintentional compliance violation of GDPR, CCPA, FedRAMP, PCI, or other standards and regulations. The SASP 102 can risk-score each vendor based on the importance and quantity of customer data being exchanged. The software security evaluation provided by the SASP 102 may be implemented or executed without requiring agents installed on client machines used to run the business' production code, changes to DNS (domain name system) configuration, or modifications to existing CI/CD (continuous integration/continuous delivery or deployment) pipelines.

The SASP 102 may provide security evaluation via hardware or software modules, which may be referred to as SASP modules (e.g., SASPM 112 and 114). The SASPM may be implemented via servers of the SASP 102, implemented at or on cloud service servers 106 (e.g., via module 112), or implemented at or on client server 118 (e.g., via module 114), or any combination thereof. For example, a client may operate its business computing operations via servers of a cloud service provider 106. The client may provide the SASP 102 with access rights to its cloud computing systems. The SASP 102 may thereby access the cloud service provider 106 via network 110 using the access credentials, and remotely scan the software, monitor outgoing data traffic, and perform security evaluations. Alternately, software of the SASP 102 may be installed at the Cloud providers 106 (e.g., as SASPM 112) or on a computing system or server 118 within client systems 108 (e.g., as SASPM 114) to perform scanning and monitoring, and generate evaluation results locally at those systems, or provide data back to the SASP 102 via network 110 for processing and evaluation. In an example implementation, server 118 (e.g., a server computing device, or a Docker container) within client systems 108 my run a software security evaluation module 114 behind a company firewall. The SASPM 114 may be given permission to remotely access client machines 116 that run the client's production code via system-level accounts. The SASPM 114 may therefore scan and evaluate the software components installed at and running on the client machines 116 without being installed as an agent on client machines 116.

Turning to FIG. 2, a flowchart 200 of an example method for software security discovery is shown, in accordance with certain embodiments of the present disclosure. In particular, the method of FIG. 2 may present an example algorithm or process for discovering or detecting the elements in the system to be evaluated for security and regulation compliance. The elements may include software such as code libraries and OS (operating system) libraries and associated version indicator, service requests generated in a computing system such as third party and internal facing API (application program interface) calls, and what data is being shared or exchanged. Based on the discovered elements, the process of FIG. 2 may provide for generating a catalog or “software bill of materials” (SBOM) listing the software and third party connections in a system. The method of FIG. 2 may be implemented by a security analysis service provider (SASP), such as SASP 102 or associated modules 112 and 114 of FIG. 1, and may be remotely executed on the file systems and programs of a separate device.

The method may include mapping out the file system for the client business operations, including scanning directories for metadata and executable code, at 202. A user or client may be able to configure a scan frequency, or target directories or files to scan. Multiple files in various directories can be scanned, for example by recursively walking down the file tree. The method may include identifying code libraries, operating system libraries, and similar executable code involved in the operating systems and software used by the client, as well as associated computer languages (e.g., Java, C#, Python, etc.), at 204. The libraries and languages may be identified using regular expressions and heuristics, such as looking at the top 10% of a file for distinguishing features that identify the file as executable code, and the corresponding language. A regular expression, also referred to as rational expression, may be a sequence of characters that specifies a pattern in text (e.g., phone numbers or email addresses). The method may include searching files using a list of regular expression anchors, which may allow for searching for certain text strings at the beginning or ending of words or text elements. Different anchors may correspond to elements from different computer languages. Based on the search results, the type of code or computer language in the file can be identified, which in turn can be used as a basis for extracting code library names and identifying the types of functions and program calls executed by the code. For example, once a programming language for a file is identified, the file can be searched for known code libraries and program calls used in that programming language. The code library calls may be used to identify what software or functions are being used by a program. Metadata files may include text that further identifies what code libraries have been loaded or are available, and may further identify version information to indicate whether the software in a system is using updated or outdated versions of software. For example, code library calls in the declaration of a program file may not identify a version of the code library being called, but that information may be included in metadata associated with the program file, e.g., based on being in the same directory. Different software components of a business' software ecosystem may be using different versions of the same code libraries.

In an example embodiment, identifying OS libraries used in a business' system may be performed in a different manner from identifying code libraries. For example, code libraries may correspond to system software applications that run on the operating system, while the OS libraries may serve as the basis for the OS itself. What OS libraries are being used to implement aspects of a business' code may not be available during a static scan (e.g., looking at files before anything is executed), such as the scan used to identify code libraries and metadata. Instead, the method may include accessing a client machine that is running production code (or of the same architecture and OS), and running commands on that system to identify what OS functions or libraries are being used by the code base. For example, the method may include identifying function calls within the code (e.g., during the static scan) that will invoke OS libraries and functions. These calls may then be executed on a client machine to determine a specific library or function, and potentially a version thereof, that actually responds to the function call.

Once executable code and software libraries are identified, the method may include identifying (e.g., using regular expression anchors) where in the code external service requests are made, for example based on searching for known service call techniques in the associated computer language, at 206. Service requests may refer to calls to external systems (e.g., third party vendors), which may take the form of API (application program interface) calls, RPC (remote procedure call), gRPC (Google RPC), FTP (file transfer protocol), UDP (user datagram protocol), etc.

The identified service requests may be decomposed into constituent parts, to identify what data is being provided and to whom as part of the service request, at 208. The parts may include a target (e.g., a third party vendor to process the service request), a communication protocol employed, what information is included in the service request header, what data fields or types of data are communicated, etc. In particular, the process may note when a communication includes potentially sensitive data such as personally identifiable information (PII), contact information, account numbers, or other data that may affect compliance with various security or regulatory frameworks. Further, the method may include identifying whether the information of the constituent parts is being retrieved at runtime, or if it is statically coded into the computer code.

A catalog or SBOM may be generated based on the identified third party vendors, code libraries, OS libraries, software version information, service requests, types of communicated data, and so on, at 210. The catalog may include any number of data fields for the cataloged elements, such as supplier component name, version, dependency relationship, author of SBOM data, and timestamp. Third party vendors associated with software (e.g., that provided the software) may be identified based on targets of service request calls, or from code libraries. For example, code library files may be compared to public repositories such as Github to identify a vendor for the software. In some examples, scanning software files, code libraries, OS libraries, etc. may reveal vendors for the software, for example in file headers or commented out notes within a file. The catalog may support automation, and may be compatible with data formats such as SPDX (Software Package Data Exchange), CycloneDX, and SWID (SoftWare Identification) tags.

Further, the method may include monitoring outbound data communication traffic from the system to identify calls to third parties, at 212. For example, in addition to the service request calls identified in the software code, additional code may be incorporated into software at compile or runtime that may not be detected in a static scan. This additional code may generate unexpected outgoing transmissions, which can be detected via monitoring data packets or messages. In an example, the method may include obtaining network flow logs from a firewall for a selected time period, to determine outgoing data transmissions to third parties. The outgoing traffic may indicate SaaS transmissions to third parties, or the outbound traffic may be from a run-time compiled file wrapper. Periodic scans may also be repeated of the file system and code base to detect new software or changes to previously detected software, at 214. These scans can identify all dependencies from code libraries to APIs and SDKs (software development toolkits).

Based on the monitoring and scanning performed at 212 and 214, a determination may be made whether there have been any changes to third party vendors or external contacts for the system, at 216. If there have been changes, the method may include updating the catalog or SBOM in real time, at 218. Once the catalog has been updated, or if there have been no changes at 216, the method may include continuing to monitor transmissions and performing periodic scans, at 212 and 214.

The catalog generated and maintained by the example process of FIG. 2 may be used to illustrate the building blocks and interdependencies of a business' software environment. It may be referenced to identify and ensure safe data practices and regulation compliance, and to identify what components may need to be updated, patched, or replaced to address risks such as newly discovered software vulnerabilities.

FIG. 3 depicts a diagram of a system 300 configured for software security discovery, in accordance with certain embodiments of the present disclosure. In particular, FIG. depicts a computer system 302, which may be an example of any computing system that may be employed to perform the operations of client machines 116, server 118, security analysis service provider 102, cloud service providers 106, or third party vendors 104, and related processes and methods. Computing system 302 may include a processing system 304, a communication interface 306, and a user interface 308. Computing system 302 may include other components such as a battery and enclosure that are not shown for clarity. Computing system 302 may comprise one or more server computing systems, desktop computing systems, laptop computing systems, smartphone devices, or any other computing system, including combinations thereof.

Communication interface 306 may comprise components that communicate over communication links, such as network cards, ports, radio frequency (RF) transducers or antennas, processing circuitry and software, or other communication devices. Communication interface 306 may be configured to communicate over metallic, wireless, or optical links. Communication interface 306 may be configured to use Time Division Multiplex (TDM), Internet Protocol (IP), Ethernet, optical networking, wireless protocols, communication signaling, other communication formats, or any combinations thereof. In particular, communication interface 306 may be configured to communicate over a network with SASP 102, client systems 108, third party vendors 104, cloud service providers 106, or other computing nodes.

User interface 308 may comprise components that interact with a user to receive user inputs and to present media, notifications, or other information. User interface 308 may include a display screen, touch screen, touch pad, keyboard, buttons, speaker, microphone, pointer device or interface, communication port, other user input/output apparatus, or any combination thereof. Further, user interface 308 may include or interact with software or modules for presenting a graphical user interface (GUI), audio interface, or other software-based interface.

Processing system 304 may be linked to communication interface 306 and user interface 308. Processing system 304 can include processing circuitry 310 and memory device 312. Memory device 312 can store executable instructions or other operating software 316, and a catalog of system components or software bill of materials (SBOM) 314.

Processing circuitry 310 may comprise a microprocessor and other circuitry that can retrieve and execute instructions 316 from memory device 312. Memory 312 may comprise a non-volatile data storage medium, such as a disk drive or solid state drive, or volatile memory such as random access memories (RAM) and dynamic RAM (DRAM), or any other memory apparatus. Processing circuitry 310 may be mounted on a circuit board that may also hold memory device 312 and portions of communication interface 306 and user interface 308.

Executable instructions 316 may comprise computer programs, firmware, or some other form of machine-readable processing instructions. Executable instructions 316 may include discovery module 318, and catalog module 320, although related operations may be handled by multiple different modules or programs, all operations may be performed by a single module, or additional modules may be included in executable instructions 316. Executable instructions 316 may further include an operating system, utilities, drivers, network interfaces, applications, or some other type of software. When executed by processing circuitry 310, executable instructions 316 may direct processing system 304 to operate computing system 302 as described herein.

Discovery module 318 may be a set of instructions for determining the components and interconnections of a business' software ecosystem, such as identifying programs and code libraries, including code versions and third party software vendors, identifying service requests and what data is transmitted, determining target systems of data transmissions, identifying security risks, and otherwise identifying the building blocks and dependencies of a computing environment. Discovery module 318 may perform operations for scanning and identifying elements of a system as described in regard to FIG. 2, including by performing static scans and runtime analysis. For example, the discovery module 318 may scan directories for executable code files, use regular expression anchors to identify a type of program language employed in the code, and use a library or database of code expressions associated with each type of program language to identify service requests and data transfers performed by the code. Data transmissions may be monitored by the discovery module 318 during runtime to identify additional third party vendors or components with which the system communicates, and to identify the data transmitted. Discovery module 318 may also perform additional discovery operations not specifically enumerated herein.

Catalog module 320 may include a set of instructions regarding how to organize the information obtained by the discovery module, and how to generate and update a comprehensive catalog of all software components of a client's digital supply chain or software ecosystem, their vulnerabilities, and their interactions. This catalog or “software bill of materials” (SBOM) 314 may be stored to memory 312, where it may be accessed or searched via user interface 308 or by the processing system 304 for other operations. The catalog module 320 may also be configured to generate a graphical user interface (GUI) for displaying and interacting with the SBOM 314, or related notices or warnings, via user interface 308.

In some embodiments, the catalog module 320 may be configured to compare the data of the SBOM 314 against known vulnerabilities, privacy concerns, or compliance requirements. The catalog module 320 may access databases of security vulnerabilities and legal compliance requirements, or be configured to recognize selected vulnerabilities or requirements, and then scan the SBOM 314 to determine if any of the client systems conflicts with the identified information. For example, if a code library version employed in the client's system is listed as having a known security exploit, the catalog module 320 may identify the vulnerability while scanning or maintaining the SBOM 314. Similarly, if a type of data is being sent from the client system to an external party that violates a consumer privacy law, the catalog module 320 may identify this issue. Security and compliance databases or lists may be stored internally at computing system 302, or may be accessed from external sources, e.g., via communication interface 306. The catalog module 320 may generate notifications or logs of compliance or security issues that have been identified. This catalog module 320 may produce a warning indication, e.g., via user interface 308, or may store a log file that can be accessed by a system administrator or other user.

The illustrations of the embodiments described herein are intended to provide a general understanding of the structure of the various embodiments. The illustrations are not intended to serve as a complete description of all of the elements and features of apparatus and systems that utilize the structures or methods described herein. Many other embodiments may be apparent to those of skill in the art upon reviewing the disclosure. Other embodiments may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Moreover, although specific embodiments have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar purpose may be substituted for the specific embodiments shown.

This disclosure is intended to cover any and all subsequent adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the description. Steps depicted in the flowcharts may optionally be excluded, added, performed in a different order, or performed with different degrees of concurrency than shown (e.g., steps depicted as sequential may be performed concurrently). Additionally, the illustrations are merely representational and may not be drawn to scale. Certain proportions within the illustrations may be exaggerated, while other proportions may be reduced. Accordingly, the disclosure and the figures are to be regarded as illustrative and not restrictive.

Claims

1. A method comprising:

executing a software security discovery system, including: performing a scan on a directory of a client computing system for executable code; identifying a service request within the executable code; decomposing the service request into constituent parts, including a target entity of the service request; and generating a catalog of the client computing system, including third party vendors for the client computing system, based on the target entity.

2. The method of claim 1 further comprising:

monitoring outgoing data traffic from the client computing system to identify an additional target; and

generating the catalog, including the third party vendors, based on the target entity and the additional target.

3. The method of claim 2 further comprising:

identifying a computer language corresponding to the executable code; and

identifying the service request within the executable code based on the computer language.

4. The method of claim 3 further comprising:

determining an executable code library at the client computing system based on the scan; and

including the executable code library in the catalog.

5. The method of claim 4 further comprising:

identifying the computer language and the executable code library based on performing a search for regular expression anchors.

6. The method of claim 5 further comprising:

identifying the computer language and executable code library includes: scanning the directory for files including regular expression anchors corresponding to a plurality of computer program languages to identify the computer language; and scanning the files for regular expression anchors corresponding to a plurality of known code libraries of the computer language to identify the executable code libraries.

7. The method of claim 6 further comprising:

identifying an operation system (OS) library of the client computing system, including: executing a command on the client computing system known to invoke an OS function; identifying the OS library based on a response to the command from the OS function; and

including the OS library in the catalog.

8. The method of claim 7 further comprising:

performing a periodic scan to identify a change to the client computing system; and

updating the catalog in real time based on the change.

9. A system comprising:

a processor configured to implement a software security discovery process, including: perform a scan on a directory of a client computing system for executable code; identify a service request within the executable code; decompose the service request into constituent parts, including a target entity of the service request; and generate a catalog of the client computing system, including third party vendors for the client computing system, based on the target entity.

10. The system of claim 9 comprising the processor further configured to:

monitor outgoing data traffic from the client computing system to identify an additional target; and

generate the catalog, including the third party vendors, based on the target entity and the additional target.

11. The system of claim 9 comprising the processor further configured to:

identify a computer language corresponding to the executable code; and

identify the service request within the executable code based on the computer language.

12. The system of claim 11 comprising the processor further configured to:

determine an executable code library at the client computing system based on the scan; and

generate the catalog to identify the executable code library.

13. The system of claim 12 comprising the processor further configured to:

identify the computer language and executable code library, including: scan the directory for files including regular expression anchors corresponding to a plurality of computer program languages to identify the computer language; and scan the files for regular expression anchors corresponding to a plurality of known code libraries of the computer language to identify the executable code library.

14. The system of claim 9 comprising the processor further configured to:

identify an operation system (OS) library of the client computing system, including: execute a command on the client computing system known to invoke an OS function; identify the OS library based on a response to the command from the OS function; and

include the OS library in the catalog.

15. The system of claim 9 comprising the processor further configured to:

perform a periodic scan to identify a change to the client computing system; and

update the catalog in real time based on the change.

16. A memory device storing instructions that, when executed, cause a processor to perform a method comprising:

executing a software security discovery system to generate a catalog of components of a client computing system, including: identifying a third party vendor for the client computing system based on a target entity of a service request from the client computing system; determining an executable code library of the client computing system; determining an operating system (OS) library of the client computing system; and generating the catalog to include the third party vendor, the executable code library, and the OS library.

17. The memory device of claim 16 storing instructions that, when executed, cause the processor to perform the method further comprising:

performing a scan on a directory of the client computing system for executable code;

identifying the service request within the executable code; and

decomposing the service request to identify the target entity of the service request.

18. The memory device of claim 16 storing instructions that, when executed, cause the processor to perform the method further comprising:

monitoring outgoing data traffic from the client computing system to identify the service request; and

determine the target entity from the outgoing data traffic.

19. The memory device of claim 16 storing instructions that, when executed, cause the processor to perform the method further comprising:

identifying a computer language and the executable code library, including: scanning a directory of the client computing system for files including regular expression anchors corresponding to a plurality of computer program languages to identify the computer language; scanning the files for regular expression anchors corresponding to a plurality of known code libraries of the computer language to identify the executable code library; and identifying the service request within executable code of the client computing system based on the computer language and the executable code library.

20. The memory device of claim 16 storing instructions that, when executed, cause the processor to perform the method further comprising:

identifying the OS library of the client computing system, including: executing a command on the client computing system known to invoke an OS function; and identifying the OS library based on a response to the command from the OS function.