Those involved in the world of software development are used to continuous change, high expectations, and industry interruptions that require constant pivoting, but the last couple of years have challenged the most stalwart of professionals.
There was the pandemic beginning in 2020 that may have long-lasting impact. In 2021, we saw an increase in regulatory requirements around the use of open source software including one by the U.S. Federal Government on Cybersecurity and we ended the year with the Log4j vulnerability that left many organizations with months of resources focused on mitigation. All of this leads to increased regulations across the globe and the need for expanded collaboration across the software supply chain. There are four key trends for software suppliers and creators of software to be aware of.
SBOMs are Becoming More Mainstream
The need to produce a Software Bill of Materials (SBOM) is becoming more of a normal mode of operation. Prior to 2021, we had to explain to people what was meant by an SBOM, what they are, why they are important, what should be included in it, and so on. As we sit here today, awareness has grown tremendously for both software producers and software buyers. We are seeing a large uptick in external requests for SBOMs from direct customers as well as downstream partners. Typically, every organization at this point knows that there is a requirement for a Software Bill of Materials.
Having said that, there continues to be ongoing discussion around the best way to produce an SBOM and consume it given the variety of different formats that exist; and more importantly, if you have multiple SBOMs coming from your upstream software vendors, how do you pull them together and reconcile the software parts. The key question becomes how to consolidate them and create a viable report for complete transparency. The cybersecurity mandate by the U.S. government has had the effect of bolstering industry specific guidelines that have been around for many years. That mandate certainly wasn’t the first, but its breadth and depth has helped move forward the idea of regulatory maturity.
The Linux Foundation conducted an SBOM survey and found that in 2022 they expect close to 80 percent of organizations will in some way either produce and/or consume SBOMs. That’s a significant 66 percent increase from last year. This means that eight out of ten organizations will be creating SBOMs for their applications or ingesting them from their software vendors.
SBOMs Dominate the Conversation
With SBOMs dominating the conversation, where does that leave license compliance? Everyone is wrapped up in the SBOM frenzy and other license obligations are not getting discussed as much these days. Producing only an SBOM does not satisfy all of the license obligations. While it is a critical compliance artifact it does not necessarily address the attribution requirements required by most OSS licenses or the third-party source distributions requirement imposed in weak copyleft licenses. So, even though SBOMs are the talk of the town, we need to be mindful of other artifacts needed to satisfy obligations incurred by using OSS packages.
In some cases, especially if using SPDX, you can get a head start on third-party notices from your SBOM, but you still have to include the actual observed license text, not just the license name or the license template. This is typically a burdensome manual activity, and in some cases requires a significant amount of work. Very few SCA tools on the market are capable of automatically fulfilling the attribution requirement by generating third-party notices out of the box. Revenera’s Code Insight addressed this need, even in cases where the scanned codebase has stripped license texts or where there is no code available for scanning and all that has been provided is an SBOM document. For more information, check out this quick read.
The Evolving Role of the Developer
We are seeing the developer role continue to evolve. Some organizations consider developers their first line of defense for open source security and compliance management. After all, it’s the developer who selects components and modifies the code or manifest files that ultimately cause the components to enter the codebase. On the flip side, it’s also the developer who is the last to touch the code before applications are releases to users. If you exclude the developer from your process, you’re inevitably dealing with issues after the fact—after applications are released—which is much more difficult and much more expensive.
We are also seeing organizations struggle with who is ultimately responsible for open source and third-party component management. Do you burden your developers and take time away from their number one job, coding? Do you instead create a specialized centralized team of experts to deal with scanning analysis, and remediation planning; and in turn free up your developers to focus on their day job and only get pulled in to answer questions as needed? When we look across our customer base, we see both extremes as well as some hybrid deployments where there is a bit of both. Your team ultimately need to decide what works best for them and their larger organization.
Every organization is different with varying degrees of resources from people to budgets. There is no one right answer, but the advice is to approach your strategy to meet your needs with the flexibility to flex and shift as needed.
Past Trends Are Still Relevant
We continue to see codebases getting larger and more complicated with lots of mixing of technologies and interest around the entire deployment ecosystem, not just a single application. Additionally, attention on what container you’re running in, what’s the base container, and what are all the other packages that are out there? People aren’t just thinking about your product and the need it fulfills. They’re interested in how your product is deployed and what’s sitting next to it. Your product can be the most secure thing out there, but if you’re talking to an unsecure database, it doesn’t matter. The entire system needs to be secure and not just a single application.
Finally, we continue to see the need for on-premises code scanning. Many organizations are still uneasy about uploading their proprietary codebases to the Cloud for scanning and are requiring on-premises scanning; in some cases, completely air-gapped with no Internet access.
Check back here to get updates on how these trends are changing and any new developments that could impact your approach to managing the software supply chain.
