Microsoft headquarters building
Image: gguy/Adobe Stock

Software development isn’t only about code; more importantly, it’s driven by a set of best practices and guidelines that help us write better and more secure software. Like all large software companies, Microsoft has developed its own set of policies and procedures to implement approaches like its Secure Software Development Lifecycle.

SEE: Google Workspace vs. Microsoft 365: A side-by-side analysis w/checklist (TechRepublic Premium)

One of the biggest problems facing software development today is the growing software supply chain, where closed and open source components come together to build familiar applications. But as recent problems have shown, it’s easy to accidentally include security issues in your code when a trusted component is compromised. Modern software relies on sources like Docker Hub, NuGet and npm, pulling in code that could come from large enterprise software teams or from one developer working in their limited spare time, scratching their own itch and sharing the resulting code with the rest of the world.

Jump to:

Securing the software supply chain

The modular nature of modern code makes it hard to track all those various components, especially when we’re looking at long and complex dependency chains. You only have to install a new package on a Linux machine to see the chain of dependencies that come with a simple piece of software. Those visible dependencies are only part of the story, as other libraries and components are compiled into the code you’re using, along with their own dependencies and so on down the chain.

It’s clear we need a set of best practices to manage growing software supply chains, especially when we may not know the complete provenance of the code we’re using. Tools like Software Bills Of Materials are important, but they’re only a tool that shows what we know about the software we’re using, not the entire supply chain. With malicious actors aiming to compromise software before it’s distributed to component repositories, you need to shift from trusting all the code you use to active skepticism, testing and retesting before it crosses into your trusted networks.

Microsoft’s move toward supply chain transparency

Industrywide, there’s been a lot more focus on SBOMs and the software supply chain since the White House issued its “Improving the Nation’s Cybersecurity” executive order. As part of its response to the US government’s policies, Microsoft has been opening its internal tooling to the outside world open sourcing tools like its Software Package Data Exchange-based SBOM tool. That’s now been followed by something that’s less tangible, but just as important: the Secure Supply Chain Consumption Framework, S2C2F.

Part of its internal processes since 2019, S2C2F began life as the Open Source Software-Supply Chain Framework, helping manage how Microsoft both consumed and contributed to open source projects. With many thousands of developers working with open source, it’s essential to have a way of managing those interactions to protect Microsoft’s many millions of users — as well as the many millions of customers and users of other products that depend on Microsoft’s written and maintained open source components.

What is SC2C2F and how is it used?

The aim of processes like S2C2F is to have a way of seeing how your organization interacts with open source, looking at possible areas of risk and providing a repeatable set of actions that can keep any threats to a minimum. What’s perhaps most interesting about S2C2F is that it’s coupled with a maturity model, helping you get the right level of compliance for your development process.

Eight practices to secure code

At the heart of S2C2F are eight different practices, which focus on specific interactions with open source code and on the threats associated with them:

  1. Ingest
  2. Inventory
  3. Update
  4. Enforce
  5. Audit
  6. Scan
  7. Rebuild
  8. Fix and upstream

Each is one point in the software development life cycle where you work with open source code, libraries or components, and where you need to consider threats and risks.

It would be easy to write a whole book on these practices, as they cover how you bring open source code into your software development processes, how you analyze and test it, and how you make sure it’s fit for purpose — passing on all the lessons you’ve learned to other potential users by becoming part of the community around code, submitting change requests and even becoming a project maintainer yourself, with all the responsibilities that entails. Once you’re using these practices in your software development lifecycle, you need to consider how mature your processes are.

Four levels of secure organizational maturity

There are four levels of maturity. Level 1 is how most organizations work with open source, keeping an inventory of what’s being used and scanning incoming software and libraries for vulnerabilities using off-the-shelf security tools. Level 1 requires you to make sure all dependencies are up to date and scanned using the same tools as the software you intended to use.

Level 2 speeds up the Level 1 processes so you’re patching risks quicker than any malicious actors and getting your fixes out before any zero days are in use.

Moving to Level 3 requires a lot more work, as you need to have proactive security tools in use and incoming software segregated from your development environment until it’s been tested and secured. The aim of this level is to ensure you don’t let compromised software into your network.

Much of the tooling required to reach Level 4 is rare or non-existent, as it requires working at scale to protect your code in real time. Most businesses should therefore aim for Level 3. Level 4 companies will rebuild all components on their own infrastructure after deep code scanning and check each component against their own SBOM before digitally signing the rebuilt code.

Open sourcing S2C2F

Microsoft recently announced that S2C2F had been adopted by the Open Source Security Foundation as part of the work of its Supply Chain Integrity Working Group. The intent is to use it as the basis of a process that’s able to build on the work of all OSSF members — not only Microsoft — with the process and practices being targeted at CISOs and security practitioners with a responsibility for software development.

It’s a work that’s still very much in progress, but one that’s going to be worth following. Part of the initial work of the OSSF is a paper that maps S2C2F to other open source supply chain management specifications, so if you’re already using your own or another process, you can start to bring the lessons Microsoft has learned into your own business.

With open source, we can benefit from the work of other companies and individuals, and that’s as much about how they do things as what they produce. SC2C2F may have been designed for Microsoft, but its principles are suitable for any software development process.