AI rules the day
Most of the conversation, news and excitement was certainly around Copilot X and what it will bring for developer productivity and security. While I’m thrilled at the capability, as a buyer of software or manager of subscription license management this only means likely an increase in cost for Copilot or maybe an add-on, though I doubt they’ll break it out. Will it remain user based or more of a usage model? Will developers have to watch how many lines of code they have it evaluate and correct for them due to costs? So far, they didn’t indicate a move in this direction but it always something to be mindful of. Actions can already be an abyss cost for IT Procurement, Sourcing, or whomever in your organization is concerned about cloud spend. Relying on developers to explain the costs to the approval chain is often already required and any sudden jump or increase in the current climate could be devastating. Depending on how deeply your organization utilizes GitHub, make sure you’re in tune with your organization owners, and anyone else controlling settings as well as your Microsoft/GitHub team to stay on top of licensing or pricing changes.
Self-Service Software Bill of Materials (SBOM)
It was hard to catch in the keynote, but for me the most exciting news was self-service SBOMs!
This was something I started complaining to GitHub about around 2019 when I was responsible for the initial deployment of GitHub for productive use at my organization, as well as open source management for our redistributed software. At the time, this was more a concern that I couldn’t really utilize dependency graph for exporting a list that I could work with and far from being able to capture the open source notices that I needed to collect for our thirdpartynotices.txt file. Not to mention, as with most code analysis tools, language support took a while and the focus is clearly always on security. My role had to focus on license compliance and approval tracking, so GitHub wasn’t offering me any help here, even dependency review was a new feature and only for private repos running Advanced Security or public repositories.
Was the announcement too soon?
There are still problems here that I don’t see GitHub calling out or commenting on in the announcement. As you’ll notice “NOASSERTION” dominates the reports. I decided to take a look at some of the repositories starting with the Microsoft SBOM tool itself and then drilling into its dependencies, many of which are commonly used.
When reviewing some of the results in further detail, clearly there is a need for more work on how this data is pulled.
Here this item shows “NOASSERTION” in all but the ID, Name and Version.
{“SPDXID”:”SPDXRef-npm-js-yaml”,”name”:”npm:js-yaml”,”versionInfo”:”^ 3.13.1″,”downloadLocation”:”NOASSERTION”,”filesAnalyzed”:false,”licenseConcluded”:”NOASSERTION”,”licenseDeclared”:”NOASSERTION”,”supplier”:”NOASSERTION”},
However, this package exists on NPM, and GitHub with the MIT license listed.
There is no Package verification code, checksum or homepage field. These are required to properly identify a package and part of the SPDX specification. I dug around nearly a dozen of the most popular repos, in many languages and none of them had the required data. Of the 27 SPDX specification fields I couldn’t find a repo with more than 8 fields, but who is responsible for that? With all this missing data can you even call these SBOMs at this point?
If you’re organization wants to have a highly automated process for reviewing third party packages and would like to incorporate this export into the process, when the response is “NOASSERTION” in both license fields, then automated approval would fail. Because this data is being pulled through this GitHub action process, correcting this manually would be required on the exported SBOM at every release.
How would you use this SBOM?
In the SBOM export current state, if someone working for a regulated industry receives this file, could they possibly accept the software? Perhaps with the use of other tools to process the results, but what tools? Security tools would likely have enough data to work with to pull CVE information even with this many missing fields. However, I’m not aware of any tools that could overcome the license information issue as most of the security tools have this same gap. Maybe that won’t be an issue, after all we’re mostly weighing risk, and security beats legal risk, right? Having not worked myself for a government organization, I can’t say if it would be any different but, the requirement is just to have an SBOM, not that it is accurate and complete, so I don’t see any purchases stopping over bad data.
Commercial software implications
What about the legal risks if the SBOM doesn’t capture third party code not properly disclosed by the developer and your organization is found to be illegally redistributing to your own customers? Can you sue over missing SBOM data? At this time, it’s hard to say how things will play out as many see this as a best effort situation given the amount of technical debt most organizations are facing approaching this requirement.
Wait and see
What is the value of an export without valid data, why isn’t the data here, and why don’t I see anyone asking? I’ve posted a discussion thread on GitHub and I’ll be interested to see if I get any response. https://github.com/orgs/community/discussions/52168
What else did we learn?
Galaxy was clearly an event to draw in Enterprise customers, and grow Advanced Security usage. Security and Collaboration enhancements should appeal to many organizations that already utilize GitHub and there was an interesting perspective from Tyler Miles, DevOps Product Owner, Liberty Mutual on moving all their repositories to GitHub. That seems ambitious for any organization that has been developing software for more than 10 years, considering the challenges of moving from one repository management system to another. In my experience most organizations will change code management systems every 5 years, even if they don’t want to, through acquisition or changing technology stacks this change just seems to happen. Often the decision isn’t to move but abandon old products in their old system, either continuing to spend money to keep the system updated and running or cutting off support to your customers and archive it away somewhere. I enjoyed seeing familiar faces that I knew at GitHub and some of the chatting was lively but overall I wasn’t knocked out by anything outside of the SBOM announcement. I didn’t feel that same jolt of excitement I got out of NVIDIA, check back soon for my post about GTC and this week’s Microsoft Build Conference. We can only hope GitHub Universe will be far more expansive than Galaxy was!
Leave a Reply