You sit down. You stare at your screen. The cursor blinks. So do you. Frustration sets in. Which tool can you use to understand all of the components in your software supply chain and generate a coherent, detailed Software Bill of Materials? The tooling landscape is vast and there’s a wide array of possible options (both open source and proprietary) available. But wait. There’s good news. ACT, the Automating Compliance Tooling project, is working on open source compliance software and key advancements for tools that increase their ease and adoption. And we’re proud to announce VMware’s open source engineer Rose Judge will be contributing significantly to this effort.
On December 12, 2019 The Linux Foundation announced founding member commitments from Google, Siemens and VMware among other companies to underwrite and lead collaborative work for ACT, a community formed to accelerate work on Tern and other projects, while increasing interoperability and usability of open source compliance tooling.
“I’ve been involved with ACT since its inception and was happy to volunteer for the Technical Advisory Committee Chair,” Rose says. “It’s an opportunity to take a leadership role on a larger scale and represent VMware and multiple companies on ACT’s behalf.”
The Constituents of ACT and Tern-ing the Tide
ACT is comprised of maintainers and developers associated with open source tools that make compliance easier. Tern, a project under the ACT umbrella for which Rose is a maintainer, finds license and package metadata in a container and furnishes a report. Maintainers fix bugs that haven’t been fixed by a developer and review code that hasn’t been reviewed. With large projects like the Linux kernel, there are often hundreds of code patches, which need to be maintained every week.
“Tooling is great,” Rose comments, “but it’s limited by whether or not it’s interoperable with other tools. If folks have to run Tern manually and parse the data into some other tool, then it’s inefficient. ACT brings these people together to collectively work on making changes in tools to automate the compliance and security process in the cloud native ecosystem. In our meetings, we talk about our tooling as well as the general state of cloud native compliance and security and how our tools can improve the overall ecosystem to secure the software supply chain. That is what ACT is all about.”
Tern uses Scancode, an open source project associated with ACT, that produces package metadata and license info at the file level, which enhances the software build materials that Tern can provide. Rose says, “Having that direct connection to other maintainers helps us plan our roadmap in accordance with what other tools are doing in the space.”
The SPDX Project and SBOM Specs
Software Package Data Exchange (SPDX) is an ACT project that aligns with the NTIA’s recent declaration for standards of an SBOM. SPDX is a file format used to document information on the software licenses under which a given piece of computer software is distributed. SPDX is managed by the SPDX Working Group, representing more than twenty different organizations, also under the auspices of the Linux Foundation. SPDX attempts to standardize the way in which organizations publish their metadata on software licenses and components in bills of material. One of the ACT projects Rose is working on with Kate Stewart and Gary O’Neall for SPDX is planning a DocFest on September 16, 2021, inspired by the PlugFest hosted by the NTIA on April 29, 2021.
“We’re asking people who own or use tools that produce SPDX documents to participate so we can compare the SBOM output from a variety of artifacts. The goal is to compare SPDX documents produced from various tools in order to agree on best practices for how to represent software from different build tools and data sources. We hope to address any ambiguities in the SPDX spec to make sure that these producer tools are all representing data in the same way, which will make SPDX more uniform. This makes it easier for SPDX consumers to anticipate how certain data is going to be represented and ultimately, makes compliance tooling more interoperable.”
NTIA’s Involvement
The National Telecommunications and Information Administration has outlined three SBOM specifications that align with the Biden Administrations recent Executive Order on Improving the Nation’s Cybersecurity and SPDX is one of them.
Rose expounds on the PlugFest, where the goal was for EtherNet/IP product vendors to test their product against a suite of interoperability tests with a number of other products and infrastructure vendors, and receive feedback regarding any possible interoperability problems before they are discovered in the field.
“At the NTIA Plugfest there were SBOM producers, like Tern, and SBOM consumers. Example targets were provided for the participating tools to work with and the results were compared and discussed. The event followed a “sweat equity” model, which meant that to participate participants had to have generated or consumed at least one SBOM. We discussed pain points and general ecosystem issues. Because the event was SBOM standard agnostic, it was hard to get consensus around specific changes required for SPDX specification—this is where the idea for the SPDX DocFest stemmed from and we hope to take discussions that we have there to the next NTIA Plugest to discuss with the broader SBOM community.”
Looking Ahead at the ACT Agenda: Legal and Security Compliance, SPDX 3.0
There’s a lot of overlap right now between supply chain compliance and security efforts. While compliance is generally focused on the licensing aspect of software and security tends to focus more on addressing threats or vulnerabilities, both efforts are interested in knowing what packages, sources or artifacts are present in a given supply chain.
“We’re having discussions about the intersection of compliance and security and how we can eliminate duplicate work being done for each effort,” Rose comments. “Supply chain attacks are on the rise so there’s a lot of news and attention around security but compliance is still important, especially when it comes to working with open source software.”
Another hot topic is SPDX 3.0 and its addition of a security profile. Historically, SPDX has been more focused on license compliance but due to the ever developing relationship between legal compliance and security, SPDX wants to make it easier to represent detailed security vulnerability information in their SBOMs as well. In a final note, Rose states:
“There’s a lot of discussion around NTIA and Biden’s executive order involving SBOMs and how we can make it easier for software users to meet that criteria. We’re always looking for projects that can further these efforts and what the requirements for acceptance to ACT should be.”
As the chair of ACT’s technical advisory committee, Rose flags action items they need to to influence change. As an example, ACT recently submitted feedback in regards to what the standards for a valid SBOM should look like to the NTIA’s Request for Comment. NTIA even incorporated some of the suggestions into their report. (Now, that’s incredibly fast results!)
ACT is Seeking New Members, Community Partners and Additional Tooling Projects
Software supply chain security and SBOMs—it’s all top of mind for developers, vendors, and users. ACT aims to make this complex, changing environment a bit easier to implement and contribute. To learn more about ACT and the tools, visit the Foundation’s site or contact [email protected]. In addition, the Tern project maintainers are always eager to onboard new contributors. Feel free to reach out here to become part of the Tern community.
