You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ISO/IEC 19770-2:2015 SWID (Software Identification) Tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles.
IETF draft-ietf-sacm-cowid-22 CoSWID (Concise Software Identification) Tags are a concise representation of SWID tags where SWID tag representations are too large for devices with network and storage constraints.
Use-cases for SWID and CoSWID Tags
SWID and CoSWID Tags are designed to support software asset management by providing a standardised representation of the critical attributes of installed software, such as software vendor, name, major, minor and patch versions, etc.
In more modern use-cases, SWID and CoSWID Tags build the foundation of continuous software attribute and posture collection. This would assist organisations in compliance scanning, vulnerability scanning, and general software inventorying.
Comparison to CPE
CPE (Common Product Enumeration) is a specification introduced and developed under the NIST SCAP (Security Content Automation Platform) v1 specification umbrella. CPE is the predecessor to SWID and "is being deprecated and will not be supported as it was in SCAP v1".
SWID and CoSWID Tags are the successor to CPE. It resolves the following issues with CPE (taken from NIST.CSWP.09102018):
Inadequate expression of granular metadata about software releases and version ranges to accurately identify vulnerable software
Inability to identify software patches
Notably, version ranges are ubiquitous in the Node.js and NPM ecosystem. With CPE, every vulnerable version would need to be enumerated. In addition, the more granular expression of SWID Tags enables better extraction of semantic meaning behind the SWID Tag, and how it relates to the other packages and versions released under the LoopBack project.
Relevance to LoopBack project
The LoopBack project has ongoing work to revamp its publication of security advisories. As part of this work, the LoopBack project has decided to update the NIST CPE dictionary (see: #3).
These CPEs are intended to be placed as part of security advisories, and for more general use by the LoopBack community.
As CPEs are considered deprecated, the LoopBack project should consider publishing SWID Tags alongside CPEs. As CPEs can be generated, there is little cost for maintaining current and future CPEs. Likewise, SWID Tags can also be generated and hence has little maintenance cost beyond initial "generation code" prototyping.
Further usage
SWID tags can also be stored in *.swidtag files for discovery by a SWID-aware file system scanner. Hence, LoopBack Node.js modules can be packaged with *.swidtag files for discovery by more generic tools which may not be Node.js module-aware.
Another use-case is exposure of LoopBack server information as SWID Tags, which are discovered through ROLIE (Resrouce-Oriented Lightweight Information Exchange) Feeds. This would enable for software attribute collection in line with SCAP v2 and SACM (Security Automation and Continuous Monitoring) architecture.
Relevance to LoopBack users
LoopBack users can benefit from leveraging existing or potential tooling which understand SWID and CoSWID Tags to aid in managing their IT asset management programme without relying on Node.js-aware scanners. By combining *.swidtag files and publishing of SWID Tags in security advisories, LoopBack users can use generic tools to perform correlation of security advisories against their environment. This is further extended through Vex profiles, which provide a more granular insight to the practical impact of LoopBack dependency vulnerabilities as dictated by the LoopBack Maintainers or by external security researchers
Overview of specifications
ISO/IEC 19770-2:2015 SWID (Software Identification) Tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles.
IETF draft-ietf-sacm-cowid-22 CoSWID (Concise Software Identification) Tags are a concise representation of SWID tags where SWID tag representations are too large for devices with network and storage constraints.
Use-cases for SWID and CoSWID Tags
SWID and CoSWID Tags are designed to support software asset management by providing a standardised representation of the critical attributes of installed software, such as software vendor, name, major, minor and patch versions, etc.
In more modern use-cases, SWID and CoSWID Tags build the foundation of continuous software attribute and posture collection. This would assist organisations in compliance scanning, vulnerability scanning, and general software inventorying.
Comparison to CPE
CPE (Common Product Enumeration) is a specification introduced and developed under the NIST SCAP (Security Content Automation Platform) v1 specification umbrella. CPE is the predecessor to SWID and "is being deprecated and will not be supported as it was in SCAP v1".
SWID and CoSWID Tags are the successor to CPE. It resolves the following issues with CPE (taken from NIST.CSWP.09102018):
Notably, version ranges are ubiquitous in the Node.js and NPM ecosystem. With CPE, every vulnerable version would need to be enumerated. In addition, the more granular expression of SWID Tags enables better extraction of semantic meaning behind the SWID Tag, and how it relates to the other packages and versions released under the LoopBack project.
Relevance to LoopBack project
The LoopBack project has ongoing work to revamp its publication of security advisories. As part of this work, the LoopBack project has decided to update the NIST CPE dictionary (see: #3).
These CPEs are intended to be placed as part of security advisories, and for more general use by the LoopBack community.
As CPEs are considered deprecated, the LoopBack project should consider publishing SWID Tags alongside CPEs. As CPEs can be generated, there is little cost for maintaining current and future CPEs. Likewise, SWID Tags can also be generated and hence has little maintenance cost beyond initial "generation code" prototyping.
Further usage
SWID tags can also be stored in
*.swidtagfiles for discovery by a SWID-aware file system scanner. Hence, LoopBack Node.js modules can be packaged with*.swidtagfiles for discovery by more generic tools which may not be Node.js module-aware.Another use-case is exposure of LoopBack server information as SWID Tags, which are discovered through ROLIE (Resrouce-Oriented Lightweight Information Exchange) Feeds. This would enable for software attribute collection in line with SCAP v2 and SACM (Security Automation and Continuous Monitoring) architecture.
Relevance to LoopBack users
LoopBack users can benefit from leveraging existing or potential tooling which understand SWID and CoSWID Tags to aid in managing their IT asset management programme without relying on Node.js-aware scanners. By combining
*.swidtagfiles and publishing of SWID Tags in security advisories, LoopBack users can use generic tools to perform correlation of security advisories against their environment. This is further extended through Vex profiles, which provide a more granular insight to the practical impact of LoopBack dependency vulnerabilities as dictated by the LoopBack Maintainers or by external security researchersSpecifications which incorporate SWID and CoSWID
Tools which leverage SWID and CoSWID Tags
This is a non-exhaustive list.
Projects & software which produce SWID an CoSWID Tags
This is a non-exhaustive list.
References
Information technology — IT asset management — Part 2: Software identification tag https://www.iso.org/standard/65666.html
Automation Protocol (SCAP) Version 2 - NIST Cybersecurity White Paper https://doi.org/10.6028/NIST.CSWP.09102018
The text was updated successfully, but these errors were encountered: