Software Instance node

A Software Instance (SI) node represents an instance of an off-the-shelf software product or equivalent proprietary item of software. It can correspond to one single running process or a group of processes (possibly on multiple hosts). A Software Instance often corresponds to a licensable entity. Where possible, versions of Software Instances are retrieved and stored. They are created, maintained and destroyed by patterns. Software Instance nodes always have a relationship to the Pattern node corresponding to their maintaining pattern.

• A first-order Software Instance is one that models a piece of software running directly on the OS.
• A second-order Software Instance is one that models software formed from first-order Software Instances.

Software Instance Lifecycle

The lifecycle of an SI node depends upon the details of the pattern that maintains it. This is determined by a combination of the pattern trigger condition, whether the pattern specifies an explicit key for the Software Instance, and the logic contained in the pattern itself. In all cases, if a pattern is deleted, the SI nodes it maintains are immediately destroyed (as are all other nodes it might be maintaining).

Patterns can trigger on a Directly Discovered Data node, see Directly Discovered Data Trigger. They can also trigger on the creation or modification of other SI nodes, see Software Instance Trigger.

Directly Discovered Data Trigger

Creation/update

If a pattern triggers on a Directly Discovered Data node, such as a Discovered Process node or a Discovered Listening Port node, it might choose whether to specify keys for the SI nodes it creates and maintains. If a key is specified, then the decision whether to create a new SI node or to update an existing one depends on the key. If a SI node with the specified key exists, that node is updated, even if the node was previously maintained by a different pattern. In this case, the pattern takes over as the maintainer of the Software Instance. If a node with the specified key does not exist, a new SI node is created. In both cases, the Software Instance node is linked to the pattern with a maintainer relationship.

If a key for the Software Instance node is not specified by the pattern, the system creates or updates a group SI with an automatically generated key. The key is based on the key of the hosting node (Host or Cluster) on which the SI is running, the specified type of the SI, and optionally, a key group that can be used to separate the nodes into a number of groups. The count attribute is set to the number of instances in the group identified in the collection of Directly Discovered Data. Each time the host is scanned, the count attribute is changed to represent the number of instances seen in that scan.

Removal

The Software Instance node, including in a clustered environment, can be destroyed either manually or automatically.

To manually remove an SI node, find the necessary SI, select it from the list, and select Destroy from the Actions list.

The Software Instance is automatically removed in the following scenarios:

The age_count attribute of the (first order) SI node contains information about when the SI node was last confirmed by its maintaining pattern. If the age_count is positive, it represents the number of consecutive scans of the Host node in which the Software Instance was confirmed. If the age_count is negative, it represents the number of consecutive scans in which the SI node was not confirmed. The last_update_success and last_update_failure attributes contain the date and time at which the Software Instance node was last confirmed, and not confirmed, respectively.

In a clustered environment, the SI node is automatically destroyed when the Cluster node that contains the SI is deleted or when aging determines that the instance can be deleted.The aging of clustered Software Instances is performed slightly differently than normal SIs. This is because clustered SIs can be running on different hosts at different times due to a failover, or it can be running on multiple hosts of the cluster. Therefore, the age count for a clustered SI is stored on each Hosted Software relationship with a host of the cluster. If a cluster is configured to support a failover software, a flag is maintained to indicate whether the software is actively running on this host. When the age_count of all Hosted Software relationships for a clustered SI exceeds the aging threshold, only then the SI node is destroyed.

If the pattern does not have a removal block, SI nodes are removed using an aging strategy based on the age_count and last_update_success attributes. The default aging parameters are the same as for a Host-node, that is, if a SI node has not been seen for at least 7 scans, over a period of at least 10 days, it is destroyed. The parameters can be changed in the options, see Configuring-model-maintenance-settings for more information.

The default aging strategy only applies to Software Instance nodes created from patterns triggering on the following node kinds and maintaining the Software Instances:

• DiscoveredProcess
• DiscoveredService
• DiscoveredListeningPort
• DiscoveredSoftware

If the SI is triggered on anything else, for example, a discovered file, then aging must be implemented in the pattern using a removal block.

If the pattern maintaining a node does have a removal block, the block can override the default aging scheme to destroy its nodes either earlier or later than normal. For TKU patterns, refer to the documentation accompanying each pattern for details of special removal behavior.

Regardless of the presence or absence of a removal block in the pattern, if the Host corresponding to a DDD-triggered Software Instance node is destroyed, the Software Instance node is immediately destroyed (see How nodes get removed).

Software Instance trigger

Creation/update

When patterns trigger on the creation or modification of other Software Instance nodes, the behavior is simpler. In this situation, the pattern must provide a key for each Software Instance node. The key is used to find an existing Software Instance node to update, or to create a new one. In both cases, the node is linked to the pattern with a maintainer relationship.

Removal

Software Instance nodes created as a result of Software Instance triggers are destroyed using the Cascade removal type; when the triggering Software Instance node is destroyed, the destruction is cascaded to the higher-level Software Instance node. See Cascade Removal.

Stable SI

Stable SIs are used to model containerized software. A Stable SI can be regarded as information about why the software is present; it represents the deployment. For example, where Nginx is running in a pod that is managed by Kubernetes, it represents the template used to deploy the particular configuration of the Nginx software that runs in the pods. It is not linked to the host on which the pods are running; it is linked to the deployment.

To make sure that the model takes into account the content of the containers, all child nodes of the Contained SI are copied to the Default partition under the Stable SI. This means that the model reflects the content of the containers, without the churn that occurs in the normal operation of containerized software.

Stable SIs show the quantity or number of instances of software running, which can be used, for example, for licensing queries and vulnerability assessments.

Stable SI aging

A deployment managed by Kubernetes is modeled as a Stable SI. The Stable SI is not aged, it is only removed when the Kubernetes resource is removed, even if all of the containers that Kubernetes is managing have been removed. This approach caters for the following situations:

• A deployment has been scaled to zero, for example, for maintenance, and is likely to be scaled up again. The Stable SI is retained until the Kubernetes resource (Deployment, DaemonSet, StatefulSet) is deleted.
• While scanning a large cluster, the timing of the removal and redeployment of containers means that the discovery scan misses them.

Where containers are running on a host, the Stable SI is linked to the host node. When the Contained SIs are removed, the Stable SI remains and is aged out as a 'normal' SI.

Attributes of the SoftwareInstance node

The attributes of the SoftwareInstance node are described in the following table:

Relationships of the SoftwareInstance node

The relationships of the SoftwareInstance node are described in the following table:

Expressions of the SoftwareInstance node

The expressions of the SoftwareInstance node are described in the following table: {anchor:exprs}