Getty Images
GitHub SBOM updates build automation foundation
A new CLI extension and other features due to ship this month lay the groundwork to help developers make better use of software supply chain data and mitigate vulnerabilities.
Developers who want to generate software bills of material data for their projects on GitHub gained a new open source command-line interface option this week, with more SBOM generation and export features due out this month.
SBOMs are used to generate and verify information about code provenance and relationships between application components to help companies determine whether they are susceptible to security vulnerabilities in the software supply chain. Many areas of SBOM technology, especially for cloud-native systems, are still evolving, but the term has received heightened attention during the past two years after it was mentioned in a presidential executive order as a requirement for federal agencies in software purchases.
The GitHub SBOM command-line interface (CLI) extension surfaced as an open source project this week, contributed to the GitHub Advanced Security repository by Zach Steindler, staff security engineer at GitHub. It will output SBOM data as a JSON file in Software Package Data Exchange (SPDX) or CycloneDX formats, both specification standards used to share SBOM information among asset management systems. Developers can also use GitHub Actions to generate an SBOM for their repositories, and the dependency submission API to upload an SBOM to GitHub's dependency graph to receive relevant Dependabot alerts.
Later this month, GitHub also plans to support exports of customers' overall dependency graph information -- as opposed to single projects -- as SBOM documents and add an API-based retrieval process for SBOM data, according to a company spokesperson in an email to TechTarget Editorial.
All these new features will make it easier for developers to use SBOM data in automated workflows, which is an important step for enterprises toward operationalizing SBOMs in a meaningful way, according to one industry analyst.
"A static SBOM in a build directory or a document storage system offers little benefit," said Katie Norton, an analyst at IDC. "The upload to the dependency graph and Dependabot capabilities are certainly a step in the right direction in terms of making SBOMs actionable."
The availability of a free and automatic way to generate SBOM data will hopefully mean more software producers offer them, said Reed Loden, vice president of security at secure access vendor Teleport.
"I'm excited to see GitHub supporting the notion that SBOMs should become the industry standard and be super easy to produce," Loden said. "I look forward to seeing all software manufacturers providing an SBOM with every release."
This is pretty cool: a brand new free @github tool for creating #SBOM data for your repos. Built on the dependency graph API—supports go, rust, npm, maven, and more. Both CDX and SPDX support!
— Allan Friedman @allanfriedman @infosec.exchange (@allanfriedman) March 9, 2023
I'd love to hear your thoughts.https://t.co/5SayxIWXZK
Experts: Vulnerability data another key SBOM ingredient
A logical next step for the GitHub SBOM roadmap includes marrying SBOM data with vulnerability scan information, said Dan Kennedy, an analyst at 451 Research, a division of S&P Global.
"The SPDX format helps in the general sense in supporting the different formats being used, but there are also tools that specifically take this format to map packages against possible vulnerabilities," Kennedy said. "The next step in the SBOM discussion, that some are working toward, is likely the ability to continuously assess SBOMs from third parties against both public but also more advanced intelligence sources."
That's where the Vulnerability Exploitability eXchange (VEX) also might come in. Users can scan VEX documents supplied as a companion to SBOMs to assess not only which vulnerabilities are present, but also which are exploitable and most critical.
"The fear of receiving 'false positives' keeps many software suppliers from distributing SBOM to their customers," Norton said. "GitHub may also want to add the ability to ingest VEX artifacts to lessen the noise of false positives."
GitHub didn't confirm whether VEX support is on the way but said, "we're excited about the momentum in the community around VEX," according to a company spokesperson.
GitHub plans CodeQL management update
The new SBOM features should ideally be accompanied by thorough documentation and training, said another GitHub user, who called for quality-of-life updates to other aspects of GitHub’s built-in security features.
For example, GitHub allows secrets scanning to detect whether sensitive information is contained within users’ code repositories, but so far it hasn’t been intuitive to set up alerts based on those scans, according to Kyler Middleton, senior principal software engineer at healthcare tech company Veradigm.
“It’s very useful to identify if any risky secrets are in source, but that data is provided on a GitHub page, and no emails are sent, no notifications are sent,” she said.
Users or teams with write access to application repositories can configure security scanning alerts via the security view on GitHub.com or the GitHub mobile app, according to GitHub documentation. Secrets scanning can be turned on for all public repositories by default; private repositories require a GitHub Advanced Security license to enable the feature.
Another item on Middleton’s GitHub security wish list is CodeQL management at the organizational level.
“CodeQL scans your code and provides a report of dependencies,” Middleton said. “The only way to turn it on is to click a button in each repo. We have 1,500 repos, [so] that would take literally days to enable.”
GitHub plans to change that in the coming months with a new bulk code scanning feature, a company spokesperson said.
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.
