To be honest, at Microsoft we’re struggling with the same supply chain issues that everyone else is (including pharmaceuticals). Just today I was working on a slide deck explaining the overall problem and I framed it like this. <slides
below – hopefully they come through.>
I look forward to working with you, Steve, and our entire working group as we move forward and learn from each other.
From: Steve Springett
Sent: Tuesday, January 28, 2020 7:27 PM
To: Kay Williams
Subject: RE: Agenda - Weekly SBOM WG Meeting
Yes, that’s the one. ePedigree was a standard by EPCGlobal for tracking pharmaceuticals from their creation (raw materials), to the manufacturing, wholesaling/distribution, to the shelves of your local pharmacy. In a previous life, I led
a development team for a company that had a leading solution in this space.
IMO, the format was simple and flexible, but the use cases were extremely complex and costly for anyone in the supply chain to implement. My team spent 6 months just developing negative test cases (hundreds for the dozen or so positive
I can try to ping a few orgs that do this today. Is there anything specific I should be looking for? Thousands of orgs using OWASP Dependency-Track do this today. Some orgs have given talks or had training classes on the subject (BH I think).
So there may be some publicly accessible info (video or presentations). An SCA vendor supports these use cases as well. And some orgs are using GitHub actions for SBOM generation as well - but I don’t know how they handle policy evaluation in that scenario.
But I’m really interested in understanding how Microsoft approaches supply chain, SBOM, and the types of risk they care about in comparison to what others are doing. I’m certain there’s scenarios and use cases that most software companies
never have to face. I’ll patiently await any info the team at Microsoft is able to share.
On Jan 28, 2020, 8:05 PM -0600, Kay Williams <
Comments below. >>
Does Microsoft have any publicly accessible information that describes the objectives, testing methodology, and success metrics for the POC?
>> Not yet - we are still early in our POC thinking. We are planning to be as transparent as possible, however, and share our plans, progress and results with this forum.
I’m specifically interested in knowing more about the 2 BOM approach as that differs from other supply chain formats such as ePedigree. Some of the good ideas from ePedigree were
used as inspiration in the development of CycloneDX, possibly others.
>> I was not previously aware of ePedigree. Is this it?
I’m also be interested in knowing how the success metrics will be compared to what other organizations are achieving with policy-based SBOM build pipelines. Is Microsoft aiming
to achieve more than what’s currently possible or to simply validate the OMG format is capable of the use cases Microsoft has?
>> I am not aware of success metrics for other organizations with policy-based SBOM build pipelines. Is there information you can share? Are there other organizations we can bring
into this effort so that we can share learning?
Anyway, any info would be useful.
On Jan 28, 2020, 4:30 PM -0600, Kay Williams <
here is an agenda for our meeting tomorrow at 12:00 PM Pacific, copied below for convenience:
Agenda and Notes:
Anura Fernando, Underwriters Laboratories
Ken Modeste, Underwriters Laboratories
Sean Barnum, MITRE
Next OMG Spec Submission - February 24
Next OMG Technical Meeting March 24 & 25 - Reston VA
Registration information here
Agenda outline here
Understand scenarios across existing communities
Work together on model that encompases and extends
TODO: address scenario/structural compatibility concerns
SPDX - schedule meetings next week?
Continue working through GitHub Issues
CycloneDX - meeting scheduled on Friday at 4 Eastern
TODO: Address naming compatibility concerns
Sean investigating options (e.g. aliasing)
Target Feb 24
Monitor based on progress over the coming week
Microsoft POC scenario as follows:
Internal build system produces artifacts and SBOM 1
Internal security scanning system
receives SBOM 1
scans SBOM 1 artifacts
produces scan results
produces SBOM 2
Internal release system uses SBOM 2 to apply policy, verify and release SBOM 1 artifacts.