A secure software supply chain represents another facet of Microsoft’s built-in security to enhance and maintain trust in our products. It’s a continuation of the journey we embarked upon since the launch of Security Development Lifecycle (SDL) in 2004 and represents our commitment to continually enhance Microsoft’s foundational security.

Understanding the Supply Chain Threat

A supply chain attack is usually characterized as “two (or more) separate attacks”. The first is an initial compromise in the hope of compromising a downstream consumer. An example of this would be compromising a popular open source component so that as developers around the world consume the latest version, they unknowingly ingest a malicious or backdoored package. These types of threats primarily target developers and the systems that developers use. Put simply, as seen with incidents such as Solorigate and 3CX, attackers have been shifting left earlier in the software development lifecycle.

We constructed a threat model of Microsoft’s engineering system – the Continuous Integration / Continuous Deployment (CI/CD) platform, identities, and all connected devices (such as Microsoft Dev Box and GitHub Codespaces) used by our developers. This enabled us to enumerate all the threats to the engineering system using real-world threat reports, and calculated risk scores for each. This helped us establish a list of requirements for securing the software supply chain that exceeds what was required by the U.S. Presidential Executive Order 14028. We then used the risk scores to determine which security investments to prioritize so we could systematically drive down risk.

Simplifying the Complex: How we model the space

The software supply chain is a vast, global landscape comprised of an interconnected web of software producers and consumers. This article focuses on a single aspect of an overall software supply chain: securing the production and consumption of software throughout the software development lifecycle (SDLC) to maintain the trust of our downstream consumers. This diagram represents how our security frameworks and our software development platforms come together.

Using the SDL to Secure our Software Supply Chain

The Microsoft SDL was originally focused on secure design and secure coding practices. Since its inception, the SDL requirements have evolved along with software development practices (such as Agile) and with changes in technology (Cloud, AI/ML). Most recently, and in alignment with the U.S. Presidential Executive Order 14028, Microsoft incorporated its Secure Supply Chain requirements into the SDL.

Microsoft’s implementation of the SDL has evolved as well, using enforcement mechanisms at various points in the Software Development Lifecycle (SDLC) to ensure that SDL tooling and security controls are enforced by policy throughout our engineering system. Such examples of enforcement include blocking a git push, breaking a build, or preventing a release. In essence, our security controls provide guardrails that keep our developers on the paved path.

Enforcement of security controls can often be at odds with developer productivity. Therefore, our supply chain security controls are designed with productivity in mind so that we reduce developer toil while reducing risk. Some examples include secure boot of our build agents, build system security monitoring, network isolation controls, ephemeral build agents, inventorying and updating build tools, and Software Bill of Material (SBOM) integrity validation at release.

How Microsoft uses the OpenSSF Secure Supply Chain Consumption Framework (S2C2F)

Microsoft has been implementing the S2C2F since 2019 and then published and contributed the S2C2F to the OpenSSF in 2022 so that any development team or organization can adopt. Microsoft continues leading and maintaining the framework within the Supply Chain Integrity working group in partnership with the OpenSSF community. The S2C2F is a consumption-focused framework, enabling it to pair well with any producer-focused frameworks such as Microsoft SDL, NIST Secure Software Development Framework (SSDF), OpenSSF Supply-chain Levels for Software Artifacts (SLSA), and others.

We first focused on establishing our ingestion channel using Azure Artifacts. Azure Artifacts helps store packages (which mitigates against package availability incidents such as left-pad), and has also implemented default settings that protect against dependency confusion. We’ve implemented improvements for updating known vulnerable components (part of S2C2F Maturity Level 2) using capabilities such as surfacing vulnerabilities as comments in a Pull Request (PR) – preventing the introduction of new dependencies with vulnerabilities, and automatic PRs to update vulnerable components. We’ve further implemented internal gates that check for typosquatting, malware, and other Indicators of Compromise (IOC) to protect us from OSS supply chain threats (part of S2C2F Maturity Level 3).  This approach enables our developers to have the freedom to choose the OSS component that’s right for their project without restricting them to some type of pre-approved list.

Securing the Upstream

Microsoft’s strategy to secure the supply chain doesn’t stop at our own internal controls that we’ve implemented. As a co-founding member of the OpenSSF, we continue to make investments into various OpenSSF initiatives to improve the security of the entire open source ecosystem for everyone. Microsoft co-leads and has provided $5 million in funding to the OpenSSF Alpha-Omega project, which has a mission to protect society by improving the security of open source software through direct maintainer engagement and expert analysis.

Through “Alpha”, we identify opportunities to fund security work within the 100 most critical open source projects. To date, we’ve provided over $3 million in grants to the Eclipse Foundation, the Python Software Foundation, the Rust Foundation, Node.js, jQuery, Prossimo, and OpenSSL. These funds are tailored to each engagement, and often take the form of hiring security staff to oversee and drive security improvements within the project. We receive monthly reports outlining progress and outcomes, which are available to the public.

Securing the Access Layer

Zero Trust goes beyond just identity, devices, and access, but it provides the principles that we use to secure our developers, such as phish-resistant Multi-Factor Authentication (MFA), conditional access policies, principle of least privilege, user access reviews, and Just in Time (JIT) permission controls for admin-level tasks. In addition, we are driving programs to eradicate Personal Access Tokens (PAT) bearer tokens and replace them with Managed Identities. According to the Microsoft Digital Defense Report (MDDR) 2022, 100% of initial access for ransomware attacks consisted of compromised credentials, and we saw an average of 30,000 MFA fatigue attacks per month, making these investments key to reducing our attack surface and preventing against initial compromise.

Monitoring the DevOps Platform

All of the above security programs we drive were focused on preventative controls, however, two other critical pillars of the Cybersecurity Framework are Detect and Respond. This involves using analytics to monitor for anomalous behavior such as tampering across source control, build environments, and release systems. These IOCs are immediately triaged for response actions. The quicker our response, the sooner we can evict bad actors from our environment.

Microsoft is forging a path to identify threat scenarios ahead of incidents occurring through the creation of a detection coverage matrix. The coverage matrix offers security response teams a granular view of the attack surfaces within an engineering system and integrates historic event data with a heat map of alerts. This novel approach to the MITRE ATT&CK Framework applies a defender mindset to what has often been a reactionary game of cat and mouse with offensive penetration testing.

Tying It All Together

Governments, organizations, and people around the world are all consumers of software to support their mission, business, and daily life – the importance of this cannot be understated. Microsoft continues this journey to further protect our engineering systems from compromise, to provide software transparency via

SBOMs, to enable our customers to secure their supply chains from code to cloud through products such as Microsoft Defender for Cloud, and continued investments and partnership with open source communities toward improving the security of open source for the benefit of everyone.