SPECIAL NOTICE
99 -- Software Bills of Material (SBOMs) Request for Information
- Notice Date
- 11/9/2022 4:38:15 AM
- Notice Type
- Special Notice
- Contracting Office
- DEPT OF THE ARMY
- ZIP Code
- 00000
- Solicitation Number
- W15QKN-23-X-0RR0
- Response Due
- 11/22/2022 2:00:00 PM
- Point of Contact
- Thomas Cummings, Hadir Elba-Parsons
- E-Mail Address
-
thomas.a.cummings16.civ@army.mil, hadir.m.elba-parsons.civ@army.mil
(thomas.a.cummings16.civ@army.mil, hadir.m.elba-parsons.civ@army.mil)
- Description
- Request for Information Office of the Deputy Assistant Secretary of the Army 1. Description Purpose: The purpose of this RFI is to solicit industry feedback on approaches being developed for urgent action to address software supply chain issues.� This RFI focuses primarily on the acquisition, validation, ingest, and use of Software Bills of Material (SBOMs) and closely associated matters. The Army is run on software made with hundreds of thousands of different components brought together to achieve mission outcomes. Every mission, major system acquisition, and technology modernization effort is software intensive. Effective, security-focused software is critical to enabling future Army capabilities to dominate future conflicts. However, unknown components can cause systems to perform in unexpected ways and create exposure to attack when the components have vulnerabilities. Knowledge of the components and their provenance allows the Army to conduct risk assessment and to mitigate the risks. The Army must ensure the software underpinning every aspect of its mission is secure and resilient to adversarial interference, and must have the ability identify issues early and swiftly respond. The Office of Assistant Secretary of the Army for Acquisition, Logistics and Technology, ASA(ALT), is actively seeking feedback from traditional and non-traditional Commercial Partners to gather innovative ideas. The Army solicits industry inputs and ideas to improve software supply chain security through the collection and review of SBOMs and associated scanning and other supply chain risk management (SCRM) information, to ensure Army software is secure, and vulnerabilities can be addressed quickly through the course of the software lifecycle. The Army seeks your feedback on effective, streamlined, and innovative ways to better secure the supply-chain of software that ends up in Army systems, supporting Army systems, or storing Army data. This RFI focuses specifically on accomplishing acquisition, continuing ingest, and lifecycle risk management using SBOMs, associated validation and related artifacts. Procurement and acquisition policy play a large role in the supply chain, as do technical practices and systems engineering. The Army values your input on all aspects of software SCRM that enable the DoD to be a better partner, while also better securing the capabilities supporting the warfighter. 2. Background This RFI will contribute to the Army�s effort to address the policies and directives codified in Executive Order (EO) 14028 � Improving the Nation�s Cybersecurity, and OMB Memo 22-18. EO 14028 contributes to addressing System Security, System Mission, and Supply Chain risks aligned with the following policies: DoDI 5000.83, TECHNOLOGY AND PROGRAM PROTECTION TO MAINTAIN TECHNOLOGICAL ADVANTAGE DoDI 5200.44, Protection of Mission Critical Functions to Achieve Trusted Systems and Networks (TSN) Army Regulation 70-77 Research, Development and Acquisition Program Protection. Feedback gained through this RFI will be considered by the Department as it continues developing contracting guidance, technical policies, and shaping future software acquisitions. 3. Requested Feedback The Army seeks written feedback on potential contracting approaches for securing the software supply chain, tools and methods to analyze SBOMs to identify issues, and concepts, concerns, issues around the department�s implementation of SBOMs and incorporation with C-SCRM. Dependent on industry feedback to this RFI, the Army may follow-up with future engagement opportunities; to include question and answer sessions, one-on-one engagements, roundtables and/or requests for additional written information. The Army encourages respondents to share their innovative ideas on effective contract structures and changes in policy and licensing that could be used to: Select contract types that are best suited for secure software development and SBOM generation and submission Incentivize high-quality, timely, comprehensive SBOMs Enable software assurance risk evaluation and mitigation techniques of COTS software, GOTS software, company developed software, and subcontractor developed software. Ensure acquisitions incorporate requirements and accountability for secure software development practices Successfully reduce timelines to identify and mitigate risks and issues within the software supply chain 4. Response Guidelines Interested parties should respond to this RFI using the template found at Appendix 1 and focus on the best techniques and examples. To the greatest extent possible, please keep responses to under five (5) pages, single sided. Copies of particularly successful contracts and arrangements are also welcome to support responses and are not counted toward the page count.� Links to resources including videos or position papers are welcome.� We recommend excluding marketing material, instead focusing directly on responding to the priority issues above. Please include the following on response cover pages (cover pages are not included in the page count): Organizational Name, Address, and Country of Business (if organization has experienced name changes, please list all previous names used) Company representative and business title Industry NAICS Codes (North American Industry Classification System) and business size for each NAICS code Vehicles and contracts held (vehicle, agency, and expiration date) - please highlight Army and DoD contracts clearly Year company was established/founded Company ownership (public, private, joint venture).� Provide information regarding Foreign Ownership, Control, or Influence (FOCI) issues associated with your company/and or offering(s). Business Classification/Socio-Economic Status (e.g., large, small, 8(a), women-owned, hub-zone, Small Disadvantaged Business (SDB), Service-Disabled Veteran-owned) Location of corporate headquarters Locations of facilities Outside of Continental United States (OCONUS) Location where incorporated Overview of products and services provided Overview of experience in OCONUS with specific locations discussed Responses are not expected to be comprehensive � they should focus on key recommendations and best practices. Respondents are asked to generalize best practices and approaches for a wide Army audience. Responses are due by Thursday on 22 November 2022 to enable the Government to organize findings. Submissions should be made via email to: thomas.a.cummings16.civ@army.mil hadir.m.elba-parsons.civ@army.mil 5. Additional Discussions The Government may choose to reach out to select respondents for additional discussions as a result of this RFI. Such discussions would only be used to obtain additional information as part of market research. 6. Questions Questions regarding this RFI shall be submitted in writing by email to the contacts listed above. The Government does not guarantee that questions received after 10 November 2022 will be answered. 7. Disclaimer This RFI is issued solely for information and planning purposes. This RFI is not a solicitation and is not to be construed as a commitment by the Government to issue a solicitation or ultimately award a contract. Responses will not be considered as proposals, nor will any award be made as a result of this request. Federal Acquisition Regulation (FAR) clause 52.215-3, �Request for Information or Solicitation for Planning Purposes�, is incorporated by reference. The Government does not intend to reimburse respondents for any costs associated with the submissions of their responses to this RFI; respondents to this RFI are solely responsible for all expenses associated with responding. Proprietary information and trade secrets, if any, must be clearly marked on all materials. All information received in response to this RFI that is marked �Proprietary� will be handled accordingly. Please be advised that all submissions become Government property and will not be returned nor will receipt be confirmed. In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract. Responses from this RFI will be used to formatively shape broad Army guidance for acquiring software solutions. Response content may be aggregated and anonymously published into summary documentation to facilitate such guidance. Any publications resulting from this RFI will be non-attributional, and RFI respondents� consent for their responses to be used for such purposes. Appendix 1: Response Template Respondents should provide a response that addresses the questions below.� If any of the questions below are not applicable to your company, please specify that. 1. Software Bill of Materials Requirements Does your company currently generate Software Bill of Materials (SBOMs) for your software deliverables? Does your company log, track, and continuously monitor software development activities with processes and procedures that conform to the NIST Secure Software Development Framework (SSDF) guidance.� What format(s) does your company use for SBOMs? Does your company also produce human-readable documents as part of an SBOM? How do you incorporate SBOMs into other Bill of Materials programs (hardware, software, firmware)? What are the most efficient mechanisms for ensuring that software suppliers and government recipients/users (Army) remain mutually fully informed about software vulnerabilities? About currently applicable SBOMs? What type of logging and tracking capabilities or processes is your company using today, to keep track of all the pieces and parts of a software, that would be applicable or reportable to the Army? What type of continuous monitoring or continuous vetting of software does your company perform that does or would identify vulnerabilities to fielded / delivered / operational software that with new or evolving attack methods / exploitations? How do you ensure software assurance during sustainment? How is software assurance risk incorporated and managed in Program technical and schedule risks? What tools and methods has your company had success with the process of developing and using SBOMs? Specifically, are you using or are you aware of streamlined approaches to ingesting, storing, processing, updating, or generating reports from SBOMs? Bottom Line: What processes for continuous vetting of software / code have been successful in identifying new or emerging vulnerabilities? 2. Contract Recommendations In reviewing the sample contract language in the Appendix 2 to follow, what contract or legal challenges does your company see that may hinder your ability to produce comprehensive SBOMs and deliver quality software and software services to the Army? What gaps or oversights does your company see in the sample contracting language? Are there areas that are unaddressed or that would benefit from additional clarification? What other recommendations do you have for the Army to consider when contracting for secure software development solutions? These may be informed by successful contracting arrangements with commercial entities or other corporate best practices. Bottom Line: What type of contractual language would your company expect to see from a Request for Proposal that includes SBOMs as a major deliverable? 3. Examples of Success For examples of security-focused, or security-forward software development contracts (if applicable) please consider the following: What are the characteristics of previous successful software development contracts, including but not limited to: program background, Contract Line-Item Number (CLIN) structures, contract-types, metrics, and incentives? What type of security verification methodologies were employed (e.g., SBOMs, third-party verifications, etc), and how were they contracted for (e.g. contract types, services contracts, third-party evaluator services, etc) What novel approaches were used for evaluating and selecting vendors with secure software practices and procedures? What are some examples of criteria and/or scenarios used? What metrics, measures, documented processes and evidence were delivered to support claims of software assurance at the system, subsystem, component, libraries, and supporting services levels? What DoD or other federal government organizations are you working with on similar issues surrounding the software development & delivery process, and what specifically are they doing well? Bottom Line: What has worked for securing the software supply chain when contracting for software development services and ensuring software security throughout the lifecycle? 4. Barriers and Challenges What challenges have you encountered when contracting with the Army or DoD for secure software development services? What are the greatest barriers-to-entry for innovation in this space, and what recommendations do you have for overcoming challenges? What do you believe are the top areas of concern related to the software supply chain requirements? For companies that have not yet partnered with the DoD, what barriers and challenges do you see? What barriers or challenges do you see in the future, due to these new SBOM requirements? Are there downstream effects you believe will have unintended consequences? Are there steps that can be taken today, to mitigate concerns in the future? Bottom Line: What has not worked when contracting for secure software development services? 5. Innovations What innovative ideas and recommendations can you offer with regards to contracting for secure software development solutions? These may be informed by successful contracting arrangements with commercial entities or other corporate best practices. Bottom Line: What new concepts should the Army consider when contracting for secure software development? 6. Follow-on Engagements Would your company be interested in participating in follow-on market research to this RFI (e.g., Q&A sessions, one-on-one discussions, roundtables)? Appendix 2: Sample Contract Language Respondents should consider the following SAMPLE contract language when generating responses to this RFI: Topic 1 � Statement of Work, Scope Section If the scope of a contract / statement of work includes the delivery of software, software development, software engineering, software design, or anything similar, Agencies may include this sample language in the SOW. This language supplements the mission customer�s primary scope of the contract / SOW, to ensure creation, maintenance and delivery of software supply chain data is within scope of the contract. This work would be similar to, or even overlapping with that of an Information Systems Security Engineer or Officer (ISSE or ISSO). Sample Language: The Vendor shall execute Software Security reporting and tracking activities for the purposes of generating and delivering SBOMs to the Government for all code, components, and software-based services provided under this contract Includes firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software. Includes systems or services being operated by a contractor (or other organization) on behalf of ASA(ALT), even if off-premises or as part of a cloud or �as a service� offering. The Vendor shall track and report compliance of every component of software with NIST standards outlined in Standard Form XXX (published by CISA by March 14, 2023), and enter reporting data into Agency prescribed formats & databases before delivery (including before updates and patches) Topic 2 � Statement of Work, Reference Documents section In addition to the Mission Customer�s reference documents � Agencies may also add the documents listed here. Sample Language: - Executive Order 14028 � Improving the Nation�s Cybersecurity (May 12, 2021) - NIST Secure Software Development Framework (SSDF) � SP 800-218 - NIST Software Supply Chain Security Guidance - CISA Standard Form XXX (Due to be published on/before March 14, 2023) Topic 3 � Statement of Work, Requirements Section � Secure Software Development, SBOM Requirements To meet the requirements of M-22-18, this language will be recommended for all Army software contracts. Sample Language: The Contractor shall provide timely artifacts (in accordance with the contract CDRLs) that demonstrate conformance to NIST Guidelines for secure software development before delivery of any software or software-based services. Software Bills of Materials (SBOMs) shall be provided from the software producer / manufacturer. SBOMs shall be generated in one of the data formats defined in the National Telecommunications and Information Administration (NTIA) report �The Minimum Elements for a Software Bill of Materials (SBOM),�13 or successor guidance as published by the Cybersecurity and Infrastructure Security Agency (CISA). As of YYYYMMDD, Vendor must provide SBOMs in data formats that are compatible with Software Package Data eXchange (SPDX) version 2.3 or later; as well as CycloneDX version 1.4 or later;� SBOMs shall be scalable and expandable across organizational, programmatic, or contractual boundaries, to allow for integration with other SBOMs SBOMs shall be also submitted in a format that is human readable with common office software (Microsoft, Adobe, etc). ASA(ALT) will remain open to considering acceptance of artifacts in non-standard formats, given they contain all directly applicable data, are timely/current, and are already being produced for other Federal Agencies. Topic 4 � Statement of Work, Requirements Section � Secure Software Development, SBOM Update Requirements To meet the requirements of M-22-18, this language will be recommended for all Army software contracts. Sample Language: The Contractor shall provide a new or updated SBOM with each update and/or release of software that is delivered to ASA(ALT) � either directly or as a subordinate component of a larger system/software suite. SBOM updates may be required at any or all of the following trigger points: renewal of license; exercise of an option year; upon each delivery of the Software (including any applicable patch or hotfixes delivered to the ASA(ALT) any other timeline or trigger defined in CDRL or TO Topic 5 � Statement of Work, Requirements Section � Inventory & Reporting In addition to the core requirements / tasks outlined by the customer, the following language should be included in the requirements and/or tasks section of a SOW, SOO or PWS: Sample Language: The Contractor shall provide an inventory report of all software produced or delivered under the terms of this contract. The report shall be in the form of an SBOM, as outlined below, and delivered in accordance with the contract CDRLs. The Vendor shall ensure an up-to-date SBOM has been submitted to ASA(ALT) at the time of initial code delivery. Requirements for updating the initial SBOM are outlined in other SOW sections below.
- Web Link
-
SAM.gov Permalink
(https://sam.gov/opp/22a17c9e1501436dba2ac8762a51a859/view)
- Record
- SN06513508-F 20221111/221109230109 (samdaily.us)
- Source
-
SAM.gov Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's SAM Daily Index Page |