NISTIR 8060

Guidelines for the Creation ofInteroperable Software Identification(SWID) Tags
David Waltermire
Brant A. Cheikes
Larry Feldman
Greg Witte

This publication is available free of charge from:http://dx.doi.org/10.6028/NIST.IR.8060

NISTIR 8060

Guidelines for the Creation ofInteroperable Software Identification(SWID) Tags
David Waltermire
Computer Security Division
Information Technology Laboratory
Brant A. Cheikes
The MITRE Corporation
Bedford, Massachusetts
Larry Feldman
Greg Witte
G2, Inc.
Annapolis Junction, Maryland

This publication is available free of charge from:http://dx.doi.org/10.6028/NIST.IR.8060
April 2016

U.S. Department of Commerce
Penny Pritzker, Secretary
National Institute of Standards and Technology
Willie May, Under Secretary of Commerce for Standards and Technology and Director

National Institute of Standards and Technology Internal Report 8060
86 pages (April 2016)
This publication is available free of charge from:http://dx.doi.org/10.6028/NIST.IR.8060
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
available for the purpose.
There may be references in this publication to other publications currently under development by NIST in
accordance with its assigned statutory responsibilities. The information in this publication, including concepts andmethodologies, may be used by federal agencies even before the completion of such companion publications. Thus,
until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain
operative. For planning and transition purposes, federal agencies may wish to closely follow the development ofthese new publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide feedback
to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at
http://csrc.nist.gov/publications.

Comments on this publication may be submitted to:
National Institute of Standards and Technology
Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930
Email: nistir8060-comments@nist.gov

All comments are subject to release under the Freedom of Information Act (FOIA).

Reports on Computer Systems Technology
The Information Technology Laboratory (ITL) at the National Institute of Standards andTechnology (NIST) promotes the U.S. economy and public welfare by providing technicalleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advancethe development and productive use of information technology. ITL’s responsibilities include thedevelopment of management, administrative, technical, and physical standards and guidelines forthe cost-effective security and privacy of other than national security-related information infederal information systems.
Abstract
This report provides an overview of the capabilities and usage of software identification (SWID)
tags as part of a comprehensive software lifecycle. As instantiated in the International
Organization for Standardization/International Electrotechnical Commission 19770-2 standard,
SWID tags support numerous applications for software asset management and information
security management. This report introduces SWID tags in an operational context, provides
guidelines for the creation of interoperable SWID tags, and highlights key usage scenarios forwhich SWID tags are applicable.
Keywords
software; software asset management; software identification (SWID); software identificationtag
Acknowledgments
The authors would like to thank Harold Booth, Bob Byers, Christopher Johnson, and Alex J.
Nelson of the National Institute of Standards and Technology (NIST); Steve Klos of
TagVault.org and 1E; Christine Deal and Charles Schmidt of The MITRE Corporation; Piotr
Godowski and Brian Turner of IBM; Hopeton Smalling of OQI Cares, Inc.; Sharon Hope ofNASA Jet Propulsion Laboratory; and John Richardson of Veritas for their reviews andcontributions of feedback to this report. The authors would also like to thank Dr. Peter Fonash
and Juan Gonzalez from the U.S. Department of Homeland Security (DHS) for their ongoingsupport for and contributions to this report. The authors would also like to thank Jessica
Fitzgerald-McKay from the National Security Agency (NSA) for supporting the development of
this report.
Trademark Information
Any mention of commercial products or reference to commercial organizations is for information
only; it does not imply recommendation or endorsement by NIST, nor does it imply that the
products mentioned are necessarily the best available for the purpose.
All names are trademarks or registered trademarks of their respective owners.

iiDocument Conventions
This report provides both informative and normative guidance supporting the use of SWID tags.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in thisreport are to be interpreted as described in Request for Comment (RFC) 2119 [RFC 2119]. Whenthese words appear in regular case, such as “should” or “may”, they are not intended to beinterpreted as RFC 2119 key words.
Some of the requirements and conventions used in this report reference Extensible Markup
Language (XML) content. These references come in two forms, inline and indented. An example
of an inline reference is: A patch tag is differentiated by the fact that the value of the @patch
attribute within the <SoftwareIdentity> element is “true”.
In this example, the notation <SoftwareIdentity> can be replaced by the more verbose
equivalent “the XML element whose qualified name is SoftwareIdentity”.
The general convention used when describing XML attributes within this report is to reference
the attribute as well as its associated element, employing the general form “@attributeNamefor the <prefix:localName>”. Attribute values are indicated in quotations, such as theexample “true” above.
In cases where any valid value may be provided for an XML attribute, this report specifies“<any>” as the attribute value.
This report defines a number of new XML attributes that are extensions to the SWID
specification. These extension attributes are defined in a new XML namespace,http://csrc.nist.gov/ns/swid/2015-extensions/1.0. These new attributes will be assigned the prefix“n8060” mapped to this namespace. In guidelines and examples, extension attributes will be
provided in the form “@n8060:attributeName”. The schema for these extensions can be
downloaded at http://csrc.nist.gov/schema/swid/2015-extensions/swid-2015-extensions-1.0.xsd.
Indented references are intended to represent the form of actual XML content. Indented
references represent literal content by the use of a fixed-length font, and parametric (freely
replaceable) content by the use of an italic font. Square brackets “[]” are used to designate
optional content.
Both inline and indented forms use qualified names to refer to specific XML elements. A
qualified name associates a named element with a namespace. The namespace identifies the
XML model, and the XML schema is a definition and implementation of that model. A qualified
name declares this schema to element association using the format “prefix:element-name”. The
association of prefix to namespace is defined in the metadata of an XML document and varies
from document to document.
Many portions of this document include cross references to other sections. Such references areoften indicated by the use of the “section symbol” (§), with two symbols indicating multiple
sections (§§).
iii

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Table of Contents
1

Introduction ............................................................................................................ 1
1.1 Problem Statement ......................................................................................... 1
1.2 SWID Tag Benefits ......................................................................................... 2
1.3 Purpose and Audience.................................................................................... 4
1.4 Section Summary............................................................................................ 5
1.5 Report Structure ............................................................................................. 62

SWID Tag Overview ............................................................................................... 7
2.1 SWID Tag Types and the Software Lifecycle .................................................. 7
2.1.1 Corpus Tags ......................................................................................... 8
2.1.2 Primary Tags ........................................................................................ 9
2.1.3 Patch Tags ......................................................................................... 10
2.1.4 Supplemental Tags............................................................................. 12
2.2 SWID Tag Creation ....................................................................................... 13
2.2.1 Corpus Tags ....................................................................................... 13
2.2.2 Primary and Patch Tags ..................................................................... 13
2.2.3 Supplemental Tags............................................................................. 14
2.3 SWID Tag Deployment ................................................................................. 14
2.3.1 Deployment during Installation ........................................................... 14
2.3.2 SWID Tag Generation from Existing Package Management Data ..... 15
2.3.3 Deployment of SWID Tags in a Repository ........................................ 16
2.4 Summary ...................................................................................................... 16

3

SWID Tag Structure ............................................................................................. 17
3.1 SWID Tag Data Elements ............................................................................. 17
3.1.1 <SoftwareIdentity>: The Root of a SWID Tag .................................... 17
3.1.2 <SoftwareIdentity> Sub-Element: <Entity> ......................................... 21
3.1.3 <SoftwareIdentity> Sub-Element: <Evidence> ................................... 23
3.1.4 <SoftwareIdentity> Sub-Element: <Link> ........................................... 24
3.1.5 <SoftwareIdentity> Sub-Element: <Meta> .......................................... 26
3.1.6 <SoftwareIdentity> Sub-Element: <Payload> ..................................... 27
3.2 Authenticating SWID Tags ............................................................................ 27
3.3 A Complete Primary Tag Example ................................................................ 29
3.4 Summary ...................................................................................................... 30
iv

NISTIR 8060

4

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Implementation Guidance for All Tag Creators ................................................. 31
4.1 Limits on Scope of Guidelines ...................................................................... 31
4.2 Authoritative and Non-Authoritative Tag Creators......................................... 32
4.3 Implementing <SoftwareIdentity> Elements .................................................. 32
4.4 Implementing <Entity> Elements .................................................................. 33
4.4.1 Providing Detailed Information about Entities ..................................... 34
4.4.2 Preventing Complex Entity Specifications .......................................... 34
4.4.3 Distinguishing Between Authoritative and Non-Authoritative Tags ..... 35
4.4.4 Furnishing Information about the Software Creator ............................ 36
4.5 Implementing <Link> Elements ..................................................................... 36
4.5.1 Linking a Source Tag to a Known Target Tag .................................... 36
4.5.2 Linking a Tag to a Collection of Tags ................................................. 37
4.6 Implementing <Payload> and <Evidence> Elements.................................... 41
4.6.1 Providing Sufficient File Information ................................................... 41
4.6.2 Selecting the Hash Function ............................................................... 42
4.6.3 Handling of Path Separators and Environment Variables................... 43
4.7 Providing Attribute Values in Multiple Languages ......................................... 45
4.7.1 Specifying Product Names in Multiple Languages ............................. 46
4.7.2 Specifying <Entity> Elements in Multiple Languages ......................... 46
4.7.3 Specifying <Payload> Elements in Multiple Languages ..................... 47
4.8 Updating Tags .............................................................................................. 49
4.9 Summary ...................................................................................................... 50

5Implementation Guidance Specific to Tag Type................................................ 51
5.1 Implementing Corpus Tags ........................................................................... 51
5.1.1 Setting the <SoftwareIdentity> @corpus Attribute .............................. 51
5.1.2 Specifying the Version and Version Scheme in Corpus Tags ............ 51
5.1.3 Specifying the Corpus Tag Payload ................................................... 53
5.2 Implementing Primary Tags .......................................................................... 53
5.2.1 Setting the <SoftwareIdentity> Tag Type Indicator Attributes............. 53
5.2.2 Specifying the Version and Version Scheme in Primary Tags ............ 53
5.2.3 Specifying Primary Tag Payload and Evidence .................................. 54
5.2.4 Specifying Product Metadata Needed for Targeted Search ............... 56
5.3 Implementing Patch Tags ............................................................................. 56v

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

5.3.1 Setting the <SoftwareIdentity> @patch Attribute ................................ 57
5.3.2 Specifying Patch Tag Payload and Evidence ..................................... 57
5.4 Implementing Supplemental Tags................................................................. 58
5.4.1 Setting the <SoftwareIdentity> @supplemental Attribute ................... 58
5.4.2 Linking Supplemental Tags to Other Tags ......................................... 58
5.4.3 Establishing Precedence of Information ............................................. 58
5.5 Summary ...................................................................................................... 59
6

SWID Tag Usage Scenarios ................................................................................ 60
6.1 Minimizing Exposure to Publicly Disclosed Software Vulnerabilities ............. 60
6.1.1 US 1: Continuously Monitoring Software Inventory ............................ 60
6.1.2 US 2: Ensuring that Products are Properly Patched ........................... 65
6.1.3 US 3: Identifying Vulnerable Endpoints .............................................. 66
6.2 Enforcing Organizational Software Policies .................................................. 68
6.2.1 US 4: Preventing Installation of Unauthorized or Corrupted Software 69
6.2.2 US 5: Preventing the Execution of Corrupted Software ...................... 70
6.3 US 6: Preventing Vulnerable Devices from Accessing Network Resources . 71
6.4 Association of Usage Scenarios with Guidelines .......................................... 72
List of Appendices

Appendix A— Acronyms ............................................................................................ 76
Appendix B— References .......................................................................................... 77
List of Figures
Figure 1: SWID Tags and the Software Lifecycle ............................................................ 8
Figure 2: Primary Tag Relationships ............................................................................. 10
Figure 3: Patch Tag Relationships ................................................................................ 11
Figure 4: Supplemental Tag Relations .......................................................................... 12

List of Tables
Table 1: How Tag Types Are Indicated ......................................................................... 20
Table 2: <Link> Relations.............................................................................................. 25
Table 3: Allowed Values of @versionScheme............................................................... 52
Table 4: Relationship of Guidelines to Usage Scenarios............................................... 74vi

NISTIR 8060

1

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSIntroduction

The International Organization for Standardization (ISO) and the International ElectrotechnicalCommission (IEC) has published ISO/IEC 19770-2, an international standard for software
identification tags, also referred to as SWID tags. A SWID tag is a structured set of data elementsthat identify and describe a software product. The first version of the standard, ISO/IEC
19770-2:2009 [ISO/IEC 19770-2:2009], was published in November 2009. A significantly
revised version of the standard, ISO/IEC 19770-2:2015 [ISO/IEC 19770-2:2015], was publishedin October 2015, and is referenced herein as the SWID specification.
This report provides an overview of the capabilities and usage of SWID tags defined by the
ISO/IEC 19770-2:2015 standard. Additionally, this report describes the use of SWID tags as partof comprehensive software asset management lifecycles and cybersecurity procedures. Section
1.1 discusses the software asset management and cybersecurity problems that motivated thedevelopment of SWID tags. Section 1.2 highlights the stakeholder benefits that can be gained as
SWID tags become more widely produced and consumed within the software marketplace.
Section 1.3 describes the purpose and target audiences of this report. Section 1.4 summarizes thissection’s key points, and Section 1.5 describes how the rest of this report is organized.
1.1

Problem Statement

Software is part of the critical infrastructure for the modern world. Enterprises and individuals
routinely acquire software products and deploy them on the physical and/or virtual computing
devices they own or operate. This report refers to an instance of such a computing device as adevice. ISO/IEC 19770-5 [ISO/IEC 19770-5:2013], a companion standard to the SWID
specification, defines software asset management (SAM) as “control and protection of softwareand related assets within an organization, and control and protection of information about related
assets which are needed in order to control and protect software assets.” A core SAM process issoftware inventory management—the process of building and maintaining an accurate andcomplete inventory of all software products deployed on all of the devices under anorganization’s or individual’s operational control.
Accurate software inventories of managed devices are needed to support higher-level business,
information technology, and cybersecurity functions. For example, enterprises need to know how
many copies of a given product are installed in order to ensure compliance with software license
agreements. To ensure they are not paying for unneeded licenses, enterprises also need to know
where specific copies are installed. As another example, operations personnel need accurate andcomplete software inventories to ensure that all deployed software assets are authorized,
appropriately patched, free of known exploitable weaknesses, and configured according to theirorganizations’ security policies. Organizations may also use software inventory information toplan software investments and resources needed to support upgrades to and replacement oflegacy systems.
Effective software inventory management depends on the ability to discover, identify, andcontextualize software products installed on managed devices. Software discovery processes
analyze observable states of a managed device to detect and enumerate discrete units of installedsoftware. Discovery is technically challenging due to the enormous variation across the software
1

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

industry in what it means to be a unit of software. For example, a single unit of software may
consist of a combination of executable files, data files, configuration files, library files, and soforth. A single unit of software may also include supporting software units which may be
independently installed and executed, as well as changes to the underlying operating
environment, such as the addition of device drivers and entries in operating-system maintainedtables and databases. Discovery processes need to be able to handle all these sources of variation
while avoiding “false positives” (i.e., erroneous reports that a unit of software is present) as well
as “false negatives” (i.e., failures to report discovery of a unit of software that is, in fact,
present).
Once the discrete units of software have been enumerated on a device, software identification
processes assign identifying labels to those units. These labels are used in various contexts torefer to the products, report their presence, and correlate with other sources of information. A
key requirement of the labeling process is that when the same unit of software is discovered on
different devices, it must be assigned the same label. Identification is technically challenging
because the identifying labels are not physically part of the software units, nor can they bediscovered in the same manner. Instead, the labels are assigned using inferential techniques
based on observable features which vary widely by software provider, operating environment,
and device. These inferential techniques may be inaccurate, unreliable, and/or proprietary.
Assuming software units can be discovered and identified, software contextualization processes
associate the identifying label with other sources of enriching information. For example, thelabel of a software unit may be used to collect key descriptive characteristics, such as thesoftware unit’s exact version, license keys, patch level, associated files in device storage areas,
and associated configuration settings. As another example, the assigned software identifier may
also be used to search for related patches, upgrades, vulnerabilities and remedies, andconfiguration checklists. Contextualization is technically challenging to the extent that it depends
on widespread agreement on, and dissemination of, the identifying labels to be assigned to unitsof software.
The SWID tag standard was developed to help overcome the technical challenges associatedwith software discovery, identification, and contextualization, and thereby enhance the accuracy
and reliability of software asset management processes. SWID tags aid discovery by furnishing astandardized indicator of a software product’s presence on a device. Tags aid identification by
including a consistent label for a product within its tag. Finally, tags aid contextualization by
allowing a wide variety of related product details to be supplied, including the product’s fullname and version.
1.2

SWID Tag Benefits

SWID tags offer benefits to creators and publishers of software products, as well as those who
acquire and use those software products. The SWID specification identifies these stakeholdersas:•

Tag producers: Organizations and entities that create SWID tags for use by others in themarket. Examples of tag-producing organizations include the organizations (or theirauthorized agents) involved in creating, licensing, packaging, and/or distributing software
products. These organizations are best able to ensure that tags contain correct, complete,
2

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

and consistent data when describing software products. Tag producers are responsible forestablishing a norm for data values in the tags they produce, with a goal of ensuring thatthe same data values are used, where possible and appropriate, across tags for similar
products or product versions they produce. Tags may also be produced and distributed bythird parties, as well as by automated discovery tools.
•

Tag consumers: Organizations and entities that use information contained in SWID tags
to support higher-level, software-related business and cybersecurity functions. Categories
of tag consumers include software consumers, inventory/discovery tools, inventory-based
cybersecurity tool providers (e.g., providers of software vulnerability management
products, which rely on accurate inventory information to support accurate vulnerability
assessment), and organizations that use these tools.

The implementation of SWID tags supports these stakeholders throughout the entire software
lifecycle—from software creation and release through software installation, management, andde-installation. As more software creators also become tag producers and release their productswith SWID tags, more consumers of software products are enabled to consume the associatedtags. This gives rise to a “virtuous cycle” where all stakeholders gain a variety of benefits,
including the abilities to:•Consistently and accurately identify software products that need to be managed for
purposes such as inventory, licensing, and cybersecurity, or for the management ofsoftware and software dependencies.

•

Use stable software identifiers to report changes to a device’s software load as products
are installed, patched, upgraded, and removed.

•

Exchange software information between software producers and consumers in astandardized format, regardless of software creator, platform, or management tool.

•

Identify and manage software products equally well at any level of abstraction, regardlessof whether a product consists of a single application or one or more groups or bundles.

•

Correlate information about installed software with other information, including list(s) ofauthorized software, related patches, configuration settings, security policies, and threat
advisories.

•

Automatically track and manage software license compliance and usage by combining
information within a SWID tag with independently-collected software entitlement data.

•

Aggregate deployed software asset information across an enterprise, providing theorganization with knowledge of what software is deployed on specific devices.

•

Record details about the deployed footprint of installed products on devices, such as thelist of supporting software components, executable and data files, system processes, andgeneric resources that may be included in the installation (e.g., device drivers, registry
settings, accounts).

•

Identify all organizational entities associated with the installation, licensing, maintenance,and management of a software product on an ongoing basis. This identification includes
entities external to the software consumer (e.g., software creators, software licensors,
packagers, and distributors), and those internal to the software consumer’s organization.
3

NISTIR 8060•
1.3

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Use digital signatures to validate that information within a tag comes from a known
source and has not been corrupted.
Purpose and Audience

This report has three purposes. First, it provides a high-level description of SWID tags in order toincrease familiarity with the standard. Second, it provides tag implementation guidelines that
supplement the SWID tag specification. Third, it presents a set of operational usage scenarios,
which illustrate how SWID tags conforming to these guidelines can be used to achieve a variety
of cybersecurity goals. By following the guidelines in this report, tag producers can haveconfidence they are providing all the necessary data, with the requisite data quality, to support
the operational goals of each tag usage scenario. Additionally, tag consumers can haveconfidence that the tags they are using adequately support each tag usage scenario.
This report addresses four distinct audiences. The first audience is software providers – theindividuals and organizations that develop, license, and/or distribute commercial, open source,
and custom software products, to include software developed solely for in-house use. This report
helps providers understand the problems addressed by SWID tags, why providers’ participation
is essential to solving those problems, and how providers may produce and distribute tags that
support a wide range of usage scenarios.
The second audience is providers of software build, packaging, and installation tools – theindividuals and organizations that develop tools used by software providers to build, package,release, and support installation of software. These tools can provide much of the informationneeded for SWID tag creation. If these tools provide the ability to generate SWID tags as part oftheir native functionality, SWID tags can be produced by software providers with minimal effort.
Using this approach, SWID tags can be generated automatically for any software releasemanaged by the tool, increasing the availability of SWID tags for related products. Support forsuch a SWID tag generation capability is critical for ensuring that SWID tags are provided aspart of all commercial and open source software releases. Furthermore, it is important that
installation tools support the consistent management of installed tags on devices during software
installation, upgrade, patch, and removal processes. The guidance in this report identifies the
SWID tag information needed to ensure that tags generated by these tools support the usage
scenarios required by software consumers.
The third audience is providers of inventory-based products and services – the individuals andorganizations that develop tools for discovering, monitoring, and managing software assets forany reason, including securing enterprise networks using standardized inventory information.
This audience needs consistency in the content and interpretation of data in SWID tags collectedfrom computing devices to make full use of this information. This report offers guidance tosoftware providers on how to consistently implement tags to support SWID tag usage scenarios.
The degree of consistency supported by this guidance helps inventory-based product providers to
use tag data to materially enhance the quality and coverage of software information collected andutilized by their products.
The fourth audience is software consumers – the individuals and organizations that install anduse commercial, open source, and/or in-house developed software products, and inventory-based
products and services. This report helps software consumers understand the benefits of software
4

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

products that are delivered with SWID tags, and why they should encourage software providers
to deliver products with SWID tags that meet their anticipated usage scenarios. The guidance
provided in this report to software providers also promotes the production of tags that are usefulin meeting the usage scenarios of software consumers.
Using a set of well-defined usage scenarios, this report identifies how the goals of these four
audiences are interrelated. Consumers are trying to cope with software management andcybersecurity challenges that require accurate software inventory. Consumers also are seeking
solutions that help to reduce the total cost of ownership for the software they manage.
Consumers need to understand how SWID tags can help them, need providers to supply highquality tags, and need implementers of inventory-based tools to collect and use tags.
Providers need to recognize that adding tags to their products will make their products more
useful and more manageable, and also need this recognition to be reinforced by consumer
demand for tag support. Software build and installation tool providers can assist software
providers with producing tags for software releases and managing tags as part of software
installation processes. Inventory-based tool implementers are uniquely positioned to recognize
how tags can make their products more reliable and effective, and to work constructively withboth consumers and providers to promote software tagging practices.
1.4

Section Summary

The following are the key points of this section:•

The ISO/IEC 19770-2:2015 international standard specifies the data format for SWID
tags described by this report.

•

SWID tags were developed to help enterprises meet the need for accurate and complete
software inventories to support higher-level business and cybersecurity functions.

•

SWID tags provide benefits to organizations that create and use tags.

•

Four audiences have interrelated goals pertaining to SWID tags and tagging practices:o Software providers often want to increase the manageability of their products fortheir customers. To justify investing the resources necessary to become tag
providers, they need consumers to send clear signals that they value productmanageability as much as features, functions, and usability.
o Providers of software build, packaging, and installation tools often want tosupport SWID tags in their tools. This support can assist software providers that
use their tools with generating tags during product build and release processes.
Additionally, these tools can support the management of installed tags on devices
during software installation, upgrade, patch, and removal processes. Providers
need clear guidance on what information needs to be included in a SWID tag toensure that they generate useful tags for software consumers.
o Providers of inventory-based products and services often want to use SWID tags
as their primary method for identifying software. These providers need tags to
become more widely available in order to make their specialized tools more
5

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

reliable and effective based on tag data. They act as software providers as well assoftware consumers, and thus have the needs and goals of both audiences.
o Software consumers often want software providers to supply tags along with theirproducts as a common practice. Consumers need tags to be routinely provided inorder to cope with the challenges of maintaining an accurate software inventory,
and to address software-related management and cybersecurity issues.
•

1.5This report seeks to raise awareness of the SWID tag standard, promote understanding of
the business and cybersecurity benefits that may be obtained through increased adoptionof software tagging standards and practices, and provide detailed guidance to bothproducers and consumers of SWID tags to promote consistency and interoperability.
Report Structure

The remainder of this report is organized into the following sections and appendices:•

Section 2 presents general SWID tag concepts that are helpful for understanding thedifferent types of tags, how tags are created, and how tags are made available for use.

•

Section 3 presents the SWID tag data elements described in the SWID specification, anddiscusses specific data elements that support the authentication of tags.

•

Section 4 provides implementation guidelines that address common issues related to tag
deployment and processing on information systems.

•

Section 5 provides implementation guidelines for specific types of tags.

•

Section 6 presents usage scenarios for software asset management and software integrity
management processes which are enhanced through the use of SWID tags.

•

Appendix A presents a list of acronyms used in this report.

•

Appendix B provides the references for the report.

6

NISTIR 8060

2

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSSWID Tag Overview

A SWID tag is a standardized XML format for a set of data elements that identify and describe asoftware product. This report uses the term tagged software product (or, simply, tagged product)
to refer to a software product that is installed on a device along with one or more discoverable
tags describing that product.
This section provides a general overview of concepts related to SWID tags and is organized asfollows. Section 2.1 describes the four types of SWID tags and the distinct role each type of tag
plays at key points in the software lifecycle. Section 2.2 discusses common methods for creatingtags. Section 2.3 discusses expectations regarding the deployment of SWID tags. Finally, Section
2.4 concludes with a summary of key points from this section.
2.1

SWID Tag Types and the Software Lifecycle

The SWID specification defines four types of SWID tags: corpus, primary, patch, andsupplemental. Corpus, primary, and patch tags have similar functions in that they describe theexistence and/or presence of different types of software, and, potentially, different states ofsoftware products. In contrast, supplemental tags furnish additional information not contained in
corpus, primary, or patch tags. All four tag types come into play at various points in the software
lifecycle, and support software management processes that depend on the ability to accurately
determine where each software product is in its lifecycle. Figure 1 illustrates the steps in thesoftware lifecycle and the relationships among those lifecycle events supported by the four typesof SWID tags, as follows:•

Software Deployment. Before the software product is installed (i.e., pre-installation),
and while the product is being deployed, a corpus tag provides information about the
installation files and distribution media (e.g., CD/DVD, distribution package).

•

Software Installation. A primary tag will be installed with the software product (orsubsequently created) to uniquely identify and describe the software product.
Supplemental tags are created to augment primary tags with additional site-specific or
extended information. Patch tags may also be installed during software installation toprovide information about software fixes deployed along with the base software
installation.

•

Software Patching. When a new patch is applied to the software product, a new patch
tag is provided, supplying details about the patch and its dependencies.

•

Software Upgrading. As a software product is upgraded to a new version, new primaryand supplemental tags replace existing tags, enabling timely and accurate tracking of
updates to software inventory.

•

Software Removal. Upon removal of the software product, relevant SWID tags are
removed. This removal event can trigger timely updates to software inventory reflecting
the product’s removal.

7

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Figure 1: SWID Tags and the Software Lifecycle

The software lifecycle events described in Figure 1 represent typical uses of tags within thesoftware deployment lifecycle. While not depicted in Figure 1, software discovery, configuration
management, and vulnerability management processes generate other lifecycle events which may
create and use primary, patch, and supplemental tags. The four tag types related to software
lifecycle events are discussed in the following subsections.
2.1.1

Corpus Tags

Before software is installed, it is typically delivered or otherwise made available to a computing
device in the form of a software installation package. The installation package contains thesoftware in a pre-installation condition, often compressed in some manner. Common formats for
installation packages include TAR and ZIP files, and “self-unpacking” executable files. In allcases, an installation procedure must be run to cause the software contained in an installation
package to be unpacked and deployed on a target device. The SWID specification defines corpus
tags for vendors and distributors to use to identify and describe products in such a preinstallation state. The availability of software identification and descriptive information for asoftware installation package enables verification of the software package and authentication of
the organization releasing the package.
Corpus tags are intended to be used as inputs to software installation tools and processes; they
are not installed on devices as part of an installation procedure. Corpus tags may be used byinstallation tools to verify the integrity of an installable product, and to authenticate the issuer of
an installation package before executing the installation procedure (see §3.2). If a manifest of theinstallation files is included in the corpus tag (see §3.1.6 on the <Payload> element),
installation package tampering can be detected and the installation procedure aborted if the
payload data and the actual files do not match. When combined with other licensing data, corpus
tags may aid consumers in confirming whether they have a valid license for a product before
they install it. All of this information can be used as part of an automated policy decision toallow or prevent the software installation (see §6.2.1) on a device.

8

NISTIR 8060

2.1.2

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSPrimary Tags

As previously illustrated in Figure 1, primary tags are involved in different software lifecycle
events. The SWID specification defines primary tags to identify and describe software products
once they have been successfully installed on a computing device. The primary tag for eachtagged product needs to furnish values for all data elements that are designated “mandatory” in
the SWID specification. A minimal primary tag supplies the name of the product (as a string), a
globally unique identifier for the tag, and basic information identifying the tag’s creator.
Ideally, the software provider is also the creator of that product’s primary tag; however, the
SWID specification allows other parties (including automated tools) to create tags for products incases where software providers have declined to do so or have delegated this responsibility toanother party. The SWID specification recognizes a number of alternative roles for creators oftags, including organizations and individuals which aggregate, distribute, and license software
products (see §3.1.2).
A globally unique tag identifier is essential information in many usage scenarios because it may
be used as a globally unique proxy identifier for the software installation. The tag identifier of a
primary tag can be considered a proxy identifier for the tagged product because there is a one-toone relationship between the primary tag and the installed software it identifies. For increased
processing efficiency, inventory and discovery tools may choose to identify and report tagged
products using just their tag identifiers rather than their fully populated primary tags.
When a product is upgraded, the primary tag(s) associated with the old version are removed andreplaced with primary tag(s) for the new version. When a product is removed from a device, its
primary tag(s) are removed as well. By strictly maintaining the one-to-one association between
installed software and associated tags, it is possible to continuously monitor installed software
inventory and track software updates using SWID tag data (see §6.1.1).
Because software products may be furnished as suites or bundles or as add-on components forother products, the SWID specification defines a <Link> element (see §3.1.4), which may be
used within a SWID tag to indicate relationships between the product described by the tag andother products or items that may be available. Two noteworthy relationships are:•

Component. Indicates that the product described by the primary tag has a separately
installable software product as one of its components. In such situations, the product’s
primary tag points to the primary tag of the component product using a <Link> element
where the @rel attribute is set to “component”.

•

Requires. Indicates that the product described by the primary tag depends on a separately
installable software product. In such situations, the primary tag points to the primary tagof the required product using a <Link> element where the @rel attribute is set to“requires”.

The relationships that may be expressed in primary tags are illustrated in Figure 2 below. Thisillustration shows how primary SWID tags may indicate the associations among several software
components. The figure shows an overarching Productivity Suite that has a component
relationship with each of its supporting applications. The figure also shows how the two
9NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

subsidiary products may require other component software (e.g., language pack, spell checking
software).

Figure 2: Primary Tag Relationships

2.1.3

Patch Tags

A software provider may release patches to correct errors in, or add new features to, a product.
When a patch is installed on a device, changes are made to a product’s installation footprint.
Since a patch augments an existing installation, these changes need to be tracked separately. The
SWID specification defines patch tags for software providers to identify and describe each patch.
When a patch is installed, a patch tag is placed on the device in a location associated with thepatched product. When a patch tag is not provided by a software provider, discovery tools cancreate a patch tag to indicate the previous application of a patch. In contrast with a patch, an
upgrade is defined as a complete replacement of a product’s installation footprint. An upgrade
typically changes the product’s version number and/or release details.
The data elements contained in a patch tag identify and describe the patch, rather than the
product to which the patch is applied. For example, the product name and version recorded in apatch tag need not match the product name and version recorded in the patched product’s
primary tag. Instead, these attributes can be used to record the name and version of the patch
assigned by the software provider.
A patch tag can indicate relationships between the patch described by the patch tag and otherproducts or patches that may be available using the <Link> element (see §3.1.4). Three types ofrelationships are worth noting here:•

Patches. Indicates that a patch applies to a patched product. In such situations, thepatch’s patch tag points to the primary tag of the patched product using a <Link>
element where the @rel attribute is set to “patches”.

10

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS•

Requires. Indicates that a patch requires the prior installation or co-existence of anotherpatch. In such situations, the patch’s patch tag points to the patch tag of the required
patch using a <Link> element where the @rel attribute is set to “requires”.

•

Supersedes. Indicates that a patch can entirely replace another patch. In such situations,
if the other patch is installed, it might be removed or overwritten when the new patch isinstalled. This is expressed using a <Link> element where the @rel attribute of thesuperseding patch tag is set to “supersedes” with a pointer to the patch tag of thesuperseded patch.

When used in this way, patch tags may assist in determining whether an installed product has all
required patches applied (see §6.1.2). Figure 3 illustrates the tag relationships for four productpatches that can be applied over time.

Figure 3: Patch Tag Relationships

All patches have @rel=patches Product, since they all patch the same product.
Patch 2 has @rel=requires Patch 1, since Patch 1 must be installed before Patch 2.
Patch 3 has @rel=supersedes Patch 2, since Patch 3 entirely replaces Patch 2. Although notdepicted here, Patch 3 could also require or supersede Patch 1 depending on the specificscenario. Such additional relationships would be indicated by additional <Link> elements.
Patches 1 and 4 are completely independent of the other two patches, so their patch tags do notinclude any <Link> elements pointing to any of the other patch tags.
A patch can include a manifest of the new and/or changed files (see §3.1.6 for discussion on the<Payload> element), which can be used to verify that the actual patched files are present on
the device. This allows for confirmation that the patch has been correctly installed and remains
installed, preventing a malicious actor from deploying files that misrepresent the installation
status of a patch.

11

NISTIR 8060

2.1.4

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Supplemental Tags

The SWID specification allows tags to be modified only by the tag creator. To provide amechanism whereby consumers and software management tools may add arbitrary postinstallation information of local utility, the SWID specification allows for any number ofsupplemental tags to be installed, either at the same time the primary tag is installed, or at any
time thereafter.
Any entity may create a supplemental tag for any purpose. For example, supplemental tags may
be created by automated tools in order to augment an existing primary tag with additional sitespecific information, such as license keys and contact information for local responsible parties.
Each supplemental tag contains a pointer to the tagged product’s primary tag using a <Link>
element where the @rel attribute is set to “supplemental”. When supplemental tags arepresent, a tag consumer may create a complete record of the information describing a product by
combining the data elements in the product’s primary tag with the data elements in any linked
supplemental tags.
The relationships that may be expressed in supplemental tags are illustrated in Figure 4.

Figure 4: Supplemental Tag Relations

Supplemental tags may also be employed to augment non-primary tags. For example, a
supplemental tag could add local information about a patch tag (e.g., to record a timestamp
indicating when the patch was applied), or even about another supplemental tag (as illustrated in#3 above). In such situations, the supplemental tag also contains a <Link> element pointing to
the tag that is having its information augmented.
A supplemental tag is intended to furnish data values that augment and do not conflict with data
values provided by the primary tag and any of the product’s other supplemental tags. If conflicts
are detected, data in the primary tag, if provided by the software producer, is considered the mostreliable, and tools can be expected to ignore conflicting data or to report all conflicting data as
exceptions. For example, the mandatory product name recorded in a supplemental tag is
expected to match the product name recorded in the product’s primary tag; if they are different,
the name recorded in the primary tag is considered the preferred name.
As previously illustrated in Figure 1, after a software product is upgraded, all primary, patch, andsupplemental tags associated with the pre-upgrade version of the product will be removed. If
12

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

needed, new supplemental tags associated with the upgraded version may be deployed. When asoftware product is removed, all primary, patch, and supplemental tags associated with the
product will be removed.
2.2

SWID Tag Creation

A SWID tag for a software package, product, or patch can be created in a number of ways. The
following subsections describe the circumstances under which SWID tags are created and how
the method of SWID tag creation impacts their use.
2.2.1

Corpus Tags

Corpus tags provide information about a software installation package. To ensure that the mostcomplete and accurate information is provided, a corpus tag is ideally created through an
automated process when the software installation package is created. Generation of a corpus tag
is typically done as part of the software build and release process thereby ensuring that the tag is
included with the software installation package and available for use during the installation
processes described in Section 2.1.1. Additionally, the corpus tag can be signed to enable
authentication of the tag provider as the software provider, verification of the tag’s integrity, andverification of the software installation package footprint (see §3.2).
In cases where a corpus tag is not created by the software provider as part of the package
creation process, a secondary party may generate a corpus tag using information gathered byanalyzing an existing software installation package provided by another organization. This typeof creation pattern is not ideal, since the secondary party may not have all the needed
information, resulting in a corpus tag that contains incomplete or inaccurate information.
Furthermore, while the tag can still be signed, the organization signing the tag will differ fromthe software installation package provider. This means that although the signed tag can still be
used to authenticate the tag provider, to verify the tag’s integrity, and to verify the software
installation package footprint, the tag’s signature cannot be used to authenticate that the tag
provider is the software provider. This results in a lesser degree of assurance.
2.2.2

Primary and Patch Tags

To maximize the availability, accuracy, and completeness of information contained within a
primary or patch tag, it is important that such a SWID tag be created during a product’s build
and/or release process by an authoritative source such as the software provider. As software is
being prepared for release, build and packaging processes can automatically generate primaryand patch tags using authoritative information made available during these processes. This is theideal case for tag creation since the information available during these processes tends to be themost accurate and authoritative. Additionally, a primary or patch tag can be signed, enabling theauthentication of the tag provider as the software provider, verification of the tag’s integrity, andverification of the software’s installed footprint (see §3.2).
If creation of a primary or patch tag at build or release time is not possible, a second approach is
to create a SWID tag after the software is installed using authoritative information from asoftware package database. While this information may be equivalent to the information
available during a build or packaging process, signing of these tags is not possible, since thesoftware provider’s signing key cannot be distributed. This limitation greatly reduces the13

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

assurance of the SWID tag since the tag provider cannot be authenticated, and neither the tag’s
integrity nor the integrity of the software’s installed footprint can be verified.
Lastly, a primary or patch tag can be created as the result of a technical analysis process. This
type of creation can be performed by an entity that obtains a copy of a product after its release tomarket or by an automated software discovery tool that analyzes software installed on a device.
In both cases, the resulting tag will likely contain incomplete or inaccurate information due to alack of authoritative information. In the latter case, either the tag will be a matching tag retrieved
from a store of previously analyzed tags, or the tag will be generated directly from theinformation available on the device. If a stored tag is used, it may be signed by the discovery tool
vendor, allowing the signature to be used to authenticate the tag provider, verify the tag’s
integrity, and verify the installed footprint of the software discovered. However, the installedfootprint might not be completely accurate, and the tag’s signature cannot be used to authenticatethat the tag provider is the software provider, resulting in a lesser degree of assurance.
2.2.3

Supplemental Tags

Supplemental tags provide a flexible and extensible means to augment the information provided
in a corpus, primary, or patch tag to assist with the overall management of software, supporting
related processes (e.g., configuration management, vulnerability management). The creators of
supplemental tags can vary along with the uses of the supplemented information. The assuranceof a supplemental tag can be improved through the application of a tag signature in the sameways as previous examples; however, in many cases, supplemental tags will be generated
directly on the device, making signing impractical.
2.3

SWID Tag Deployment

This section describes various factors regarding the deployment of SWID tags. Section 2.3.1
describes how and where SWID tags should be deployed as the result of installing new software,
applying a patch, or performing an update to existing software. Section 2.3.2 describes the
deployment of SWID tags that are generated from existing package management data. Section
2.3.3 provides information about storing SWID tags within a repository separate from a software
installation.
2.3.1

Deployment during Installation

The most common method of tag deployment is for a tag to be incorporated into a product’s
installation package, which then installs the tag on a device during the installation procedure.
Such a procedure may be run during the installation of new software, when applying a patch, or
when updating existing software. This method of tag deployment is available when the tag
creator is able to ensure that the tag is included in the installation package. The SWID
specification makes the following statements about SWID tag deployment in this situation:
On devices with a file system, but no API [application programming interface] defined toretrieve SWID tags, the SWID tag data shall be stored in an XML file and shall belocated on a device’s file system in a sub-directory named “swidtag” (all lower case) thatis located in the same file directory or sub-directory of the install location of the software
component with which they are installed. It is recommended, but not required, that theswidtag directory is located at the top of the application installation directory tree. Any
14

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

payload information provided must reference files using a relative path of the location
where the SWID tag is stored. On devices that do not have a file system, the SWID tag
data shall be stored in a data storage location defined and managed by the platform
provider for that device. […] On devices that utilize both a file system for software
installation as well as API access to the SWID tag files, it is recommended that the SWID
tag data be stored in the API managed repository as well as stored as a file on the system.
[…] Finally, the SWID tag data may also be accessible via a URI, or other means […][ISO/IEC 19770-2:2015, pp. 6-7].
The SWID specification provides the following rules and recommendations when creating names
for SWID tag files:
Filenames should be restricted to use only the characters listed in the Portable Filename
Character Set defined in IEEE 1003.1:2013, 3.278 to maximize interoperability between
platforms. If this limitation is too restrictive, the tag creator shall ensure that thecharacters used in the filename are valid characters for all platforms where their SWID
tags may be stored on a file system. SWID tag base filenames (i.e., the filename without
the .swidtag extension) shall be structured to be globally unique for the tag creator andproduct. SWID tag creators may use different approaches to defining the base portion of
the SWID tag filename; however, if the filename aligns with the following structure, thefilename will be unique for the product and recognizable by a system administrator<name of the tag creator> + <product name>.swidtag. The .swidtag file extension shallbe used for all software identification tags. [ISO/IEC 19770-2:2015, p. 8]
Following this guidance, for example, the SWID tag referencing product name “ACMERoadrunner” from the software creator “acme.com” could be stored in a file named“acme.com.acmeroadrunner.swidtag”.
As a general rule, after a tag has been installed on a device, software discovery processes areable to recover the tag from that device. This allows the product described by the tag to be listed
in the software inventory associated with the device.
2.3.2

SWID Tag Generation from Existing Package Management Data

The second method of tag deployment is implicit and may be applicable in situations where
software products are not accompanied by vendor-provided tags. Some operating environments
furnish a standard package management system that automatically maintains a database ofdetailed product information as software products are installed or updated. In such cases, it may
be possible to generate SWID tags dynamically by mapping fields in the package manager’s
database to tag data elements. Depending on the richness of the package manager’s database,dynamically generated tags may contain highly reliable information, including all of the required
data elements and many optional data elements.
When a tag is produced dynamically on the installation host in this way, digital signing of the tag
is not possible. As a result, the integrity of the tag cannot be verified based on a digital signatureunless an equivalent tag is also produced using the first method described above. Absent a
verified tag signature, processes on the device and downstream consumers of the information
15

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

within a SWID tag may have less assurance of the tag’s authenticity and integrity, limiting theuse of the SWID tag information in usage scenarios that require a high degree of assurance.
2.3.3

Deployment of SWID Tags in a Repository

A third method of tag deployment is to store SWID tags in accessible repositories. By retrieving
specific tags from an appropriate repository, software consumers can do the following:•

Confirm that a tag discovered on a device has not been modified; this can be done bycomparing the tag on the device with the corresponding tag found in the repository.

•

Restore a tag that has been inadvertently deleted.

•

Repair a tag that has been improperly modified.

•Utilize the information in the tag to support various software-related management andanalysis processes.

2.4

Summary

The SWID specification defines four different types of tags to support various portions of thesoftware lifecycle, including software deployment, installation, patching, upgrading, andremoval.
•Corpus tags provide information about a software distribution, such as information about
the files that it includes. This information may be used to verify the integrity and/or
authenticity of the software distribution during software deployment.

•

Primary tags provide specific information (e.g., product naming information, thesoftware creator, lists of files expected to be included) regarding a software product thathas been installed or patched.

•

Patch tags provide specific information about a software patch that has been provided tocorrect errors in, or add new features to, a product. A patch tag supplies information
about the changes that a patch makes to the patched software product’s installation
footprint including files added, removed, or changed.

•

Supplemental tags provide a mechanism to describe additional information related toother tags.

Any entity may create a supplemental tag for any purpose. For example, supplemental tags may
be created by automated tools in order to augment an existing primary tag with additional sitespecific information, such as license keys and contact information for local responsible parties.
By deploying tags in consistent locations, inventory processes and automated tools are able toreliably and accurately determine and maintain software inventory.
Tags may also be deployed in accessible repositories to make tag information available for use
by other management and cybersecurity processes.

16

NISTIR 8060

3

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSSWID Tag StructureThis section reviews the structure of SWID tags. Section 3.1 presents an overview of the basic
tag data elements that are used to identify and describe software products. Section 3.2 discusses
how SWID tags may be authenticated. Section 3.3 presents an example of the primary tag type,and Section 3.4 concludes with a summary of key points from this section.
To correctly implement tags, interested readers may obtain the SWID specification and thecorresponding XML schema definition (XSD). When used with a validating XML parser, the
XSD can be used to check that a SWID tag is conformant with the SWID specification. An upto-date and extensively documented XSD may be downloaded at no cost from:http://standards.iso.org/iso/19770/-2/2015-current/schema.xsd
3.1

SWID Tag Data Elements

This section discusses the basic data elements of a SWID tag, and explains how the four tag
types described in Section 2.1 are distinguished from each other.
A SWID tag (whether corpus, primary, patch, or supplemental) is represented as an XML root
element with several sub-elements. <SoftwareIdentity> is the root element, and it isdescribed in Section 3.1.1. The following sub-elements are used to express distinct categories of
product information: <Entity> (see §3.1.2), <Evidence> (see §3.1.3), <Link> (see§3.1.4), <Meta> (see §3.1.5), and <Payload> (see §3.1.6).
3.1.1<SoftwareIdentity>: The Root of a SWID Tag

Besides serving as the container for all the sub-elements described in later subsections, the<SoftwareIdentity> element provides attributes to record the following descriptive
properties of a software product:•@name: the string name of the software product or component as it would normally bereferenced, e.g., “ACME Roadrunner Management Suite”. A value for @name isrequired according to the SWID specification.

•@version: the detailed version of the product, e.g., “4.1.5”. In the SWID specification,a value for @version is optional and defaults to “0.0”. Sections 5.1.2 and 5.2.2 of thisreport provide guidelines that require a value for @version in corpus and primary tags.

•@versionScheme: a label describing how version information is encoded, e.g.,“semver”. In the SWID specification, a value for @versionScheme is optional anddefaults to “multipartnumeric”. Sections 5.1.2 and 5.2.2 of this report provide
guidelines that require a value for @versionScheme in corpus and primary tags.

•@tagId: a globally unique identifier that may be used as a proxy identifier in othercontexts to refer to the tagged product. A value for @tagId is required according to the
SWID specification.

17

NISTIR 8060•

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS@tagVersion: an integer that allows one tag for a software product to supersede
another without suggesting any change to the underlying software product being
described. Typical reasons for an increment in @tagVersion include correcting
erroneous information in an older version of a tag, or adding new information that was
not included in a previously deployed tag. A value for @tagVersion is optional anddefaults to “0” according to the SWID specification.
Under normal conditions, it would be unexpected to discover multiple tags in the same
location on a device that all identify the same installed product by having the same@tagId attribute value, but different @tagVersion attribute values. Such a situation
likely reflects a failure to properly maintain the device’s inventory of SWID tags.
Nevertheless, should such a situation be encountered, the tag with the highest@tagVersion is considered to be the most up-to-date tag, and the others may beignored. When considering tags in this situation, it is important to verify tag signatures, if
available, to ensure that the most up-to-date tag being considered contains a valid XML
signature (see §3.2). Furthermore, it is important that this signature contains a valid
certificate to avoid using a tag that might have been produced by an unauthorized party.
For example, if a tag with a @tagVersion value of x is found to contain an invalid
signature, a safer choice would be a valid tag with a @tagVersion value that is lower
than but as close to x as possible (e.g., x-1), and that also has a valid signature.

•@supplemental: a boolean value that, if set to “true”, indicates that the tag type is
supplemental (see §2.1.4). A value for @supplemental is optional and defaults to“false” according to the SWID specification.

•@patch: a boolean value that, if set to “true”, indicates that the tag type is patch (see§2.1.3). A value for @patch is optional and defaults to “false” according to the
SWID specification.

•@corpus: a boolean value that, if set to “true”, indicates that the tag type is corpus(see §2.1.1). A value for @corpus is optional and defaults to “false” according to the
SWID specification.

18

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Table 1 illustrates how the tag type may be determined by inspecting the values of @corpus,@patch, and @supplemental. If all these values are false, the tag type is primary. This
report provides guidelines requiring that, at most, one of @corpus, @patch, or@supplemental be set to true (see §§ 5.1.1, 5.2.1, 5.3.1, and 5.4.1). The SWID specification
requires that patch tags explicitly link to the primary tag(s) of the product(s) that are patched,using the “patches” relation in the <Link> @rel attribute. Section 5.4.2 of this document
provides a guideline requiring supplemental tags to explicitly link to the supplemented tag(s)using the “supplemental” relation in the <Link> @rel attribute. Although they may link toother tags, there are no requirements that corpus or primary tags do so.

19

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS
Table 1: How Tag Types Are Indicated

Tag Type@supplemental@patch@corpus<Link> required @rel

Corpus

false

false

true

N/A

Primary

false

false

false

N/A

Patch

false

true

false

patches

Supplemental

true

false

false

supplemental

3.1.1.1 Example 1—Primary Product Tag

This example illustrates a primary tag for version 4.1.5 of a product named “ACME RoadrunnerManagement Suite Coyote Edition.” The globally unique tag identifier, or @tagId, is“com.acme.rms-ce-v4-1-5-0”. The <Entity> element (see §3.1.2) is included so theexample illustrates all data values required in a minimal tag that conforms to the SWID
specification. Any additional identifying data (not shown) would appear in place of the ellipsis.
<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
name="ACME Roadrunner Management Suite Coyote Edition"
tagId="com.acme.rms-ce-v4-1-5-0"
tagVersion="0"
version="4.1.5"><Entity
name="The ACME Corporation"
regid="acme.com"
role="tagCreator softwareCreator"/>…
</SoftwareIdentity>
3.1.1.2 Example 2—Supplemental Tag

This example illustrates a supplemental tag for an installed product. The globally unique
identifier of the supplemental tag is “com.acme.rms-sensor-1”. The <Entity> element(see §3.1.2) is included so the example illustrates all data values required in a minimal tag that
conforms to the standard. The <Link> element (see §3.1.4) is included to illustrate how asupplemental tag may be associated with the primary tag shown above in Section 3.1.1.1. This
supplemental tag may supply additional installation details that are not included in the product’s
primary tag (e.g., site-specific information such as contact information for the information
steward.) These details would appear in place of the ellipsis.
<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
name="ACME Roadrunner Management Suite Coyote Edition"
tagId="com.acme.rms-sensor-1"
supplemental="true"><Entity
20

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

name="The ACME Corporation"
regid="acme.com"
role="tagCreator softwareCreator"/><Link
rel="related"
href="swid:com.acme.rms-ce-v4-1-5-0">…
</SoftwareIdentity>
3.1.1.3 Example 3—Patch Tag

This example illustrates a patch tag for a previously installed product. The name of the patch is“ACME Roadrunner Service Pack 1”, and its globally unique tag identifier is“com.acme.rms-ce-sp1-v1-0-0”. <Entity> and <Link> elements are illustrated as
before. Any additional identifying data (not shown) would appear in place of the ellipsis.
<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
name="ACME Roadrunner Service Pack 1"
tagId="com.acme.rms-ce-sp1-v1-0-0"
patch="true"
version="1.0.0"><Entity
name="The ACME Corporation"
regid="acme.com"
role="tagCreator softwareCreator"/><Link
rel="patches"
href="swid:com.acme.rms-ce-v4-1-5-0">…
</SoftwareIdentity>
3.1.2<SoftwareIdentity> Sub-Element: <Entity>

Every SWID tag identifies, at minimum, the organization or individual that created the tag.
Entities having other roles associated with the identified software product, such as its creator,
licensor(s), or distributor(s), may optionally be identified using <Entity> elements contained
within the <SoftwareIdentity> element. Each <Entity> element provides the following
attributes:•@name: the string name of the entity, e.g., “The ACME Corporation”. A value for@name is required according to the SWID specification.

•@regid: the “registration identifier” of the entity. A value for @regid is required
when the <Entity> element is used to identify the tag creator (e.g.,@role=“tagCreator”), otherwise @regid is optional and defaults to“invalid.unavailable” according to the SWID specification. Additional
information about creation of @regid values is provided below.
21

NISTIR 8060•

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

@role: the role of the entity with respect to the tag and/or the product identified by thetag. Every <Entity> element contains a value for @role, and additionally, every tag
contains an <Entity> element identifying the tag creator. The @role attribute can list
multiple roles with a space separating each role. Values for @role can be selected froman extensible set of allowed tokens, including:o aggregator: An organization or system that encapsulates software from its
own and/or other organizations into a different distribution process (as in the caseof virtualization), or as a completed bundle to accomplish a specific task (as in thecase of a value-added reseller)o distributor: An entity that furthers the marketing, selling, and/or
distribution of software from the original place of manufacture to the ultimate
user without modifying the software, its packaging, or its labelingo licensor: A person or organization that owns or holds the rights to issue asoftware license for a specific software packageo softwareCreator: A person or organization that creates a software producto tagCreator: The entity that creates a given SWID tag•@thumbprint: a hexadecimal string containing a hash of the entity’s signing certificate
for SWID tags which are digitally signed (see §3.2). This allows the digital signature to
be directly related to the entity specified.

Values for @regid are uniform resource identifiers (URIs) as described in RFC 3986 [RFC3986]. Values for @regid are not required to be dereferenceable on the Internet. To ensureinteroperability and to allow for open source project support, Section 6.1.5.2 of the SWID
specification recommends that tag creators do the following when creating a value for @regid:•

Unless otherwise required, the URI should utilize the http scheme.

•

If the http scheme is used, the “http://” may be left off the regid string (a string
without a URI scheme specified is defined to use the “http://” scheme.)•

Unless otherwise required, the URI should use an absolute URI that includes an authority
part, such as a domain name.

•To ensure consistency, the absolute URI should use the minimum string required (forexample, example.com should be used instead of www.example.com).

For tag creators that do not have a domain name, the mailto scheme can be used in place of thehttp scheme to identify the tag creator by email address, e.g., mailto:foo@bar.com.
The example below illustrates a SWID tag containing two <Entity> elements. The first<Entity> element identifies the single organization that is both the software creator and the
tag creator, and the second element identifies the organization that is the software’s distributor:<SoftwareIdentity …>…
22

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

<Entity
name="The ACME Corporation"
regid="acme.com"
role="tagCreator softwareCreator"/><Entity
name="Coyote Services, Inc."
regid="mycoyote.com"
role="distributor"/>…
</SoftwareIdentity>
3.1.3<SoftwareIdentity> Sub-Element: <Evidence>

Not every software product installed on a device will be supplied with a tag. When a tag is notfound for an installed product, third-party software inventory and discovery tools will continue tobe used to discover untagged products residing on devices. In these situations, the inventory or
discovery tool may generate a primary tag on the fly to record the newly discovered product. The
optional <Evidence> element may then be used to store results from the scan that explain why
the product is believed to be installed. To that end, the <Evidence> element provides two
attributes and four sub-elements, all of which are optional according to the SWID specification:•@date: the date the evidence was collected.

•@deviceId: the identifier of the device from which the evidence was collected.

•<Directory>: filesystem root and directory information for discovered files. If noabsolute directory is provided, the directory is considered to be relative to the directory
location of the SWID tag.

•

<File>: files discovered and believed to be part of the product. If no absolute directory
path is provided, the file location is assumed to be relative to the location of the SWID
tag. If a parent <Directory> includes a nested <File>, the indicated file is relative
to the parent location.

•<Process>: related processes discovered on the device.

•<Resource>: other general information that may be included as part of the product.

Note that <Evidence> is represented in a SWID tag in the same manner as <Payload> (see§3.1.6). There is a key difference, however, between <Evidence> and <Payload> data. The<Evidence> element is used by discovery tools that identify untagged software. Here, thediscovery tool creates a SWID tag based on data discovered on a device. In this case, the<Evidence> element indicates only what was discovered on the device, but this data cannot be
used to determine whether discovered files match what a software provider originally released orwhat was originally installed. In contrast, <Payload> data supplies information from an
authoritative source (typically the software provider or a delegate), and thus may be used, forexample, to determine if files in a directory match the files that were designated as being
installed with a software component or software product.

23

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSThe example below illustrates a SWID tag containing an <Evidence> element. The evidence
consists of one file discovered in a folder named “rrdetector” within the device’s standard
program data area:<SoftwareIdentity …>…
<Evidence date="11-28-2014" deviceId="mm123-pc.acme.com"><Directory location=".." name="rrdetector"><File name="rrdetector.exe" size="532712”
SHA256:hash="a314fc2dc663ae7a6b6bc6787594057396e
6b3f569cd50fd5ddb4d1bbafd2b6a"/></Directory></Evidence>…
</SoftwareIdentity>
In cases where the evidence is collected from a shared location (e.g., a Network Attached
Storage [NAS] device), the provided @deviceId could reference that shared location, rather
than the device where the discovery occurs. Using this approach helps to prevent a situation
where software installed in a shared location is tagged multiple times with conflicting@deviceId values.
3.1.4<SoftwareIdentity> Sub-Element: <Link>

Modeled on the [LINK] element from the Hypertext Markup Language (HTML), SWID tag<Link> elements are used to record a variety of relationships between tags and other items. A
typical use of the <Link> element is to document a relation that exists between a product orpatch described by a source tag (the tag containing the <Link> element) and a product or patch
described by a target tag (the tag to which the <Link> element points). <Link> elements may
also be used to associate a source tag with other arbitrary information elements.
A <Link> element is often used to associate a patch tag or supplemental tag to a primary tag(see §§2.1.3 and 2.1.4). Other uses include pointing to documents containing applicable licenses,
vendor support pages, and installation media. The <Link> element has a number of attributes,
two of which are required, as follows:•@href: the value is a URI pointing to the item to be referenced. It can point to several
different values, including:o a relative URI
o a physical file location with any system-acceptable URI scheme (e.g., file://,http://, https://, ftp://)o a URI with "swid:…" as the scheme, which refers to another SWID tag by @tagIdo a URI with “swidpath:...” as the scheme, which contains an XPATH query[XPATH 2.0]. This XPATH would need to be resolved in the context of the system

24

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

by software that can look up other SWID tags and select the appropriate tag based on
the query.
•@rel: the value specifies the type of relationship between the SWID tag and the item
referenced by @href.

Table 2 lists some of the pre-defined values of the @rel attribute used this report. A more
complete list of values is presented in Section 8.6.7 of the SWID specification, and also in theschema. Note that this list may be extended to support future needs.
Table 2: <Link> Relations
Relation

Meaningcomponent

Defines a link to a component of the product. A component could
be an independently functioning application that is part of a productsuite or bundle, as well as a shared library, language pack, etc.
patchesDefines a link to the product to which the patch was applied.
requiresDefines a link to a required patch, or to any other software productthat is required in order for the product described by the source tag
to function properly.
supersedes
Defines a link to a superseded patch.
supplemental
Defines a link to a supplemental tag.
<any>
Additional relationships can be specified by referencing the Internet
Assigned Numbers Authority (IANA) Link Relations registration
library. 1
The example below illustrates how a <Link> element may be used to associate a patch tag withthe tag for the patched product:<SoftwareIdentity…
name="ACME Roadrunner Service Pack 1"
tagId="com.acme.rms-ce-sp1-v1-0-0"
patch="true"
version="1.0.0">…
<Link
rel="patches"
href="swid:com.acme.rms-ce-v4-1-5-0"/>…
</SoftwareIdentity>
The patch in this example is linked to the patched product’s tag using that product’s @tagId.

1 See http://www.iana.org/assignments/link-relations/link-relations.xhtml for the current list of defined link relations.

25

NISTIR 8060

3.1.5

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS<SoftwareIdentity> Sub-Element: <Meta><Meta> elements are used to record an array of optional metadata attributes related to the tag or
the product. Several <Meta> attributes of interest are:•@activationStatus: identifies the activation status of the product. The SWID
specification provides several example values (e.g., “Trial”, “Serialized”,“Licensed”, and “Unlicensed”), but any string value may be supplied. Valid values
for @activationStatus are expected to be worked out over time by tag
implementers.

•@colloquialVersion: the informal version of the product (e.g., 2013). The
colloquial version may be the same through multiple releases of a software product where
the @version specified in <SoftwareIdentity> is much more specific and willchange for each software release.

•@edition: the variation of the product (e.g., “Home”, “Enterprise”, “Student”).

•@product: the base name of the product, exclusive of vendor, colloquial version,
edition, etc.

•

@revision: the informal or colloquial representation of the sub-version of the product(e.g., “SP1”, “R2”, “Beta 2”). Whereas the <SoftwareIdentity> element’s@version attribute will provide exact version details, the @revision attribute isintended for use in environments where reporting on the informal or colloquial
representation of the software is important. For example, if, for a certain businessprocess, an organization decides that it requires Service Pack 1 or later of a specificproduct installed on all devices, the organization can use the revision data value toquickly identify any devices that do not meet this requirement.

In the example below, a <Meta> element is used to record the fact that the product is installed
on a trial basis, and to break out the full product name into its component parts:<SoftwareIdentity …>…
name="ACME Roadrunner Detector 2013 Coyote Edition SP1"
tagId="com.acme.rd2013-ce-sp1-v4-1-5-0"
version="4.1.5">…
<MetaactivationStatus="trial"
product="Roadrunner Detector"
colloquialVersion="2013"
edition="coyote"revision="sp1"/>…
</SoftwareIdentity>

26

NISTIR 8060

3.1.6

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS<SoftwareIdentity> Sub-Element: <Payload>

The optional <Payload> element is used to enumerate the items (e.g., files, folders, licensekeys) that may be installed on a device during software product installation. In general,<Payload> lists the files that may be installed with a software product, and could be a supersetof those files (e.g., because some optional files might not be installed on the device).
The <Payload> element is a container for <Directory>, <File>, <Process>, and/or<Resource> elements, similar to the <Evidence> element (see §3.1.3). When the<Payload> element is used, information contained in the element is considered to beauthoritative information about the software. This differs from the use of the <Evidence>element, which is used to store results from a scan that indicate why the product is believed to beinstalled. The following example illustrates a primary tag with a <Payload> element
describing one file in a single directory:<SoftwareIdentity …>…
<Payload><Directory root="%programdata%" name="rrdetector"><File name="EPV12.cab" size="1024000"
SHA256:hash="a314fc2dc663ae7a6b6bc6787594057396e
6b3f569cd50fd5ddb4d1bbafd2b6a"/></Directory></Payload>…
</SoftwareIdentity>
3.2

Authenticating SWID Tags

Because SWID tags are XML documents discoverable on a device (see §2.3.1, §2.3.2) or byretrieving a tag from a repository (see §2.3.3), they are vulnerable to unauthorized or inadvertent
modification like any other document. To recognize such tag modifications, it is necessary tovalidate that a SWID tag was produced by a known, trusted entity and has not been altered after
creation. XML digital signatures embedded within a SWID tag can be used to prove theauthenticity of the tag signer and to validate that changes have not been made to the original
signed tag.
Applying an XML digital signature to a tag directly after it is created addresses the following
risks:•Creation of a tag by an unauthorized creator. Any entity can create a tag for asoftware product. By including a certificate acquired from a trusted certificate authority
in the tag’s digital signature, it is possible to validate the certificate, ensure that it has notbeen revoked, and determine that the signature was produced while the certificate wasvalid. By linking the signature to the <Entity> element having a @role value of“tagCreator” and using the @thumbprint attribute (see §3.1.2) to record thethumbprint of the certificate, it is possible to identify that the tag creator is also the tag
signer. This provides a method for source authentication of a tag’s creator.
27

NISTIR 8060

•

•

•

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Detecting unauthorized changes to a tag. Changes made to a tag after it is created canbe detected by validating the tag’s signature. Such changes may occur due to accidental
modification, incomplete copying, network errors, filesystem corruption, or an attacker
wishing to misrepresent the software installation state or the information contained withina tag. The use of an XML digital signature in this way provides a means to validate theintegrity of a tag. When coupled with authenticating the creator of a tag, this greatly
increases the assurance of the tag data.
Detecting unauthorized changes to software installation media and packages. If thecreator of a corpus tag can be authenticated and the integrity of the tag can be verified, itis then possible to use the information in the tag’s <Payload> element, if provided, tomeasure the integrity of software installation media or packages. This can be useful for
detecting unauthorized changes to software installation media and packages, and caninform policy decisions pertaining to authorizing software installations (see §6.2.1).
Detecting unauthorized changes to installed software. If the creators of primary andpatch tags related to an installed software product can be authenticated and the integrityof the tags can be verified, it is then possible to use the information in each tag’s<Payload> element, if provided, to measure the integrity of the related installedsoftware product. This can be useful for detecting unauthorized changes to installedsoftware and can inform policy decisions pertaining to authorizing software execution(see §6.2.2).

When considering the totality of these risks, SWID tags can enhance the assurance of software
before and after it is installed in a standardized way, regardless of the target platform or software
product installed.
Section 6.1.10 of the SWID specification states that:
Signatures are not a mandatory part of the software identification tag standard, and can beused as required by any tag producer to ensure that sections of a tag are not modified
and/or to provide authentication of the signer. If signatures are included in the software
identification tag, they shall follow the W3C recommendation defining the XML
signature syntax which provides message integrity authentication as well as signer
authentication services for data of any type.
Digital signatures use the <Signature> element as described in the World Wide Web
Consortium (W3C) XML Signature Syntax and Processing (Second Edition) specification[xmldsig-core] and the associated schema. 2 Users may also include a hexadecimal hash string(i.e., the “thumbprint”) to document the relationship between the tag entity and the signature,using the <Entity> @thumbprint attribute.
Section 6.1.10 of the SWID specification also requires that a digitally-signed SWID tag enable
tag consumers to:2

See http://www.w3.org/TR/xmldsig-core/#sec-Schema.

28

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Utilize the data encapsulated by the SWID tag to ensure that the digital signature wasvalidated by a trusted certificate authority (CA), that the SWID tag was signed during thevalidity period for that signature, and that no signed data in the SWID tag has been
modified. All of these validations shall be able to be accomplished without requiring
access to an external network. If a SWID tag consumer needs to validate that the digital
certificate has not been revoked, then it is expected that there be access to an external
network or a data source that can provide [access to the necessary] revocation
information.
Additional information on digital signatures, how they work, and the minimum requirements for
digital signatures used for U.S. Federal Government processing can be found in the Federal
Information Processing Standards (FIPS) Publication 186-4, Digital Signature Standard (DSS)[FIPS-186-4].
3.3

A Complete Primary Tag Example

A complete tag is illustrated below, combining examples from the preceding subsections. This
example illustrates a primary tag that contains all mandatory data elements as well as a numberof optional data elements. This example does not illustrate the use of digital signatures.
<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
name="ACME Roadrunner Detector 2013 Coyote Edition SP1"
tagId="com.acme.rrd2013-ce-sp1-v4-1-5-0"
version="4.1.5"><Entity
name="The ACME Corporation"
regid="acme.com"
role="tagCreator softwareCreator"/><Entity
name="Coyote Services, Inc."
regid="mycoyote.com"
role="distributor"/><Link
rel="license"
href="www.gnu.org/licenses/gpl.txt"/><Meta
activationStatus="trial"
product="Roadrunner Detector"
colloquialVersion="2013"
edition="coyote"revision="sp1"/><Payload><Directory root="%programdata%" name="rrdetector"><File name="rrdetector.exe" size="532712"
SHA256:hash="a314fc2dc663ae7a6b6bc6787594057396e6b3f569c
d50fd5ddb4d1bbafd2b6a"/></Directory>
29

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS</Payload></SoftwareIdentity>
3.4

Summary

SWID tags are rich sources of information useful for identifying and describing software
products, whether in a pre-installation state or installed on devices. A relatively small number of
elements and attributes is required in order for a tag to be considered valid and conforming to thespecification. The SWID specification defines other optional data elements and attributes that
support a wide range of usage scenarios.
A minimal valid and conforming tag uses a <SoftwareIdentity> element to record a
product’s name and the tag’s globally unique identifier, and contains an <Entity> element torecord the name and registration identifier of the tag creator. While such a minimal tag is better
than no tag at all in terms of enhancing the ability of SAM tools to discover and account for
installed products, it falls short of satisfying many higher-level business and cybersecurity needs.
To meet those needs, the SWID specification offers several additional elements, such as<Evidence> for use by scanning tools to record results of the discovery process; <Link> toassociate tags with other items, including other tags; <Meta> to record a variety of metadata
values; and <Payload> to enumerate files, etc., that comprise the installed product. Finally,
digital signatures may optionally be used by any tag producer to ensure that the contents of a tag
are not accidentally or deliberately modified after installation, and to provide authentication of
the signer.

30

NISTIR 8060

4

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Implementation Guidance for All Tag Creators

Sections 4 and 5 provide implementation guidance for creators of SWID tags that is broadly
applicable to common IT usage scenarios of interest to both public and private sector
organizations. The primary purpose of this guidance is to help tag creators understand how to
implement SWID tags in a consistent manner that will address common cybersecurity andoperational IT usage scenarios, such as those defined in Section 6.
Each guideline in the next two sections is prefixed with a coded identifier for ease of reference.
Such identifiers have the following format: CAT-NUM, where CAT is a three-letter symbol
indicating the guideline category, and NUM is a number. Guidelines are grouped into thefollowing categories:•

GEN: General guidelines applicable to all types of SWID tags (see §4.1 through §4.7),•

COR: Guidelines specific to corpus tags (see §5.1),•

PRI: Guidelines specific to primary tags (see §5.2),•

PAT: Guidelines specific to patch tags (see §5.3), and•

SUP: Guidelines specific to supplemental tags (see §5.4).

This section provides implementation guidelines that address issues common to all situations inwhich tags are deployed and processed. Section 5 provides guidelines that vary according to thetype of tag being implemented.
4.1

Limits on Scope of Guidelines

This report assumes that tag creators are familiar with the SWID specification and ensure that
implemented tags satisfy all requirements contained therein.
GEN-1. When producing SWID tags, tag creators MUST produce SWID tags that conformto all requirements defined in the ISO/IEC 19770-2:2015 specification.
Guideline GEN-1 establishes a baseline of interoperability that is needed by all adopters of
SWID tags.
All guidelines in this report are intended solely to extend, and not to conflict with, guidelines
provided by the SWID specification. Guidelines in this report either:•Strengthen existing guidelines contained in the SWID specification by elevating“SHOULD” clauses contained in the SWID specification to “MUST” clauses, or•

Add guidelines to address implementation issues where the SWID specification is silent
or ambiguous by adding new “SHOULD” or “MUST” clauses.

In no cases should this report’s guidelines be construed as either weakening or eliminating
existing guidelines in the SWID specification.

31

NISTIR 8060

4.2

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Authoritative and Non-Authoritative Tag Creators

SWID tags may be created by individuals, organizations, or automated tools under different
conditions. The entity that creates a tag, as well as the conditions under which a tag is created,
profoundly affect how a tag can be used. The quality, accuracy, completeness, andtrustworthiness of the data in a tag will determine its suitability for specific usage scenarios.
Tags may be created by authoritative or non-authoritative entities. For the purposes of this report,
an authoritative tag creator is a first- or second-party that creates a tag as part of the process of
releasing software. A first-party authoritative tag creator is the software creator. A second-party
authoritative tag creator aggregates, distributes, or licenses software on behalf of the software
creator. Such parties typically possess accurate, complete, and detailed technical knowledge thatis needed for creation of authoritative tags containing reliable information.
A non-authoritative tag creator is defined as an entity that has a third-party relation to thecreation, maintenance, and distribution of the software. Non-authoritative tag creators typicallycreate tags using product information that is gathered using forensic methods while discovering
installed software on devices (e.g., through use of a discovery tool).
As a shorthand, this report uses the term “authoritative tag” to refer to tags created byauthoritative entities, and “non-authoritative tag” to refer to tags created by non-authoritative
entities. Unless otherwise specified, guidelines in this report are directed equally at both
authoritative and non-authoritative tag creators. Guidelines prefixed with “[Auth]” are directed
specifically at authoritative tag creators, and guidelines prefixed with “[Non-Auth]” are directed
specifically at non-authoritative tag creators.
4.3

Implementing <SoftwareIdentity> Elements

This section provides guidelines to be observed by tag creators when implementing SWID tag<SoftwareIdentity> elements.
The SWID specification defines an international standard intended to be adopted and usedworldwide. To support an international audience, it is necessary to permit tag creators to provide
language-dependent attribute values in region-specific human languages. For example, aJapanese software provider may want to specify the value of a particular product’s<SoftwareIdentity> @name attribute as a string of Japanese characters.
The SWID tag XML schema provides multi-language support in two ways. First, the schema
specifies UTF-8 as the allowed character encoding scheme for SWID tag files. Second, theschema allows the optional @xml:lang attribute to be included on all tag elements. By taking
advantage of these features, a Japanese software provider could issue a SWID tag like this:<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
xml:lang="ja-jp"
name="コンピュータ管理システム 2015"
tagId="jp.largecomputerco.タグ番号 1"
version="1.0">
32

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

<Entity
name="大型コンピュータ会社"
regid="largecomputerco.jp"
role="tagCreator softwareCreator"/>…
</SoftwareIdentity>
According to W3C documentation, language tags “are used to indicate the language of text orother items in HTML and XML documents” [W3C-langtags]. By supplying the language tag“ja-jp” as the value of the <SoftwareIdentity> @xml:lang attribute, the tag creatorsignals to tag consumers that various language-dependent attributes, such as the<SoftwareIdentity> @name attribute, are provided in Japanese. Additionally, the SWID
schema is designed so that any value of @xml:lang specified on any tag element is inheritedby all of that element’s child elements, unless explicitly overridden. As a result, the value
specified for the <SoftwareIdentity> @xml:lang attribute will, in effect, establish thepreferred language that is used for all language-dependent attributes within the tag.
Knowing the preferred language of SWID tag attribute values can be very useful to tag
consumers, and can relieve them of the need to attempt to perform language auto-detection. The
following guideline requires that tag creators always specify the preferred language of a tag:GEN-2. The <SoftwareIdentity> element MUST specify an @xml:lang attributewith a non-blank value to indicate the default human language used for expressing all
language-dependent attribute values.
Guideline GEN-2 is directed towards both authoritative and non-authoritative tag creators. Whileauthoritative tag creators can always be expected to know the default language of the tag, nonauthoritative creators may need to use local knowledge to ascertain the most appropriate default
language. This document recommends that non-authoritative tag creators supply the default
language of the device where the tagged product resides.
GEN-3. [Non-Auth] When specifying a value for the <SoftwareIdentity>@xml:lang attribute, non-authoritative tag creators SHOULD use the language tagcorresponding to the default language of the device where the tagged product resides.
In some cases, tag creators may want to specify various SWID tag attribute values in more than
one human language. This presents a number of challenges and potential interoperability issues;these are discussed further in Section 4.7.
4.4

Implementing <Entity> Elements

This section provides guidelines to be observed by tag creators when implementing SWID tag<Entity> elements. The guidelines in this section address four issues:
1.
2.
3.
4.

Providing detailed information about entities (see §4.4.1),
Preventing unnecessarily complex entity specifications (see §4.4.2),
Distinguishing between authoritative and non-authoritative tags (see §4.4.3), andFurnishing information about the software creator (see §4.4.4).
33

NISTIR 8060

4.4.1

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Providing Detailed Information about Entities

The first issue to be addressed concerns the need for detailed information about the various
entities associated with tags and/or tagged products.
Section 8.2 of the SWID specification requires that every SWID tag contain an <Entity>element where the @role attribute has the value “tagCreator”, and the @name attribute isalso provided. Although <Entity> elements may furnish @regid attribute values, thespecification does not require this information to be provided. Instead, the specification defaults
the @regid attribute value to “http://invalid.unavailable” when a value is not
explicitly provided in the element. Because the @regid attribute serves as a unique reference toan organization, this report provides guidelines to ensure that explicit values are provided
whenever possible.
The ability to provide @regid attribute values varies, depending on whether a tag creator is
authoritative or non-authoritative. For authoritative tag creators, it is reasonable to require the@regid value on all <Entity> elements:GEN-4. [Auth] Every <Entity> element MUST provide an explicit (i.e., non-default)@regid attribute value.
Non-authoritative tag creators may be less able to provide reliable @regid information. Whilethey are expected to provide a @regid value for the <Entity> element with the“tagCreator” @role that identifies their organization, they can only be encouraged toprovide @regid information for entities in other roles. This leads to the following two
guidelines:
GEN-5. [Non-Auth] The <Entity> element containing the @role “tagCreator”
MUST provide an explicit (i.e., non-default) @regid attribute value.
GEN-6. [Non-Auth] Every <Entity> element SHOULD provide an explicit (i.e., nondefault) @regid attribute value if such a value can be determined.
4.4.2

Preventing Complex Entity Specifications

The second issue to be addressed concerns the potential for unnecessarily complex specificationsof entities and roles associated with the tag and/or the tagged product. The SWID specification
allows a tag to furnish multiple <Entity> elements in order to support situations in which
different organizations play different roles with respect to the tag and/or the tagged product. So if
one organization were the tag creator, and a second organization were the software creator, thisinformation could be specified as follows:<Entity
name="Organization 1 Corp"
role="tagCreator"/><Entity
name="Organization 2 Corp"
role="softwareCreator"/>34

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSThis ability to furnish multiple <Entity> elements has an undesirable side effect, however. It
now becomes possible for role information associated with a single organization to be spread
across multiple <Entity> elements, as illustrated by this example:<Entity
name="Organization 1 Corp"
role="tagCreator"/><Entity
name="Organization 1 Corp"
role="softwareCreator"/>Such spreading of role information across <Entity> elements is discouraged. Furnishing entity
information in this way increases the size of the tag unnecessarily, and creates additional
processing complexity for tag consumers. To preclude this, the following guideline is provided:GEN-7. All <Entity> elements that provide the same @regid attribute value MUST
provide the same @role attribute values.
Guideline GEN-7 works in concert with guidelines GEN-4 through GEN-6 to achieve thedesired effect. It should be clear that the following example satisfies these guidelines:<Entity
name="Organization 1 Corp"
regid="org1.com"
role="tagCreator softwareCreator"/><Entity
name="Organization 2 Corp"
regid="org2.com"
role="licensor"/>As will be seen later in Section 4.7, guidelines GEN-4 through GEN-7 also play an importantrole in addressing potential interoperability issues that could arise when tag creators specify
attribute values in multiple human languages.
4.4.3

Distinguishing Between Authoritative and Non-Authoritative Tags

The third issue to be addressed here concerns the process by which a tag consumer may rapidly
determine whether the tag creator is authoritative or non-authoritative.
When a tag contains an <Entity> element that specifies only a single @role of“tagCreator”, tag consumers can safely assume that the tag creator is non-authoritative. To
enable tag consumers to accurately determine that a tag is created by an authoritative source,
authoritative tag creators are required to include one or more additional predefined role values,
as follows:
GEN-8. [Auth] Authoritative tag creators MUST provide an <Entity> element where the@role attribute contains the value “tagCreator” and at least one of these additional rolevalues: “aggregator”, “distributor”, “licensor”, or “softwareCreator”.
35

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

If this guideline is observed, tag consumers may reliably distinguish between authoritative andnon-authoritative tags according to this rule:
If a tag contains an <Entity> element with a @role value that includes “tagCreator”
as well as any of “aggregator”, “distributor”, “licensor”, or“softwareCreator”, then the tag is authoritative; otherwise, it is non-authoritative.
4.4.4

Furnishing Information about the Software Creator

The fourth issue to be addressed here concerns the furnishing of information about the software
creator, if that information is known.
Explicit knowledge of the software creator is important for many software inventory scenarios,
but the SWID specification does not require that this information be provided. To support
software inventory scenarios, authoritative tag creators are expected to furnish information on
the software creator’s identity. If the tag creator is not the same as the software creator,
authoritative tag creators are expected to know the appropriate @name and @regid attributevalues for the software creator.
GEN-9. [Auth] Authoritative tag creators MUST provide an <Entity> element where the@role attribute contains the value “softwareCreator”.
Non-authoritative tag creators may be unable to accurately determine and identify the various
entities associated with a software product, including the software creator. Nevertheless, because
tag consumers may obtain substantial benefits from knowing a product’s software creator, nonauthoritative tag creators are encouraged to include this information in a tag whenever possible.
GEN-10. [Non-Auth] Non-authoritative tag creators SHOULD provide an <Entity>element where the @role attribute contains the value “softwareCreator”.
4.5

Implementing <Link> Elements

This section provides guidelines to be observed by tag creators when implementing SWID tag<Link> elements. As discussed in Section 3.1.4, <Link> elements are used to establish one ormore relationships of various kinds between tags and other documents, including other tags. The
guidelines in this section address two issues:
1. Linking a source tag to a known target tag, and
2. Linking a tag to a collection of tags.
A tag may contain multiple <Link> elements, and either method of linking may be used in eachelement. These methods are described in the following subsections.
4.5.1

Linking a Source Tag to a Known Target Tag

In many tag creation situations, there will be a need to embed a <Link> element in a source tag(i.e., a tag being created) which points to a preexisting target tag. For example, when a patch tag(see §2.1.3) is being created, it is important to link that patch tag to the tag that describes the
product being patched. As another example, a supplemental tag (see §2.1.4) will typically belinked to another preexisting tag that is having its information supplemented. To establish these36

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

relationships, tag creators use the <Link> @href attribute in the source tag to provide a pointerto the target tag.
In these situations, the tag creator will know the contents of the target tag, including its @tagId.
Here, the target tag is known to the tag creator at the time that the source tag is being created. To
link a source tag to a known target tag, tag creators are required to use the “swid:” scheme
followed by the @tagId of the target tag.
GEN-11. In order to link a source tag to a specific target tag with a @tagId that is known at
the time the source tag is created, tag creators MUST set the value of the <Link> @href
attribute in the source tag to a URI with “swid:” as its scheme, followed by the @tagId of
the target tag.
This idea is illustrated below with two tag fragments.
Tag 1:<SoftwareIdentity
name="Application 1"
tagId="com.largecomputerco.app1"…
</SoftwareIdentity>

Tag 2:<SoftwareIdentity
name="Application 2"
tagId="com.largecomputerco.app2"…
<Link rel="relation" href="swid:com.largecomputerco.app1"/></SoftwareIdentity>
In the above example, the source tag, Tag 2 (describing “Application 2”), is linked to the target
tag, Tag 1 (describing “Application 1”).
4.5.2

Linking a Tag to a Collection of Tags

In contrast to situations where the @tagId of the target tag is known, there also are many tag
creation situations where there is a need to embed a <Link> element in a source tag which
points either to a single target tag or to a collection of target tags with @tagId value(s) thatcannot be known with certainty at the time the source tag is created. Consider the following
scenarios:•

A primary tag (the source) is being created for a product that requires a commonly usedshared library. This shared library is maintained by a third party, has its own primary tag,and is periodically upgraded in ways that maintain backwards compatibility. It is
important that the source tag includes a link to the shared library’s tag (the target), but it
is not possible to specify a fixed @tagId for the target tag.

37

NISTIR 8060•

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSA patch tag (the source) is being created for a patch that applies to a collection of
products based on version. For example, imagine that a software provider has released aseries of versions of a product, all in the “4.1.x” version series. A flaw is discovered inversion 4.1.5 of the product, and it is determined that the flaw was introduced in version
4.1.0. A single patch is developed to correct this flaw, so its patch tag needs to link to allaffected versions.

The SWID specification provides a mechanism that tag creators may use when linking a source
tag to a collection of target tags. That mechanism is to set the <Link> @href attribute value toa URI with a scheme of “swidpath:”, followed by an XPath 2.0 [XPath20] conformant query.
Any such XPath query is expected to be used by a system to iterate over a set of SWID tags andidentify matching tags by applying the XPath query to each tag and checking for a non-empty
result. Because the SWID specification is not clear and specific about this usage, this document
provides the following guidelines:
GEN-12. When linking a source tag to one or more target tags with @tagId value(s) thatcannot be determined at the time the source tag is created, tag creators MUST set the value ofthe <Link> @href attribute in the source tag to a URI with “swidpath:” as its scheme,
followed by an XPath 2.0 [XPath20] conformant query. All characters contained in the
XPath query which the URI specification [RFC3986] designates as reserved MUST be
percent-encoded per the URI specification. All embedded SWID tag elements in the query
MUST be prefixed with the “swid:” namespace.
The above guideline clarifies two points: (1) that URI reserved characters in the embedded
XPath query must be percent-encoded, and (2) that the “swid:” namespace must be used for all
SWID elements. Thus, in order to process such a query, the “swidpath:” scheme must be
stripped off, any embedded percent encodings must be replaced with the decoded characters, and
the XPath query processor must be supplied with the definition of the “swid:” namespace.
The following guideline advises query developers on how to prepare queries in a consistent andinteroperable manner.
GEN-13. Any XPath query used within a <Link> @href element MUST be designed insuch a way that it can used by a system to iterate over a set of SWID tags and identify
matching tags by applying the XPath query to each tag and checking for a non-empty result.
To illustrate the guidelines for linking tags, a series of examples is presented relative to thisexample tag:
<SoftwareIdentity
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
xmlns:SHA256="http://www.w3.org/2001/04/xmlenc#sha256"
xmlns:ext="http://example.org/ns/swid-example"
name="ACME Roadrunner Detector 2013 Coyote Edition SP1"
tagId="com.acme.rrd2013-ce-sp1-v4-1-5-0"
version="4.1.5">
38

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

<Entity
name="The ACME Corporation"
regid="acme.com"
role="tagCreator softwareCreator"/><Entity
name="Coyote Services, Inc."
regid="mycoyote.com"
role="distributor"/><Meta
activationStatus="trial"
product="Roadrunner Detector"
colloquialVersion="2013"
edition="coyote"revision="sp1"
ext:newattr="newvalue"/><Payload><Directory root="%programdata%" name="rrdetector"><File name="rrdetector.exe" size="532712"
SHA256:hash="a314fc2dc663ae7a6b6bc6787594057396e6b3f569cd50fd5dd
b4d1bbafd2b6a"/></Directory></Payload></SoftwareIdentity>
4.5.2.1 Example 1: Using an XPath Query to Refer to a Tag by its @tagId

Although the “swid:” scheme is intended to be used in cases where the target tag’s @tagId
value is known, the “swidpath:” scheme followed by an XPath query could also be used toachieve the same effect. The following XPath query will match the tag illustrated above in
Section 4.5.2:/swid:SoftwareIdentity[@tagId='com.acme.rrd2013-ce-sp1-v4-1-50']
When incorporated into a <Link> element, the above query must be prefixed with the“swidpath:” scheme, and reserved characters must be percent-encoded, as follows:<Link rel="relation"
href="swidpath:%2Fswid%3ASoftwareIdentity%5B%40tagId%3D%27com.ac
me.rrd2013-ce-sp1-v4-1-5-0%27%5D"/>

39

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

4.5.2.2 Example 2: Using an XPath Query to Refer to a Tag by Name and Tag Creator@regidIn the next example, an XPath 2.0 query is shown which matches any tag such that (1) the
product name includes the string “Roadrunner Detector”, and (2) the <Entity> element
containing the “tagCreator” @role also contains the @regid value “acme.com”:/swid:SoftwareIdentity[contains(@name,'Roadrunner Detector')and swid:Entity[@regid='acme.com'
and (count(index-of(@role,'tagCreator')) gt 0or contains(@role,'tagCreator')]]Note: Depending on whether the XML parser is running in a schema-aware mode or not, XPathparsing behavior can vary. In schema-aware mode, the tag is validated against the SWID schema
before the XPath query engine is run. The query above is designed with the assumption that the
SWID tag parser can be either schema-aware, which causes the @role attribute to be parsed asa list of string values, or non-schema-aware, where the @role attribute is a single string value.
When incorporated into a <Link> element, the above query must be prefixed with the“swidpath:” scheme, and reserved characters must be percent-encoded, as follows:<Link rel="relation"
href="%2Fswid%3ASoftwareIdentity%5Bcontains(%40name%2C%27Roadrun
ner%20Detector%27)%20and%20swid%3AEntity%5B%40regid%3D%27acme.co
m%27%20and%20(count(indexof(%40role%2C%27tagCreator%27))%20gt%200%20or%20contains(%40role%2C%27tagCreator%27)%5D%5D"/>
4.5.2.3 Example 3: Using an XPath Query to Refer to a Tag Containing a Known FileIn the next example, an XPath 2.0 query is shown which matches any tag that includes a<File> element describing the “rrdetector.exe” file with a specific hash value:/swid:SoftwareIdentity[descendant::swid:File[@name ='rrdetector.exe'
and @*[local-name() = 'hash'and namespace-uri() ='http://www.w3.org/2001/04/xmlenc#sha256'
and.='a314fc2dc663ae7a6b6bc6787594057396e6b3f569cd50fd5ddb4d1bbafd2b6a']]]Such a query could be used in a patch tag that affects a specific file used by any number of otherproducts, which may or may not be installed on a device at any given time. When incorporated
into a <Link> element, the above query must be prefixed with the “swidpath:” scheme, andreserved characters must be percent-encoded, resulting in this <Link> element:<Link rel="relation"
href="%2Fswid%3ASoftwareIdentity%5Bdescendant%3A%3Aswid%3AFile%540

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

B%40name%20%3D%20%27rrdetector.exe%27%20and%20%40*%5Blocalname()%20%3D%20%27hash%27%20and%20namespaceuri()%20%3D%20%27http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmlenc%23
sha256%27%20and%20.%3D%27a314fc2dc663ae7a6b6bc6787594057396e6b3f
569cd50fd5ddb4d1bbafd2b6a%27%5D%5D%5D"/>
4.5.2.4 Example 4: Using an XPath Query to Refer to Tags with a Range of Versions

In the next example, an XPath 2.0 query is shown which matches any tag that describes a
product with the name of “Roadrunner Detector” and with a version of 4.1.0 or greater within the
4.x release branch.
/swid:SoftwareIdentity[swid:Meta[@product = 'RoadrunnerDetector']and tokenize(@version,'\.')[1] cast as xs:unsignedInt = 4
and tokenize(@version,'\.')[2] cast as xs:unsignedInt ge 1]
When incorporated into a <Link> element, the above query must be prefixed with the“swidpath:” scheme, and reserved characters must be percent-encoded, resulting in this
<Link> element:<Link rel="relation"
href="%2Fswid%3ASoftwareIdentity%5Bswid%3AMeta%5B%40product%20%3
D%20%27Roadrunner%20Detector%27%5D%20and%20tokenize(%40version%2
C%27%5C.%27)%5B1%5D%20cast%20as%20xs%3AunsignedInt%20%3D%204%20a
nd%20tokenize(%40version%2C%27%5C.%27)%5B2%5D%20cast%20as%20xs%3
AunsignedInt%20ge%201%5D%"/>
4.6

Implementing <Payload> and <Evidence> Elements

This section provides guidelines to be observed by tag creators when implementing SWID tag<Payload> and <Evidence> elements. The guidelines in this section address three issues:
1. Providing sufficient file information (see §4.6.1),
2. Selecting the hash function (see §4.6.2), and
3. Handling path separators and environment variables (see §4.6.3).
4.6.1

Providing Sufficient File Information

The first issue to be addressed here concerns the amount of payload/evidence information thatneeds to be provided.
Authoritative tag creators use the <Payload> element to enumerate the files and folders
comprising a product or patch, whereas non-authoritative tag creators use the <Evidence>element for this purpose. Files are described using the <File> element, and folders aredescribed using the <Directory> element.
The SWID specification requires only that the <File> element specify the name of the fileusing the @name attribute. This information is insufficient for most cybersecurity usage
41

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

scenarios. Additional information is needed to check whether files have been improperly
modified since they were originally deployed. By including file size information within<Payload> and <Evidence> elements using the @size attribute, cybersecurity processes
may efficiently test for changes that alter a file’s size.
GEN-14. Every <File> element provided within a <Payload> or <Evidence> element
MUST include a value for the @size attribute that specifies the size of the file in bytes.
Knowing a file’s expected size is useful and enables a quick check to determine whether a file
may have changed. Similarly, knowing a file’s version as recorded in the file or filesystem canbe useful when searching for installed products containing a file with a known version. This
motivates the following guideline:
GEN-15. Every <File> element provided within a <Payload> or <Evidence> element
MUST include a value for the @version attribute, if one exists for the file.
Because improper changes may also occur in ways that do not alter file sizes or versions, filehash values are also necessary. If there is a difference in the files’ sizes, a change has occurred. If
the size is the same, recomputing a hash will be necessary to determine if a change has occurred.
Authoritative tag creators are expected to have sufficient knowledge of product details to be able
to routinely provide hash values. Non-authoritative tag creators may not have the necessary
knowledge of or access to files to provide hash information, but are encouraged to do sowhenever possible.
GEN-16. [Auth] Every <File> element within a <Payload> element MUST include ahash value.
GEN-17. [Non-Auth] Every <File> element within an <Evidence> element SHOULD
include a hash value.
4.6.2

Selecting the Hash Function

The second issue to be addressed here concerns selection of the hash function to be used whenproviding hash values.
Software products tend to be used long beyond the formal product support period. Whenselecting a hash function, it is important to consider the deployment lifecycle of the associatedproduct. The hash value will likely be computed at the time of product release and will be usedby tag consumers over the support lifecycle of the product and in some cases even longer.
Stability in the hash functions used within SWID tags is desirable to maximize theinteroperability of SWID-based tools while minimizing development and maintenance costs.
Taking these considerations into account, it is desirable to choose a hash function that provides aminimum security strength of 128 bits to maximize the usage period. 3

3 According to NIST SP 800-57 Part 1 [SP800-57-part-1], when applying a hash function over a time period that extends beyond

the year 2031, a minimum security strength of 128 bits is needed. Weak hash values are of little use and should be avoided.

42

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

GEN-18. Whenever <Payload> or <Evidence> elements are included in a tag, every<File> element SHOULD avoid the inclusion of hash values based on hash functions withinsufficient security strength (< 128 bits).
According to [SP800-107], the selected hash function needs to provide the following security
properties:•

Collision Resistance: “It is computationally infeasible to find two different inputs to thehash function that have the same hash value.” This provides assurance that two different
files will have different hash values.

•

Second Preimage Resistance: “It is computationally infeasible to find a second inputthat has the same hash value as any other specified input.” This provides assurance that afile cannot be engineered that will have the same hash value as the original file. This
makes it extremely difficult for a malicious actor to add malware into stored executablecode while maintaining the same hash value.

The SHA-256, SHA-384, SHA-512, and SHA-512/256 hash functions meet the 128-bit strength
requirements for collision resistance and second preimage resistance. 4 This leads to thefollowing guidelines:
GEN-19. [Auth] Whenever a <Payload> element is included in a tag, every <File>element contained therein MUST provide a hash value based on the SHA-256 hash function.
GEN-20. [Non-Auth] Whenever an <Evidence> element is included in a tag, every<File> element contained therein SHOULD provide a hash value based on the SHA-256
hash function.
GEN-21. Whenever a <Payload> or <Evidence> element is included in a tag, every<File> element contained therein MAY additionally provide hash values based on the
SHA-384, SHA-512, and/or SHA-512/256 hash functions.
Due to the use of 64-bit word values in the algorithm, SHA-512 hash function implementations
may perform better on 64-bit systems. For this reason, tag creators are encouraged to consider
including a SHA-512 hash value.
4.6.3

Handling of Path Separators and Environment Variables

The third issue to be addressed here concerns interoperable handling of path separators andenvironment variables in <File> and <Directory> elements.
The SWID specification defines three attributes that may be used on <File> and<Directory> elements to fully specify a file or a folder:•

location: A string specifying the directory or location where a file was found or can

4 See FIPS 180-4 [FIPS180-4].

43

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSbe expected to be located;•

name: A string specifying the name of the filename or directory without any embedded
path separators; and•root: A string specifying a system-specific root folder that the “location” attribute is
an offset from; if this is not specified, it is assumed that the “root” is the same folder as
the location of the SWID tag, or is the directory specified by an enclosing<Directory> element.

While the “name” attribute is defined to explicitly exclude path separators, both “location”
and “root” are permitted to include such separators. The problem is that path separators varyacross operating environments. The most widely known difference is between Windows andUNIX/Linux systems; Windows uses the backslash “\” as the path separator, while UNIX/Linuxsystems use the forward slash “/”.
It is important that tag consumers be able to reliably parse strings containing embedded path
separators without having to guess the path separator. This document recommends that the path
separator character be made explicit in <Payload> and <Evidence> elements. The
following guideline achieves this by introducing a new @n8060:pathSeparator extension
attribute:GEN-22. The @n8060:pathSeparator extension attribute SHOULD be used within<Payload> and <Evidence> elements to specify the path separator character used inembedded <File> and <Directory> elements.
In a related vein, the SWID specification also allows platform-specific environment variables tobe used within any or all of the “root”, “location”, and “name” attributes. Once again, theformat of such variables differs across platforms. On Windows machines, environment variables
are enclosed in percent “%” characters, while UNIX/Linux systems prefix variables with a dollar“$” character. This document recommends that environment variable prefix and suffix charactersbe made explicit in <Payload> and <Evidence> elements. The following guidelines
introduce the @n8060:envVarPrefix and @n8060:envVarSuffix extension attributes:
GEN-23. The @n8060:envVarPrefix extension attribute SHOULD be used within<Payload> and <Evidence> elements to specify the character(s) used to prefix
environment variables that may be embedded <File> and <Directory> elements.
GEN-24. The @n8060:envVarSuffix extension attribute SHOULD be used within<Payload> and <Evidence> elements to specify the character(s) used to suffix
environment variables that may be embedded <File> and <Directory> elements.
When guidelines GEN-22 through GEN-24 are observed, a <Payload> could be represented
as follows:<Payload n8060:pathSeparator="/" n8060:envVarPrefix="$"n8060:envVarSuffix=""><Directory root="$ETC/drivers" name="printers">
44

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

<Directory name="printermodel"><File name="colordriver.shlib" size="234824"/><File name="bwdriver.shlib" size="143854"/></Directory></Directory></Payload>
Given this information, a tag consumer should be able to straightforwardly construct these two
fully-qualified filenames:••$ETC/drivers/printers/printermodel/colordriver.shlib$ETC/drivers/printers/printermodel/bwdriver.shlib

To access these files on the device, device-specific information will still be required to determine
the value of the “$ETC” environment variable.
4.7

Providing Attribute Values in Multiple Languages

Section 4.3 introduced a guideline to require that the <SoftwareIdentity> @xml:lang
attribute be used to specify the preferred human language used within the tag to provide
language-dependent attribute values. This is the most common scenario, i.e., that all languagedependent attribute values within a tag will be provided in the same language. Such tags will betermed monolingual tags. For example, a Japanese software provider wishing to create amonolingual tag in Japanese will set the preferred language of its tag to be Japanese (e.g., using
the language tag “ja-jp” as the value for the <SoftwareIdentity> @xml:lang
attribute), then specify all language-dependent attributes in Japanese.
Because the SWID specification permits the @xml:lang attribute to be used on any tag
element, this enables tag creators to implement multilingual tags, tags that provide languagedependent attributes in more than one language. Suppose, for example, that a Japanese software
provider wants to provide its organization’s name in both Japanese and English. Technically, thisis straightforward to do, as illustrated here:<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
xml:lang="ja-jp"
name="コンピュータ管理システム 2015"
tagId="jp.largecomputerco. タグ番号 1"
version="1.0"><Entity
name="大型コンピュータ会社"
regid="largecomputerco.jp"
role="tagCreator softwareCreator"/><Entity xml:lang="en-us"
name="Large Computer Company"regid="largecomputerco.jp"
role="tagCreator softwareCreator"/>…
45

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS</SoftwareIdentity>
The first <Entity> element in the example inherits the value of @xml:lang specified by the<SoftwareIdentity> element. The second <Entity> element explicitly overrides thepreferred language, signaling that information is being furnished in English (in this example).
Although the SWID specification provides the technical means to implement multilingual tags,in practice, implementing and processing such tags present a number of challenges and potential
interoperability issues, so care must be taken.
This report does not offer guidelines to address these issues, since the marketplace requirements
for multilingual tags are insufficiently clear to support development of robust guidelines to fullyand effectively address all associated interoperability concerns. Instead, this report will discuss
some of the most significant issues and suggest future directions for interoperability guidance.
4.7.1

Specifying Product Names in Multiple Languages

The <SoftwareIdentity> @name attribute specifies the preferred name of the software
product, and is provided in the language indicated by the value of the @xml:lang attribute(which is now required per guideline GEN-2). The SWID specification makes no provisions forthe specification of multiple product names, much less for the specification of multiple productnames in different languages.
If the marketplace determines that there is a demand for recording a multilingual representationof a product name in a single SWID tag, two options (short of revising the SWID specification
itself) exist:
1. Use the <Meta> element. Note, however, that because the <Meta> element described in
the SWID specification does not offer a pre-defined attribute for alternate product names,
the user community would need to agree on a new extension attribute to be used for thispurpose.
2. Use supplemental tags. Here, the idea would be to create one or more supplemental tags,
each of which specifies a different preferred language via the <SoftwareIdentity>@xml:lang attribute, that then provides the <SoftwareIdentity> @nameattribute value in that preferred language. In other words, a U.S.-based software provider
might issue a single primary tag providing the product name in English, along with four
supplemental tags providing the product name in French, German, Japanese, and Spanish,
respectively.
The first option is relatively compact, but depends on effective procedures for defining andmanaging extension attributes. The second option avoids the introduction of an extension
attribute, but forces tag creators to generate arbitrary quantities of supplemental tags to address
all human languages of interest.
4.7.2

Specifying <Entity> Elements in Multiple Languages

The example at the top of this section shows how a Japanese organization’s name could be
provided in both Japanese and English in two separate <Entity> elements distinguished by46

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

different @xml:lang attributes, one value inherited from <SoftwareIdentity> and theother an explicit value overriding the inherited value.
This multilingual capability also creates opportunities for entity information specified in one
language to differ in unexpected and confusing ways from entity information specified in asecond language. For example, there is nothing in either the SWID specification or the associatedXML schema that would prevent the following scenario:<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
xml:lang="ja"
name="コンピュータ管理システム 2015"
tagId="jp.largecomputerco. タグ番号 1"
version="1.0"><Entity xml:lang="en"name="The Large Computer Company"regid="largecomputerco.jp"
role="tagCreator softwareCreator"/><Entity xml:lang="fr"name="Le Grand Enterprise d’Informatique"regid="largecomputerco.jp"
role="tagCreator"/>…
</SoftwareIdentity>
This example contains two problems. First, the tag’s preferred language is specified as Japanese,but entity information is only provided in English and French. Given such a tag, it is not obvious
how a tag consumer should decide which <Entity> element provides the preferred name of
the tag creator. Second, the two <Entity> elements agree on the @regid, but disagree on the@role. Again, it is not obvious how to interpret such data. A number of equally odd scenarios
can easily be envisaged.
Future guidelines may be needed to address issues like these. Such guidelines might include:•

A requirement that at least one <Entity> element be provided in the preferredlanguage; and•A requirement that all <Entity> elements which agree on the @regid value also
agree on the @role value, regardless of the @xml:lang value.

4.7.3

Specifying <Payload> Elements in Multiple Languages

When software products are localized to a particular language region, files and folder names
often change to match the localized language. To account for this, authoritative tag creators may
want to create multilingual tags that provide <Payload> elements which enumerate alternate
language-specific versions of files and folders. If this is done, it must be done in a way thatenables tag consumers to simply and accurately determine the effective language-specific

47

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

payload. This information could be represented in multiple ways; for example, a tag creator
could implement multiple alternative <Payload> elements, as illustrated here:<SoftwareIdentity
xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
xml:lang="en"name="Joyful App 2015"
tagId="com.largecomputerco.joyfulapp1"
version="1.0">…
<Payload<File name="joyfulapp.exe"/></Payload><Payload xml:lang="fr"<File name="appdejoie.exe"/></Payload>…
</SoftwareIdentity>
In this example, the first <Payload> element is expressed in the tag’s preferred language(English), inherited from <SoftwareIdentity>. The second <Payload> element isexpressed in French. This is a simple and straightforward way to represent equivalent payloads
in alternate languages. But because @xml:lang may be used on any element, there is nothing
to prevent a tag creator from representing the payload in the following way:
<Payload<File name="joyfulapp.exe"/><File xml:lang="fr" name="appdejoie.exe"/></Payload>
Arguably, this is a more compact representation, but raises questions of how someone might
determine the effective language-specific payload for a given device. The above payload could
potentially represent two files that are co-present on a device, or two different files, only one ofwhich is present as determined by the local language. Future guidelines may be necessary toresolve potential interoperability issues like these.
For non-authoritative tag creators, two scenarios are pertinent. In the first scenario, when a tag is
generated by a tool based on evidence collected on a device, the tool is unlikely to be able todetermine and record that evidence in multiple languages. As a result, for such non-authoritative
tag creators, including data in multiple languages in <Evidence> elements is not likely to be aconcern. In contrast, when a tag is generated by a human analyst, and that tag is later deployedduring discovery, it may be possible to provide data in multiple languages in <Evidence>elements. This topic requires further study and additional guidelines may be necessary as aresult.

48

NISTIR 8060

4.8

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Updating Tags

The SWID specification prohibits modification of SWID tags by anyone other than the original
tag creator. The primary reason for altering a tag after it has been installed on a device is tocorrect errors in the tag. In rare circumstances, it may be useful to update a tag to add data
elements that logically belong in the tag and not in a separate supplemental tag. However, undernormal conditions, tags should rarely be modified, and supplemental tags should be used to add
identifying and descriptive product information.
When changes are made to a product’s codebase that cause the product’s version to change,
those changes should be reflected by removing all original tags (primary, supplemental, andpatch tags) and installing new tags as appropriate to identify and describe the new productversion. Patches should be indicated by adding a patch tag to the installed collection of tags.
When an existing tag must be updated, it will rarely make sense to edit the tag in place, that is, toselectively modify portions of the tag as if using a text editor. Such editing actions would likely
invalidate XML digital signatures stored in the tag. Thus it is expected that when a tag is
updated, it is always fully replaced along with any embedded digital signatures.
When a tag must be updated to correct errors or add data elements, its <SoftwareIdentity>@tagId should not be changed. This is because tag identifiers may be used as proxy identifiers
for pre-installation software packages, installed software products, or software patches. It is
important that tag identifiers be usable as reliable persistent identifiers. This leads to thefollowing guideline.
GEN-25. When it is necessary to update a tag to correct errors in or add data elements to thattag, the tag’s <SoftwareIdentity> @tagId SHOULD NOT be changed.
When tags are updated, however, it is important that the updates be implemented in a mannerthat supports easy change detection. Tag consumers should not be required or expected to fullycompare all contents of discoverable tags to determine if any of the products have changed since
the last time the tags were examined. To facilitate change detection by tag consumers, tag
creators are expected to update the <SoftwareIdentity> @tagVersion attribute toindicate that a change has been made to the tag.
GEN-26. When it is necessary to update a tag to correct errors in or add data elements to thattag, the tag’s <SoftwareIdentity> @tagVersion attribute MUST be changed.
If this guideline is observed, tag consumers need only to maintain records of tag identifiers andtag versions discovered on a device. If a tag with a previously unseen tag identifier is found on a
device, a tag consumer may conclude that a new product has been installed since the last time thedevice was inventoried. If a tag with a previously discovered tag identifier can no longer be
discovered on a device, a tag consumer may conclude that a software product has been removed
since the last time the device was inventoried. If, however, a tag is discovered on a device with apreviously seen tag identifier but a new tag version, a tag consumer may conclude that
identifying or descriptive metadata in that tag has been changed, and so the tag should be fully
processed.

49

NISTIR 8060

4.9

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Summary

The primary purpose of all the guidelines in this report is to help tag creators understand how to
implement SWID tags in a manner that will satisfy the tag handling requirements of IT
organizations. The guidelines are intended to be broadly applicable to common IT usage
scenarios that are relevant to all software providers and consumers.
This section provided implementation guidelines addressing issues common to all situations inwhich tags are deployed and processed. These are the key points from this section:•

Tags may be created by authoritative or non-authoritative entities. An authoritative tag
creator is a first or second party that creates a tag as part of the process of releasing
software. Authoritative tag creators typically possess accurate, complete, and detailed
technical knowledge that is needed for creation of authoritative tags containing reliable
information. A non-authoritative tag creator is an entity that has a third-party relation to
the creation, maintenance, and distribution of the software. Discovery tools may also act
as non-authoritative tag creators. Non-authoritative tag creators typically create tags
using product information that is gathered using forensic methods while discovering
installed software.

•

The SWID specification supports an international audience, allowing tag creators toprovide language-dependent attribute values in region-specific human languages.
Guidelines in this section specify how tag creators should designate the default humanlanguage of language-dependent attribute values provided within a tag, and how suchvalues may be provided in multiple languages.

•

SWID tags provide detailed information about various entities associated with thesoftware product described by the tag, as well as with the tag itself. Guidelines in thissection address how complex entity specifications are to be avoided, how authoritativeand non-authoritative tags are to be distinguished, and how information about thesoftware creator is to be furnished.

•

SWID tags may be explicitly linked to other tags and/or other resources in a variety ofways. Guidelines in this section address how source tags are to be linked to individual
target tags, and/or to sets of target tags.

•

Tag creators may provide detailed information about the files and folders comprising asoftware product. Guidelines in this section address how sufficient information may beprovided, how cryptographic hashes may be provided, and how platform-specific path
separators and environment variables may be incorporated in file or folder descriptions.

50

NISTIR 8060

5

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Implementation Guidance Specific to Tag Type

This section provides implementation guidelines that are specific to each of the four tag types
defined in Section 2.1: corpus tags (see §5.1), primary tags (see §5.2), patch tags (see §5.3), andsupplemental tags (see §5.4).
5.1

Implementing Corpus Tags

As noted in Section 2.1.1, corpus tags are used to identify and describe products in a preinstallation state. This section provides guidance addressing the following topics related to
implementation of corpus tags: setting the <SoftwareIdentity> @corpus attribute (see§5.1.1), specifying @version and @versionScheme (see §5.1.2), and specifying<Payload> element information (see §5.1.3).
5.1.1

Setting the <SoftwareIdentity> @corpus Attribute

To indicate that a tag is a corpus tag, tag implementers set the value of the<SoftwareIdentity> @corpus attribute to “true”. The SWID specification does not
specifically prohibit tag implementers from also setting other tag type indicator attributes to“true” (e.g., <SoftwareIdentity> @patch and <SoftwareIdentity>@supplemental), but doing so would create confusion regarding how the information
contained within the tag should be interpreted. This report provides guidelines to ensure that at
most one tag type indicator attribute is set to “true”.
COR-1. If the value of the <SoftwareIdentity> @corpus attribute is set to “true”,
then the values of @patch and @supplemental MUST be set to “false”.
5.1.2

Specifying the Version and Version Scheme in Corpus Tags

Corpus tags identify and describe software products in a pre-installation state. As part of theprocess of determining whether a given product is suitable for—or allowed to be installed on—adevice, tag consumers often need to know the product’s specific version. The SWID
specification provides the <SoftwareIdentity> @version attribute for recording version
information, but defines this attribute as optional with a default value of “0.0”.
This report seeks to encourage software providers to assign product versions for their products,
and to explicitly record software versions in tags released along with those products. In short, if asoftware product has an assigned version, that version must be specified in the tag.
COR-2. If a software product has been assigned a version by the software provider, thatversion MUST be specified in the <SoftwareIdentity> @version attribute of the
product’s corpus tag, if any.
For many cybersecurity purposes, it is important to know not only a product’s version, but also
whether a given product version represents an “earlier” or “later” release of a product, compared
to a known version. For example, security bulletins often warn that a newly discovered
vulnerability was found in a particular version V of a product, but may also be present in “earlier
versions.” Thus, given two product versions V1 and V2, it is important to be able to tell whether
V1 is “earlier” or “later” than V2.
51

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSIn order to make such an ordering decision reliably, it is necessary to understand the structure ofversions and how order is encoded in versions. This is no single agreed-upon practice within thesoftware industry for versioning products in a manner that makes clear how one version of a
product relates to another. The “Semantic Versioning Specification” [SEMVER] proposes acommon interpretation of multi-part numeric versions, but it is not universally followed.
The SWID specification defines the <SoftwareIdentity> @versionScheme attribute torecord a token that designates the “scheme” according to which the value of<SoftwareIdentity> @version can be parsed and interpreted. Like @version, the
SWID specification defines @versionScheme as “optional” with a default value ofmultipartnumeric. Table 3 lists the allowed values of @versionScheme that are definedin the SWID specification.
Table 3: Allowed Values of @versionScheme
Value

Meaning

multipartnumeric

Numbers separated by dots, where the numbers areinterpreted as integers (e.g., 1.2.3, 1.4.5, 1.2.3.4.5.6.7)
multipartnumeric+suffix Numbers separated by dots, where the numbers areinterpreted as integers with an additional string suffix(e.g., 1.2.3a)alphanumeric
Strictly a string, sorting is done alphanumericallydecimalA floating point number (e.g., 1.25 is less than 1.3)
semverFollows the [SEMVER] specification
unknown
Other unknown version scheme; no attempt should bemade to order versions of this type<any>
Other version schemes that may be generally known inthe market
The following guideline is provided in consideration of the fact that tag consumers have a criticalinterest in knowing not only a product’s version, but also its versioning scheme and thesemantics of that scheme.
COR-3. If a corpus tag contains a value for the <SoftwareIdentity> @version
attribute, it MUST also contain a value for the <SoftwareIdentity>@versionScheme attribute.
If a particular product’s version does not conform to one of the pre-defined schemes listed inTable 3, whatever value a tag creator provides for the <SoftwareIdentity>@versionScheme attribute ought to be selected from a well-known public list of version
scheme identifiers. Mechanisms for establishing, advertising, and curating such public lists arebeyond the scope of this document. Ideally, such well-known public lists of version schemes will
provide enough semantic definition of each scheme to enable tag consumers to determine
whether a version V1 conforming to a particular scheme should be ordered “before” or “after”
another version V2 conforming to that same scheme.

52

NISTIR 8060

5.1.3

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSSpecifying the Corpus Tag Payload

Corpus tags are used to document the installation media associated with a software product. This
documentation enables the media to be checked for authenticity and integrity. At a minimum,
corpus tags are required to provide <Payload> details that enumerate all the files on the
installation media, including file sizes and hash values.
COR-4. A corpus tag MUST contain a <Payload> element that enumerates every file thatis included in the tagged installation media.
5.2

Implementing Primary Tags

The primary tag for a software product contains descriptive metadata needed to support a varietyof business processes. To ensure that tags contain the metadata needed to help automate IT andcybersecurity processes on information systems, additional requirements must be satisfied. Thissection provides guidance addressing the following topics: setting tag type indicator attributes todesignate a tag as a primary tag (see §5.2.1), specifying version and version scheme information(see §5.2.2), specifying <Payload> or <Evidence> information (see §5.2.3), and specifying
attributes needed support targeted search (see §5.2.4).
5.2.1

Setting the <SoftwareIdentity> Tag Type Indicator Attributes

To indicate that a tag is a primary tag, tag implementers ensure that the values of all three tag
type indicators (the <SoftwareIdentity> @corpus, @patch, and @supplemental
attributes) are set to “false”. This is enforced by the following guideline.
PRI-1. To indicate that a tag is a primary tag, the <SoftwareIdentity> @corpus,@patch, and @supplemental attributes MUST be set to “false”.
5.2.2

Specifying the Version and Version Scheme in Primary Tags

Primary tags identify and describe software products in a post-installation state. Like corpus tags,
primary tag information about product versions and associated version schemes is important toenable tag consumers to conduct various cybersecurity operations. Unlike the case for corpus
tags, however, guidelines for primary tags must distinguish between authoritative and nonauthoritative primary tag creators.
PRI-2. [Auth] If a software product has been assigned a version by the software provider,that version MUST be specified in the <SoftwareIdentity> @version attribute of
the product’s primary tag.
PRI-3. [Auth] If a primary tag contains a value for the <SoftwareIdentity>@version attribute, it MUST also contain a value for the <SoftwareIdentity>@versionScheme attribute which accurately reflects the versioning scheme used in the@version attribute.
PRI-4. [Non-Auth] If a software product has been assigned a version by the software
provider, and that version can be determined, the <SoftwareIdentity> @version
attribute of the primary tag MUST contain that value.
53

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

PRI-5. [Non-Auth] If a primary tag contains a value for the <SoftwareIdentity>@version attribute, and the version scheme of that @version attribute value can be
determined, the <SoftwareIdentity> @versionScheme attribute of the primary tag
MUST contain that version scheme value.
As was true for corpus tags (see §5.1.2), it is important that the version schemes used in primarytags enable distinct versions of a product to be placed in a defined order, minimally so that
consumers can determine whether one version of a product is “before” (earlier than) or “after”(later than) another version. Section 8.6.13 of the SWID specification provides a table ofpre-defined values for the @versionScheme attribute with defined semantics (reproduced
above in Table 3). If a value for the @versionScheme attribute is provided that is not listed
among the pre-defined values, ideally that value ought to come from a well-known public list ofversion scheme identifiers. The public list would specify the meaning for each version scheme
sufficiently to allow for comparing two versions and determining their relative order in asequence of versions.
5.2.3

Specifying Primary Tag Payload and Evidence

Detailed information about the files comprising an installed software product is a critical needfor cybersecurity operations. For example, such information enables software inventory andintegrity tools to confirm that the product described by a discovered tag is, in fact, installed on a
device. Authoritative tag creators are encouraged to provide a <Payload> element in the
primary tag, and non-authoritative tag creators are encouraged to provide an <Evidence>element in the primary tag.
PRI-6. [Auth] A <Payload> element SHOULD be provided in a software product’s
primary tag.
PRI-7. [Non-Auth] An <Evidence> element SHOULD be provided in a software
product’s primary tag.
Note that guidelines PRI-6 and PRI-7 specify that payload and evidence information is supplied
within the primary tag, and not within a supplemental tag. This is due to concerns about
additional processing complexity and difficulties with assuring the reliability of such payload
and evidence information when it is stored separately from the primary tag.
Ideally, <Payload> and <Evidence> elements should list every file that is found to be partof the product described by the tag. Such information aids in the detection of malicious software
attempting to hide among legitimate product files. It also aids in reconciling authoritative andnon-authoritative tags in cases where both kinds of tags exist on a device for the same product.
PRI-8. <Payload> and <Evidence> elements SHOULD list every file comprising the
product described by the tag.
Although a full enumeration of product files is the ideal, at a minimum, only those files subject
to execution, referred to here as machine instruction files, need to be listed. A machine
instruction file is any file that contains machine instruction code subject to runtime execution,
whether in the form of machine instructions that can be directly executed by computing hardwareor hardware emulators; bytecode that can be executed by a bytecode interpreter; or scripts that54

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

can be executed by scripting language interpreters. Library files that are dynamically loaded atruntime are also considered machine instruction files.
PRI-9. [Auth] If a <Payload> element is provided, it MUST list every machine instruction
file comprising the product described by the tag.
PRI-10. [Non-Auth] If an <Evidence> element is provided, it MUST list every machine
instruction file comprising the product described by the tag.
If a tag creator enumerates every file according to PRI-8, this can cause problems later for tag
consumers. Recall that Section 4.6 of this document provides guidelines that require tag creators
to supply file size, version, and hash information (see GEN-11 through GEN-18). These
guidelines are there to ensure that tag consumers can later use the provided information toconfirm the integrity of files discovered on devices. The problem, however, is that particular files
listed in a <Payload> or <Evidence> element might be changed for non-malicious reasons
at arbitrary times after the product is installed. Data and configuration files are two examples.
If a tag consumer were to inspect a particular file listed in a tag’s <Payload> or <Evidence>element, compare the file’s hash value as listed in a tag to a new value computed from the actual
file on a device, and discover a mismatch, that would be a “false positive” if that file was
expected to be dynamic. If tag consumers were to generally find that performing suchcomparisons led to an unwieldy number of false positives, they might be inclined to stop using
SWID tag payload and evidence information altogether, an undesirable outcome.
In the interest of minimizing the possibility of such false positives, this document provides
guidelines for tag creators to explicitly mark all mutable files listed in a tag’s <Payload>
element with a special value. Specifically, this document introduces an @n8060:mutable
extension attribute on <File> elements. The @n8060:mutable extension attribute takes a
Boolean value with the default value of “false”. Authoritative tag creators are required to set
the @n8060:mutable attribute value to “true” for any <File> element that describes a
non-static file. Non-authoritative tag creators are encouraged to do so whenever possible.
PRI-11. [Auth] If a <File> element included in a <Payload> element of a primary tag
describes a file that can undergo authorized changes over time in ways that could alter its
size, version, and/or hash value, the tag creator MUST set that file’s <File>@n8060:mutable extension attribute to “true”.
PRI-12. [Non-Auth] If it can be determined that a <File> element included in an<Evidence> element of a primary tag describes a file that can undergo authorized changes
over time in ways that could alter its size, version, and/or hash value, the tag creator
SHOULD set that file’s <File> @n8060:mutable extension attribute to “true”.
Observance of these guidelines by tag creators will help ensure that the resulting <Payload>and <Evidence> elements are useful to tag consumers attempting to verify the integrity of
installed software products, while minimizing the potential number of false positives that suchconsumers may have to cope with.

55

NISTIR 8060

5.2.4

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSSpecifying Product Metadata Needed for Targeted Search

The SWID specification furnishes the <SoftwareIdentity> @name attribute to capture“the software component name as it would typically be referenced.” This is also called the
product’s market name, i.e., the product name as used on websites and in advertising materials to
support marketing, sales, and distribution. Market names for commercial software products often
combine a variety of market-relevant descriptive elements, such as the provider’s “brand name,”
and the product’s market version, edition, revision, or update level. While any or all of theseelements may appear in the <SoftwareIdentity> @name attribute of the product’s primarytag, there is no consistency in whether or how those elements are included, making it difficult fora machine to reliably separate them out.
These metadata elements are often needed by local administrators, cybersecurity personnel, andsupporting automated tools when performing targeted searches. To make this possible, there
needs to be a way to individually refer to each descriptive element embedded within a product’s
market name. To this end, the SWID specification defines these <Meta> element attributes:•@product: The base name of the product. The base name is expected to exclude
substrings containing the software provider’s name, as well as any indicators of the
product’s version, edition, or revision level.

•@colloquialVersion: The market version of the product. This version may remain
the same through multiple releases of a software product, whereas the version specified in
the <SoftwareIdentity> @version is more specific to the underlying software
codebase and will change for each software release.

•@edition: The edition of the product.

•@revision: An informal designation for the revision of the product.

If these attributes are specified, targeted searches will be easier to define and execute, and it will
also be possible to mechanically generate a valid CPE name from an input SWID tag. 5 The
guideline is as follows:
PRI-13. If appropriate values exist and can be determined, a <Meta> element MUST be
provided and MUST furnish values for as many of the following attributes as possible:@product, @colloquialVersion, @revision, and @edition.
5.3

Implementing Patch Tags

As noted earlier in Section 2.1.3, a patch tag is used to describe localized changes applied to an
installed product’s codebase. This section provides guidance addressing the following topics
related to implementation of patch tags: setting the <SoftwareIdentity> @patch attribute(see §5.3.1), and specifying <Payload> or <Evidence> information (see §5.3.2).

5 See [NISTIR 8085] for an algorithm that may be used to generate such CPE names.

56

NISTIR 8060

5.3.1

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Setting the <SoftwareIdentity> @patch Attribute

To indicate that a tag is a patch tag, tag implementers set the value of the<SoftwareIdentity> @patch attribute to “true”. The SWID specification does not
specifically prohibit tag implementers from also setting other tag type indicator attributes to“true” (e.g., <SoftwareIdentity> @corpus and <SoftwareIdentity>@supplemental), but doing so would create confusion regarding how the information
contained within the tag should be interpreted. This report provides guidelines to ensure that at
most one tag type indicator attribute is set to true.
PAT-1. If the value of the <SoftwareIdentity> @patch attribute is set to “true”,
then the values of @corpus and @supplemental MUST be set to “false”.
5.3.2

Specifying Patch Tag Payload and Evidence

Patches change files that comprise a software product, and may thereby eliminate known
vulnerabilities. If patch tags clearly specify the files that are changed as a result of applying thepatch, software inventory and integrity tools become able to confirm that the patch has actually
been applied and that the individual files discovered on the device are the ones that should bethere. Guidelines in this section propose that patch tags document three distinct types of changes:
1. Update: A file previously installed has been modified in place or replaced on the device
with a modified version.
2. Remove: A file previously installed has been removed from the device.
3. Add: An entirely new file has been added to the device.
For files that are replaced or added, patch tags must include file sizes and hash values. As stated
before in requirements GEN-14 and GEN-16, authoritative tag creators are required to provide
this information in the <Payload> element of the patch tag. Non-authoritative tag creators areencouraged to provide this information whenever possible in the <Evidence> element of thepatch tag (see GEN-14, GEN-17).
PAT-2. [Auth] A patch tag SHOULD contain a <Payload> element that enumerates every
file that is replaced, removed, or added by the patch.
PAT-3. [Auth] Each <File> element contained within the <Payload> element of a patch
tag MUST include an extension attribute named @n8060:patchEvent, that has one of thefollowing values:•

The string value “update” to indicate that the patch updates a pre-existing installedfile by either modifying the file or replacing it with a new version of the file•

The string value “remove” to indicate that the patch removes a pre-existing
installed file•

The string value “add” to indicate that the patch installs a new file that did notpreviously exist

57

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

PAT-4. [Non-Auth] A patch tag SHOULD contain an <Evidence> element thatenumerates every file that was found to have changed as a result of the patch process.
5.4

Implementing Supplemental Tags

As noted in Section 2.1.4, supplemental tags are used to furnish identifying and descriptive
information not contained in other tags. This section provides guidance addressing the following
topics related to implementation of supplemental tags: setting the <SoftwareIdentity>@supplemental attribute (see §5.4.1), linking supplemental tags to other tags (see §5.4.2),
and establishing the precedence of information contained in a supplemental tag (see §5.4.3).
5.4.1

Setting the <SoftwareIdentity> @supplemental Attribute

To indicate that a tag is a supplemental tag, tag implementers set the value of the<SoftwareIdentity> @supplemental attribute to “true”. The SWID specification
does not specifically prohibit tag implementers from also setting other tag type indicator
attributes to “true” (e.g., <SoftwareIdentity> @corpus and <SoftwareIdentity>@patch), but doing so would create confusion regarding how the information contained within
the tag should be interpreted. This report provides guidelines to ensure that at most one tag typeindicator attribute is set to “true”.
SUP-1. If the value of the <SoftwareIdentity> @supplemental attribute is set to“true”, then the values of @corpus and @patch MUST be set to “false”.
5.4.2

Linking Supplemental Tags to Other Tags

An individual supplemental tag may be used to furnish data elements that complement or extend
data elements furnished in another individual tag. That is, a supplemental tag may not be used tosupplement a collection of tags. A supplemental tag may supplement any type of tag, including
other supplemental tags. Because the SWID specification does not clearly state how asupplemental tag should indicate its linkage to other tags, a clarifying guideline is provided here.
SUP-2. A supplemental tag MUST contain a <Link> element to associate itself with theindividual tag that it supplements. The @rel attribute of this <Link> element MUST be set
to “supplemental”.
Note that the SWID specification also requires that every <Link> element provide a value forthe @href attribute. Section 4.5 of this document provides pertinent guidelines for how tag
creators should use the @href attribute to refer to other tags, in situations when the @tagId of
the target is known (see GEN-11) and when it is not known (see GEN-12 and GEN-13).
5.4.3

Establishing Precedence of Information

As noted earlier, a supplemental tag is intended to furnish data elements that complement or
extend data elements furnished in another tag. This does not preclude situations in which a
supplemental tag contains elements or attributes that potentially conflict with elements or
attributes furnished in the tag being supplemented. For example, suppose a device contains a
primary tag where the value of the <SoftwareIdentity> @name attribute is specified as

58

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

“Foo”, and a supplemental tag is also present that is linked to the primary tag but specifies thevalue of the <SoftwareIdentity> @name attribute as “Bar”.
This report takes the position that supplemental tags strictly extend, and never override, data
elements found in the tags that are supplemented. In the example above, Foo is considered to be
the correct value for @name, and the value of Bar furnished in the supplemental tag is ignored.
Because certain attribute values pertain to tags themselves—e.g., @tagId, @tagVersion,and <Entity> information about the tag creator—differences in those values between asupplemental tag and a supplemented tag are never construed as conflicts. In other cases,
information in a supplemental tag may be combined with information in the supplemented tag toobtain a full description of the product. For example, a primary tag may provide an <Entity>element that specifies the tagCreator role, while a supplemental tag provides <Entity>elements specifying other roles such as softwareCreator and licensor. In this scenario,
the primary and supplemental tag collectively furnish all Entity roles. If, however, both theprimary and supplemental tags provide <Entity> elements specifying values for the same role(e.g., both tags specify different softwareCreator values), then the conflicting value in the
supplemental tag is ignored. This leads to the following guideline.
SUP-3. If a supplemental tag provides a data value that conflicts with corresponding data
values in the tag being supplemented, the data value in the supplemented tag MUST beconsidered to be the correct value.
5.5

Summary

Key points presented in this section include:•

The <SoftwareIdentity> @corpus, @patch, and @supplemental attributevalues are mutually exclusive, so that a tag type can be clearly distinguished as corpus,
primary, patch, or supplemental.

•

Corpus tags must provide <SoftwareIdentity> @version information, and also<SoftwareIdentity> @versionScheme information whenever possible. Corpus
tags also must include <Payload> details.

•

Primary tags must provide <SoftwareIdentity> @version information, and also<SoftwareIdentity> @versionScheme information whenever possible.
Authoritative creators of primary tags are encouraged to provide <Payload>
information, and also to include <Meta> attribute values needed to support metadatabased searching. Non-authoritative creators of primary tags are encouraged to provide<Evidence> information for any data used to detect the presence of the product.

•

Patch tags should document all files updated, removed, or added by the patch.

•

Supplemental tags may supplement any type of tag, but must be explicitly linked to the
supplemented tag. Any data value supplied in a supplemental tag that conflicts with acorresponding data value in the supplemented tag is ignored.

59

NISTIR 8060

6

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSSWID Tag Usage Scenarios

Enterprises are concerned with managing the security of endpoints, devices connected to their
networks. Knowing what software products are installed on these endpoints, which
vulnerabilities may be present in those products, and how to define policies around the
management of software, are critical to achieving a variety of cybersecurity objectives. Thissection presents a set of usage scenarios (US) that illustrate how, based on the guidelines
provided in Sections 4 and 5 of this document, security professionals can achieve three important
cybersecurity objectives:
1. Minimize exposure to publicly disclosed software vulnerabilities (see §6.1),
2. Enforce organizational policies regarding authorized software (see §6.2), and3. Control network resource access from potentially vulnerable endpoints (see §6.3).
By using SWID tags in accordance with the guidelines provided in this report, the security
practitioner (e.g., Chief Information Security Officer (CISO), Information System Security
Officer (ISSO)) can achieve these objectives quickly, accurately, and efficiently. Sections 6.1
through 6.3 each describe the cybersecurity objective to be achieved, followed by specific usage
scenarios that contribute to achieving the objective. Section 6.4 describes how the guidelines
presented in this report enable each scenario.
6.1

Minimizing Exposure to Publicly Disclosed Software Vulnerabilities

This section presents usage scenarios illustrating how SWID tags may be used by security
practitioners to minimize risks from exploitation of endpoints with known vulnerabilities within
enterprise networks. To minimize these risks, security practitioners need to maintain awarenessof vulnerabilities related to installed software, especially those vulnerabilities for which a patch
or other remediation has not been made available. Security practitioners also need to maintainawareness of changes to the software inventory on each endpoint, since each change could(intentionally or inadvertently) introduce new vulnerabilities. For example, a user might
unintentionally roll back a patch that mitigates a critical vulnerability.
This section presents three usage scenarios related to this cybersecurity objective:•

US 1 – Continuously Monitoring Software Inventory (see §6.1.1),•

US 2 – Ensuring that Products are Properly Patched (see §6.1.2), and•US 3 – Identifying Vulnerable Endpoints (see §6.1.3).

6.1.1

US 1: Continuously Monitoring Software Inventory

In this scenario, SWID tags are used to continuously monitor the inventory of software installed
on endpoints within an enterprise network. Tags are key to the process of gathering andmaintaining an up-to-date and accurate accounting of software inventory on each endpoint.
SWID data may be aggregated, if needed, in regional and/or enterprise-wide repositories. Using
this data, organizations are able to maintain an ongoing understanding of installed software
inventory by continuously monitoring software change event notifications. Information provided
by SWID tags contributes to an up-to-date and accurate understanding of the software on
endpoints. As software changes are made, the endpoint’s software inventory is updated to reflect
60

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

those changes. Modifications including installing, upgrading, patching, and removing software
occur throughout the software lifecycle.
One or more software discovery or monitoring tools (referred to generically in this section as“discovery tools”) can continuously monitor endpoints for software changes, either on an eventdriven basis or through periodic assessment of installation locations. These tools discoverchanges, including modifications to existing SWID tags on the endpoint. This analysis should
consider various sources for performing this discovery (see §2.3.1 for a discussion of SWID tag
placement on devices), including:•

Local filesystems directly attached to the endpoint, such as files installed by traditional
installation utilities and archived distributions (e.g., tar, zip);•

Temporary storage connected to the endpoint (e.g., external hard drives, Universal Serial
Bus (USB) devices);•

Software contained in native package installers (e.g., RPM Package Manager (RPM));and•Shared filesystems (e.g., a mapped network drive or network-attached storage) that
contain software that is executable from an endpoint.

SWID tags provide identification, metadata, and relationship information about an endpoint’s
installed software. Authoritative tags discovered on an endpoint can supply reliable andcomprehensive information about installed software, whereas discovery tools can place nonauthoritative SWID tags on the endpoint to leave a record of newly-discovered, untagged
products. This is an important capability, since it is likely that some software will be untagged at
the time of installation.
As the tools collect the data, SWID tags enable many reporting capabilities for enterprise system
software inventories. SWID tags can be aggregated to one or more repositories (e.g., regional orenterprise) to enable accurate analysis and reporting of the software products installed on a set oforganizational endpoints. This aggregation supports the exchange of normalized data pertaining
to these products, an important component of effectively managing IT across an enterprise.
SWID tags provide a vendor-neutral and platform-independent way to analyze the state of
installed software (e.g., software installed, products missing, or software in need of patching)
within the organization, and to monitor endpoints for the purpose of maintaining continual
awareness of their security posture.
6.1.1.1 Initial Conditions

This usage scenario assumes the following conditions:•

A software discovery tool is installed on each enterprise-managed endpoint, and isconfigured to run on a defined schedule, on request, and/or in response to events
generated on the endpoint, which may indicate there has been a change to the installedsoftware inventory.

•

The discovery tool records inventory data in a configuration management database(CMDB), which may or may not be co-resident on the endpoint.

61

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS•The CMDB retains information about products (and their associated tags, if any), whichhave been discovered in the past on each endpoint. The discovery tool is able to use the
CMDB to compare current inventory state to the last known state in order to detectchanges.

•At the time the discovery process is run on each endpoint, the discovery tool has
sufficient access rights to the endpoint to discover each installed software instance andany associated metadata. This includes access rights to read SWID tags on the endpoint.

•

Some installed software products might not have an associated SWID tag because an
authoritative source did not furnish one.

6.1.1.2 Process

1. Upon detecting new or changed software in an installation location or in a filesystem
mounted on the endpoint, the discovery tool will collect and process all SWID tags (primary,
supplemental, and/or patch tags) present in that location. Changes to be detected may
include:•New software products (or subcomponents) that were not previously recorded in theinventory,•

Changes or updates to installed software products discovered previously, and•New or modified SWID tags, as indicated by a new @tagId or @tagVersion attributevalue within the <SoftwareIdentity> element.

2. The discovery tool will update the CMDB with the data from newly discovered or changed
SWID tags, creating new entries and/or modifying existing entries, as needed, for installed
products and their related software components. Because the software version information is
critical for understanding the related configuration and potential vulnerabilities of thesoftware installed on the endpoint, if any primary tag contains such version information(using the <SoftwareIdentity> element’s @version and @versionScheme
attributes), then that information will be recorded (see PRI-2, PRI-3, PRI-4, PRI-5).
The discovery tool will likely validate accessed tags using the SWID tag schema (see §3) toensure that the tag conforms to the SWID specification. If any tags are identified as not being
in compliance with the SWID specification (see GEN-1), those tags will not be recorded in
the CMDB, since they may not be reliable for the purpose of software inventory.
The discovery tool will consult the <SoftwareIdentity> @xml:lang attribute todetermine the default human language used for expressing language-dependent values within
the tag (see GEN-2 and GEN-3). It will also collect any furnished metadata for analysis andreporting purposes (see PRI-13).
3. The tool will determine the type of tag discovered, using the <SoftwareIdentity>@corpus, @patch, and @supplemental attributes (see PRI-1, COR-1, PAT-1, SUP1). The discovery tool will read any payload information provided within the tag, including
the file names, sizes, and cryptographic hashes for each component of the software product.
These values can later be used to perform file integrity verification (see GEN-14, GEN-15,
GEN-16, GEN-17, GEN-18, GEN-19, GEN-20, GEN-21, GEN-22, GEN-23, GEN-24,
PRI-6, PRI-7, PRI-8, PRI-9, PRI-10, PRI-11, PRI-12, PAT-2, PAT-3, PAT-4).
62

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

4. The discovery tool will attempt to determine if the tag is authoritative by checking that the@regid of the <Entity> element containing the @role value “tagCreator” also
contains the @role value of “softwareCreator”, “aggregator”, “distributor”,
or “licensor” (see GEN-4, GEN-5, GEN-6, GEN-7, GEN-8, GEN-9, GEN-10).
5. If a tag was not installed with the software, the discovery tool will create and deploy a nonauthoritative tag to the endpoint for each instance of a discovered application. As analternative, the discovery tool may be able to determine that a previously generated nonauthoritative tag already exists in the CMDB which describes the newly-discovered product.
This is possible if (1) the CMDB records all tags—authoritative and non-authoritative—
discovered or deployed anywhere within the enterprise, and (2) the discovery tool is able touse information about the newly-discovered product to retrieve a matching tag from the
CMDB. In this case, the discovery tool may simply deploy the matching tag from the CMDB
(or an appropriate related source) to the endpoint, rather than generate and deploy acompletely new non-authoritative tag.
Information about the files discovered is important to support continuous monitoring forsoftware vulnerabilities, so the deployed tag will list every machine instruction filecomprising the software product discovered (see §5.2.3), using the <Evidence> element(see PRI-7, PRI-8). This information will include filenames, sizes, versions, andcryptographic hashes discovered (see GEN-14, GEN-15, GEN-17, GEN-18, GEN-20,
GEN-21, GEN-22, GEN-23, GEN-24). It will also include any version information
determined for the software product (see PRI-4, PRI-5).
When SWID tags are discovered that do not conform to the 2015 release of the SWID
specification, these tags are not stored in the CMDB, but their contents might still be useful
to support the evidence collected above.
6. Many cybersecurity decisions will be based upon the authenticity and integrity of the SWID
tags discovered. To validate the integrity of a discovered tag, the discovery tool canauthenticate the certificate in the digital signature, validate the signature, and use the@thumbprint attribute of the <Entity> element (see §3.2) to ensure that the tag signer
is also the tag creator.
7. The discovery tool will read the tag identifier (i.e., @tagId) and identify the tag location,
along with the type of tag discovered or created: primary tags for installed software (see§2.1.2), and patch tags for software patches (see §2.1.3). Supplemental tags can provide
additional information and may be useful for inventory. If the tag identifier already exists ininventory, the discovery tool will determine if the tag version has changed by examining thevalue associated with the <SoftwareIdentity> element’s @tagVersion attribute. If
that tag version has been updated, the tool will register the updated values that were changedin the SWID tag (see GEN-25, GEN-26).
8. The CMDB will be updated, including sending notifications to applicable reporting systems
in the enterprise. The CMDB will track the changes discovered to support SAM and security
needs. This includes the location of discovered tags to enable subsequent extraction of theinformation contained in each tag when needed.
63

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Periodically, the complete set of tags from each endpoint is either sent to the enterpriserepository, or collected via a remote management interface by the discovery tool to create abaseline software inventory. Once this baseline inventory has been established, only softwarechanges since the last exchange need to be provided and may be supplemented with aperiodic full refresh. This provides for efficiencies in the velocity and volume of informationthat needs to be exchanged.
9. For a given endpoint, the discovery tool iterates through each tag in the repository, including
non-authoritative SWID tags.
10. The endpoint-collected tags are added to the enterprise repository, recording relevant
endpoint identification information (e.g., host name, IP addresses), the date and time of thedata collection, and data about the discovery tool or remote management interface used.
11. The discovery tool will record relationships between tags, as indicated within the SWID tags
discovered. For example, patch tags include a reference (using the <Link> element’s@href and @rel attributes) to the software being modified (see GEN-11, GEN-12, GEN13). Similarly, for supplemental tags recorded, the discovery tool will indicate the tag
identifier for the primary tag of the software for which additional information is being
provided (see SUP-2). If any data in the supplemental tag conflicts with the data in any tag it
supplements, the data in the supplemented tag is considered the correct value (see SUP-3).
6.1.1.3 Outcomes

The process described above provides an accurate and automated method for collecting
identifying and descriptive metadata about an endpoint’s inventory of installed software. Whenused in this way, SWID tags enable the collection of a comprehensive inventory of installedsoftware products by examining the system for SWID tags rather than attempting to infer
inventory information by examining arbitrary indicators on the endpoint (e.g., registry keys,
installed files).
SWID tags contribute to a reliable software inventory by supporting searching for specificproduct information or software characteristics (e.g., prohibited or required software, specificsoftware versions or version ranges, software from a specific vendor). The SWID specification
provides a rich set of data that may be used with specific query parameters to search for
instances of installed software. In addition to the common name and version values, many SWID
tags store extended information such as data identified through the <Link> and <Meta>
elements. Details regarding attributes and values that can be useful for queries are described in
Sections 3.1.4 and 3.1.5.
As an indirect result of maintaining a SWID tag-based inventory, the discovery tools candynamically identify vulnerabilities and misconfigurations. For example, upon discovering a
newly installed or changed software application, the discovery tool can check the configurationof that software using a pre-defined checklist. The discovery tool could also check for any
known vulnerabilities for that new or updated product. If the tool identifies a misconfiguration ora software vulnerability, that condition may be reported for mitigation.

64

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSIn many cases, the ability to consistently search for instances of installed software is important toachieving the organization’s cybersecurity situational awareness goals. Query results may be
used to trigger alerts based on pre-determined conditions (e.g., prohibited software detected) that
may be useful in a continuous monitoring context. The practitioner is able to know what is
installed and where it is installed, providing a critical foundation for other usage scenarios.
6.1.2

US 2: Ensuring that Products are Properly Patched

Enterprise security managers often need to quickly and easily generate reports about endpoints
having installed software products that are missing one or more patches, as this may signal
vulnerability to malicious activity. If a discovery tool also has a patch management capability, it
will need to determine that all prerequisite patches are installed before installing any newpatches. While this usage scenario focuses on an enterprise patch management approach, a local
patch management capability that is executed on an individual endpoint can also directly read theinventory of patch tags from the local repository to enable localized patch verification anddecision making.
6.1.2.1 Initial Conditions

This usage scenario assumes the existence of an enterprise repository, populated with SWID tags
that are created and collected using the process described in US 1 (see §6.1.1). This includes
application of guidelines GEN-1 through GEN-26, PRI-1 through PRI-13, and SUP-1 throughSUP-3.
6.1.2.2 Process

1. Through a dashboard or other internal process, the discovery tool determines that a given
software product needs to be patched (e.g., for a functional update, due to a discovered
vulnerability).
2. If the tag identifier of the required patch is known, the discovery tool searches through thepatch tags recorded in the repository for records indicating that a patch tag with thedesignated identifier is installed on an endpoint. If the patch tag identifier is unknown, thediscovery tool will search for patch tags with a name that matches the<SoftwareIdentity> @name of the desired patch.
3. The discovery tool then examines the patch tag to determine whether any other required
predecessor patches are also present. This is done by inspecting embedded <Link> elements
where the @role attribute value is “requires” (per §5.3.3 of the SWID specification),then confirming the presence of the target tag. If there is no such requirement, or if therequired patches are also confirmed as installed on the endpoint, the endpoint is recorded as
properly patched for this instance.
4. If desired, the discovery tool can validate each file expected to be added, modified, or
removed by the given patch(es). Patch tags created in accordance with the guidelines in
Section 5.3 (see PAT-1, PAT-2, PAT-3, PAT-4) require that the tag clearly specify the files
that are modified as a result of applying the patch. The discovery tool enumerates each of thefiles shown as added or modified within the <Payload> element of a patch tag as indicatedby the @n8060:patchEvent attribute. The tool compares the recorded filename and65

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

cryptographic hash with the actual files that reside on the endpoint. The discovery tool canalso confirm deletion of those files that the patch tag indicates should have been removed.
5. Where a patch is noted as missing, the discovery tool can take advantage of relationships toother patches, as described in Section 5.3.3 of the SWID specification, to see if that patch has
been superseded by a newer patch. In this case, the discovery tool can examine known patch
tags for any that are known to supersede the desired patch, noting that the former patch may
no longer apply.
6. The search results are provided through the discovery tool’s dashboard and/or reporting
process.
6.1.2.3 Outcomes

The discovery tool user is able to accurately and quickly identify instances where a required
patch or update is not installed on a given endpoint. If patched files are also assessed by taking
advantage of <Payload> or <Evidence> elements contained in patch tags, the user is able toverify patch installations. The user is able to determine which endpoints meet (or do not meet)
specific patch requirements, supporting security situational awareness and patch/vulnerability
management as part of a continuous monitoring solution.
6.1.3

US 3: Identifying Vulnerable Endpoints

The remediation of known vulnerabilities through timely patching is considered a vulnerability
management best practice. SWID tags improve vulnerability management by providing
comprehensive, compact descriptions of installed software and patches, which may then becompared and correlated with vulnerability information.
Because SWID tags adhere to a consistent and standardized structure, they aid automatedcorrelation of information published by vulnerability information sources (e.g., NIST’s National
Vulnerability Database, US-CERT [United States Computer Emergency Readiness Team] alerts,
vulnerability advisories issued by vendors and independent security analysts) with the inventory
information collected by discovery tools. Many vulnerability bulletins use the CPE specification
to identify classes of products that are affected by a vulnerability [CPE23N]. [NISTIR 8085]
describes a method to form CPE names automatically from input SWID tags. This capability canbe used to translate a software inventory based on SWID tags to one based on CPE names. Givena vulnerability bulletin that references products using CPE names, this translation can then be
used to identify potentially vulnerable endpoints.
If a tag creator uses the appropriate <Meta> attributes to specify additional detailed naming
information in a product’s primary tag (see §5.2.4), this information becomes readily available topublishers of vulnerability bulletins. By including appropriate references to those attributevalues, bulletins make it easier for consumers to accurately search SWID-based inventory data
for affected products. For example, if the presence or absence of a product vulnerability depends
on software edition information, it is advantageous both for tag creators to specify the <Meta>@edition attribute, and for publishers of vulnerability bulletins to reference that value
explicitly.

66

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

6.1.3.1 Initial Conditions

This usage scenario assumes the existence of an enterprise repository populated with SWID tags
that are created and collected using the process described in US 1 (see §6.1.1). This includes
application of guidelines GEN-1 through GEN-24, PRI-1 through PRI-13, and SUP-1 throughSUP-3.
6.1.3.2 Process

1. Using product advisories containing information about publicly disclosed software
vulnerabilities, the discovery tool searches for endpoints on which the referenced software is
installed. The search criteria may include SWID tag information such as the information
provided in the primary tag <SoftwareIdentity> @name and @version (see PRI-2,
PRI-3, PRI-4, PRI-5), and <Meta> @revision and @edition (see PRI-13).
Additionally, by forming CPE names from SWID tags (see [NISTIR 8085]), the discovery
tool can search for endpoints with software referenced by those CPE names included in thevulnerability bulletins.
2. If the bulletin references the tag identifier for the relevant tag for a software product or patch,the discovery tool will search for that identifier. SWID tags adhering to guidelines PRI-1
through PRI-5 enable the discovery tool to automatically and accurately correlate inventory
and vulnerability data.
3. If the bulletin only references one or more known filename(s), but does not identify thesoftware product itself, it will be necessary to search for software products and patches that
include the file(s). Guidelines PRI-6 through PRI-12 recommend that filename information
be captured in the <Payload> and/or <Evidence> elements of SWID tags to support thistype of query. As a result, the discovery tool can search the <Payload> and/or<Evidence> portions of recorded tag information in the repository to look for software andpatches of interest.
For example, to identify instances of the “Heartbleed” bug, 6 the tool might search for any
tags where the <Payload> and/or <Evidence> portions of recorded tags containreferences to the vulnerable OpenSSL library. Products including this library can be
identified and then those products can be searched for to identify vulnerable software
installations.
4. Where a record exists that matches the query parameters, as described above, the associatedendpoint is flagged as containing vulnerable software.
5. Where patch tag information is provided in the bulletin, the discovery tool queries therepository to determine whether the appropriate patch tag has been installed (see US 2,§6.1.2), including checks for predecessor or superseded patches.

6 More information about the Heartbleed bug is available from www.heartbleed.com.

67

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

6. If the endpoint is found to contain vulnerable software but not the associated patch(es), theendpoint may be flagged as potentially in need of remediation activities.
Consider the case of a fictional vulnerability involving a known buffer overflow in the productnamed Acme Roadrunner, affecting versions between 11.1 and 11.7 and between 12.0 and 12.1
(inclusive). The issue is remediated in version 12.2 and later. There is also a patch KB123 that
remediates the vulnerability. The discovery tool can review the collected SWID tags for theendpoint, searching for installed software instances that match:<SoftwareIdentity> @name="Acme Roadrunner" and either:whose major version is 11 and minor version is greater than or equal to 1; orwhose major version is 12 and minor version is less than 2.
And also the presence of the following in the software inventory:<SoftwareIdentity> @name="Acme_Roadrunner_KB123".

Upon discovering a SWID tag that indicates the installation of a vulnerable version of the Acme
Roadrunner product (e.g., Acme Roadrunner version 11.5), the discovery tool searches throughthe repository and discovers a patch tag named “Acme_Roadrunner_KB123” associated withthat endpoint.
Given the above scenario, the discovery tool reports that the endpoint contains software with aknown vulnerability, but the vulnerability appears to have been patched. This information can bereported for security situational awareness, also supporting security analysis.
6.1.3.3 Outcomes

Through the use of SWID tags for the description and discovery of vulnerable software,organizations are able to identify known vulnerabilities within their enterprise based on SWIDbased software inventory data and published vulnerability bulletins.
6.2

Enforcing Organizational Software Policies

This cybersecurity objective area focuses on the use of SWID tags to help security practitioners
minimize security risk by enforcing enterprise policies regarding authorized software. These
policies may be implemented as blacklists (lists of prohibited products, with all unlisted products
implicitly allowed) or whitelists (lists of allowed products, with all others prohibited). In
addition, specific products may be designated as mandatory by the enterprise (e.g., antivirus andintrusion detection and prevention applications), possibly depending on the endpoint’s role (e.g.,
end-user workstations versus Internet-facing web servers). Policies may be enforced at time of(attempted) product installation, and/or any time thereafter.
This section presents two usage scenarios:•

US 4 – Preventing Installation of Unauthorized or Corrupted Software (see §6.2.1), and•US 5 – Discovering and Preventing Corrupted Software Execution (see §6.2.2).

68

NISTIR 8060

6.2.1

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

US 4: Preventing Installation of Unauthorized or Corrupted Software

To strictly control what software may or may not be installed on enterprise endpoints, corpus
tags may be used whenever a software installation is initiated to confirm that the software to beinstalled either is included in a product whitelist, or is not included in a product blacklist. Theremight be multiple lists of authorized or unauthorized software. For example, Windows clientsmight have a list, Mac OS X clients another, and Linux servers yet another. Similarly, endpoints
that are dedicated to a particular role (e.g., “public-facing webserver”) might have unique lists ofallowed or prohibited software.
As described in Section 2.1.1, corpus tags may be used to authenticate the issuer of a software
product installation package before carrying out the installation procedure. Identification
information and other data in a corpus tag can be used to authorize or prohibit software
installation during the installation procedure. Additionally, if a manifest of the installation files is
included in the corpus tag (see §3.1.6 on the <Payload> element), the installation routine canconfirm (from the whitelist) that the software’s integrity has been preserved, preventing
unauthorized modifications to software distributions.
6.2.1.1 Initial Conditions

This usage scenario assumes that the following conditions exist:•

A software product/package to be installed includes a corpus tag describing what will be
installed.

•

The software installation system is policy-aware, in that it is able to consult organizationspecific whitelists/blacklists for the purpose of restricting software installations only toallowed products.

•

If the issuer of the installation package is to be verified, the corpus tag must be digitally
signed.

6.2.1.2 Process

1. Upon initiation of a software installation on an endpoint, the policy-aware installation system
discovers a corpus tag included with the distribution package of the software product thatwas requested to be installed. If no corpus tag is found, some installation systems may be
configured by enterprise policy to prevent the installation, ending this process.
2. If provided, the installation tool may examine the value of the @thumbprint attribute(s) of
the <Entity> element of the signer, comparing it to a hexadecimal string that contains ahash of the signer’s certificate. This allows each digital signature to be directly related to theentity specified. The installation tool validates the signer’s certificate and the tag’s signature
if the corpus tag is signed. If the signature is found to be invalid, the installation may be
prevented, ending this process.
3. The installation tool determines whether the @tagId or other data included in the tag (seeGEN-1, COR-1 through COR-4) matches the criteria specified in either a whitelist or a
blacklist. If the evaluation of the tag is determined to be in violation of the whitelist or
blacklist policy, then installation is prevented, ending this process.
69

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

4. The installation tool verifies the cryptographic hashes of the installation files using any<Payload> data included in the corpus tag (see COR-4, GEN-14, GEN-15, GEN-16,
GEN-18, GEN-19, GEN-21 through GEN-24). If any hash is found not to match, theinstallation is prevented, ending this process.
6.2.1.3 Outcomes

For the process described above, the application of SWID tags enables the organization to use
automation to control installation of software and patches, and to verify the signer and integrityof each installation package prior to installation.
6.2.2

US 5: Preventing the Execution of Corrupted Software

Similar to US 4 described above, effective software asset management includes the ability to
discover potentially compromised software that has already been installed on an endpoint. This isaccomplished by comparing the known hash values of installed software/packages (as recordedin the local endpoint repository and/or the enterprise repository) to the files actually observed on
the endpoint.
Detection of software tampering may be used for several purposes, including the following:•

To report potential compromise of an endpoint,•

To quarantine an endpoint pending further investigation, and•To prevent execution of an application that shows signs of unauthorized alteration.

Organizations are encouraged to take advantage of this capability by using SWID tags to convey
important information about the characteristics of installed software. Specifically, the ability tostore and compare cryptographic hashes of installed executable software is a useful method to
identify potential tampering or unauthorized changes.
This usage scenario provides an example of the benefit of a local repository that works in concert
with an enterprise repository. The local endpoint is able to perform a comparison of the recorded
cryptographic hash to the observed local file quickly enough to enable such a check on demand.
Because some legacy cryptographic hash algorithms are easily spoofed, the use of a stronger
methodology, as described in Section 4.6.2, will help provide confidence in the findings.
Comparison of observed hash values with recorded values in the enterprise repository requires
additional network and computing resources, and is more commonly performed as a periodic
monitoring task.
6.2.2.1 Initial Conditions

This usage scenario assumes the existence of an enterprise repository populated with SWID tags
that are created and collected using the process described in US 1 (see §6.1.1). This includes
application of guidelines GEN-1 through GEN-26, PRI-1 through PRI-12, and SUP-1 throughSUP-3.
6.2.2.2 Process

1. For each endpoint, the discovery tool reads each primary and supplemental SWID tag (seePRI-1, SUP-1, SUP-2, SUP-3), examining the stored cryptographic hashes for each file70

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

listed in the <Payload> or <Evidence> elements. This information may be collected andincluded in the SWID tag as described in guidelines PRI-6 through PRI-12 to provide
detailed information about the files comprising an installed software product. Detailed
information regarding the creation and comparison of cryptographic hashes with sufficient
security strength is described in Section 4.6.2.
Similarly, the discovery tool examines each patch tag to gather the cryptographic evidence
for files added or changed by that patch (see PAT-1, PAT-2, PAT-3, PAT-4).
2. The discovery tool calculates the current cryptographic hash of the actual files on those
endpoints using the same algorithm as originally used in the SWID tags.
3. If any calculated file hash does not match the one provided in the SWID tag, the discovery
tool reports the variance.
4. The tool may also, based upon the detection of potential tampering, prevent execution of thatsoftware product.
6.2.2.3 Outcomes

Identifying improperly altered executable files in an automated, accurate, and timely manner
supports an organization’s ability to prevent execution of files that have been infected bymalware or otherwise modified without authorization.
6.3

US 6: Preventing Vulnerable Devices from Accessing Network Resources

A forward-looking approach to improving organizations’ cybersecurity is to prevent potentiallyvulnerable devices from connecting to the network, or to move such devices to an isolated
network segment for remediation or investigation. Currently, products are available that achieve
this through proprietary methods, and groups are working on open standards to accomplish thisgoal. For example, the Trusted Computing Group’s Trusted Network Connect Working Grouphas defined an open solution architecture that enables network operators to enforce policies
regarding the security state of devices in order to determine whether to grant access to arequested network infrastructure. The use of SWID tags provides a technology-neutral way toverify a device’s compliance with certain configuration policies (e.g., updated antivirus
definitions, configuration compliance with baseline specifications) and safeguards against known
software vulnerabilities (e.g., missing patches).
In cases where a discovery tool is able to detect that a device is providing inventory data thatconflicts with known information, that condition may indicate that malicious software on thatdevice is intentionally misrepresenting the device’s condition. Such a conflict might provide anindicator of compromise that could trigger further investigation.
6.3.1

Initial Conditions

This usage scenario assumes the existence of an enterprise repository populated with SWID tags
that are created and collected using the process described in US 1 (see §6.1.1). This includes
application of guidelines GEN-1 through GEN-26, PRI-1 through PRI-12, and SUP-1 throughSUP-3.
71

NISTIR 8060

6.3.2

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Process

1. An endpoint attempts to access a given network resource, such as an enterprise wide area
network (WAN) or a protected website.
2. Using information from the local SWID tag repository, a trusted client on the endpointcollects the information needed to support a network access decision. Examples of theinformation to be collected include:•

The inventory of installed software and patches (see PAT-1)•

File metadata, including names, hashes, sizes, and versions (see PAT-2, PAT-3, PAT-4)

3. The client securely transfers this information to a policy decision point.
4. The policy decision point renders a decision based on the provided data, and issues a network
access recommendation to a policy enforcement point (e.g., a network switch). The policy
enforcement point might allow the endpoint on the network, place it on a restricted network,or quarantine the endpoint in order to remedy a potential risk (e.g., by updating patches orantivirus definitions). If an endpoint is assessed to be in violation of policy, but not to present
a significant risk, it may be allowed on the network, but subjected to detailed monitoring.
SWID-related data provided to a policy decision point may be used to determine:
•
•
•
6.3.3

If any known software vulnerabilities exist on the endpoint (see §6.1.1),
If the endpoint is properly patched (see §6.1.2), andIf the endpoint is in compliance with whitelist or blacklist requirements (see §6.2.1).
OutcomesThrough the use of well-formed SWID tags, network access decision points are able to collectvalidation information quickly and accurately, enabling the organization to help prevent theconnection of endpoints that represent a potential threat.
6.4

Association of Usage Scenarios with Guidelines

To aid in the association of usage scenarios to the guidelines described in Sections 4 and 5, theguidelines are organized into sets of families, described below, which help aggregate items into
relevant groupings. These items follow the coded identifier format described in the introduction
to Section 4 and are grouped into the following categories:
•
•
•
•
•

GEN: General guidelines applicable to all types of SWID tags,
COR: Guidelines specific to corpus tags,
PRI: Guidelines specific to primary tags,
PAT: Guidelines specific to patch tags, and
SUP: Guidelines specific to supplemental tags.

The guideline families are:•

Basic Compliance – Tags must be well-formed as described in the ISO 19770-2:2015
specification, so that they are interoperable among discovery tools (see GEN-1).

72

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS•Tag Type – Discovery tools need to be able to determine the type of SWID tag that is
discovered or recorded. Corpus, primary, patch, and supplemental tags are mutually
exclusive tag types that are readily distinguishable (see COR-1, PRI-1, PAT-1, SUP-1).

•

Internationalization – To support an international audience, tag creators are able toprovide language-dependent attribute values in region-specific human languages (seeGEN-2, GEN-3).

•

Entity Identification – SWID tag creators must concisely and accurately record entities,
which have an important role in addressing potential interoperability issues that could
arise when tag creators specify attribute values in multiple human languages (see GEN-4
through GEN-7). Additionally, discovery tools need to be able to inspect a SWID tag andrapidly determine the authority of the tag creator, since authoritative tags are more likely
to be accurate than non-authoritative tags (see GEN-8 through GEN-10).

•

Tag Relationships – Discovery tools need consistent reference information to be able tolink a source tag to one or more target tags (see GEN-11 through GEN-13). Because the
SWID specification does not clearly state how a supplemental tag should indicate its
linkage to other tags, it is important to follow guideline SUP-2 to establish a consistent
relationship between the tags.

•

Payload and Evidence – Detailed information about the files comprising an installedsoftware product is critical to help confirm that the correct files are installed and to verify
the integrity of those files. This information is derived from the <Payload> or<Evidence> information included in the SWID tag (see GEN-14 through GEN-24,
and PRI-6 through PRI-12). Software installation products can also use payload
information to prevent installation of software from media that might be corrupted (seeCOR-4). Patch tags need to comply with guidelines PAT-2 through PAT-4 to document
all changes to files resulting from application of the patch.

•

Tag Maintenance – While SWID tags are rarely changed, when this occurs (e.g., tocorrect an error) the tag identifier stays the same but the tag version needs to be
incremented to note that there is updated SWID tag information available (see GEN-25,
GEN-26).

•

Software Version Identification – Many cybersecurity objectives depend upon theability to accurately identify the name and version of software products in both pre- andpost-installation states. It is important that the version of a software product is provided
along with the version scheme so that software installers (see COR-2, COR-3) anddiscovery tools (see PRI-2 through PRI-5) can quickly and accurately determine asoftware product’s version. Proper use of well-known version schemes helps ensure thatsoftware versions are able to be parsed by tools supporting automation.

•

Metadata – Software products are often known by colloquial identifiers as well as byformal version references. Where metadata applies to the software identified by a SWID
tag, it helps accurately identify products and components installed (see PRI-13).

•

Data Deconfliction - Supplemental tags are secondary to the primary, corpus, and patch
tags they support; guideline SUP-3 helps ensure that the original tag (the one being
supplemented) has the correct and primary information in case of any conflict.
73

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

Table 4 illustrates the association among the usage scenarios and the previously describedguidelines. The usage scenarios demonstrate the rationale for each of the guidelines to helporganizations consistently achieve important cybersecurity objectives through the appropriate
creation and usage of well-formed SWID tags.
Table 4: Relationship of Guidelines to Usage Scenarios
Guideline Family
Basic Compliance

Guideline

GEN-20[N]GEN-21

○

○

○

◒
◒
◒
◒
●

◒
◒
◒
◒
●

◒
◒
◒

PAT-1
SUP-1
GEN-2
GEN-3[N]GEN-4[A]GEN-5[N]GEN-6[N]Entity Identification

GEN-7
GEN-8[A]GEN-9[A]GEN-10[N]GEN-11

Tag Relationships

GEN-12
GEN-13GEN-14GEN-15GEN-16[A]GEN-17[N]GEN-18

Payload and Evidence

Usage Scenario
3
4
5

●
●
●
●
●
●
◒
●
●
◒
●
●
●
◒
●
●
●
●
●
●
◒
◒
●
◒

PRI-1

Internationalization

2

●
●
●
●
●
●
◒
●
●
◒
●
●
●
◒
●
●
●
●
●
●
◒
◒
●
◒

GEN-1
COR-1

Tag Type1

GEN-19[A]GEN-22
GEN-23GEN-24GEN-25

Tag MaintenanceGEN-26

74

●
●
●
●
●
◒
●
●
◒
●
●
●
◒
●
●
●
●
●
●
◒
◒
●
◒

●
●

6

●

●

●
●
●
●
◒
●
●
◒
●
●
●
◒
●
●
●
●
●
●
◒
◒
●
◒

●
●
●
●
◒
●
●
◒
●
●
●
◒
●
●
●
●
●
●
◒
◒
●
◒

○

○

○

◒
◒
◒

◒
◒
◒
◒
●

◒
◒
◒
◒
●

●
●
●
◒
●

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS
Guideline Family

Guideline

1

2

●
●
●
●
◒
◒
◒
●
●
●
◒
●
◒
●
◒
●
●

●
●
●
●
◒
◒
◒
●
●
●
◒
●
◒
●
◒
●
●

Usage Scenario
3
4
5

●
●
●

COR-2

Software Version Identification
COR-3
Payload and Evidence

COR-4
PRI-2[A]PRI-3[A]Software Version Identification
PRI-4[N]PRI-5[N]PRI-6[A]PRI-7[N]PRI-8
Payload and Evidence

PRI-9[A]PRI-10[N]PRI-11[A]PRI-12[N]Metadata

PRI-13
PAT-2[A]Payload and Evidence

PAT-3[A]PAT-4[N]Tag Relationships

SUP-2

Data Deconfliction

SUP-3

●
●
◒
◒
◒
◒
◒
●
●
●
◒
●

◒
◒
◒
●
●
●
◒

●
●
●
●
◒
◒
◒
●
●
●
◒

◒
●
◒
●
●

◒
●
◒
●
●

Symbol indicates: ● mandatory guideline, ◒ recommended guideline, ○ optional guideline

75

6NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSAppendix A—Acronyms

Selected acronyms and abbreviations used in this report are defined below.
API
CA
CISO
CMDB
CPE
DSS
FIPS
HTML
IANA
IEC
IEEE
IETF
IP
ISO
ISSO
ITL
NAS
NIST
NISTIR
RFC
RPM
SAM
SHA
SHS
SP
SWID
URI
U.S.
US
USB
US-CERT
W3C
WAN
XML
XPath
XSD

Application Programming Interface
Certificate Authority
Chief Information Security Officer
Configuration Management Database
Common Platform Enumeration
Digital Signature Standard
Federal Information Processing Standards
Hypertext Markup Language
Internet Assigned Numbers Authority
International Electrotechnical Commission
Institute of Electrical and Electronics Engineers
Internet Engineering Task Force
Internet Protocol
International Organization for Standardization
Information System Security Officer
Information Technology Laboratory
Network Attached Storage
National Institute of Standards and Technology
National Institute of Standards and Technology Internal Report
Request for Comments
RPM Package Manager
Software Asset Management
Secure Hash Algorithm
Secure Hash Standard
Special Publication
Software Identification
Uniform Resource Identifier
United States
Usage Scenario
Universal Serial Bus
United States Computer Emergency Readiness TeamWorld Wide Web Consortium
Wide Area Network
Extensible Markup Language
XML Path Language
XML Schema Definition

76

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGSAppendix B—References[CPE23N]

Cheikes, B. A., Waltermire, D., and Scarfone, K. Common Platform
Enumeration: Naming Specification 2.3. National Institute of Standards andTechnology Interagency Report 7695, August 2011.
http://csrc.nist.gov/publications/nistir/ir7695/NISTIR-7695-CPE-Naming.pdf[accessed 2/4/2016].

[FIPS180-4]

U.S. Department of Commerce. Secure Hash Standard (SHS), Federal
Information Processing Standards (FIPS) Publication 180-4, August 2015.
http://dx.doi.org/10.6028/NIST.FIPS.180-4.

[FIPS186-4]

U.S. Department of Commerce. Digital Signature Standard (DSS), Federal
Information Processing Standards (FIPS) Publication 186-4, July 2013.
http://dx.doi.org/10.6028/NIST.FIPS.186-4.

[ISO/IEC
197702:2009]

International Organization for Standardization/International ElectrotechnicalCommission, Information technology -- Software asset management -- Part
2: Software identification tag, ISO/IEC 19770-2:2009, November 2009.
http://www.iso.org/iso/catalogue_detail?csnumber=53670 [accessed
2/4/2016].

[ISO/IEC
197702:2015]

International Organization for Standardization/International ElectrotechnicalCommission, Information technology -- Software asset management -- Part
2: Software identification tag, ISO/IEC 19770-2:2015, October 2015.
http://www.iso.org/iso/catalogue_detail?csnumber=65666 [accessed
2/19/2016].

[ISO/IEC
197705:2013]

International Organization for Standardization/International ElectrotechnicalCommission, Information technology -- Software asset management -- Part
5: Overview and vocabulary, ISO/IEC 19770-5:2013, 2013.
https://www.iso.org/obp/ui/#iso:std:iso-iec:19770:-5:ed-1:v1:en [accessed
2/4/2016].

[NISTIR
7802]

Booth, H., and Halbardier, A. (2011). Trust Model for Security Automation
Data 1.0. National Institute of Standards and Technology Interagency Report
7802, 2011. http://csrc.nist.gov/publications/nistir/ir7802/NISTIR-7802.pdf[accessed 2/4/2016].

[NISTIR
8085]

Cheikes, B. A., and Waltermire, D., Forming Common Platform
Enumeration (CPE) Names from Software Identification (SWID) Tags.
National Institute of Standards and Technology Interagency Report 8085
(Draft), December 2015.
http://csrc.nist.gov/publications/PubsNISTIRs.html#NISTIR8085 [accessed
2/4/2016].

77

NISTIR 8060

GUIDELINES FOR THE CREATION OF
INTEROPERABLE SWID TAGS

[RFC 2119]

Bradner, S. Key words for use in RFCs to Indicate Requirement Levels.
Internet Engineering Task Force (IETF) Network Working Group Request
for Comments (RFC) 2119, March 1997.
https://dx.doi.org/10.17487/rfc2119.

[RFC 3490]

Faltstrom, P., Hoffman, P., and Costello, A. (2003). Internationalizing
Domain Names in Applications (IDNA). Internet Engineering Task Force(IETF) Network Working Group Request for Comments (RFC) 3490, March
2003. https://dx.doi.org/10.17487/rfc5234.

[RFC 3986]

Berners-Lee, T., Fielding, R., and Masinter, L. Uniform Resource Identifier(URI): Generic Syntax. Internet Engineering Task Force (IETF) Network
Working Group Request for Comments (RFC) 3986, January 2005.
https://dx.doi.org/10.17487/rfc3986.

[RFC 5234]

Crocker, D., and Overell, P. Augmented BNF for Syntax Specifications:
ABNF. Internet Engineering Task Force (IETF) Request for Comments(RFC) 5234, January 2008. https://dx.doi.org/10.17487/rfc5234.

[SEMVER]

Preston-Werner, T. Semantic Versioning 2.0.0.
http://semver.org/spec/v2.0.0.html [accessed 2/4/2016].

[SP800-107]

Dang, Q. Recommendation for Applications Using Approved Hash
Algorithms, NIST Special Publication (SP) 800-107 Revision 1, National
Institute of Standards and Technology, August 2012.
http://dx.doi.org/10.6028/NIST.SP.800-107r1.

[SP800-57part-1]

Barker, E. et al. Recommendation for Key Management – Part 1: General,
NIST Special Publication (SP) 800-57 Part 1 Revision 4, National Instituteof Standards and Technology, January 2016.
http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4.
Ishida, R. Language tags in HTML and XML. W3C Article, September 2009.
http://www.w3.org/International/articles/language-tags [accessed 2/4/2016].

[W3Clangtags][xmldisgcore]

Bartel, M. et al. XML Signature Syntax and Processing (Second Edition).
World Wide Web Consortium (W3C) Recommendation, June 2008.
http://www.w3.org/TR/xmldsig-core/ [accessed 2/4/2016].

[XPATH
2.0]

World Wide Web Consortium (W3C) XML Path Language (XPath) 2.0(Second Edition), December 2010. http://www.w3.org/TR/xpath20 [accessed
2/4/2016].

78