President Biden\u2019s wide-ranging cybersecurity executive order (EO) issued in May aims to improve software security through a series of guidelines. As the EO directed, the National Institute of Standards and Technology (NIST) has produced a definition of what constitutes \u201ccritical software,\u201d published guidance on security measures for EO-critical software use, and released guidelines on vendors\u2019 source-code testing. On November 8, \u00a0NIST published preliminary guidelines for enhancing software supply chain security.NIST recently held a workshop to discuss the guidelines\u2019 provisions, which are due in final form by February 6, 2022. The EO asks NIST to produce its software supply chain security guidelines according to ten criteria, including secure software development environments; the generation of \u201cartifacts,\u201d which can contain a host of information about how the software was developed; the provenance or origin of software code and components; software bills of materials (SBOMs); vulnerability disclosure programs; and attestation to conformity with secure software development practices.The workshop gathered experts to share their insights on some of the components currently contemplated for the final supply chain security guidelines.Secure software development should be flexible and customizableNIST has updated a white paper regarding its Secure Software Development Framework in a new document, SP 800-218. This new document contains \u201ca core set of high-level secure software development practices that can be integrated into each SDLC [software development lifecycle] implementation.\u201dThis document aims to provide \u201csomething that\u2019s flexible, customizable and selective\u201d that can be used by anybody, Karen Scarfone of Scarfone Cybersecurity told the attendees. NIST designed SP 800-218 to give developers structure across four practice groups:Preparing the organizationProtecting the software from tampering and unauthorized accessProducing well-secured softwareResponding to vulnerabilitiesArtifacts should end the \u201cfind and fix\u201d security mindsetWarren Merkel, chief of standards services at NIST, walked through the attestation requirement of the EO, noting that attestations tell customers, the marketplace, or any interested organization whether specific software performance or conformity assessment requirements have been completed. Several standards are available for these conformity assessments from the International Organization for Standardization\u2019s Committee on Conformity Assessment (CASCO).Regarding software artifacts, Rohit Sethi, CEO of Security Compass, said that organizations should aim for artifacts to end the \u201cfind and fix\u201d security mindset when it comes to vulnerabilities. Moreover, artifacts \u201cneed to be understood by non-experts. We need non-security experts to look at something and be able to know whether or not there is adequate security coverage in the thing that they are buying.\u201dThe definition of artifacts varies widely, but Matt Fussa, trust strategy officer at Cisco, offered his version: Artifacts are evidence that demonstrates an organization is following a documented process or meeting a requirement. They should be gathered and archived throughout the system development lifecycle and used as evidence in internal or external audits and assessments.\u201cIf you think of the basics, it\u2019s about having the right process, policies, procedures and technology in place to create that secure build environment and then develop, for the purpose of delivering assurance, all the artifacts that can show a customer, any vendor or any the software developer is doing the right things to create that secure environment around the development process,\u201d Fussa said.A software supply chain is a journeyWhen it comes to code provenance, the goal is to provide cryptographically verifiable information for every step in the supply chain, \u201cgoing from an artifact all the way back to the keyboard the code was written on and the machines the code was built on,\u201d Dan Lorenc, co-founder, and CEO of Chainguard said.Kurt Samuelson, principal, group program manager at Microsoft, walked through the Supply Chain Integrity Model that Microsoft developed, which deals with provenance, SBOMs and attestations. Microsoft\u2019s model serves two primary purposes: policy enforcement through the supply chain and collecting evidence of this enforcement throughout the pipeline.\u201cSupply chain is a journey,\u201d Samuelson said. \u201cIt\u2019s not something that you do once and you\u2019re done. As we continue to find new supply chain vulnerabilities, we will add new capabilities. The build system for us is something that produces changes or manages the chain of custody for the official bits that get sent to a customer or get put into production.\u201dVulnerability disclosure starts with security engineeringKatie Moussouris, founder and CEO of Luta Security and the author of two vulnerability disclosure processes, ISO 29147 and 30111, explained that while penetration testing and bug bounties are terms that are often used interchangeably with vulnerability disclosure, all three practices are different.\u00a0 Moreover, pen testing and bug bounty programs are the least important part of vulnerability disclosure.\u201cThe bulk of software security processes should be in security engineering processes and where the bulk of all software security assurance processes should be in terms of resources,\u201d Moussouris said. \u201cIdeally, we are not trying to fix the same vulnerabilities in the same classes over and over again. Instead, you are incorporating every single vulnerability that you missed as part of your secure development lifecycle. Every vulnerability that comes through a vuln disclosure program is one that you missed in your earlier engineering efforts. Those are opportunities for learning and improving your software engineering security processes.\u201dTreat the federal government as a big corporation for vulnerability disclosureKim Schaffer, IT infosec specialist at NIST, recapped the recommendations from NIST for applying its initial draft of its vulnerability disclosure guidelines (SP 800-216) over to the federal government. NIST developed those guidelines following the enactment of the IoT Cybersecurity Improvement Act of 2020, which applies Moussouris\u2019s ISO 29147 and 30111 to the federal government. These guidelines are slated to become final in June 2022\u201cThe federal government can be looked at basically as a large corporation. There are all kinds of business enterprises going on,\u201d Schaffer said. \u201cI would hazard a guess that the Department of Defense has all kinds of different reporting structures going on from the Department of Commerce.\u201dLike any large corporation, the government still needs central reporting requirements. So NIST has identified two bodies that will be central for getting vulnerability reports, handling them, and giving feedback to the users as they need it. The first is the more centralized Federal Coordination Body (FCB). The second is the Vulnerability Disclosure Program Office (VPDO), more closely tied to the relevant service security office and agency.