My colleagues Art Manion, Eric Hatleback, Allen Householder, Laurie Tyzenhaus, and I had the opportunity to submit comments to the National Institute of Standards and Technology (NIST) in response to its Workshop and Call for Position Papers on Standards and Guidelines to Enhance Software Supply Chain Security. NIST is seeking positions related to executive order (EO) 14028, which was issued in May and aims to strengthen the country’s cybersecurity posture. It creates rather sweeping opportunities in policy, threat sharing, acquisition, operations, supply chain management, post-incident review, incident response, incident detection, vulnerability response, and vulnerability detection. In this specific workshop, NIST is seeking comment on its new authorities related to supply chain authority (all contained in section 4 of the EO.). Specifically, NIST requested positions in five areas:
criteria for designating “critical software”initial list of secure software development lifecycle standards, best practices, and other guidelines acceptable for the development of software for purchase by the federal governmentguidelines outlining security measures that shall be applied to the federal government’s use of critical softwareinitial minimum requirements for testing software source codeguidelines for software integrity chains and provenance
We submitted comments on each area. The comments are reproduced here.
1.Criteria for Designating Critical Software
Our comments on this area are in four parts.
1.1 Deployment Methods and Infrastructure
Federal systems are a combination of acquired software and services on diverse infrastructure including the following:
software acquired for deployment on government hardware (e.g., desktop operating systems)software acquired for deployment on service provider hardware (e.g., hosted servers)software used as part of a service purchased by the government (e.g., software-as-a-service)
Software security risks are posed by vulnerabilities rather than the method of deployment. Therefore, policy for designating critical software should be consistent regardless of deployment method. More concretely, minimize gaps between this policy effort and those applicable to FedRAMP systems.
1.2 Context is King
Software and its context of use are inseparable for the purposes of determining the “critical” designation. The designation should not be based
This article is purposely trimmed, please visit the source to read the full article.