At Microsoft we’ve long believed enhancing software supply chain security requires industry partnership and sharing of learnings and best practices across the entire ecosystem. We started on that journey nearly two decades ago when we developed the first version of our Security Development Lifecycle (SDL) and then released it publicly just a few years later. Today, we are sharing some of our more recent learnings and practices relevant to President Biden’s Executive Order (EO) 14028 and cybersecurity fact sheet, as well as our readiness to help agencies meet requirements implemented in March by the Office of Management and Budget (OMB).
For the past five years, we have brought new focus to our supply chain security journey and have spearheaded many Secure Supply Chain (SSC) initiatives, including deploying supply chain security controls to secure development pipelines for products deemed High Value Assets by the U.S. government. In 2018, we piloted our first version of Software Bill of Materials (SBOMs) to validate and build artifacts throughout the supply chain. Since 2019, we have been expanding our generation of SBOMs to additional product groups and collaborating in SBOM industry working groups and standards development efforts.
EO 14028 underlined the importance of a more secure supply chain, reinforcing the value of our past and ongoing work that enabled us to accelerate readiness and broader deployment. The investments we had already made in integrating SDL practices into our engineering processes and tooling, and mapping SDL to Version 1.0 of the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF), allowed us to pivot quickly to support the new requirements outlined in SSDF Version 1.1. Our efforts to pilot SBOM generation internally and contribute to SBOM standards development externally meant that we could quickly shift to a standards-based format and roll out a generator tool across our core engineering systems.
EO 14028 has been a catalyst to expedite current initiatives. Our focus now is to go beyond those requirements to help agency partners and others in the industry and software community by leading as well as sharing what we learn. As described in our recent submission to OMB, we also see opportunities to leverage the EO to foster deeper collaboration between agencies and software providers, to enhance information exchange and shared expectations, and build efficiency through the automated secure exchange of verifiable supply chain artifacts.
Enhancing supply chain transparency across more than 2,000 Microsoft services and the open-source community
Software Bill of Materials (SBOMs) for products and services was originally implemented to provide chain-of-custody management by enabling gated validation of build artifacts as they moved through the software supply chain. In October 2021 we moved from our initial proprietary format for SBOMs to utilize the standard SPDX 2.2 format, and now generate SBOMs for more than 2,000 Microsoft products and services, providing software transparency, integrity, and identity benefits to our operations and to our software consumers.
Next, we’re leveraging what we’ve learned to support others and drive the ecosystem forward. Later this year, we will share an open-source version of our SBOM generation tool. We also continue to invest in the development of next-generation SBOM standards, including SPDX 3.0, which will enable additional software transparency, identity, and integrity use cases.
Continuing to invest in secure software development,software testing, and engineering system operational security
Microsoft has been developing, implementing, and evolving the Security Development Lifecycle (SDL) for almost 20 years, addressing new paradigms such as cloud computing, open source, and AI/ML development. Many aspects of EO 14028’s SSDF requirements were already being met by our SDL engineering requirements, and we are ensuring alignment of SDL with NIST’s latest recommendations, including in the SSDF as well as NIST Special Publication (SP) 800-218.
We have also significantly invested in automating measurement of compliance with SDL requirements and processes, using telemetry from engineering systems and other security tooling. Our acquisition of CodeQL (a static analysis tool originally named Semmle) in 2019, considerably enhanced our ability to measure SDL compliance automatically with data from code analysis. We have also enhanced our compliance analytics platform to align with the requirements of EO 14028 and the SSDF.
Leveraging our Zero Trust strategy, we continue to raise the security bar for our engineering systems. We’re accomplishing this through key initiatives that drive to a healthy identity using un-phishable credentials, healthy devices accessing the build systems, and telemetry across the stack to identify risks and possible threats. Additional investments such as network isolation and code integrity enforcement in our build systems are also being made to mitigate against more sophisticated adversaries. Furthermore, we are also improving the security of our supply chain, through expanded OSS package scanning, to address emergent threat patterns.
Leading the industry in open collaboration
Developing new and trusted ways to enhance supply chain security practices and exchange supply chain evidence and artifacts requires public-private partnership and industry collaboration. Since 2007, we’ve invested as a founding member of SAFECode, and we’ve been active in industry- and government-led efforts to develop and evolve standards such as SPDX, NIST’s SSDF, and NIST SP 800-218, including through direct participation and feedback.
We also are developing industry standards for Supply Chain Integrity, Transparency and Trust (SCITT). By partnering with others in the IETF community, we are able to provide a more trusted way to exchange supply chain evidence and artifacts, including those required by the EO and resulting from future security requirements. We look forward to contributing what we’ve learned about SCITT and broader efforts as NIST kicks off its new public-private partnership to improve cybersecurity in supply chains. (Note that we previously referred to SCITT as SCIM, including in an EO 14028-related submission to NIST last year.)
We are also committed to strengthening the security of critical open-source projects. Along with Google, we recently contributed an initial investment of $5 million in the Open Source Security Foundation (OpenSSF) Alpha-Omega Project, which will improve the security posture of open source software through direct engagement of software security experts and security testing.
Helping government customers modernize their IT infrastructure
Microsoft’s ongoing security engineering investments mean we’re not only prepared to support federal customers in meeting requirements today but also able shift more rapidly and holistically in response to dynamic threats tomorrow. EO 14028 represents an opportunity to urgently improve our nation’s cybersecurity, and its success requires agencies, their partners, and the broader community to work together to achieve its objectives, both in the near term, and as we continue to respond to learnings going forward.
Helping to improve our nation’s cybersecurity extends beyond continuing to invest in our own engineering systems, providing secure software and services, and supporting the broader ecosystem. We are committed to helping U.S. federal government customers modernize their IT infrastructure. Last August, alongside a White House meeting, we set aside $150 million in technical services to ensure our readiness to support every federal customer that seeks to modernize their infrastructure. As part of this commitment, federal customers have the option to choose from two offerings, Get-To-Production and FastTrack, which are designed to support customers migration process.
We will continue to share our progress and learnings at Microsoft's Executive Order on Improving the Nation's Cybersecurity, which includes our previously published resources for agency efforts on EO Sections 3, 7, and 8, including a Zero Trust rapid modernization plan, Zero Trust Scenario Architectures, new capabilities in Azure AD, and guidance on our EDR and logging tools and capabilities.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.