​3.4​ Versioning

Versioning is the mechanism that object creators use to update and revoke the STIX Objects that they create. This section describes the versioning process and normative rules for performing versioning and revocation. STIX Objects are versioned using the revoked, created, and modified properties. See the properties table in section 3.1 for full definitions and normative usage of those properties.

STIX Objects MAY be versioned in order to update, add, or remove information. A version of a STIX Object is identified uniquely by the combination of its id and modified properties. The first version of the object MUST have the same timestamp for the created and modified properties. More recent values of the modified property indicate later versions of the object. Implementations MUST consider the version of the STIX Object with the most recent modified value to be the most recent state of the object. For every new version of an object, the modified property MUST be updated to represent the time that the new version was created. If a consumer receives two objects that are different, but have the same id and modified timestamp, it is not defined how the consumer handles the objects. This specification does not address how implementations should handle versions of the object that are not current.

STIX Objects have a single object creator, the entity that generates the id for the object and creates the first version. The object creator may (but not necessarily will) be identified in the created_by_ref property of the object. Only the object creator is permitted to create new versions of a STIX Object. Producers other than the object creator MUST NOT create new versions of that object. If a producer other than the object creator wishes to create a new version, they MUST instead create a new object with a new id. They SHOULD additionally create a derived-from Relationship object to relate their new object to the original object that it was derived from.

Every representation (each time the object version is serialized and shared) of a version of an object (identified by the object's id and modified properties) MUST always have the same set of properties and the same values for each property. In order to change the value of any property, or to add or remove properties, the modified property MUST be updated with the time of the change to indicate a new version.

Objects can also be revoked, which means that they are no longer considered valid by the object creator. As with issuing a new version, only the object creator is permitted to revoke a STIX Object. A value of true in the revoked property indicates that an object (including the current version and all past versions) has been revoked. Revocation is permanent: once an object is marked as revoked, later versions of that object MUST NOT be created. Changing the revoked property to indicate that an object is revoked is an update to the object, and therefore its modified property MUST be updated at the same time. This specification does not address how implementations should handle revoked data.

​3.4.1​ Versioning Timestamps

There are two timestamp properties used to indicate when STIX Objects were created and modified: created and modified. The created property indicates the time the first version of the object was created. The modified property indicates the time the specific version of the object was created. The modified time MUST NOT be earlier than the created time. This specification does not address the specifics of how implementations should determine the value of the creation and modification times for use in the created and modified properties (e.g. one system might use when the object is first added to the local database as the creation time, while another might use the time when the object is first distributed as STIX).

​3.4.2​ New Version or New Object?

Eventually an implementation will encounter a case where a decision must be made regarding whether a change is a new version of an existing object or is different enough that it is a new object. This is generally considered a data quality problem and therefore this specification does not provide any normative text.

However, to assist implementers and promote consistency across implementations, some rules of thumb are provided. Any time a change indicates a material change to the meaning of the object, a new object with a different id should be used. A material change is any change that the object creator believes substantively changes the meaning of the object. As an example, an object creator might consider changing a Threat Actor from one country to another is a material change. These decisions are always made by the object creator. The object creator should also think about relationships to the object when deciding if a change is material. If the change would invalidate the usefulness of relationships to the object, then the change is considered material and a new object id should be used.

Examples

Example of a new version

One object creator has decided that the previous name they used for a SDO is incorrect. They consider that change as an update to the object.

Note: the IDs in the example below use a simplified format to help illustrate the changing IDs more clearly.

Example of derived object

One object creator has decided that the previous name they used for a SDO is incorrect. They consider that change fundamental to the meaning of the object and therefore revoke the object and issue a new one.

Example consumer workflow

This section describes an example workflow where a consumer receives multiple updates to a particular object. (In this example, the STIX Objects have been truncated for brevity.)

​

Example object creator workflow

This section describes an example workflow where a object creator publishes multiple updates to a particular object. This scenario assumes a human using a STIX implementation. (In this example, the STIX Objects have been truncated for brevity.)