8 Software Metadata & Attestations

 

This chapter covers

  • Understanding what information goes into making Secure Software Supply Chain decisions
  • Navigating limitations and challenges of software metadata
  • Exploring examples of useful software metadata and how to understand them

In chapter 7, we introduced Software metadata and attestations as the 2nd layer of the framework for scaling Software Supply Chain Security. In the previous chapter, we covered the trust foundation layer, which set a base of our framework, in this chapter we will go through what goes into establishing good software metadata and attestations.

8.1 What is metadata for?

When we are making a decision on whether a piece of software should be run on our production servers, how do we come about that decision? We need to be able to reason about the risk of our software in the SDLC. For example, does the software I'm about to deploy contain a known vulnerability (e.g. log4shell), and will running that put my user data at risk? Has the software been verified and built by a trusted entity? In order to answer these questions, we need metadata about the software we use, both internal and ingested software (e.g. Open Source Software, 3rd party vendors), and across multiple facets of security (vulnerabilities, supply chain, code quality, etc.). To be able to make important security decisions, we need to have this metadata available and also ensure we can trust them through verifying their attestations.

8.2 Known Security Threats

8.2.1 Visualizing known threats in an organization

8.2.2 I know the issues, now what?

8.2.3 Supply Chain Compromise

8.2.4 Metadata information must be actionable

8.3 Unknown Security Threats

8.3.1 Visualizing unknown threats

8.3.2 Protecting the source

8.3.3 Protecting the build

8.3.4 Unknown threats are still threats

8.4 Attesting the metadata

8.4.1 Attesting software metadata

8.4.2 Caveats around attestation

8.5 Summary

8.6 References