On May 7, 2025 the US Department of Defense provided guidance to software developers requiring secure software development practices in accordance with OMB M-22-18 and CISA Guidance. This is consistent with NASA SCRM policies and practices. CISA's Secure by Design best practices guidance for SBOM and other artifacts referred to in the DoD materials is available here
On September 14, 2022 the Office of Management and Budget published a memo, M-22-18, advising Federal Agencies on the steps to secure the software supply chain (SCRM) as part of procurement activities for software products. The memo identifies specific steps and timeframes for agencies to implement, starting in January 2023. The memo is very clear in setting expectations for Federal Agencies “Federal agencies must only use software provided by software producers who can attest to complying with the Government-specified secure software development practices, as described in the NIST Guidance.” See CISA's Software Acquisition Guide for specific SCRM best practices to implement.
This article contains information to help software vendors prepare for the forthcoming M-22-18 requirements identified as “NIST Guidance”. OMB Memo M-23-16, issued June 9, 2023 indicates that self-attestation form collection will begin after the CISA self-attestation form has been approved. (looks like the collection process will begin on June 8, 2024, using the RSAA repository system)
Guidance from the GSA issued in January 2024 provides the clearest understanding of what actions will be taken during pre-procurement risk assessment activities: "Prior to purchase, agencies should also assess the quality of the product or system components, vulnerabilities, authenticity, and other relevant risk factors and complete the risk assessment prior to deployment."
Three main artifacts are described in this article:
- Open source, free to use Vendor Response File (VRF) with links to artifacts and attestation materials used in a product risk assessment. A VRF is like an index card at the library showing where all the other documents can be found for a product/supplier, i.e. SBOM, VDR, SAG Spreadsheet, SDLC policies, etc.
- CISA's Software Acquisition Guide Spreadsheet used to evaluate Vendor practices for Secure by Design
- CISA final Secure Software Development Attestation Form approved March 2024
The current open-source, free to use VRF XML Schema is always available here.
The free to use, open-source Vendor Response File (VRF) machine readable format is used by software vendors to provide Procurement Officers with information required under M-22-18. The material included in the VRF contains links to several evidentiary files (Attestations) based on the requirements needed to meet NIST’s SP 800-161 and SP 800-218 standards, which are part of the “NIST Guidance” identified in the OMB memo and the North American Transmission Forum Security Assessment Model to satisfy FERC Order 850. The following table lists the data provided in a VRF. NOTE the VendorLegalName and the Product LicensorName may be different entities, this occurs often when resellers are the “Vendor” i.e. System Integrators and they are supplying software products from various Software Product Suppliers. It is common to find the VendorLegalName and Product Licensor Name belong to the same entity, i.e. Microsoft Corporation.
It's very likely that systems integrators/project managers, identified by the VendorLegalName, will need to provide a VRF per project in order to identify and provide all of the attestation materials required for the project deliverables. The VRF file name should indicate which project, or contract, the response file is associated.
Element Name
Description
VendorLegalName
Legal name of the vendor that supplied this information
SupplierID
A unique identifier for the vendor that supplied this information, i.e. dns:reliableenergyanalytics.com or a SAM.gov Unique Entity ID (UEI)
StreetAddress
Postal address of the vendor that supplied this information
City
City or Town where the postal address is located
StateOrProvince
State or Province where the City or Town is located
ZipCode
Postal zip code of the vendor’s address
Country
Country where the vendor address is located
WebsiteURL
A website URL where vendor information is located. Ideally, this is the access controlled URL where vendor supply chain artifacts are stored, such as a VRF, SBOM and other artifacts that consumers need to perform a risk assessment.
ContactTelephone
Telephone number for a contact person that can answer questions about VRF information
ContactEmail
Email address for a contact person that can answer questions about VRF information
ContactPerson
Name of person that can answer questions about VRF information
DUNSNumber
DUNS Number assigned to the vendor. May be blank. This is not required for the CISA Attestation Form.
NAESBEIRID
Identify ID assigned in the NAESB Energy Industry Registry (EIR). May be blank. This is not required for the CISA Attestation Form.
CyberSecPolicyURL
Link to the cybersecurity policies and practices attestation document implemented by the vendor, across the company
FinancialDataURL
Link to the most current attestation of financial data available from the vendor, i.e., EDGAR documents
CompanyDataURL
Link to attestation of Company Data, i.e. ownership (FOCI) information, locations and other information the vendor chooses to disclose. A good example for Company Data is available here.
Products
Container element for all products listed in the VRF
Product
Occurs once per product listed under Products. The following elements occur for each Product listed under Products
LicensorName
Name of licensor (software producer) for this product, i.e. Microsoft Corporation. Equated to NTIA minimum element "Supplier Name". This equates to the "Producer" described in OMB M-23-16, issued June 9, 2023.
ProductName
Name of product, as assigned by the product licensor, i.e. Windows 10. Equates to NTIA minimum element "Component Name" for the "Primary Component" in an SBOM.
Version
Version identifier for this product. Equates to NTIA minimum element "Version of Component" in the NTIA minimum elements.
SBOM
Link to the SBOM file associated with this product name and version provided by the Licensor of the product
SourceLocationURL
URL where this software product package is available for download by the consumer OR web API URL, for example: https://softwareassuranceguardian.com/SAGCTR_inquiry/getAPITrustScore
DigitallySigned
a Y or N flag indicating that the software product package is digitally signed, or not
UnsolvedVulnerabilities"
a Y or N flag indicating that the software product package has known unsolved vulnerabilities as of the LastModification date of this Product, shown below. MUST be"N" when a product is first released to market, indicating NO known vulnerabilities present.
KnownVulnInfoURL
The URL to a NIST Vulnerability Disclosure Report (VDR) showing the vulnerability status of each component in the product SBOM, an example NIST VDR is provided here
SDLCPolicyURL
URL to completed CISA Software Assurance Buyers Guide spreadsheet with vendor responses. This spreadsheet should be available as attestation evidence of the policy areas in which a software producer is able to satisfy/not satisfy CISA Secure by Design principles and expectations. The CISA Software Acquisition Guide is available here.
SDLCEvidenceDataURL
URL to completed CISA Attestation Form or a POA&M if no attestation for is provided.
CyberSecLabelURL
CommercialStatus
An enumerated set of options indicating the various states, see open-source VRF XML Schema for the list of valid options
SupportStatus
An enumerated set of options indicating the various support statuses for a product, see open-source VRF XML Schema for the list of valid options
LastModifiedDateTimeUTC
Date and Time in UTC representation when this product information was last updated.
CISA Software Acquisition Guide Spreadsheet
CISA has provided software consumers with the guidance needed to evaluate a software product based on Secure by Design principles. A comprehensive Software Acquistion Guide from CISA provides both consumers and software suppliers with recommendations to create and validate software products following Secure by Design principles. A companion spreadsheet is also provided, which software consumers should send to their software suppliers requesting that they complete, at a minimum, the top 19 Governance control questions and return this information to the requesting party. Software suppliers should include a link to a completed Software Acquisition Guide spreadsheet as part of their VRF materials in the SDLCPolicyURL data element (see above), in order to make this Secure by Design policy information available to other consumers.
CISA’s “self-attestation letter”
The final CISA approved Secure Software Development Attestation Form is now being requested by US Government agencies as part of new requirement to produce only secure software products, across the US Government
This article is being provided to help software vendors and others in the software supply chain prepare to respond to Federal Procurement Officer information requests for self-attestation pursuant to requirements M-22-18. Collections of these attestation forms began on June 8, 2024 with announcements from GSA, the State Department, NASA and other agencies that are required to implement OMB M-22-18 requriements.
My advice to software vendors is to begin preparing for M-22-18 compliance by creating your evidentiary materials which you may be required to submit, per product, i.e. SBOM (SBOM element), a vulnerability disclosure report (KnownVulnInfoURL element), CISA Secure by Design practices and policy documentation spreadsheet (SDLCPolicyURL element) , and the CISA self-attestation letter (SDLCEvidenceDataURL element), and create your digitally signed VRF XML file containing links to these artifacts. Use CISA Software Acquisition Guide to fill-in the Software Assurance Guide spreadsheet and prepare to deliver this to Federal Agencies by providing links to this information in your own Vendor Response File, using the open-source VRF format, if you desire. Place your completed Vendor Response File, it's digital signature file and other artifacts, i.e. SBOM, Vulnerability Disclosure Reports, CISA secure software attestation form and the CISA Software Acquisition Guide Spreadsheet in an access controlled location, such as a customer portal and provide Federal Procurement Officers with a link to the VRF file in this location. The VRF contains links to all of the other required artifacts so a vendor only needs to supply Federal Agencies with a link to the VRF, that lists all of the other evidence data, along with other required information. As of August 1, 2024 Federal procurement officers, i.e. GSA, the State Department, the Department of Energy and NASA, are now collecting these attestation forms and other artifacts, via the CISA RSAA portal.
Procurement Officers can automatically retrieve the VRF file, in JSON or XML format, and all of the other attestation files listed in the VRF using available commercial tools, i.e. SAG-PM
[UPDATE August 3, 2024: These recommendations have been updated to include CISA Secure by Design expectations from vendors to include references to CISA's Software Acquisition Guide, released August 1, 2024. SDLC policy items in this guidance material have been updated to use the CISA Common Form and CISA Software Acquisition Guide Spreadsheet - see recommendations below]
On May 14, 2024 the US Government GSA announced they will acquire and use only approved products. On June 8, 2024 the era of government "blind trust" in software objects ends and the era of "radical transparency" begins.
[UPDATE June 08, 2024: CISA is hosting a Software Supply Chain Conference on June 12 in McLean VA. "Secure by Design" and the CISA secure software attestation form are marquee topics. A complete agenda is now posted. Looking forward to seeing friends and colleagues on June 12. Safe travels.]
[UPDATE April 14, 2024: Proposed changes to the Vendor Response Form data structure to add a "DescriptionURL" within the Product section. This proposed change has been submitted to the IETF SCITT list for consideration, and is also shown below in redline My NASA presentation on 4/15/2024 showing how to submit secure software attestation forms and other artifacts, i.e. POA&M, SBOM, VDR and VRF to government agencies is now online]
[UPDATE March 18, 2024 CISA released the final Secure Software Development Attestation Form on March 11 with instructions for software producers to follow when submitting their self attestation forms. This article identifies the software artifacts that a software producer may be called upon to provide as part of US Government self attestation form processing requirements. This information is intended to help software producers prepare for June 8, 2024 when the government will begin to request self attestation forms from software producers. A guiding template of the open-source, free to use Vendor Response Form (VRF) described in this article is available online to help software producers prepare to respond to US Government requests for additional information. JSON and XML formats of the VRF template are available here Additional information is provided by the GSA that aligns with the advice provided in this article, regarding the information needed by government agencies to perform a proper C-SCRM risk assessment of software products]
[UPDATE July 17, 2023 Today, Reliable Energy Analytics gifted the open-source Vendor Response File (VRF) XML schema version 1.1.5 to the IETF Supply Chain Integrity, Transparency and Trust (SCITT) work group for further development and international adoption. A VRF lists the various attestation artifacts and other information that a software supplier may be asked to provide, such as a completed Attestation Form, an SBOM and SBOM Vulnerability Disclosure Report (VDR) to prospective customers, such as the US Government. A working sample of the VRF is available here]
[UPDATE July 23, 2023] The IETF Supply Chain Integrity, Transparency and Trust (SCITT) work group successfully demonstrated how an internationally defined "Trust Registry" standard can be used to exchange legitimate, trusted software supply chain information using a SCITT "Trust Registry". A SCITT Trust Registry works like a "Registry of Deeds", only legitimate, trusted information is permitted into a SCITT Trust Registry. Congratulations to the IETF SCITT work group for this important accomplishment.