Digital asset traceability and assurance using a distributed ledger

Various embodiments provide an apparatus, method, system, and/or instructions by which source code can be linked to a compiled binary, guaranteeing the origin of the binary and ensuring traceability of the binary file back to the source code that originated it. An example method includes determining a request to register a digital asset; computing a first hash of an initial source file of the digital asset; ascertaining a version of the initial source file; electing one or more nodes of a blockchain to commit the first hash to the blockchain in association with a version of the digital asset corresponding to the version of the initial source file; converting the source file into a binary file, resulting in a binary version of the digital asset; computing a second hash of the binary file; and committing the second hash to the blockchain in association with the version of the digital asset.

BACKGROUND

The present application relates to computing, and more specifically to software and accompanying methods for tracing digital assets and implementing quality control in a networked computing environment.

Systems and methods for tracing digital assets are employed in various demanding applications, including tracing copywritten music, videos, software applications, files, etc.; for preventing and/or mitigating malicious cyberattacks (e.g., ransomware attacks), enforcing software Intellectual Property (IP) rights and identifying software owners, facilitating software updating, and so on. Such applications often demand efficient mechanisms for tracking and tracing digital asset origin.

Security conscious organizations and industries (e.g., intelligence services, healthcare, finance, etc.) often demand efficient, accurate, and virtually tamper-proof mechanisms for tracing or tracking digital assets. Such efficient mechanisms may enable the organizations to readily ascertain responsibility (e.g., for malware attacks) and to thereby mitigate associated liabilities. Digital asset traceability can also be important for protecting and enforcing intellectual property rights, e.g., software copyrights. Nevertheless, robust and efficient digital asset traceability and other preventative security and traceability mechanisms have remained elusive.

Conventionally, to track and trace digital assets, organizations, e.g., companies, governments, universities, etc., rely upon adjusting centralized control systems (e.g., app stores) that govern a particular computing environment. As such, for example, to defend against malware, such centralized control systems are sometimes equipped with additional security features, e.g., anti-malware software etc.

However, such security measures are frequently only implemented after security breaches have already occurred, e.g., after a zero-day malware attack. Generally, organizations using such centralized systems must often rely upon customer trust. Accordingly, breaches of the trust, such as in response to a malware attack, can be particularly problematic; not just for the customers, but for the organization, which may lose customers.

SUMMARY

An example embodiment discloses a system and method for facilitating software quality control and tracing in a networked computing environment, in part by employing repositories for source code and associated compiled binary files, which have been (or will be) registered, using cryptographical hashes of the files, in a distributed ledger, e.g., a blockchain. The historical record of the distributed ledger (i.e., entries that have already been committed to the ledger) can be updated and read from, but not readily altered by a given participant system. Blockchain records, i.e., blocks, store source code hashes and binary hashes in association with a software version and/or time stamp.

Accordingly, a given binary file can be traced to its source code by virtue of its version, and/or time stamp, as logged in the blockchain. Furthermore, the source code registrations and associated hashes are computed using a fingerprint (e.g., checksum, MD-5 hash, or other mechanism) of the source code in combination with workstation identifier, e.g., a Central Processing Unit (CPU) ID of the workstation on which the source code was developed (or from which it was dispatched to a source code repository), a Media Access Control (MAC) address, and/or User ID, etc.

The stored hashes (for both source code and corresponding binary) can be used to verify that a source code file and/or binary image have not been altered and to determine and/or verify the author and workstation corresponding to the associated software version.

Furthermore, various additional capabilities readily flow from use of the blockchain and accompanying functionality of the nodes as discussed herein. For example, mechanisms for facilitating digital asset version control, tracing, monitoring, and notifications; code release sequencing; IP protection; software bug tracing, notification, and mitigation; malware attack detection, tracing, and mitigation; quality assurance source-code filtering; customer detection of binary file corruption or alteration; component nesting tracking; production server flagging of unregistered code, and so on, can all be readily implemented using the blockchain and accompanying systems and methods discussed herein.

In addition, client systems (e.g., consumer systems) and associated customers can now readily verify the integrity of a downloaded binary file, in preparation for installation of the software, e.g., by comparing a hash of the downloaded binary file with the corresponding hash registered in the blockchain. Alternatively, or in addition, a cloud service provider may readily verify that a binary file (or files) to be sent to a production server has (or have) not been altered, e.g., by comparing the hash of the binary (to send to the production server) with the associated hash for the binary file that has been registered in the blockchain.

Another example method for facilitating digital asset traceability in a networked computing environment includes determining a request to register a digital asset in the networked computing environment; computing a first hash of an initial source file of the digital asset; ascertaining a version of the initial source file; electing one or more nodes of a distributed ledger of the networked computing environment to commit the first hash to the distributed ledger in association with a version of the digital asset corresponding to the version of the initial source file; converting the source file into a binary file, resulting in a binary version of the digital asset; computing a second hash, wherein the second hash is of the binary file; and committing the second hash to the distributed ledger in association with the version of the digital asset.

Another example method includes generating a source code file; storing the source code file in a repository; storing a hash of the source code file in a blockchain; compiling the source code file to generate a binary file (also simply called the “binary” herein); storing a hash of the binary file in a block of the blockchain; and distributing the binary file so that participants can use the distributed ledger to identify the origin of the source code file used in compiling the binary file.

Hence, by using distributed ledger technology (e.g., blockchain technology), or other suitable trusted database, as discussed herein, to ensure traceability of computer code from a source file to a binary via the blockchain, associated efficient methods for enabling digital asset version control; code release sequencing; IP protection; software bug tracing and mitigation; malware attack prevention, tracing, mitigation, and so on, readily flow.

Accordingly, various embodiments provide an apparatus, method, system or instructions for a method by which source code can be linked to a compiled binary, guaranteeing the origin of the binary and ensuring traceability of the binary back to the source code that originated it.

DETAILED DESCRIPTION OF EMBODIMENTS

In many applications it is desirable and even critical to know details about the origin and subsequent modification of digital assets such as computer source code, executable code, data objects, etc. However, when these assets are exchanged and modified among different users or customers who may be in different places and unknown to each other it is difficult to authenticate and trace the assets. Companies have tried to solve this issue by concentrating on centralized version control systems. But this requires users to trust the central authority.

One way to reduce or eliminate the need for a central authority is to use a distributed ledger approach. Examples of a distributed ledger can be found in various blockchain implementations known today. One or more of the blockchain features can be adapted for use with digital assets as described herein. Although specific features may be described, not all of the features need be implemented in every embodiment. In some embodiments, third party code, including open source code, may be used to implement some or all of the functionality.

Features of version control systems can be combined with features of a distributed ledger system as described herein. In general, numbers and types of features of version control systems or similar digital asset development aids can be mated with distributed ledger functionality to provide desired tracing and organized modification and distribution of the asset. Existing components, such as Hyper-Fabric architecture components provided by the open source Hyperledger project, may be used. Features may be productized and sold as part of a secure development service. Established commercial companies, as well as free or open source software projects, can use the described features integrated or associated with their own version control or continuous deployment products.

For the purposes of the present discussion, a software ecosystem may be any computing environment that includes a collection of networked distributed computing resources configured to enable uploading and/or downloading of software components to/from the distributed computing resources (e.g., catalog instances, accompanying distributed blockchain, etc.). A networked computing environment may be any computing environment that includes intercommunicating computers, i.e., a computer network, such as a local area network (LAN), wide area network (WAN, e.g., the Internet), cloud infrastructure and services, etc. Similarly, a networked software application may be computer code that is adapted to facilitate communicating with or otherwise using one or more computing resources, e.g., servers, via a network.

Note that collections of computing resources, e.g., computer systems that may intercommunicate via a network of the ecosystem, are called nodes herein. A given node, e.g., an instance of a software component catalog (called catalog instance herein), may include software for intercommunicating with other nodes and selectively sharing data (e.g., replicas of blockchains containing registration information for the ecosystem); for facilitating creation of transactions (e.g., via user interface software for guiding completions of various registrations), and for ensuring conformance with rules of the ecosystem, thereby enabling implementation of a peer-to-peer ecosystem.

For the purposes of the present discussion, a peer-to-peer network or ecosystem may be any collection of computing resources, e.g., computer systems and/or software applications, i.e., nodes, which are distributed across a computer network, and which may intercommunicate to facilitate sharing process workloads.

Note that conventionally, peers or nodes of a peer-to-peer network have similar privileges to access data and functionality provided by the network. However, as the term is used herein, peers or nodes of a peer-to-peer network need not be similarly privileged. For example, some nodes, called full nodes, are maximally privileged, i.e., maintain privileges to read from the ecosystem blockchain and write thereto. Other less privileged nodes may require use of a full node as a proxy to access the ecosystem blockchain. Note that the terms “peer-to-peer network” and “peer-to-peer ecosystem” may be employed interchangeably herein.

For the purposes of the present discussion, software functionality may be any function, capability, or feature, e.g., stored or arranged data, that is provided via computer code, i.e., software. Generally, software functionality may be accessible via use of a user interface and accompanying user interface controls and features. Software functionality may include actions, such as retrieving data pertaining to a computing object (e.g., business object associated with a transaction); performing an enterprise-related task, such as promoting, hiring, and firing enterprise personnel, placing orders, calculating analytics, launching certain dialog boxes, performing searches, and so on.

A blockchain may be a sequenced list of linked records, called blocks, wherein the blockchain can grow by adding new blocks to an end of the blockchain, but the insertion of earlier blocks is prohibited unless later blocks are first unwound or removed from the blockchain. Different blocks of a blockchain are often timestamped upon incorporation into the blockchain. Blockchains may be implemented using distributed or networked software applications, e.g., which may be installed on nodes of a given computing environment or ecosystem. The links between blocks may be implemented via implementation of one or more hashes applied to new blocks, wherein the one or more hashes leverage or use information from one or more previous blocks. Blockchains can be used to implement distributed ledgers of transactions.

For the purposes of the present discussion, a distributed ledger may be a collection of shared digital data, which is shared among plural nodes of a network, copies of which may be replicated and stored among the plural nodes. Data maintained by a distributed ledger may be synchronized among the nodes.

Accordingly, a distributed ledger may act as a type of distributed database, i.e., mechanism for storing data among different entities coupled to a network of the entities. A node may be any computer system and/or software application and/or software system, or groups thereof that are coupled to a network. The nodes discussed herein are generally called “catalog instances,” as they facilitate access to data stored in the catalogs by other nodes and/or participants of the accompanying computing ecosystem.

A transaction may be any collection of information describing an event, status, property, or other information, descriptive of one or more aspects of the ecosystem, wherein the one or more aspects may include participating developer entities, software component consumer entities, contributor entities, proxied ecosystem participants and systems, software component interrelationships, instances of software component downloads and/or uploads, support status of a software component, component provenance information, and so on. Depending upon the context in which the term is used, a transaction may refer to a collection of data describing an activity in the ecosystem, e.g., a developer entity registration, a namespace registration, a contributor registration, and so on; or alternatively, a transaction may refer to the actual activity, e.g., downloading a component.

Transactions representing activities or tasks may be fully automated or may also contain human workflow tasks such as manual approvals or other verification activities. Thus, although a transaction may be expressed as a single thing (e.g., collection of information) in the blockchain, some forms of transactions may actually be broken down into discrete sub-transactions which can be recorded in the ledger as the workflow is processed. Accordingly, depending upon the context in which the term is used, the term “transaction” may also refer to the act of conveying a collection of information (e.g., computing object) and may also refer to the actual collection of the information (e.g., computing object).

For example, if an individual software developer (e.g., a component contributor) registers with a component ecosystem, as discussed herein, information pertaining to (e.g., documenting) the contributor registration process may be propagated to one or more unverified queues of catalog instances in preparation for incorporation into the blockchain of the ecosystem. The collection and/or transfer of the information may be called a transaction, and the computing object maintaining the collected information may also be called the transaction, e.g., developer registration transaction.

A given node may be allocated different privileges in a given computing environment or ecosystem. Nodes with similar privileges, as it pertains to implementation of one or more particular tasks, are called peers for the purposes of completing the tasks. For the purposes of the present discussion, a peer-to-peer ecosystem may be any ecosystem or computing environment implemented, at least in part, via one or more distributed or networked software applications implemented via different nodes or peers of the of ecosystem.

Various example embodiments discussed herein are implemented via a peer-to-peer software ecosystem that includes nodes of software component catalog instances. Example software component catalog instances, discussed more fully below, may run various software applications, including software for maintaining and managing a local data store (which may include a database of software components); software for implementing security and permissions functionality; software for generating User Interface (UI) display screens for enabling various types of registrations (examples of which are discussed more fully below); for managing unverified transaction queues for the ecosystem; for communicating with other catalog instances; for maintaining replicas of the ecosystem blockchain; for computing, i.e., verifying or validating new blocks for the blockchain of the ecosystem; for submitting transactions for verification (and inclusion in a blockchain block) by one or more catalog instances of the ecosystem; for implementing any algorithms for selection of catalog instances to perform computations required to add one or more blocks to the blockchain; for computing hashes required to add blocks to the blockchain, and so on.

Generally, communities of developers and/or businesses may use software ecosystems to cooperatively interact with a shared market for software and services using a common technological platform, which enables or facilitates exchange of information, resources and components.

A software ecosystem can implemented as an open ecosystem of re-usable software components for use by developers, vendors and customers. Such an ecosystem may be built around networked or “cloud” infrastructure and accompanying processes and services. However, although specific embodiments of the invention may be described with reference to specific processing platforms, techniques and infrastructures, other variations are possible and may be adapted for different systems.

Conventionally, software developers may subscribe to certain cloud services to facilitate development of software applications and storage of associated files. A cloud service that is configured for software application or process flow development is called a Process Cloud Service (PCS) herein.

A process cloud service may employ a networked database to store files and other objects used by a given software program being developed. Server-side development environments may be accessible to developers via a browser. The development environments may be backed by the PCS, such that developed software application files are stored in the PCS database.

For the purposes of the present discussion, a computing environment may be any collection of computing resources used to perform one or more tasks involving computer processing. A computer may be any processor in communication with a memory. A computing resource may be any component, mechanism, or capability or quantities thereof of a computing environment, including, but not limited to, processors, memories, software applications, user input devices, and output devices, servers, and so on. Examples of computing resources include data and/or software functionality offered by one or more web services, Application Programming Interfaces (APIs), etc.

An enterprise computing environment may be any computing environment used for a business or organization. An example enterprise computing environment includes various computing resources distributed across a network and may further include private and shared content on Intranet Web servers, databases, files on local hard discs or file servers, email systems, document management systems, portals, and so on.

A given software application may include (but not necessarily) constituent software applications or modules (e.g., services, functions, procedures, computing objects, etc.). Accordingly, the term “software application” may also include networked software applications or integrated groups thereof.

Certain embodiments discussed herein are particularly useful for development, deployment, and implementation of process-based software applications. A process-based software application may be any software application definable by one or more sequences of steps, also called process elements or software activities. The terms “process element,” “flow element,” “software element,” and “software process element” may be employed interchangeably herein to refer to any step, e.g., event, activity, gateway, sub-process, and so on. A sequence of steps of a process-based software application may be called a process flow. Process flows are often modeled and illustrated via swim lanes in a User Interface (UI) display screen. Process-based applications are often implemented via composite applications that may leverage different web services and associated software components for different process steps.

For clarity, certain well-known components, such as hard drives, processors, operating systems, power supplies, routers, Internet Service Providers (ISPs), workflow orchestrators, process schedulers, process clouds, business process management systems, ecosystem developer entities, ecosystem contributor entities, Integrated Development Environments, proxy systems, identity management systems (e.g., identity domains), Certificate Authorities (CAs), and so on, are not necessarily explicitly called out in the figures. However, those skilled in the art with access to the present teachings will know which components to implement and how to implement them to meet the needs of a given implementation.

FIG. 1illustrates a first example system10and accompanying computing environment equipped to use a distributed ledger18to facilitate linking source code of a software application or component to not only a compiled version (called the binary herein) but the workstation12and developer with which the source code and binary are associated. The overall system10acts as software ecosystem, whereby developers using workstations12can provide software, e.g., to a source code repository46and binary repository48, which can be made selectively available to customer systems20and/or a production server16, as discussed more fully below.

The example system10includes one or more workstations (e.g., computers operated by respective software developers)12in communication with distributed servers14(e.g., a cloud) via a network, such as the Internet. The example workstation12includes client-side software24for developing software applications. The client-side software24may include client-side developer tools for developing source code files26, and a browser for accessing functionally provided by the distributed servers14.

Note however, embodiments are not limited to client-side software development environments but may also include server-side development environments and other Integrated Development Environments (IDEs) that may include browser-accessible web-based or cloud-based software development functionality. Furthermore, the workstation12may also include a compiler, as opposed to just relying upon a server-side compiler36.

The client-side software24facilitates displaying various User Interface (UI) display screens22, which include user options and controls for accessing software development functionality and for initiating registrations of source code, binary, etc., with the blockchain18via the distributed servers14, which include functionality for enabling servers of the distributed servers14to act as blockchain nodes.

For the purposes of the present discussion, a UI display screen may be any software-generated depiction presented on a display. Examples of depictions include windows, dialog boxes, displayed tables, and any other graphical user interface features, such as user interface controls, presented to a user via software, such as a browser. A user interface display screen contained within a single border is called a view or window. Views or windows may include sections, such as sub-views or sub-windows, dialog boxes, graphs, tables, and so on. In certain cases, a user interface display screen may refer to all application windows presently displayed on a display.

A UI control may be any displayed element or component of a user interface display screen, which is adapted to enable a user to provide input, view data, and/or otherwise interact with a user interface. Additional examples of user interface controls include buttons, drop down menus, menu items, tap-and-hold functionality, and so on. Similarly, a user interface control signal may be any signal that is provided as input for software, wherein the input affects a user interface display screen and/or accompanying software application associated with the software.

Note that in general, groupings of various modules of the system10are illustrative and may vary, e.g., certain modules may be combined with other modules or implemented inside of other modules, or the modules may otherwise be distributed differently (than shown) among a network or within one or more computing devices or virtual machines, without departing from the scope of the present teachings.

For example, while inFIG. 1, the distributed ledger18, e.g., blockchain, appears as a separate entity from the workstation12and distributed servers14, that in practice, the blockchain18is implemented as a distributed set of replicated data and functionality (e.g., blockchain replicas), which may be distributed about the distributed servers14.

Furthermore, inFIG. 1, while implementation of a source-code hash function (also simply called the source hash function) is shown as being implemented by one or more of the distributed servers14(e.g., distributed software quality control servers), note that instead, such hash function can be implemented on the workstation12. Furthermore, while the distributed servers14are shown as including blockchain interfacing functionality44, note that in certain embodiments, such functionality may also be included in the workstation12. Furthermore, the workstation12may be equipped with yet additional functionality, e.g., such that the workstation12may act as one of the servers of the distributed servers14, without departing from the scope of the present teachings.

The distributed servers14are called “quality control servers” herein as they incorporate code and functionality for facilitating software bug tracing, malware detection, software release sequencing, software IP protection and enforcement mechanisms, and so on, as discussed more fully below. Such functionality helps to ensure quality of software provided to consumer systems20and/or to the production server16via the ecosystem10.

In the present example embodiment the distributed servers14include a controller28, which incorporates middleware that facilitates interfacing various modules30-48and controlling intercommunications and routing between the various modules30-48. The controller28also handles and routes communications with the workstations12, and may further include instructions or functionality for facilitating UI rendering instructions for the workstation UI controls and options22.

The example server-side modules and functionality30-48include a source code (also simply called “source” herein) fingerprinting module30, a source hash function32, a binary hash function34, the compiler36, a software version controller36, a software-release sequencing module38, a Quality Assurance (QA) module40, a software provenance analyzer42, and blockchain interfacing functionality44. The controller28also acts as a gate keeper for the source code repository46and binary code repository48, and communicates with the production server16, and optionally, the consumer systems20, as discussed more fully below.

In an example scenario, a developer using the workstation12who has been permissioned to supply source code to the distributed servers14(e.g., by submitting credentials, e.g., User ID) uses the developer tools24to create one or more source code files26. The one or more source code files26represent source code containing programming language instructions defining one or more software programs and/or components.

The developer using the workstation12then selects an option (e.g., from among the UI controls and options22) to register the source code with the distributed servers14. The source code files26are then delivered to the controller28of one or more of the distributed servers14, along with workstation identifying information, e.g., CPU ID, MAC address, and User ID. Note that in some embodiments, other numbers or combinations of one or more numbers or identification codes, which are suitable to identify the workstation12and associated developer, may be used instead.

The controller28then inputs the source code file(s) to the source fingerprinting module30, so as to obtain a fingerprint of the source code file(s) in accordance with a fingerprinting algorithm implemented by the fingerprinting module30. Exact details of the fingerprinting algorithm are implementation specific and may vary, depending upon the needs of a given implementation. In the present example embodiment, the source fingerprinting module30uses an MD-5 hash algorithm, or other suitable checksum or hash function. The output of the source fingerprinting module30represents a number (or code, e.g., a message digest) that can be used to identify the input source file(s). In theory, different source files, including even slightly altered versions of a given source file result (absent collision) in a different source code fingerprint output from the source fingerprinting module30.

The resulting source code fingerprint is then routed by the controller14to the source hash function32, and submitted as input thereto, in combination with the CPU ID, MAC address, and User ID, which were supplied to the controller28(from the workstation12) along with the source files26. The source hash function32then runs a hash algorithm with the source file(s)26, CPU ID, MAC address, and User ID as inputs, producing a source hash (also called source code hash herein) as output.

Accordingly, the source hash returned by the source hash function32contains information about the workstation12(e.g., via the CPU ID and MAC address), the user (e.g., via the User ID), and the source files26. The resulting source hash and associated source code files26are then routed by the controller28for storage in the source code and hash repository46.

Note that the controller28may first store the source code files26in the source code and hash repository46before routing it to the source fingerprinting module30, without departing from the scope of the present teachings. Furthermore, note that the received CPU ID, User ID, and MAC address may be maintained in local cache of the distributed servers14and/or also temporarily stored in the source code and hash repository46.

The controller28then uses the blockchain interfacing code44to generate a corresponding transaction (containing the source hash) for registration via the blockchain18. When a block of the blockchain18that contains the source hash is verified and committed to the blockchain18by one or more nodes (where, in this case, nodes correspond to the distributed servers14) of the blockchain18, the source hash is said to have been registered with the blockchain18or committed to the blockchain18.

The blockchain interfacing module44includes functionality for not just verifying and committing blocks to the blockchain18, but also for communicating with other nodes14via their respective blockchain interfacing modules44, and for complying with any consensus algorithm for determining which of the nodes14will perform the transaction and block verification and committing functions to commit a particular block to the blockchain18. The blockchain interfacing module44further includes instructions for maintaining an updated local blockchain replica and for propagating indications of received transactions (that are to be committed to one or more blocks of the blockchain18) to other participant nodes14.

In the present example embodiment, a node from among the nodes14is selected in accordance with a proof-of-stake consensus mechanism, as opposed to a proof-of-work mechanism. For the purposes of the present discussion, a proof-of-stake mechanism may be any node-selection algorithm that selects one or more nodes to perform processing to commit a block to a blockchain, which does not involve a race to compute blocks (i.e., proof-of-work mechanism). The exact proof-of-stake method used may vary depending upon the needs of a given implementation.

In the present example embodiment, the node that is selected to commit a particular block to the blockchain18is the node that first received the source files26from the workstation12. Alternatively, or in addition, nodes can also be screened and selected based on permissions of each of the nodes14; available computing resources; or other criteria. One or more identity domains may manage and allocate permissions among authenticated nodes14and workstations12and other users (e.g., consumers using consumer systems20) of the ecosystem10. This can reduce or eliminate the need for more computationally expensive proof-of-work mechanisms.

Nevertheless, in the present embodiment, when a particular node14commits a block to the blockchain18, the node14adds identifying indicia to the block, thereby enabling the nodes14to validate the origin of blocks. Note that in alternative implementations where the workstations12act as nodes of the blockchain18, the requisite identifying indicia may already be included in the source hash. This can happen when the workstation12that is selected to commit the block is also the provider of the source code files26to be registered.

Note that while the blockchain18is shown as a chain of linked blocks (linked by hash pointers to the previous block), that in practice, nodes14of the blockchain18will also maintain so-called unverified queues. The unverified queues are also replicated among the nodes14. The unverified queues contain one or more transactions that are being gathered in preparation for being committed into a block of the blockchain18. While in the unverified queue, various testing can be performed, e.g., to facilitate confirming the validity and integrity of the transaction data in the unverified queue before committal to the blockchain18. Such use of an unverified queue is discussed more fully in the above-identified related U.S. patent application Ser. No. 15/829,684, filed on Dec. 1, 2017 (Trellis ref. ORACP0200/Client ref. ORA180001-US-NP), entitled SYSTEM AND METHOD FOR MANAGING A PUBLIC SOFTWARE COMPONENT ECOSYSTEM USING A DISTRIBUTED LEDGER, which is incorporated by reference herein.

In the present example embodiment, before the source hash is registered in the blockchain18, various types of quality-control processing and testing occur. For example, the version controller36determines the version of the source files26, which corresponds to the version of the software application or component defined thereby. The version controller36may also add external logic coupled with the source files26that ensures that only source files26that have been processed by the QA module40will be released for further processing, e.g., compilation by the compiler36. This can result in higher quality code being released for compilation and further testing, which can reduce costs associated with low-quality or infected code being released.

In the present example embodiment, the QA module40includes multiple stages of analysis, whereby if the code does not pass one stage of the processing, further processing may not be needed. Examples of tests that can be run by the QA module40include detecting and tracing software bugs (e.g., logical errors, such as “divide by zero” possibilities) and/or malware; notifying the developer of any found bugs or instances of malware; thereby helping to mitigate any bugs or other problematic traits of the software.

Note that in some implementations, the version of a source file need not have a title, but instead can be a timestamp (e.g., file completion date) and/or other metadata included with the source files26. In addition, or alternatively, additional timestamps may also be used as a replacement for, or in combination with, a developer-selected name for the source files26. An additional timestamp may be applied by the servers14upon receipt of the source code files26. Yet another time stamp is applied to the block of the blockchain18in which the source hash is registered.

Such timing information can be used by the provenance analyzer42to help ensure that a given set of source files26, received by someone other than the original developer, is not violating the original developer's IP rights to the developed software. The provenance analyzer42can be applied to the source code files26submitted by developers to facilitate such provenance determinations applicable to IP considerations. Furthermore, note that the provenance analyzer42can also be applied to compiled binary, e.g., as maintained in the binary code and hash repository48. In the event of an IP conflict between developers, the provenance analyzer42can help to establish which developer was first to submit the source code files to the servers14.

Furthermore, note that in the present embodiment, neither the production servers16nor the consumer systems20need to have access to the source code files26maintained in the source code and hash repository46. This further helps to reduce chances that one of the operators of the consumer systems20will readily incorporate other developers' source code files or sections thereof into their own code with a license from the original developer.

Note that the provenance analyzer42also includes functionality for producing timelines of code development and revisions. The timeline, version sequence, and/or software patch sequence is then used by the software-release sequencing module38to ensure that code is released in the proper order. Note that the software release sequencing module38and the provenance analyzer42can both use registration data (e.g., source hash and/or binary hash) for a particular software application. The registration data also includes timestamp information, and the hashes can be used to confirm that a particular source file and/or binary file has not been altered or changed from a registered version.

After registration of the source hash output from the source hash function32(and maintained in the source code and hash repository46in association with the corresponding source code) is registered in the blockchain18, and after processing by various modules, e.g., the QA module40, the software-provenance analyzer42, and the software-release sequencing module38, the source files26may proceed to compilation, i.e., conversion to binary (one or more binary files). After conversion to binary (via the compiler36), a corresponding binary hash is computed by the binary hash function34using the binary output from the compiler36.

To obtain binary from the compiler36, the controller28inputs the source code files26to the compiler36, which returns binary. The resulting binary may then be stored in the binary code and hash repository48in association with version information, which may be the same version information as the source code files26, as determined by the provenance analyzer42. Note that versions of binary files in the binary code and hash repository48can be matched with corresponding versions of the source code in the source code and hash repository46, e.g., to find versions of binary code that match the corresponding versions of source code files. This helps the provenance analyzer42and the QA module40to complete tracing operations, e.g., for the purposes of IP enforcement, bug tracing and notifications (back to the original developer), malware detection and tracing, etc.

Note that exact details of the binary hash function and source hash function32are implementation specific and may vary, depending upon the needs of a given implementation. Those skilled in the art with access to the present teachings may readily select and/or develop a suitable hash function to meet the needs of a given implementation, without undue experimentation.

In a continuous deployment scenario, the software-release sequencing module38releases source code to the compiler36so as to produce binary output (corresponding to the binary images50) that is delivered to the production server16, for execution thereby, in the sequence determined by the software-release sequencing module38.

Alternatively, or in addition, the software-release sequencing module38may use already compiled binary that exists in the binary code and hash repository48. In this case, binary files (for a particular software application stored) in the binary code and hash repository48are sequentially released to the production server16, via the controller28, for running as binary images50.

In a client-side installation scenario, consumers (e.g., customers of cloud services of a cloud that hosts the distributed servers14that wish to download and install binary on their consumer system20) may install a blockchain client on their systems20that allows read access to the blockchain18. Once the consumer systems20have obtained a set of one or more binary files for installation and execution, e.g., from the binary code and hash repository48, then one or more blockchain entries corresponding to the downloaded binary may be used to confirm that the downloaded binary exhibits a hash that matches what is expected in view of the corresponding hash entry or entries in the blockchain18. Accordingly, consumers can now readily determine or confirm that a particular downloaded binary file has not been tampered with or otherwise corrupted or altered.

InFIG. 1, the consumer systems20are shown communicating directly with the binary code and hash repository48. However, the consumer systems20may instead (or in addition) selectively access the binary from the binary code and hash repository48via the controller28. Alternatively, the consumer systems20may obtain binary output from the compiler36, via the controller28.

In the present example embodiment, the consumer systems20are only granted access to read the blockchain18; to access the binary code and hash repository48; and/or to access the distributed servers14, after they have been authenticated and appropriately permissioned. Public Key Infrastructure (PKI) may be used as part of the interaction between the consumer systems20and other modules of the overall system10. In this case, depending upon permissions granted to particular consumers of the consumer systems20, the consumers may be issued one or more public keys and one or more private keys for use in accessing other modules of the system10.

Note that a message (e.g., a message containing an encrypted binary file for client-side installation on one of the consumer systems20) that is encrypted with the public key can be accompanied by a digital signature (that represents a combination of the message body and the private key). The receiver of the message may use the public key to check that the digital signature is valid (i.e., made with a valid private key). However, a valid private key will be required to decode the entire message that has been encoded with the public key, and to thereby allow installation of the downloaded binary.

Note that other types of asymmetric encryption (other than public-key encryption) may be used to implement embodiments, without departing from the scope of the present teachings. Furthermore, note that principles of embodiments discussed herein need not be limited to already trusted computing environments, as is the example ecosystem10. The example ecosystem10is said to be already trusted, as all participants have already been authenticated and permissioned for participation in the ecosystem10.

Note that while the embodiment discussed with reference toFIG. 1discusses registrations of source code hashes and binary hashes, in practice, virtually every interaction occurring in the ecosystem10(e.g., that occurs during the process of creating a software application for distribution) can be securely logged in the blockchain18or other trusted database mechanism. Accordingly, the blockchain18may maintain a detailed audit trail that may record virtually every code change, build, code libraries used, and packaging events that contribute to the creation of a given software artifact. Even instances of software component and/or application testing (e.g., whereby one application or component is used as part of another) can be readily tracked and traced. Use of the blockchain18can facilitate alternative embodiments, e.g., wherein the blockchain18is publicly viewable (but not alterable by the public), enabling consumers and potential consumers to confirm and trust the provenance of code made available in the ecosystem10, and to potentially ascertain who worked on a given software application.

Note that use of the system10and accompanying use of the blockchain technology as discussed herein enables the tracing of any binary file or executable image in a production server to a specific set of one or more source files. This helps to provide an additional layer of security. Embodiments discussed herein are anticipated to reduce the operational risk index that directly affects the bottom line of various organizations, e.g., financial institutions.

A quality control organization or system now has a mechanism of releasing the code for compilation by adding the appropriate release order to the blockchain18. Logic (e.g., in the form of a Chain Code or external logic) can be added so that only code approved by the quality control organization or system is cleared for compilation and testing. This can result in higher quality code being released for compilation and testing, resulting in less costs due to inappropriate or low quality code being released for the testing.

Software testing is now able to identify which code files result in which binary image allowing the test process to assist development by correctly identifying which file, or files, need correction.

Accordingly, in summary, basic steps and/or features of an embodiment can include one or more of the following:

1—A hash generated from a workstation's Media Access Control (MAC) Address, CPU ID and User ID along with a hash (e.g., MD5, etc.) of the code is attributed to a source code file generated in any specific workstation.

2—The source file is checked-in to a repository (e.g., the source code and hash repository46) and the file's hash is stored as a block in a blockchain18.

3—If a file is altered and a new version is checked in the existing version control system, a new block, using the same hash logic as in step 1 is added to the blockchain18to evidence the evolution of the code and for tracing file versions back to their developers and editors.

4.1—A quality control organization now has a mechanism of releasing the code for compilation by adding the appropriate release order to the blockchain18.

4.2—Logic (in the form of a Chain Code or external logic) can be added so that only code approved by the quality control organization or system (e.g., represented by the servers14) is cleared for compilation and testing. This can result in higher quality code being released for compilation and testing, resulting in less costs due to inappropriate or low quality code being released for the testing.

5—When the source code is compiled, the hash of the resulting binary is added as a new block on the blockchain18indicating the code version that has been compiled. The hash of the generated binary will then allow tracing any binary in production to a specific code written in a specific workstation by a specific developer.

6.1—Software testing is now able to identify which code files result in which binary image. This can allow the test process to assist development by correctly identifying which file, or files, need correction.

6.2—As with quality control steps, approved code is released for packaging and production by adding an appropriate release order to the blockchain18.

7—The whole blockchain18, or parts of it, can be made public and distributed in a network of servers which ensures the integrity of the data in the database. Systems can be audited to identify the original source code without the auditors need to access the original source files.

In an embodiment where any participant (e.g., any operators of the workstations12and any operators of the consumer systems20) can generate and commit a block to the blockchain18, blocks that are trusted for inclusion in the blockchain18are determined by a consensus model. The consensus model in some blockchain implementations such as “Bitcoin” use a “proof of work” model. In the proof of work model, participants' computers are used as hashing nodes, which compete to calculate a very specifically formatted hash code. However, this consensus model can be overly expensive and energy-inefficient for some implementations, such as business environments where there is already a degree of trust and/or authentication. Rather than proof-of-work, a model based on proof-of-stake, as set forth more fully above, can be used.

Accordingly, in embodiments that assume a more controlled environment, blocks do not need to be “mined” by computing-intensive hash solving. Rather, the origin of blocks can be validated by using digital signatures and authentication that will be validated by the peer nodes of the blockchain network. Signature authentication can be provided by existing components such as in the Hyperledger architecture referenced above.

Nevertheless, embodiments are not limited to use of proof-of-stake, and proof-of-work may still be used in some implementations, especially implementations involving potentially untrusted nodes.

FIG. 2-1illustrates an example message sequence diagram illustrating example messaging that may occur between various modules12,46,18,36,48,40,20,16, of an example computing environment, e.g., the computing environment10ofFIG. 1. Note that an overall message sequence60extends fromFIG. 2-1throughFIG. 2-2and includes different groups of message sequences, e.g., a QA control sequence68, a compiler-release sequence80(which occurs that if a source code file is released for use by a consumer), a consumer software installation sequence90(as shown inFIG. 2-2), and a continuous deployment sequence96(also shown inFIG. 2-2).

Furthermore, note that some of the scenarios illustrated inFIGS. 2-1 and 2-2differ from those discussed with reference toFIG. 1. Accordingly, the example ecosystem10ofFIG. 1may represent an alternative embodiment of the system implementing the message sequencing60inFIG. 2, and vice versa.

For example, unlike inFIG. 1, the sequence60inFIGS. 2-1 and 2-2suggests that the source code hash is being computed on the workstation12, and then registered with the blockchain18by software running on the workstation12. As such, the workstation12can also include blockchain interfacing code (that is not shown as residing on the workstation12ofFIG. 1).

Furthermore, inFIGS. 2-1 and 2-2, the binary hash is computed by one or more modules of the compiler36, as opposed by a separate binary hash function module34(inFIG. 1) running on one or more of the servers14ofFIG. 1. Note that inFIG. 1, hash computations are offloaded to the one or more distributed quality control servers14, which act as nodes hosting blockchain replicas, forming the distributed ledger, i.e., blockchain18.

Furthermore, note that inFIGS. 2-1 and 2-2, other types of common messaging are omitted for clarity, e.g., messaging involving the sending and receiving of request messages. However those skilled in the art with access to the present teachings may readily implement the appropriate request messaging and other types of messaging to meet the needs of a given implementation, without undue experimentation.

The overall message sequence60includes a first message62, which includes source code that is sent from the workstation12to the source code repository46. A second message64sends a source code hash and workstation identification information to the blockchain18for registration. In a third message66, the code hash that was registered in the blockchain18via the previous message64is forwarded to the source code repository46for storage in association with the corresponding source code (which may be included in one or more source code files).

Next, the QA control sequence68is shown. The QA control sequence68includes sending a fourth message70from the source code repository46to the complier36. The fourth message70includes the source code file that was previously stored in the source code repository46, and its hash registered in the blockchain18.

The compiler36then converts the source code file into a binary file, which is sent from the compiler36to the binary repository48as a fifth message72. The binary repository48then releases the binary file to the QA module or service40for analysis, via a sixth message74. If a binary hash for the binary file has already been registered in the blockchain18, then the QA module40retrieves the binary hash from the blockchain18via a seventh message76.

After the QA module40completes testing of the binary file, the test results are forwarded for registration with the blockchain18in association with the binary file. If the test results are passing results, then the compiler-releasing sequence80is performed.

The compiler-releasing sequence80includes a ninth message82that is sent from the source code repository46to the compiler36. The ninth message82includes the source code corresponding to the binary that was tested by the QA module40. The compiler36the retrieves the previously registered source code hash from the blockchain18, via a tenth message84.

The compiler36then uses the retrieved source code file and source code hash to compute a binary hash in accordance with a binary hash function implemented by the compiler36. The computed binary hash is then sent to the blockchain18for registration, via an eleventh message86. (Note that this scenario differs fromFIG. 1, where the binary hash is shown being computed separately from the compiler36.) The binary file is then sent by the compiler36to the binary repository48, via a twelfth message88.

FIG. 2-2is a continuation ofFIG. 2-1. After the binary file has been stored in the binary repository48, via the twelfth message88ofFIG. 2-1, an optional consumer software installation sequence90is performed.

The consumer software installation sequence90includes releasing binary and associated binary hash files to a client or customer (called a consumer herein) system20, via a thirteenth message92. The consumer system20then retrieves the binary hash that was registered in the blockchain18, via a fourteenth message94. The consumer system20may then compare the hash files obtained from the binary repository48with the registered hash files to ensure that the downloaded binary has not been corrupted or altered, i.e., the binary hashes match.

Next, an alternative continuous deployment sequence96occurs. The continuous deployment sequence96includes the compiler36retrieving source code and corresponding source code hash files from the source code repository46, via a fifteenth message98. The compiler36uses the retrieved source code to generate a binary file and to compute a hash of the binary file.

In the present example embodiment, the resulting binary hash is shown as being transferred to the source code repository46for storage in association with the corresponding source code stored therein, via a sixteenth message100. Note however, the binary hash may, alternatively or additionally, be transferred for storage in the binary repository48(e.g., if it has not already been stored therein).

Next, the compiler36forwards the binary (e.g., as an executable image) to the production server16, e.g., in preparation for hosting the software application as a web application.

FIG. 3is a flow diagram of a first example method110, implementable via the computing environments ofFIGS. 1-2, for facilitating digital asset traceability, etc. The example method110links source and binary files by virtue of versioning applied to each, and includes a first step112, which involves determining or otherwise receiving a request to register a digital asset in the networked computing environment.

With reference toFIGS. 1 and 3, the request may be issued by the workstation12, which may communicate with the blockchain18via the one or more networked servers14, i.e., blockchain nodes.

A second step114includes computing a first hash of an initial source file of the digital asset. With reference toFIGS. 1 and 3, the computation of the first hash may be implemented by the source hash function32, and the source file corresponds to the source code files26.

A third step116includes ascertaining a version of the initial source file. With reference toFIGS. 1 and 3, the version of the first source file can be determined by the version controller36and/or the provenance analyzer42, e.g., by referencing source code registration information in the blockchain18, which may include timestamp data pertaining to a particular source code version, the name of the code, etc. Note that version information can also be extracted, in some instances, by analyzing source file metadata sent along with the initial source code files26ofFIG. 1.

A fourth step118includes electing one or more nodes of a distributed ledger of the networked computing environment to commit the first hash to the distributed ledger in association with a version of the digital asset corresponding to the version of the initial source file. With reference toFIGS. 1 and 3, the one or more nodes may correspond to the distributed servers14, and the distributed ledger corresponds to the blockchain18. The committal process may be implemented via one or more of the blockchain interfacing modules44, e.g., in accordance with a consensus method, such as proof-of-stake, as set forth above.

A fifth step120includes converting the source file into a binary file, resulting in a binary version of the digital asset. With reference toFIGS. 1 and 3, conversion of the source file into a binary file is performed by a compiler, such as the compiler36.

A sixth step122includes computing a second hash, wherein the second hash is of the binary file. With reference toFIGS. 1 and 3, the computation of the second hash of the binary file can be performed by the binary hash function34.

A seventh step124includes committing the second hash to the distributed ledger in association with the version of the digital asset. With reference toFIGS. 1 and 3, the committal process, involving verifying and registering a transaction containing the second hash and version information with the blockchain18.

Note that the first example method110may be altered, without departing from the scope of the present teachings. For example, the method110may augmented to further specify a step of using the version information associated with the second hash and version information associated with the first hash to associate one or more binary file hashes in the distributed ledger with one or more source files in a source file repository, a workstation from which the source file originated, and a developer of the source file. The first example method110may further specify that the distributed ledger includes a blockchain, and wherein the digital asset includes software.

The first example method110may further include selectively making the binary file available to one or more client devices (e.g., corresponding to the consumer systems20ofFIG. 1) and associated one or more respective authenticated and permissioned users (e.g., consumers using the consumer systems20) of the networked computing environment, in accordance with one or more permissions allocated to the one or more authenticated and permissioned users. The one or more client devices include one or more computers of one or more customers of one or more cloud services provided in the networked computing environment.

Another optional step of the first example method110includes selectively making data in the blockchain accessible to the one or more client devices and accompanying one or more respective authenticated and permissioned users, whereby the one or more respective authenticated and permissioned users can compare a registered hash for the binary file in the blockchain with an obtained binary file. Public Key Infrastructure (PKI) and accompanying public key cryptography may be used to authenticate user permissions to access data in the blockchain.

The fourth step118may further include selecting, in accordance with a proof-of-stake mechanism, one or more nodes of the networked computing environment to implement committing the first hash, and for committing the second hash, to the blockchain. In a specific implementation, the proof-of-stake mechanism implements the following steps: referencing identifying information and associated permissions of the one or more nodes, to confirm that the one or more nodes are permissioned to commit one or more blocks to the blockchain, resulting in a set of one or more confirmed nodes; determining which of the one or more confirmed nodes first received a source file or binary file; selecting a node from among the one or more confirmed nodes to perform a calculation to commit a registration entry to the blockchain, resulting in a selected node; and using the selected node to commit the registration entry to the blockchain in combination with an indicator of the selected node that commits the registration entry to the blockchain as a block, whereby the block includes the indicator.

The first example method110may further specify the following steps: submitting the binary file to a production server; storing the source code in a source code repository that is accessible to one or more quality control mechanism; and storing the binary file in a binary code repository.

The first example method110may further include: updating the blockchain with updated source code registration information in response to detection that a new version of the source code is loaded into the source code repository, wherein the updated source code registration information includes information linking the updated source code with original source code; and updating the blockchain with updated binary registration information in response to detection that the new version of the source code has been compiled into a new binary file.

The request to register a digital asset may originate from a computer (e.g., the workstation12ofFIG. 1) with which the source code was developed or from which it was submitted. The first hash may be implemented by a hash function that receives, as input, a digital fingerprint of the source code, a user IDentification (ID), a Central Processing Unit (CPU) ID, and a Media Access Control (MAC) address, all associated with or characterizing the computer.

The first hash function provides an output hash (e.g., output from the first hash function32ofFIG. 1) that corresponds to the first hash, and which is accessible to one or more software quality control servers (e.g., the servers14ofFIG. 1). The one or more quality control servers include functionality for selectively registering, in the distributed ledger (e.g., the blockchain18ofFIG. 1), the first hash in association with source file version information.

FIG. 4is a flow diagram of a second example method130implementable via the embodiments ofFIGS. 1-3, for enabling ecosystem participants (e.g., consumers, developers, proprietors of production servers, etc.) to use the distributed ledger (blockchain) ofFIGS. 1-2to confirm that one or more binary files to be executed (run) have not been tampered with or corrupted.

The second example method includes an initial source-code generation step132, which involves generating a source code file, e.g., using the developer tools24ofFIG. 1.

Next, a source-code storing step136includes storing the source code file in a repository, e.g., the source code and hash repository46ofFIG. 1.

Subsequently, a first hash-storing step138includes storing a hash of the source code file in a blockchain, e.g., the blockchain18ofFIG. 1.

Next, a source-code compilation step140includes compiling (e.g., via the compiler36ofFIG. 1) the source code file, resulting in a generated a binary file.

Next, a second hash-storing step142includes storing a hash of the binary file (i.e., binary hash) in a block in the blockchain.

Finally, a distribution step144includes distributing the binary file so that ecosystem participants can use the distributed ledger to identify the origin of the source code file used in compiling the binary file.

Note that the second method130may be altered, without departing from the scope of the present teachings. For example, the second example method130may further specify associating the binary file with the source code file (also simply called source file herein), e.g., by providing a blockchain mechanism (e.g., including registration functionality) to enable comparing a hash of the registered binary file with a hash of a binary file retrieved, responsive to user input; and then sending the binary file to one or more computing devices (e.g., the consumer systems20and/or production server16ofFIG. 1) for installation and running.

Accordingly, registration entries in the blockchain for a particular binary file and source file include version information indicating a version of the source file and binary file, which can be used to trace a binary file back to its source file. Registered source code hashes can be further used to trace the associated source file back to the original developer and workstation, e.g., by virtue of the inputs to the first hash function32ofFIG. 1, which include User ID and workstation identification information, such as CPU ID, MAC address, etc.

Traceability, as discussed herein, enabling linking binary files with corresponding source code files, enables various additional efficient solutions to long-felt needs in the art, including facilitating digital asset version control, code release sequencing, IP protection, software bug tracing, malware attack tracing and identification of the malware writer, and so on.

Note that in certain embodiments discussed herein, the historical record of the blockchain18is substantially immutable by one or more users of the workstation12and consumer systems20ofFIG. 1.

An alternative method for facilitating digital asset traceability and facilitating software quality control in a networked computing environment includes receiving a source code file and an identification of a workstation from which the source file was received; computing a fingerprint of the source code file; calculating a first hash using the fingerprint of the source code file and the identification; selectively compiling the source code file, resulting in production of a binary file; calculating a second hash using the binary file; registering the first hash and second hash in a distributed ledger, in association with common software version, resulting in a first registration and a second registration; and using the first registration and the second registration to facilitate software quality control in the networked computing environment.

FIG. 5is a general block diagram of a system900and accompanying computing environment usable to implement the embodiments ofFIGS. 1-4. The example system900is capable of implementing a distributed software ecosystem according to embodiments of the invention. Embodiments may be implemented as standalone applications (for example, residing in a user device) or as web-based applications implemented using a combination of client-side and server-side code.

The general system900includes user devices960-990, including desktop computers960, notebook computers970, smartphones980, mobile phones985, and tablets990. The general system900can interface with any type of user device, such as a thin-client computer, Internet-enabled mobile telephone, mobile Internet access device, tablet, electronic book, or personal digital assistant, capable of displaying and navigating web pages or other types of electronic documents and UIs, and/or executing applications. Although the system900is shown with five user devices, any number of user devices can be supported.

A web server910is used to process requests from web browsers and standalone applications for web pages, electronic documents, enterprise data or other content, and other data from the user computers. The web server910may also provide push data or syndicated content, such as RSS feeds, of data related to enterprise operations.

An application server920operates one or more applications. The applications can be implemented as one or more scripts or programs written in any programming language, such as Java, C, C++, C#, or any scripting language, such as JavaScript or ECMAScript (European Computer Manufacturers Association Script), Perl, PHP (Hypertext Preprocessor), Python, Ruby, or TCL (Tool Command Language). Applications can be built using libraries or application frameworks, such as Rails, Enterprise JavaBeans, or .NET. Web content can created using HTML (HyperText Markup Language), CSS (Cascading Style Sheets), and other web technology, including templating languages and parsers.

The data applications running on the application server920are adapted to process input data and user computer requests and can store or retrieve data from data storage device or database930. Database930stores data created and used by the data applications. In an embodiment, the database930includes a relational database that is adapted to store, update, and retrieve data in response to SQL format commands or other database query languages. Other embodiments may use unstructured data storage architectures and NoSQL (Not Only SQL) databases.

In an embodiment, the application server920includes one or more general-purpose computers capable of executing programs or scripts. In an embodiment, web server910is implemented as an application running on the one or more general-purpose computers. The web server910and application server920may be combined and executed on the same computers.

An electronic communication network940-950enables communication between user computers960-990, web server910, application server920, and database930. In an embodiment, networks940-950may further include any form of electrical or optical communication devices, including wired network940and wireless network950. Networks940-950may also incorporate one or more local-area networks, such as an Ethernet network, wide-area networks, such as the Internet; cellular carrier data networks; and virtual networks, such as a virtual private network.

The system is one example for executing applications according to an embodiment of the invention. In another embodiment, application server910, web server920, and optionally database930can be combined into a single server computer application and system. In a further embodiment, virtualization and virtual machine applications may be used to implement one or more of the application server910, web server920, and database930.

In still further embodiments, all or a portion of the web and application serving functions may be integrated into an application running on each of the user computers. For example, a JavaScript application on the user computer may be used to retrieve or analyze data and display portions of the applications.

As an example, with reference toFIGS. 1 and 5, the web server910, application server920, and data storage device/database930ofFIG. 5may be used to implement the distributed ledger18ofFIG. 1by hosting server-side applications corresponding to the distributed servers14, which are in turn accessible to individual computer systems via a browser. The workstations12and consumer systems20ofFIG. 1may be implemented by one or more of the desktop computer960, tablet900, smartphone980, mobile phone985, or notebook computer970ofFIG. 5. The source code and hash repository46and binary code and hash repository48ofFIG. 1may be implemented via the data storage device/database930ofFIG. 5.

Alternatively, or in addition, the individual computing devices950,985,970,980,990may run blockchain node software and accompanying functions (as shown in the servers14ofFIG. 1) used to network the devices into a peer-to-peer software ecosystem to implement embodiments, using the wired network940and/or wireless network950.

FIG. 6is a general block diagram of a computing device usable to implement the embodiments ofFIGS. 1-5. While system500ofFIG. 6is described as facilitating performing the steps as described in certain implementations herein, any suitable component or combination of components of system500or any suitable processor or processors associated with system500may be used for performing the steps described.

FIG. 6illustrates a block diagram of an example computing system500, which may be used for implementations described herein. For example, computing system500may be used to implement server devices910,920ofFIG. 5as well as to perform the method implementations described herein. In some implementations, computing system500may include a processor502, an operating system504, a memory506, and an input/output (I/O) interface508. In various implementations, processor502may be used to implement various functions and features described herein, as well as to perform the method implementations described herein. While processor502is described as performing implementations described herein, any suitable component or combination of components of system500or any suitable processor or processors associated with system500or any suitable system may perform the steps described. Implementations described herein may be carried out on a user device, on a server, or a combination of both.

Computing device500also includes a software application510, which may be stored on memory506or on any other suitable storage location or computer-readable medium. Software application510provides instructions that enable processor502to perform the functions described herein and other functions. The components of computing system500may be implemented by one or more processors or any combination of hardware devices, as well as any combination of hardware, software, firmware, etc.

For ease of illustration,FIG. 6shows one block for each of processor502, operating system504, memory506, I/O interface508, and software application510. These blocks502,504,506,508, and510may represent multiple processors, operating systems, memories, I/O interfaces, and software applications. In various implementations, computing system500may not have all of the components shown and/or may have other elements including other types of components instead of, or in addition to, those shown herein.

As an example, with reference toFIGS. 1 and 6, the computing device500ofFIG. 6may be used to implement the workstation12and consumer systems20ofFIG. 1. The computing device500may also be used to implement each of the servers14ofFIG. 1.

Although the description has been described with respect to particular embodiments thereof, these particular embodiments are merely illustrative, and not restrictive. For example, while certain embodiments discussed herein use a blockchain to maintain registration information related to software files (e.g., source or binary files for software applications), embodiments are not limited thereto. For example another type of database may be used in certain implementations without departing from the scope of the present teachings.

Furthermore, embodiments are not necessarily limited to use in linking and tracing software binary and source files. For example, versions of embodiments discussed herein could be used to selectively link music sheets or documents (e.g., containing written music) with corresponding digitized implementations of the music (e.g., MP3 files). This could facilitate copyright enforcement in a manner analogous to that used for software, as set forth above.