Experts at a NIST-sponsored workshop weigh in on what might be in the final version of the Biden executive-order-mandated supply chain security guidelines. Credit: Andrey Suslov / Getty Images President Biden’s 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 “critical software,” published guidance on security measures for EO-critical software use, and released guidelines on vendors’ source-code testing. On November 8, NIST published preliminary guidelines for enhancing software supply chain security.NIST recently held a workshop to discuss the guidelines’ 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 “artifacts,” 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 “a core set of high-level secure software development practices that can be integrated into each SDLC [software development lifecycle] implementation.” This document aims to provide “something that’s flexible, customizable and selective” 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 “find and fix” 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’s Committee on Conformity Assessment (CASCO). Regarding software artifacts, Rohit Sethi, CEO of Security Compass, said that organizations should aim for artifacts to end the “find and fix” security mindset when it comes to vulnerabilities. Moreover, artifacts “need 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.”The 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.“If you think of the basics, it’s 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,” 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, “going from an artifact all the way back to the keyboard the code was written on and the machines the code was built on,” 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’s model serves two primary purposes: policy enforcement through the supply chain and collecting evidence of this enforcement throughout the pipeline.“Supply chain is a journey,” Samuelson said. “It’s not something that you do once and you’re 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.” Vulnerability 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. Moreover, pen testing and bug bounty programs are the least important part of vulnerability disclosure.“The 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,” Moussouris said. “Ideally, 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.”Treat 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’s ISO 29147 and 30111 to the federal government. These guidelines are slated to become final in June 2022“The federal government can be looked at basically as a large corporation. There are all kinds of business enterprises going on,” Schaffer said. “I would hazard a guess that the Department of Defense has all kinds of different reporting structures going on from the Department of Commerce.” Like 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. Related content news analysis P2Pinfect Redis worm targets IoT with version for MIPS devices New versions of the worm include some novel approaches to infecting routers and internet-of-things devices, according to a report by Cado Security. By Lucian Constantin Dec 04, 2023 5 mins Botnets Botnets Botnets news Hackers book profit by scamming Booking.com customers Malicious elements are using Vidar infostealer to gain access to Booking.com’s management portal and defraud customers. By Gagandeep Kaur Dec 04, 2023 4 mins Cyberattacks Cybercrime Security opinion Proactive, not reactive: the path to ensuring operational resilience in cybersecurity The experience of the financial sector in dealing with threats is instructive to anyone in the cybersecurity space — there’s no substitute for getting out ahead of potential risks and problems. By Cameron Dicker Dec 04, 2023 6 mins Financial Services Industry Financial Services Industry Financial Services Industry feature 4 budget-savvy strategies for building an effective purple team Building a purple team is not only for organizations with a generous budget. From the shoestring one-person operation harnessing open-source power to the well-oiled machine of a comprehensive team, organizations of all sizes have a pathway to heighte By Maril Vernon Dec 04, 2023 14 mins Threat and Vulnerability Management IT Training Risk Management Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe