This GitHub public repository cti-go-stix was created at the request of the CTI TC as an OASIS TC Open Repository to support development of open source resources related to Technical Committee work.
While this TC Open Repository remains associated with the sponsor TC, its development priorities, leadership, intellectual property terms, participation rules, and other matters of governance are separate and distinct from the OASIS TC Process and related policies.
All contributions made to this TC Open Repository are subject to open source license terms expressed in the BSD-3-Clause License. That license was selected as the declared applicable license when the TC Open Repository was created.
As documented in CONTRIBUTING, contributions to this OASIS TC Open Repository are invited from all parties, whether affiliated with OASIS or not. Participants must have a GitHub account, but no fees or OASIS membership obligations are required. Participation is expected to be consistent with the OASIS TC Open Repository Guidelines and Procedures, the open source LICENSE designated for this particular repository, and the requirement for an Individual Contributor License Agreement that governs intellectual property.
OASIS Go STIX API: a repository containing the MVP implementation of Go STIX APIs
A STIX object is a Go map. The Go type is named STIXObject and is based
on a map[string]any. To invoke validation from another map, one can call
STIXObject.FromMap():
var indicator STIXObject
err := indicator.FromMap(map[string]any{
"type": "indicator",
"name": "File hash for malware variant",
"indicator_types": []any{"malicious-activity"},
"pattern_type": "stix",
"pattern": "[file:hashes.md5 = 'd41d8cd98f00b204e9800998ecf8427e']",
"valid_from": "2014-08-25T15:00:07.527004Z",
})This will populate the indicator map with validated/cleaned content from
the given map data. There are some STIX object initialization conveniences,
for example a STIX ID is created automatically with a UUIDv4 (or a
deterministic ID for SCOs with ID contributing properties), and versioning
properties are added in objects of versionable types, with the current
timestamp. So it is okay to omit them in the map above.
Creating a STIXObject from JSON will automatically invoke
cleaning/validation:
// assuming import "encoding/json"
var indicator STIXObject
err := json.Unmarshal([]byte(
`{
"type": "indicator",
"spec_version": "2.1",
"id": "indicator--dbcbd659-c927-4f9a-994f-0a2632274394",
"created": "2017-09-26T23:33:39.829Z",
"modified": "2017-09-26T23:33:39.829Z",
"name": "File hash for malware variant",
"indicator_types": [
"malicious-activity"
],
"pattern_type": "stix",
"pattern_version": "2.1",
"pattern": "[file:hashes.md5 ='d41d8cd98f00b204e9800998ecf8427e']",
"valid_from": "2017-09-26T23:33:39.829952Z"
}`,
), &indicator)Being a map, the Go standard library already knows how to serialize a
STIXObject to a JSON object. Instances of special types which the
cleaning process puts into the map have custom JSON serialization included
with this library. So one can dump to JSON using standard APIs as usual:
// assuming import "encoding/json"
jsonBytes, err := json.Marshal(indicator)STIX 2.0 style "custom" content is not supported. This means that it is not possible to add arbitrary custom top-level properties to a registered object type, in the absence of a toplevel property extension. Additional 2.0 style markings can't be registered (tlp 1.0 and statement markings are supported).
STIX 2.1 style extensions are supported, however. Unregistered extension objects are passed through without error, with the exception that spec-defined common properties are still checked (e.g. version timestamps, STIX ID, etc). Unregistered property extensions allow arbitrary properties.
This module includes an ANTLR generated parser for the STIX Patterning grammar, and a simplified API to parse a pattern. The generated code is the stix2/patternParser package. Convenience API for STIX Patterning is found in the stix2/utils package.
This version of cti-go-stix brings support to STIX Version 2.1 published on 10 June 2021 currently at the Committee Specification (CS) 03 level, also known as the "OASIS Standard".
The stix2 Go library does not currently support older versions of the STIX 2 Technical Specification.
TC Open Repository Maintainers are responsible for oversight of this project's community development activities, including evaluation of GitHub pull requests and preserving open source principles of openness and fairness. Maintainers are recognized and trusted experts who serve to implement community goals and consensus design preferences.
Initially, the TC members have designated one or more persons to serve as Maintainer(s); subsequently, participating community members may select additional or substitute Maintainers, by consensus agreements.
Current Maintainers of this TC Open Repository are:
- Rich Piazza, rpiazza, MITRE
- Marlon Taylor, GHID, DHS CISA
Questions or comments about this TC Open Repository's activities should be composed as GitHub issues or comments. If use of an issue/comment is not possible or appropriate, questions may be directed by email to the Maintainer(s) listed above.
Please send general questions about TC Open Repository participation to OASIS Staff at repository-admin@oasis-open.org and any specific CLA-related questions to repository-cla@oasis-open.org.