Security Content Automation Protocol Version 2 (SCAP v2) SCAP v2

SCAP is a suite of specifications for exchanging security automation content used to assess configuration compliance and to detect the presence of vulnerable versions of software. The same SCAP content can be used by multiple tools to perform a given assessment described by the content.

SCAP v2 will allow software installation and configuration posture to be monitored and reported as changes to that posture occur. Event-driven reporting will be used in SCAP to support software inventory and vulnerability management. SCAP will also be expanded to include transport protocols that enable the secure, interoperable communication of security automation information. Where possible, SCAP v2 will adopt international standards to address issues and gaps in SCAP v1.

With SCAP v2, timeliness of collection and evaluation will be improved through the monitoring and reporting of posture changes as they occur. This will improve on the currency of collected posture as compared to the periodic scanning approach supported by SCAP v1. SCAP v2 will also allow for more active responses to posture changes as they occur.

Contribute to SCAP v2 to by engaging in discussion on the SCAP Dev list, attending SCAP v2 related events, and contributing text to SCAP v2 specifications and component standards. Information on subscribing to the SCAP Dev list is available at SCAP v2 Community

Participation in the appropriate standards bodies and as part of the SCAP community is the most effective way to contribute to the development of SCAP v2 specifications and component standards. Soon, the SCAP specifications will be hosted on a GitHub repository, which will facilitate community contribution.

Resources related to SCAP v2 (slides, papers, specifications, etc.) can be found at Presentation Archives and at Teleconferences Minutes and Archives.

This is still to be determined. There are several existing data models and protocols that could be adopted, but the final set of data models and protocols will be decided by the community. If data models from SCAP v1 are not carried over to SCAP v2 or are replaced by new data models, a transition plan will be established to ensure that SCAP v2 can operate alongside existing SCAP solutions.

SCAP v2 intends to update existing SCAP v1 data models and to leverage new data models and protocols produced by international standards organizations to address new and evolving capabilities. SCAP v1 data models need to be reviewed, and individual data models will need to be updated or replaced to address current trends in technology.  These modifications will be done through engagement with the SCAP community. Where existing standards need to be updated, the SCAP v2 community is encouraged to get involved in the associated standard organizations to drive standards development to support SCAP v2 requirements. Furthermore, if a data model or protocol doesn't exist, it should be developed by the community and brought to most appropriate international standards organization for standardization.

As of December 2018, NISThas been hosting a series of teleconferences with the SCAP community to establish the scope and direction of the development efforts that will be required to make SCAP v2 successful. Based on community collaboration, longer-term work continues thru 2019.

The first release of SCAP v2, SCAP 2.0, will focus on traditional endpoints to support software inventory and vulnerability management use cases. CPE identifiers, used in SCAP v1 for software version identification, will be replaced with Software Identification (SWID) Tags. Other priorities for SCAP 2.0 may also be identified based on feedback from the SCAP community.

Following the SCAP 2.0 release, development of future SCAP v2 releases will focus on expanding the scope of supported endpoint types as dictated by the community, developing support for additional use cases, and standardizing the protocols that will be used to access the SCAP Configuration Management Database (CMDB).

SCAP v1 is used across multiple industry sectors today, including significant use in the public, financial and healthcare sectors internationally. To improve on the utility and adoption of SCAP, engagement with members of a diverse set of sectors is needed.  The best way to do that is to get members of those and other groups involved through community outreach by all its members.

To support broad use, SCAP v2 is intended to cover many security automation use cases. The initial security use cases are described in detail in the NIST White Paper:  https://csrc.nist.rip/publications/detail/white-paper/2018/09/10/transitioning-to-scap-version-2/final. Additional use cases will be added based on community collaboration.

Initially, SCAP v2 will cover traditional endpoint systems: workstations, servers, and laptops. SCAP v2 will expand over multiple releases to cover other platforms, including network, mobile, IoT, and medical devices. Selection of endpoint types to support will be based on community collaboration.

SCAP v2 in its initial 2.0 release will not support all SCAP v1 use cases. Enterprises may need to temporarily retain SCAP v1 tools for those uses. As SCAP v2 evolves over multiple releases, its scope will expand to cover configuration compliance and other use cases. SCAP v2's configuration compliance solution will likely make use of XCCDF and OVAL, perhaps in a revised form, providing continuity with SCAP v1 during and after a transition period.

SWID tags are very important in SCAP v2. Common Platform Enumeration (CPE) doesn’t scale well, doesn't support patch information, and was intended to be a software identifier rather than a software inventory standard. SWID tags can be produced by the software provider and are managed with the software on an endpoint, which is much more scalable and supports software inventory use cases.

Rapid growth in Common Vulnerability and Exposures (CVE) assignments, over the last couple of years, has also increased the work load and labor costs for analyzing CVE information and producing CPEs by the National Vulnerability Database (NVD). The use of SWID tags provides the vulnerability management community with an approach to software identification and characterization that scales well as compared to CPE. Developing tools that facilitate the integration of SWID tags into the software development and release process is the only sustainable path to support software identification in a scalable way.

CPE is being deprecated and will not be supported as it was in SCAP v1.  Transitioning from CPE to use of SWID tags needs to be managed to help organizations relying on CPE today to transition. NIST will work with the SCAP/CPE community to develop a plan for transitioning from CPE to SWID., and we will work with the community on how this can be best supported.

SCAP v2 is intended to be a community-driven effort that adopts standard data models and protocols that support hardware inventory, software inventory, vulnerability management, and configuration setting management use cases. Standards will be considered by the community on a case-by-case basis to determine their ability to satisfy these use cases as well as the community’s willingness to implement them. The long-term viability, extensibility, and scalability of a data model or protocol must be a consideration for selection. Ideally, the data models and protocols adopted for SCAP v2 will provide a stable base that can be extended to support additional endpoint information and capabilities over time.

The implementation of data models and protocols being considered for use in SCAP v2 varies widely. As consensus is reached around applicable standards, we will track their use on a page linked from this FAQ.

The standards are live, and they are designed to extensible. NIST will work with the community to ensure that, if standards are adopted by SCAP v2, those standards may grow and evolve in a way that will not create backward compatibility problems. The community will also need to work with the appropriate standards bodies to ensure that plans for future expansion have been established. Finally, as with SCAP v1, SCAP will be revised over time at a pace that balances liveness with a useful frequency of release to support ongoing adoption of changes. This balance will be established based on community feedback.

The list of standards SCAP v2 supports is still evolving and is open for community discussion. NIST is committed to discuss with the community the benefits of applicable standards and how they can support SCAP v2 use cases.

No, given the modular design of the SCAP v2 architecture, many of the architectural components can be combined on a single device or deployed across multiple devices.

Yes, SCAP v2 is intended to be used by enterprises of all sizes. Ideally, SCAP v2 capabilities will be built into future versions of the operating systems and applications used by enterprises today. Smaller enterprises might not choose to implement all parts of the modular SCAP v2 architecture. For example, small enterprises might not field their own local vulnerability database and may instead leverage a service provided by third-parties, such as NIST's NVD, or a vendor solution.

 Yes, SCAP v2 components can be provisioned on closed LAN networks. Internet access isn't required.