Another thing cybercriminals get is automation. Attacks are up and their rise is expected to continue, in no small part due to the fact that attackers are using automation to scale their criminal enterprises. With automated tools they can locate more victims faster, launch more attacks at once, and reach further along the supply chain than ever before. 

Well that’s just great. What’s to be done about it? The obvious answer is that software vendors must use defensive automation of their own.

The automation revolution in cyberattacks

Automation plays a significant role in the modern business of cyberattacks. Malicious actors use automation to their advantage to lower their costs, streamline their organizations, lend speed and scale to their attacks, and increase their chances of success. 

Here are just a few ways adversaries are using automation:

• Malware and botnets – The creation and management of botnets, networks of compromised computers which can be remotely controlled to perform various malicious activities including the distribution of malware, is largely done through automation.

• Phishing campaigns – Automated phishing kits are readily available for purchase on the dark web. These kits allow adversaries to easily create convincing phishing websites complete with fake login forms which can then be distributed, automatically of course, to a large number of potential victims.

• Credential stuffing attacks – Attackers use automated tools to test large lists of stolen or leaked username-password combinations against various websites and online services to gain unauthorized access. Let this be yet another reminder to not use the same passwords across multiple websites, systems, and services.

• Exploiting vulnerabilities – If you’re not scanning your code and infrastructure for security weaknesses, well you’ll never guess who is. Attackers employ vulnerability scanning tools to automatically identify security weaknesses in target systems, particularly outdated software and misconfigurations.

The race for automation in application security

Even with a generous budget for a large, well trained security team, manual testing cannot reach the scale, completeness, speed, or consistency of coverage that modern automated security tools can. Although manual testing certainly has its merits, it has many limitations that could have severe consequences for your organization.

And let’s face it, most security teams are overworked and understaffed. Here’s a formula that should help: automation plus a shift-left approach to application security equals shift smart. With the right tools, you can put some of the work of securing your code onto your developers and earlier into your software development lifecycle (SDLC) without slowing down releases.

Here are some automated application security testing tools you should be considering.

• Dependency updating tools – Chances are your software relies on a lot of open source components that are constantly releasing updates, many having to do with security. A good dependency health tool like Renovate enables automatic dependency updating by creating pull requests for your team to review and accept or reject. Free as both a GitHub app or self-hosted, Renovate also includes a Merge Confidence score to make decision making even faster and easier.

• Software composition analysis (SCA) – About those open source components… just because you have the latest version, doesn’t mean there aren’t still security concerns. SCA tools scan your open source code, including containers and other artifacts, and give you feedback on vulnerabilities. Advanced SCA tools (like Mend SCA) also give developers automatic alerts about vulnerable open source packages before a pull request is made and the component enters the system.

• Static application security testing (SAST) – For your bespoke code, SAST tools are used in both the coding and testing stages of the SDLC to analyze your code for coding errors and policy or regulation noncompliance that may indicate security concerns. We like Mend SAST, but we would – not just because we made it, but because it features automated remediation which writes the code to fix the security flaw for you.

Security everywhere all the time

Of course it’s not only automation that keeps attackers at bay. You also need to develop a good security culture in your organization that includes training and awareness programs, encourage responsible coding practices, and shift security left (and everywhere) so that it’s part of the fiber of your day to day activities.

But embracing automation in the SDLC with automated code review and continuous security testing must be on your menu if you want to have a robust and mature security program at your organization.

The bad guys are using automation to wreak havoc across the web. It’s time for the good guys to catch up and use automation to stop them.

But even if no one was asking you for an SBOM, knowing exactly which components are in your software is a major benefit to the security of your organization. When the next zero-day vulnerability hits, you won’t be scratching your head wondering where an affected package sits in your codebase, what applications it affects, or whether you even have that package in the first place. Sure, there’s more to staying secure and understanding your code than just generating an SBOM, and an SBOM is not the same as an inventory, but it’s a step in the direction of having clear visibility into your product.

Your customers deserve that clarity, too. Handing over an SBOM, especially in these still-early days of adoption, sends a strong signal that your organization is transparent, responsible, and secure, and it reassures customers and regulators that you are actively managing risks. Here is some advice on how to deliver that message.

Be secure

This one is basic but it has to be said. Simply handing over any SBOM isn’t going to communicate that your company has a serious and mature security program if you have major outstanding security debt. In fact, it will give your customers visibility right into your vulnerabilities, and if things are really bad they may, and rightly so, decide not to buy from you after all. So you need to actually be secure to show that you’re secure. There’s no way around it. Transparency is the whole point.

If you’re a little behind the curve here, the fastest way forward is to implement a software composition analysis (SCA) tool that will make a detailed map of all of your open-source components, give you a scored and prioritized list of your vulnerabilities so you can remediate quickly in a worst-first fashion, and automatically generate an SBOM for you. Again, there’s more to security than any one tool or process, but when it comes to managing vulnerabilities and SBOM generation, SCAs give you a lot of bang for your buck.

Be early

Take the carrot before you get hit with the stick. Get your company’s SBOM program going now, even if it’s not yet required, to show your organization is dedicated to security and compliance and get the kudos you deserve for strong leadership. You’ll spend a lot more money getting that infrastructure in place at the last minute, and you may lose money if customers go to a competitor who is already prepared to demonstrate their transparency.

Do it now, even if you’re not required to, because eventually you will be. And if SBOMs are already required for your industry, maybe you can’t be early but you can at least be on time. And you can go above and beyond by following our next piece of advice.

Don’t send an SBOM alone

By itself, an SBOM is unlikely to give a complete picture of your strengths or the true state of your vulnerabilities. When your customer scans your SBOM for vulnerabilities and licensing issues, they will probably get results that look bad on the surface but aren’t of any actual concern. They don’t know your software like you do, so it’s important that you include other materials that fill in the knowledge gaps. 

One such supplement is a list of your open source licenses, particularly dual licenses that you have purchased the commercial license for. Your customers won’t know that you have commercial rights to use open source licensed components unless you tell them.

Vulnerable doesn’t necessarily mean exploitable. Another document to include is what the NTIA calls a “companion artifact” to the SBOM, the Vulnerability Exploitability eXchange (VEX) file. Created exactly for this purpose, VEX allows you to provide context for the vulnerabilities in your software and communicate that you are aware of them and have investigated whether or not they are actually exploitable.

To sum it all up…

In this age of increasing digital complexity and heightened security concerns, the adoption of SBOMs is not just a trend but a necessity. True, governments and corporations have begun to demand SBOMs, but the advantages they offer extend beyond compliance requirements; they fundamentally enhance the security, transparency, and trustworthiness of your organization.

Moreover, embracing SBOMs sends a powerful message to your customers and signifies that your organization is committed to transparency, responsibility, and security. Being early in adopting SBOMs earns you recognition for strong leadership. Delaying may cost your organization more in the long run, both financially and reputationally.

But again, merely generating an SBOM is not enough; you have to back it up with genuine security. Transparency is meaningful only when it reveals a robust and mature security program. Address your security debt and take proactive measures to secure your software and the SBOM you send will sing your praises.

It’s not just about security; it’s about survival.

In this article, you will learn how to navigate the complex world of open source licenses, understanding their implications for software development, especially during mergers and acquisitions, to protect your business from legal and security risks.

This article is part of a series of articles about Open Source License Compliance

Types of open source licenses

Given the nature of open source, it’s unsurprising that licensing rules are also open. Anyone can create an open source license that suits them — that’s why there are so many out there. In general, however, open source licenses can be divided into two main categories: copyleft and permissive. Permissive licenses, like Apache 2.0, are typically referred to as “anything goes” because they place minimal to no restrictions on how others can use these components. Given the lack of restrictions, there is relatively little compliance risk with this category.

Copyleft licenses, such as the GNU General Public License (GPL) family of licenses, are a different story. This category of licenses gives other people the right to use, modify, and share the work, as long as the reciprocity of the obligation is maintained. In layman’s terms, if you’re using a component with this kind of license, you have to make your source code available for use by others.

Risk of copyleft licenses

We’ll use GPL as our example, but these same principles apply to other copyleft licenses.

GPL requires the release of components’ full source code along with the broad rights to modify and distribute that source code. When you build software using GPL license components, you have to release your work under a GPL-compatible license regardless of the percentage of GPL license code being used.

Nobody wants to do that, because anyone, including competitors, can learn how your software is structured and designed. Then they can modify your program, perhaps building out new high-demand functionality that supersedes your product. That’s a big risk.

How do we reduce this risk?

The GPL requirement to share source code applies to all derivative work. However, it doesn’t extend to programs that are separate and independent from the GPL license work. Unfortunately, there’s no clear legal definition of when proprietary software is separate and independent. Nevertheless, you can reduce your exposure by: 

• Using a dynamic rather than a static link between the GPL module and the custom software.
• Using separate names for the GPL and proprietary modules.
• Including separate copyright notices for GPL and proprietary modules.
• If it’s practical, price the software with and without the GPL module.
• Provide the GPL and proprietary modules to be downloaded separately.
• Provide them as separate executables and have separate documentation.

Creating a company policy for the use of components

Every company needs a clear policy regarding how or if certain open source license components can be used. Using GPL as our example, at a minimum, a policy should cover the following: 

• Will you permit any GPL components in products that get distributed?
• Can they only be used in the backend tools and not part of the distributed product?
• If these components are allowed in deliverables, which GPL versions will you prohibit? 

Licensing should be treated just like security where you manage by exception because it’s easier to have “block” lists instead of “allow” lists. Imagine trying to approve hundreds of thousands of components with over 200 different license types instead of just blocking a few unacceptable license types.

How to ensure license compliance with GPL components

Achieving license compliance with GPL components is essential to avoid legal pitfalls. Two primary steps are crucial:creating a compliant notice file and making all source code accessible. A notice file, often referred to as a header file, must be updated with each new release to accurately reflect the open source license terms. This typically includes a copyright notice, disclaimers, and the specific license text. By diligently following these steps, developers can maintain GPL compliance and protect their software projects.

Technical due diligence: Top tips

Due diligence is crucial for accurately valuing a company and determining potential risks. It’s often conducted during major corporate events like M&A, and IPOs.

It involves assessing a company’s technology-related aspects like its products, software, systems, and practices. Our focus here is on third-party software use. You need to keep a record of any third-party and open-source components that you use. Here’s how to prepare and avoid any unpleasant surprises:

• Prohibit people from downloading any software, without first reviewing its licenses.
• Know the intended use of the software.
• Categorize software by its license type, along with its permitted and prohibited uses.
• Document which version you’re using, including a link to the license text.
• Be aware of any license restrictions.
• Document if you have access to the proprietary program.
• Ensure the source code version is available for download for any GPL components..

Be prepared. Use an SBOM

The main lesson is to get your open source license policies and controls ready if you think M&A activity is imminent. Start by inventorying what components you’re using and their associated licenses and risks. Use tools like a software bill of materials (SBOM) to achieve this. It’s something that numerous governments are mandating. 

Learn More: Best Practices for Open Source Governance

Streamlining the process with SCA

This is overwhelming to do manually, but there’s an easier way, using software composition analysis (SCA).

During the due diligence process, you should produce a list of all your third-party software dependencies and relevant metadata. This should include the package names, authors, supplier inversions, declared hidden licenses, dependency paths, and whether the packages have been statically or dynamically linked to the product.  With the right SCA tool, you can do all this automatically in real time when a developer pushes code.

You could commission an external audit on your code base, but typically firms that do this use an SCA tool anyway. If you choose an external audit, ensure it flags any known open source vulnerabilities with contextual data like the CVE score. Ensure it identifies any copyleft license components and includes a license compatibility report.

Finally, a good audit should include an attribution report, containing all the licenses, the license text, the copyrights, and the notice files required for each open source component.

Developers are tasked with creating engaging and reliable applications faster than ever. To achieve this, they rely heavily on open source code to quickly add functionality to their proprietary software. With open source code making up an estimated 60-80% of proprietary applications’ code bases, managing it has become critical to reducing an organization’s security risk. 

Software Composition Analysis tools help manage open source use.

What is software composition analysis?

Software Composition Analysis (SCA) is a segment of the application security testing (AST) tool market that deals with managing open source component use. SCA tools perform automated scans of an application’s code base, including related artifacts such as containers and registries, to identify all open source components, their license compliance data, and any security vulnerabilities. In addition to providing visibility into open source use, some SCA tools also help fix open source vulnerabilities through prioritization and automated remediation.

Inventory

Software Composition Analysis tools typically start with a scan to generate an inventory report of all the open source components, (dependencies) in your products, including all direct and transitive dependencies. Having a detailed inventory of all your open source components is the foundation of managing your open source use. After all, you cannot secure or ensure compliance of a component you don’t know you’re using.

License compliance

Once all open source components have been identified, SCA tools provide information on each component. This includes details about a component’s open source license, attribution requirements, and whether that license is compatible with your organization’s policies.

Security vulnerabilities

One of the main functions of Software Composition Analysis tools is to identify open source components with known vulnerabilities. Good software composition analysis solutions will not only tell you what open source libraries have known vulnerabilities, but they will also tell you whether your code calls the affected library and suggest a fix when applicable. The solution should also identify open source libraries in your code base that need to be updated or patched.

Types of vulnerabilities that can be found using SCA

Open source vulnerabilities typically occur when there are flaws or weaknesses in the code. These may be unplanned coding errors or inconsistencies that have been deliberately inserted into the code. Attackers can then exploit them to gain unauthorized access to systems, steal data, or cause damage to the software or system. Vulnerabilities can also result from old software or versions of current software that hasn’t been updated. These can cause security vulnerabilities that attackers can use to infiltrate your code and exfiltrate sensitive and valuable data, which can be disabled and ransomed, for example.

SCA can also help identify licensing risks to ensure license compliance with any third-party code being used.

Advanced software composition analysis (SCA) features

Advanced SCA solutions also include automatic policy enforcement, which cross-references every open source component found in your code with organizational policies and triggers different responses, such as initiating an automated approval workflow or failing the build.

Advanced SCA solutions automate the entire process of open source selection, approval, and tracking. Some are even able to alert developers about vulnerabilities in a component before a pull request is made and the component enters the system. This saves developers precious time and increases their accuracy.

Limitations of software composition analysis (SCA)

SCA focuses on identifying and remediating risks in open source components and third-party dependencies. It is not designed to find vulnerabilities in custom (original) code. For example, the SolarWinds supply chain breach wasn’t something that could have been alleviated by SCA, because SolarWinds’s source code is proprietary. To scan and remediate proprietary code, use SAST (static application security testing). SCA also doesn’t detect insecure network configurations.

Older SCA solutions weren’t designed to scan development and deployment environments, so they cannot secure the later parts of your software development lifecycle (SDLC). And some older SCA tools don’t provide the context needed to accurately assess the risk impact of any issues. Without this context, these tools can generate too many false positives, which consumes limited resources as security teams end up making unnecessary fixes. Note: Newer, more modern SCA solutions have addressed this challenge with prioritization capabilities, so make sure to choose a solution that can do this (see “Prioritization and remediation,” below).

The evolution of software composition analysis

The first open source manual scanner was released around 2002. Despite greater visibility into organizations’ code bases, this early technology resulted in a high rate of false positives, which required manual intervention and did not meet the needs of agile development environments.

By 2011, the technology had improved was capable of automatically detecting vulnerabilities and licensing issues in real time. This enabled software and security teams to deploy open source management earlier in the development cycle. At the same time, SCA solutions were also being integrated with software development tools like repositories, build tools, package managers, and CI servers, which put the power of open source management and security in developers’ hands. Despite these advancements, SCA still heavily focused on detection.

The impact of emerging technologies on SCA

More and more source code, components, and dependencies are being used to create new software and applications. It is widely estimated that as much as 90 percent of some organizations’ source code is now open source, which means that the potential attack surface has expanded considerably and continues to do so.  This increases the risk of open source vulnerabilities and the threat of malicious packages infiltrating and attacking software and applications.  So, the need for SCA increases in importance.

The future of SCA in software development

Developers, DevOps, and DevSecOps teams are now being tasked with scanning, identifying, and remediating vulnerabilities in open source far earlier in the SDLC. They are shifting security left to address and fix issues sooner rather than waiting until the software is ready for production or shipping. There is an even newer trend in the development process, known as “shifting smart”, which encourages teams to adopt nimble scanning and remediation processes that quickly and easily fix code wherever it is in the SDLC, and do so within existing developer workflows. Modern SCA solutions can do this, as well as prioritize vulnerabilities and identify those that can be safely ignored. This puts modern SCA at the heart of any robust application security strategy.

Detection is not enough

As open source use continues to proliferate, the number of known open source vulnerabilities has also increased. When you take into account the volume of alerts developers and security professionals deal with daily, it all starts to become noise.

Focusing solely on detection is only the first step. It does not help organizations reduce their risk. Detection without remedy is an incomplete application security model.

So how do you forge ahead? To address today’s threat landscape, you don’t need to strive for perfection, but you do need to keep moving forward. To do so, organizations must adopt a mature SCA security model that includes prioritization and remediation on top of detection so developers and security professionals can focus on what really matters.

Prioritization and remediation

Modern SCA solutions now bridge the gap between detection and remediation.

Prioritization. A mature software composition analysis tool should include technologies that prioritize open source vulnerabilities. By automatically identifying the security vulnerabilities that present the biggest risk, organizations can address these priorities first. Developers and security professionals don’t waste their time and resources sifting through pages of alerts trying to determine what vulnerabilities are the most important, possibly leaving highly exploitable vulnerabilities running in a production system.

Remediation. After prioritization comes remediation. Remediating vulnerabilities automatically goes beyond just showing developers where the vulnerability is located to suggesting a fix and providing data on how likely the fix will impact a build. Automated remediation workflows can be initiated based on security vulnerability policies triggered by vulnerability detection, vulnerability severity, CVSS score, or when an updated version is released. One of the most reliable risk mitigation strategies is to keep your open source components continuously patched to avoid being exposed to known vulnerabilities. A good SCA solution helps you achieve this.

Advanced SCA tools – including repo, browser, and IDE integrations – seamlessly integrate into the software development life cycle (SDLC) to resolve vulnerabilities early when they are easier and cheaper to fix.

Software composition analysis requirements

Comprehensive database

The database is the heart of any SCA solution. The more comprehensive the database, aggregating data from multiple sources, the better it is at identifying open source components and security vulnerabilities. Without a comprehensive, continuously updated database, you would be unable to detect the right versions of open source components to update licenses, remediate security vulnerabilities, and apply updates and patches. The open source community is highly decentralized. Because there is no one centralized source of information on updates or patches, you rely on the database for everything.

Broad language support

An SCA solution should support not only the languages you are currently using but any language you might be considering using within the next year or two. You wouldn’t want to implement an SCA solution only to find it doesn’t support the language of your newest project a year from now. Plan ahead and choose a solution with broad language support.

Extensive reporting

From inventory, licensing, attribution, and due diligence reports to vulnerabilities and high-severity bug reports, you need a solution that offers a wide range of reporting tools tailored to every use case, including management, legal, security, DevOps and DevSecOps.

Robust policies

Choose a solution with automated policies that are robust yet highly flexible and customizable so you can define your organization’s own unique needs. Policies that automate the process of open source selection, approval, tracking, and remediation save developers time and greatly increase their accuracy. 

Vulnerability prioritization and remediation

As discussed earlier, you need a solution that prioritizes security vulnerabilities and offers remediation advice. The more you automate, the easier it will be to resolve the most critical issues first without slowing down development. 

Dual governance and developer focus

SCA solutions fall into two broad categories.

Governance solutions, used by management, security, DevOps, and legal teams, provide full visibility and control across an organization’s software portfolio. 

Developer tools help developers avoid vulnerable open source components before a pull is made and fix any vulnerabilities detected in their code via tools integrated with native development environments.

The best SCA solutions offer both governance and developer tools. This guarantees that everyone gets the tools they need, when and where they need them.

Integration with DevOps pipeline

Choose an SCA solution that integrates seamlessly with a wide range of developer environments at every stage of the SDLC – repositories, build tools, package managers, and CI servers – so developers can decide whether they can or should use an open source component before a pull request is made.

Containers/Kubernetes

Container and Kubernetes use is widespread, yet security remains a challenge. Select an SCA solution that scans open source components from inside your containerized environments, identifying vulnerabilities or compliance issues and automatically enforcing policies. Also, make sure the solution has native support for your specific container registry.

Why SCA should be part of your application security portfolio

Open source components have become the main building block in software applications across all verticals. Yet despite the heavy reliance on open source, too many organizations are lax about ensuring that their open source components meet basic security standards and are compliant with licensing requirements.

Securing your application in today’s complex digital world is a challenge. With the right Software Composition Analysis solution, you are one step closer to mitigating your open source risk.

Overview of regulatory compliance requirements

Regulatory compliance is growing in importance as organizations working on M&A activity or with government bodies are frequently required to demonstrate that their software is secure and legally compliant with license conditions.

Governments are now taking a more active role in this arena by introducing new cybersecurity strategies that companies must follow.

Having issued an Executive Order on improving the nation’s cybersecurity, and having passed the Strengthening American Cybersecurity Act, the U.S. Government announced the release of its national cybersecurity strategy in 2023. Similarly, the European Union announced its Digital Operational Resilience Act (DORA) and its Cyber Resilience Act (CRA) to enforce software security and secure delivery of services.

The Australian government has stated its aim to make Australia the most cyber-secure nation in the world by 2030. And in concert with these developments, agencies from Australia, Canada, Germany, The Netherlands, New Zealand, the United Kingdom, and the United States have together created a guide for software development organizations to ensure their products are both secure by design and by default.

These recommendations and strategies require more accountability from vendors, increased visibility into their code bases, software, application components, and dependencies, and tougher regulatory compliance. 

How SCA can help with compliance

SCA is focused on scanning, detecting, and remediating vulnerabilities in open source, which can include identifying and fixing components and dependencies that do not meet license requirements. By finding such issues and versions that comply with license conditions, SCA can help ensure that your code base is up-to-date and fully compliant.

Case studies of SCA in compliance

Educational technology company Learning Pool sought a further round of VC investment and its preferred investor was particularly concerned about the company’s use of open source software. They wanted assurances that Learning Pool had policies written and a process in place to safeguard its codebase from legal challenges. Learning Pool uses Mend SCA to scan code and identify if any components aren’t compliant. Compliant code is automatically built and deployed. Mend SCA alerts Learning Pool to non-compliant code and blocks it. Everything is done speedily and automatically.

Workvision uses open source software to improve quality and speed in development and to reduce costs. It needs to ensure that this software is used in compliance with the relevant licenses. Before using Mend SCA, the company found it difficult to carry out regular audits of its open source use and often completed these audits in the final stages of development, which led to delay development. Mend SCA has accelerated the process of identifying and fixing any compliance issues, Prior to using Mend SCA, completing an open source audit took about a week to complete. Now it can take as little as 15 minutes.

The Fintech Open Source Foundation (FINOS) accelerates collaboration and innovation in financial services through the adoption of open source software, standards, and best practices. FINOS invested heavily in building its Open Developer Platform (ODP), but FINOS’s members needed to be confident their open source components had no known vulnerabilities and were compliant with license policies. Mend SCA manages the open source licenses and security vulnerabilities in FINOS’s open source projects. With Mend SCA, FINOS can create policies around license compliance, security vulnerabilities, and quality issues that are automatically enforced. This ensures that all committed code meets FINOS’s high standards of code quality, without impeding the speed of the development process.

These are just three of many examples of how SCA can improve and accelerate license compliance.

Benefits of software composition analysis

• Improved security. SCA’s specific purpose is to scan your open source software, components, and dependencies, identify vulnerabilities, and with a modern SCA tool, automatically remediate these vulnerabilities. When using these capabilities to their fullest, SCA will certainly improve your application security.

• Cost savings. Identifying and remediating open source vulnerabilities requires considerable resources when done manually, and missing vulnerabilities can adversely affect the speed of development and innovation. This is costly. SCA accelerates and automates the process, lightening the load for developers and DevOps teams and making security cheaper to implement and more thorough.

• Enhanced efficiency. Modern SCA tools are specifically built to accelerate and automate the detection and remediation process. So, they make the process easier and faster. Plus, their ability to prioritize vulnerabilities to be addressed means that false positive results are significantly reduced, and teams spend far less time fixing issues that aren’t relevant.

• Improved developer productivity. Speed, efficiency, and automation liberate developers from the time-consuming task of scanning and securing open source. They can now do it more efficiently than ever, and the process is seamless when it is done within their development workflow, thereby minimizing any interruption to their innovation pipeline. With SCA, developers can be sure that the security of their code base is robust while enabling them to maintain and increase their productivity.

FAQs

Scaling Software Supply Chain Source Security in Large Enterprises

Rao Lakkakula, senior director of security engineering at JPMorgan Chase, gave a great overview of the extreme complexity involved in securing the software supply chain from the perspective of a large enterprise. The bottom line: while nobody can predict what’s going to happen, companies that proactively plan are better able to respond effectively to critical events. He outlined the following process: 

Understand the software process

Identify entry points into the enterprise where software is ingested, such as open source, purchased software, and third-party developed software.

Look out for shadow application development. It’s a pretty sure bet that people are using stuff you don’t know about.

Monitor integration processes

Validate the security of providers and dependencies of OSS and closed-source components. Use high-quality, valid versions of components from fewer reliable sources.

Why is this important? It’s not that easy to delete vulnerable software once it’s in the system. You risk breaking things if code is deleted or updated. The more you do at ingestion to minimize damage, the better off you are. 

Build comprehensive software bills of material (SBOMs). You need to have a realistic way for finding the next log4j, so build an asset inventory of both vendor software and OSS code, and where they deploy to. Also pay it forward by generating SBOMs for everything you ship to others.

Lakkakula gave a great analogy illustrating the complexity of SBOMs in the enterprise. He started with comparing an SBOM to a Dairy Milk candy bar list of ingredients. But SBOMs in the enterprise are more like a giant candy store that sells a ton of candy from all over the world, some of which is no longer in production. Enterprises are similar: they can bring in OSS software from all over the world, they don’t always know who wrote it, and some is probably no longer maintained.

Secure the internal CI/CD pipeline

Building a secure internal developer infrastructure starts by thinking of security integrity, build integrity, deployment integrity, and so on. This means that any components, dependencies and data are consistent, accurate, trustworthy, and protected from unauthorized modification. 

Automate vulnerability monitoring

Continuously monitor for new vulnerabilities to patch deployed software. Leverage the asset map and SBOM. Build and enforce policies based on your risk appetite.

Get involved

AppSec is a relatively new field and it’s a problem that’s complex enough that no one single company can do it alone. Government sector agencies and groups like OpenSSF, FS-ISAC, SLSA, and NIST often have working groups that are open to the public, so that’s a good place to start.

Telling Fairy Tales to the Board: Turn Attack Graphs into Business Stories

Andy Ellis and Oren Sade of Orca Security gave entertaining advice on how to translate an attack path that security understands into a business story that the board can understand. Key points:

• Drop all the technology phrases. “We have to assume that executives don’t understand these phrases. When they try to build a mental model based on keywords, those are the wrong words for them,” Ellis said.
• Focus. It’s very important to use the smallest argument to spur action.
• If there is a human responsible, don’t throw them under the bus. “Human error is an error in a system in need of redesign,” noted Ellis.
• Management needs to see the line from hazard to fix. If there are two things you have to do, you need to match a fix for each hazard.

Running in the Shadow: Perspectives on Securing the Software Supply Chain

Did you hear the one about a developer, a CISO, and a policymaker who walked into a conference session? This panel discussion featured three different — and important — perspectives on building a secure supply chain. Moderator Jessica Hardcastle of The Register led the panel, which included James Higgins, CISO, Snap, Inc.; Dan Lorenc, CEO and co-founder, Chainguard; and Camille Stewart Gloster, White House Office of the National Cyber Director. Key quotes:

Higgins: “From a CISO standpoint, the issue is easy to identify, just impossible to implement. If you can understand the landscape and where the code is coming from, you’ve solved 80% of the problem.”

Higgins: “Inventory is the most critical thing you can possibly do. What is your code? Where is it stored, and where is it coming from. If you can solve for that, you can solve the rest rather easily. It doesn’t mean I’m protected from something like Log4j, but I can tell the board we know where everything is, and it’s not a problem.”

Lorenc: “This is a developer problem. It’s a code quality and process problem. We have to change the way developers build software.”

Lorenc: “Open source is really complicated. When they grab a piece of code and run npm install it’s the equivalent of picking up a thumb drive in a parking lot and plugging it into your laptop. Nobody wants to talk about this but it is really scary.”

Stewart Gloster: “In open source software, the government should not lead, but we can be supportive: We can get our own house in order. We can invest in cleaning up code. And we could make sure that there is funding for supporting open source software investments.”

The Psychology of DevSecOps

Jennifer Czaplewski, senior director at Target and Kathryn Pimblett, senior cyber manager at A.P. Moller Maersk presented two different psychological approaches to building successful AppSec programs.

The DevSecOp team at AP Moller Maersk uses a three-pronged approach based on the theory of planned behavior to challenge the belief that AppSec is a blocker to efficient application delivery and to increase developer buy-in and collaboration.

The key: Reduce pain for developers and make it fun. “We really leveraged gamification for AppSec training,” Pimblett said. “As it stands, we have almost a third of developers actively engaging in the platform—and it’s all voluntary.”

At Target, DevSecOps uses organizational psychology — how people behave in the workplace — to build a security-minded developer culture. The main tool lies in using psychological contracts to establish standard product security values.

The three contracts: Meet developers where they work, offer end-to-end solutions, and the right way = the easiest way. “Whenever possible, we integrate right into the tools they are using so they don’t have to be interrupted,” Czaplewski said. 

The National Cyber Strategy as a Roadmap for a Secure Cyber Future

This panel of public-sector cyber strategists discussed two fundamental shifts outlined in the National Cybersecurity Strategy: rebalancing the cyberspace defense responsibility onto those most capable of bearing it, and realigning incentives to favor long-term investments over temporary fixes. One key question arose: How can organizations better support open-source software developers and infrastructure? Here’s what the panelists had to say:

Eric Goldstein, executive assistant director, Cybersecurity and Infrastructure Security Agency

“One piece is that we need a model of shared responsibility across the breadth of the OSS ecosystem. We need to make sure that the developers creating and maintaining libraries and packages have the support, resources, and information they need for that project to remain fit for purpose.

We need to know how to prioritize the libraries and packages that are heavily used in critical uses and establish a baseline for good security so it can raise the bar across the world. Because we know that there are many vulnerabilities out there. Example: A shockingly high percentage of Log4j still being downloaded are malicious.

We want to think more about what a package manager can do to create friction and speed bumps to filter and block malicious packages.“

Robert Knake, acting principal deputy national cyber director, Office of the National Cyber Director

“One of the issues is how we are talking about software liability. We want to shift responsibility in bad outcomes from end users to companies that develop that software.

But when it comes to an OSS development strategy, we don’t want to place that responsibility on open-source communities. It does no good if you hold responsible individuals doing this for free on a part-time basis. The question is, how do we create a situation where commercial software developers make better choices about what OSS to use?”

Liesyl Franz, deputy assistant secretary for international cyberspace security, Acting, US Dept of State | Cyberspace and Digital Policy Bureau 

“We can be a coalition builder for various aspects to the extent that we can help carry the message and demonstrate the activities and expertise of team CISA. “

Bryan Vorndran, assistant director at the FBI, noted that the agency is not involved in areas of regulatory action. But he did point out the value of early training on cybersecurity best practices. “We currently have no academic standards for best practices in this area across the US academic institutions. We need to up this farther upstream. “

More and more companies are using more and more open source. The stats I’ve seen say seventy to seventy-five percent of all applications use open source or have some type of open source associated with them. I think that number is actually higher. Of all the companies that I’ve worked for, just about every single application has some type of open source associated with it. And the more you use, the more this multiplies because each piece of open source has components and these components have dependencies.

The proliferation gathers pace as it progresses. For instance, you may take two or three open source libraries and apply them to your application. But underneath the covers, you may have multiple open source libraries associated with them. If you’re doing something like a simple file upload, you may only have one or two sub-dependencies, but if you’re doing something more complex, such as with languages like Angular, you could easily have thirty or forty, and the thing that you have to contend with is not only whether your direct dependencies are using indirect dependencies, but whether there could be indirect dependencies in other tools. So, it could grow to hundreds in certain circumstances.

Plus, when you’re looking for an open source library to plug into your application, it’s not necessarily clear what all the licensing models are that are associated with it. A library might follow the MIT model, and you think you’re safe, but a transitive dependency could be hidden beneath the surface that’s A GPL, which has a different set of challenges that need to be managed. It can therefore be quite a drill-down for a license management tool to cover everything.

Challenges and opportunities of open source licensing

There’s a push-pull dynamic between developers and their companies’ needs. Developers use open source code and the capabilities it brings to build new applications. Understandably they’re enthusiastic about this, and about the principle of open-sourcing their own applications.

However, companies realize that they need to protect some of their output. They don’t necessarily want total permissiveness within their environment because they don’t want to have to open source their systems completely. But licensing restrictions discourage sharing and adaptation of developers’ libraries, however amazing they are, so they seek to use less restrictive licenses like MIT, BSD, or Apache. That’s where the multi-license model comes in, to try and reconcile the differing terms and conditions of various licenses. Consequently, more companies have become aware of the need to follow multiple licenses and the multi-license model.

Developers’ priority has always been productivity rather than licensing and compliance. In my thirty years of running teams writing software, licensing wasn’t our concern beyond knowing we didn’t want to use anything super-restrictive. I’ve been through numerous mergers and acquisitions, and it was amazing to see the kind of freedom that developers had. When they found a library they needed, they simply took it and used it.

Even when performing due diligence, the focus was traditionally on security rather than licensing. Teams wanted to know if they were creating a risk by deploying applications and if there are any vulnerabilities that could expose the company to threats. Licensing was an issue for the legal department.

What happens when you don’t take care of your licensing? The Linksys router story

The following story is a great example of why companies must take care of licensing. Back in the 1990s, Linksys produced an effective, inexpensive, and hugely popular router, the WRT54G. By 2003, Andrew Miklas, a contributor to the Linux kernel email list, noticed that the router’s firmware used software based on Linux. Under the terms of use, Linksys — now owned by Cisco — had to release the firmware’s source code.

An unforeseen result of making the source code available was that people could modify the firmware themselves and change the router’s capacity and usage in ways that the company hadn’t anticipated. Cisco found itself selling cheap hardware with capabilities that far outstripped its price point. It released an “upgrade” with its own proprietary firmware, limited RAM and storage, which would make it difficult to replace the firmware with third-party versions, but unsurprisingly, users weren’t happy, and eventually, it re-released a Linux version of the router, with the original specifications.

Do some industries take licensing more seriously than others?

Corporations that handle obviously sensitive information, such as patients’ electronic health record systems or financial records, take licensing issues very seriously. Also, any government organizations and those that provide critical infrastructure, like the power grid. But I think there’s increasing awareness across the board.

That’s because if you open-source your software, you’re potentially giving everybody the keys to the kingdom, your source code. Hackers realize that they can inject malicious code, recompile it, make it look like the original, and work like the original, and nobody’s going to know. And with access to source code, they can manipulate your environment, the administration, the privileges, and the access you have set up, so they can infiltrate and cause havoc at the source. The risks manifest themselves primarily in vulnerabilities that enable hackers to disable, steal or manipulate data, money, assets, and more.

The toughest challenge for open source license management

With this in mind, it’s critical to know what you have in your open source libraries and ensure they aren’t exposed. Know what you have in production and understand what your risks are. Technically, what’s in development and not yet in production, doesn’t need such strict due diligence. However, once you put it out there for people to use, it’ll become obvious what libraries are being used, and whether you followed the terms of usage. Furthermore, and perhaps even tougher, is not only knowing what licenses are in your environment, but also anticipating what the impact of those licenses might be.

How to address this challenge?

You need a license management tool that gives you comprehensive visibility. For example, a tool like Mend will tell you that you have a GPLv3 component in your codebase. You can go into the tool and see the usage details in the form of the actual license text. A screen tells you what the copyright risk score is, and the details around it, so you have an idea of the impact of your redistribution of this component. It tells you if there are patent or royalty risks assigned to some of your open source libraries, which require payments and which are royalty-free, for instance, and we give you the copyleft detail. Risk is shown in an easy-to-understand traffic light system, so you can tell at a glance what might be problematic and what to avoid to prevent legal problems.

Which types of licenses present the most serious risks?

Risks differ based on the context in which software is used and how it’s intended to be used. So, it’s hard to say what are generally the worst licenses. Mend helps by showing the licenses you should avoid in red, directly on the dashboard.

If I were to advise avoiding one particular license, it would be GPL. That’s because it’s copyleft, you have to disclose your source every time, you have to provide your license and copyright notices, and in some of the licensing models out there, you have to disclose what libraries you’re using. Sometimes you even have to acknowledge your application in a file publicly, to show that you’re following the licensing model precisely.

That’s very transparent, but it also can leave you exposed.

What should you look for in an open source license management tool?

Your open source license management tool should be:

Comprehensive. Does it tell you exactly which licenses are being used when you’re creating an application? It’s important to have a system that tells what are both your direct and transitive dependencies because you need to know the entire scope of your licensing and vulnerabilities.

Clear. Your tool should clearly report all the details about your code base. Mend’s risk report shows you precisely what licenses are attached to a project. It tells you what your risk is at a glance, and it shows you exactly what license conditions you must comply with.

Fast and seamless. Developers must ensure that FOSS (free and open source software) goes through the QA process before plugging it into their application. If a tool gives you all the details about the libraries you’re using in a report, you can simply give it to the approving team, so they can make decisions more quickly about which licenses you can use.

Easy to use and understand. It sounds obvious but an open source licensing tool can only be effective if most or all of its potential users within an organization actually use it. So, it should be easy to use, and its UI and UX should be easy to understand. A good tool distills all the licensing information into compliance reports that are very simple so you can easily make sound judgments about risks like copyright, patents, and royalties. Mend’s tool does this. It generates visually impactful dashboards and screens so that this complex information can be understood at a glance.

Highlighting and implementing updates. A good tool not only hits the licensing issue but also provides great vulnerability data. This enables you to identify and upgrade to new versions of components and dependencies at the click of a button. Your tool should show you the versions you’re running and the available upgrades and recommend what to switch to. This means you continue to comply with licensing criteria while simultaneously reinforcing security by implementing the newest versions that are likely to be less vulnerable.

Setting up policies and alerts. Your tool can make license management easier by setting policies, and when they are breached, alerting users so that they can address the issues quickly. Ideally, your tool should even prevent building with non-compliant components to ensure you don’t introduce any risk to your applications. Mend’s tool can set policies at both the product and organizational levels and can automatically reject components that don’t comply with your policies.

Best practices for choosing an open source license management tool?

Perhaps the most important thing is to allow your developers to find the license management tool that fits them best. Then it’s a case of ensuring that it’s thorough so that developers get all the information they need to do in-depth due diligence.

If your developers want to introduce a new license, they must provide a risk report to the senior tech review, because they are the guys that need to know if something new has been introduced to your code base, so they can check it. They will be the ones to confirm whether the license of what has been introduced is compliant. Your tool must be able to facilitate this process.

The next question is whether a license is company-approved. That means passing it by your legal team to check whether a new library is on its approved list. You need to ensure that your tool enables you to submit libraries for review, so you can examine the licenses associated with each library.

You should be able to view and assess any dependencies — direct or indirect — so that you can see whether you risk introducing threats to your application by taking a particular library. And you need to see what the vulnerabilities are that are associated with each library.

What’s next for open source license management?

I think that open source license management is going to get more challenging. You’ll see more of the push/pull effect between permissiveness and protectiveness. Companies are more willing to use open source software, and a lot of newer licensing models are emerging that bring more freedom than a GPL. But companies still want to be able to protect themselves and their intellectual property. Therefore, there’s a persistent tension between everybody using open source licenses, and users wanting to make them more restrictive over time if they prefer.

A good example of this is Java. Java’s runtime engine used to be free, and they decided at one point that they wanted to monetize it by charging for use. But when they started charging for licenses, almost nobody used the new version. Everybody downloaded the old versions. Java realized that this could kill its product, so it suddenly changed its tactics. It still gave away its tool for free, with a few more strings attached, but still permissive enough for everybody to use further forthcoming versions.

This is the type of story you’re going to see repeatedly. Now, more companies release new open source features, libraries, and tools because they know it’s beneficial to themselves and their industries. Nevertheless, they want to ensure they have some control over them, so they can maintain their points of difference from their competitors. It’s a balancing act that will continue to exercise those of us concerned with open source license management.

In response, governments have made moves to protect both the public and private sectors from these threats. For example, in September 2022, U.S. senators sought to introduce the Securing Open Source Software Act, which is intended to strengthen open source software security. If the legislation is passed, open source software will be recognized as a critical part of the country’s infrastructure and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) will be tasked with assessing and mitigating the risk of all open source components that are used by federal agencies.

One important element of this is complying with the many licenses that govern every open source dependency in your code base. With more than 200 different open source licenses out there, each with its own terms and conditions, open source license management can be a tricky endeavor. However, failing to accurately track licenses is risky business, and can result in some unfortunate surprises. At best it could be just the headache of replacing a component; at worst, it could mean jeopardizing exclusive ownership over your proprietary code.

With that in mind, it’s important to understand what open source licenses are, and how best to manage them. 

The basics: What is an open source license?

Open source licenses are legal and binding contracts between the author and the user of a software component, declaring that the software can be used in commercial applications under specified conditions. The license is what turns code into an open source component. Without an open source license, the software component is unusable by others, even if it has been publicly posted on GitHub. Each open source license states what users are permitted to do with the software components, their obligations, and what they cannot do as per the terms and conditions. Licenses vary in complexity and requirements, and each organization is responsible for choosing which licenses are most compatible with its policies to ensure that it remains compliant.

What is license management software?

License management software is designed to identify, track and catalog all the components, dependencies, and relationships used when developing software and applications. This technology enables users to check how they use every component and dependency to ensure that usage complies with the license terms of each component.

It’s a big task because every piece of software comes with a license that stipulates what you can do with it, how you can use it, who can use it, and for how long. Adhering to the conditions of each piece of software, maintaining registration fees, and determining the relevance of each license, are critical to maintaining efficiency, protecting your software, and avoiding the legal costs that could arise from breaching license terms.

Advantages of license management software

• Transparency and visibility. Open source license management software makes it easy to see what software, components, and dependencies your company uses and how each of them is being used.
• Ensures compliance and avoids legal issues. This visibility ensures that organizations comply with the license agreements for every component and dependency. It means you avoid infringing any terms and conditions (T&Cs), which could result in costly fines and time-consuming revisions to your software. And it ensures that your usage remains in line with any revisions or updates to these T&Cs.
• Controls costs. You can see what licenses are being used and who is using them, so you can identify which licenses are worth retaining. There’s no point in spending money on licenses for software that is seldom or never used. And with software you do use, you may find that you can spend less for fewer users, if an audit from your license management software shows that this is appropriate.
• Reinforces security. You can easily see when software is used in an unauthorized manner, and it can help identify unusual and unexpected patterns of usage that may indicate a security threat.
• Speed and ease. The high volume of open source components and dependencies that organizations use makes manual management difficult, costly, and time-consuming. Using open source license management tools greatly reduces the time and cost.

Risks of not using license management tools

• Poor visibility. A lack of visibility over software impairs decision-makers’ view of which software is best to invest in, which to discontinue using, and which software should be prioritized for attention in order to avoid licensing and security issues.
• Compromised security. If you don’t know whether you’re complying with current licenses, you increase the possibility that you will use outdated or corrupted components, which can detrimentally affect the security of your software. This can compromise your product, your efficiency, your reputation, and ultimately your business.
• Infringement. Without a tool of this kind, you increase the risk of infringement. You’re more likely to neglect to update your license usage to comply with terms and conditions, which means you may find yourself facing legal action for unauthorized use of software.
• Costs. Without the right tools, you risk wasting money or incurring steep penalties. Back payment and legal penalties for each instance of a license infringement can be as much as $150,000. The penalties for selling illegal or incorrectly authorized software can reach $250,000 and may pose the threat of a custodial sentence. Even when using licensed software, improperly audited use may find you unnecessarily paying for unused or seldom used software.
• Reduced productivity. Without these tools, you increase the likelihood of replacing or rewriting code post-production. This slows production and hampers productivity.

Closing thoughts

Open source license management tools are a critical element for safeguarding your code, software, and applications, as well as reducing financial and legal risk for your organization. They reinforce the integrity of the components and dependencies you use, and ensure that your use of these components will neither compromise your organization nor the product that you create.

The devastating vulnerabilities found in Log4j — and other serious software supply chain breaches, like SolarWinds, Kaseya and Codecov — clearly illustrate the gravity of the situation. Governments are taking notice, and many are issuing guidelines and legislation requiring organizations to reinforce the security of their software supply chains.

The United States is a case in point. In 2021, the White House issued Executive Order (EO) 14028, entitled “Improving the Nation’s Cybersecurity,” aimed at boosting the security and integrity of the software supply chain. In 2022, the Executive Office of the President of the United States issued a further memorandum for the heads of U.S. government and federal executive departments and agencies, which doubled down on the executive order to reinforce the security of the software supply chain through secure software and application development practices.

To this end, the Cybersecurity & Infrastructure Security Agency (CISA) in the United States has pointed to the software bill of materials (SBOM) as a way to simplify remediation of similar vulnerabilities in the future. 

In light of this, here’s an overview of SBOMs — what they are, how to obtain them, and how to effectively generate and audit an SBOM.

What is an SBOM?

An SBOM is a formal, machine-readable description of the many open source and proprietary software components that make up a piece of software. It provides a structured approach to achieving supply chain security by giving those who create, buy, and operate software the necessary information to track supply chain relationships. It increases the transparency into your software components and ensures your products perform securely and as intended. 

The idea of SBOM comes from the bill of materials (BOM) used in traditional manufacturing, which lists the raw materials and other components required to produce an end product. If anomalies are detected in any aspect of the manufacturing process, a BOM makes it easy to locate and fix issues.

Why are SBOMs important?

SBOMs give developers, DevOps teams, security specialists, and others visibility into the code base and sources of your organization’s software and security. This provides visibility into the components and dependencies in your software, which provides a couple of key benefits. 

Firstly, SBOMs help you know what you’re using in your code base. This knowledge is essential for security, because it can help identify which components need to be updated or patched. Without SBOMs, you might not know which components are vulnerable to attack, you don’t know whether versions of components or dependencies have been updated — and therefore what is new, anomalous or what bears a threat to your security. In short, you can’t detect and fix vulnerabilities if you don’t know what’s there in the first place. SBOMs give you that visibility.

Secondly, SBOMs help customers and buyers assess the risk of using, installing, or integrating a product. Increasingly, purchasing organizations, particularly in the public sector, demand that vendors provide SBOMs. This increases the robustness of software security and minimizes the possibility that purchasers are unknowingly breaching any software usage licenses, which could expose them to legal and financial issues. 

SBOM users can determine whether their software is vulnerable to previously disclosed security vulnerabilities. By using SBOMs, developers can identify which components or dependencies could be vulnerable to attacks during development and deployment.

The SBOM also improves efficiency by combining open source and third-party software and helps you see if you are meeting compliance standards and following software usage policies. Using SBOMs to share infrastructure and data could save firms time and money by facilitating more collaboration between departments, and by identifying weak portions early in the software development life cycle (SDLC).

What are some key SBOM benefits?

Let’s talk about some main benefits of creating and auditing a software bill of materials. 

1. Reduces Supply Chain Risks

The software supply chain comprises each non-organic component that goes into the production of a piece of software. It includes pre-built libraries, open source packages, and other third-party resources used to expedite development and improve software quality.

Malicious actors usually implant dangerous code in third-party packages. And when an unsuspecting user installs the infected package, their system gets compromised, leading to a supply chain attack. 

A major advantage of a software bill of materials is that it increases transparency into the various supply chain components. This enhanced visibility lets software producers, purchasers, and operators better identify and address vulnerabilities.

2. Increases Consumer Confidence

An SBOM is just like a list of ingredients on a food packet; consumers usually consult the labels before making a purchase decision. Similarly, software buyers can consult an SBOM to perform vulnerability analysis and determine the suitability of the product. 

Consumer confidence is particularly important in today’s software industry where attackers like targeting open source components to infiltrate the software supply chain. With the massive use of open source codebases in software development projects — from 36% in 2015 to 90% in 2022 — they offer a lucrative opportunity for attackers to inject vulnerabilities and compromise the supply chain. 

Creating an SBOM is a proactive approach to understanding the supply chain and ensuring its various components, including open source codebases, are safeguarded from attacks. This increases the buyers’ confidence in consuming the software.

Additionally, an SBOM can be pivotal when an organization is conducting due diligence for merger and acquisition purposes. An SBOM can simplify the auditing process, provide transparency into an organization’s technical proficiency, and build trust with prospects. 

3. Supports Regulatory Compliance

The recent escalation of supply chain attacks, such as the widely publicized SolarWinds attack in late 2020, has ignited a regulatory response from the government. In May 2021, the Biden administration issued an executive order that aimed to improve the US’s cybersecurity defenses. 

The order sets out new security requirements for any software sold to the Federal Government. One such strict requirement is that vendors should include an SBOM to maintain greater transparency into their software and prevent supply chain attacks. 

Given the buying power of the Federal Government, the rest of the software development industry is likely to follow suit and require SBOMs for all critical software. 

Traditional methods of generating SBOMs

The traditional methods of creating a software bill of materials come with several challenges that complicate effective SBOM management. They often introduce several risks and issues that increase the possibility of getting attacked. 

For example, some organizations generate and manage SBOMs manually using spreadsheets or emails. Such methods often lead to several challenges, including the following:

• Managing SBOMs traditionally leads to scaling challenges, especially when an organization gets more supply chain partners, introduces new products, or experiences growth. 
• Using a spreadsheet-based SBOM complicates the tracking of the hierarchical relationships between different software parts. Worse still, if an SBOM document is modified and shared with multiple people, it complicates identifying the latest revised file.
• Looking for information in a spreadsheet bill of material is tedious and slow, especially if two or more products have some components in common. Even if your organization has a spreadsheet-formula guru, digging into SBOMs does not amount to productive work.

Additionally, some organizations use traditional tools to create and manage SBOMs. That’s another way of doing SBOM incorrectly, and it often leads to several problems, including the following:

• Many tools are not suited for managing SBOMs. For example, they disclose vulnerabilities without giving a clear path of addressing them, they cover only a specific set of programming languages or package managers that leads to incomplete SBOMs, and produce high false-positive rates that misdiagnose libraries and dependencies. Such incompetency exposes organizations to greater risks. 
• Many tools cannot generate SBOMs automatically in a machine-readable format. They cannot also scale to meet emerging software development needs. Such issues often slow down the release process and hurt the organization’s bottom line. 

What’s in an SBOM?

The basis of an SBOM is an inventory of the source components and dependencies in a piece of software or application, including items like dynamic link libraries (DLLs), that applications use to operate, middleware, and programming frameworks on which an application operates.

An SBOM should also provide information about where each component comes from. And. As components and pieces of code are often dependent on others, an SBOM should include a dependency tree so users can see what the core components of an application are.

In July 2021, the United States National Telecommunications and Information Administration (NTIA) issued guidance on what should be the minimum elements in an SBOM. This guidance highlighted three essential things: 

1. Data fields. The fundamental information about each component, such as: supplier details, component name, which version of the component, license information, relationship with dependencies, who authored the SBOM data and the timestamp of when SBOM data was generated. When these elements are broken down into their constituent parts, they can be identified as:
   • Open source licenses. Which components are open source? What type of license do they allow use and reproduction — copyleft or permissive? What terms and conditions (T&Cs) of use should you be aware of when using them, and what T&Cs should subsequent users of your software and applications understand?
   • Compliance. You SBOM should identify whether your current components are being used and reproduced in line with their license terms and conditions.
   • Dependencies. A comprehensive list of all the dependencies attached to every component of a piece of software or an application. Important for compliance purposes and to ensure awareness of potentially problematic or vulnerable dependencies and version updates.
   • Open source components. As open source components are almost ubiquitous in modern software and applications, they are a popular attack vector. As such, it is important that SBOMs can identify them so that it’s clear when they are anomalous or are compromised in some way.
   • Open source versions. Updates happen frequently. Many improve the robustness and operational capabilities of software. Some do the opposite and can compromise the code. SBOMs should identify and indicate whenever a new version of code, a component or a dependency has been introduced, and whether it is fit for use by being secure and compliant with usage policies.
   • Open source vulnerabilities. Where vulnerabilities exist, an SBOM should identify them. The impact of vulnerabilities can vary from none to considerable, depending on the context in which an open source item is used and its interaction with other components and dependencies. Therefore, it’s important for developers and users to know what’s there so they can make an informed judgment on whether to use or avoid it.
   • Automatically update components. Modern software development processes can be so complex that manually updating components and dependencies within an SBOM is inadvisable. So, the NTIA recommends a minimum level of automation for SBOM generation and data transfer.
   • Remediation. Ideally, remediation of vulnerabilities, preferably automatic, would be included to ease and expedite the reinforcement of components and dependencies identified in an SBOM.
2. Automated support. Automated detection and identification of components, dependencies, and vulnerabilities dramatically reduce the burden on DevOps and security teams to keep on top of version generation. Furthermore, automation makes it easier for other systems to understand and make use of SBOM data across the software ecosystem. This requires standardization of data formats for SBOMs, including the main formats, SPDX and Cyclone DX, and Software Identification (SWID) tags.
3. Practices and processes. The right processes must be in place in an SBOM to help enable the ongoing collection of data, plus a definition for how each SBOM is generated and accessed. This involves defining the operation of SBOM requests, generation and use, including frequency, depth, known unknowns, distribution and delivery, access control and accommodation of mistakes.

Best practices for generating and auditing SBOMs

Generating and auditing SBOMs require a modern approach that can help you surmount the challenges of mitigating supply chain risks. 

Here are some best practices for managing software bill of materials:

• Use a tool that supports automation. The Biden executive order requires software inventories to be automatically generated in a machine-readable format. If you use a tool that does not support full automation, you will not meet the requirements. You can also create loopholes for attackers to harm your supply chain.
• Use a tool that supports continuous remediation. You need a tool that continuously discovers and addresses supply chain risks. It should assist you in avoiding harmful components at the sourcing stage and continuously alert you when any anomaly is detected during development or production. It should also be capable of identifying risks in downstream components in case an upstream component is infected. 
• Use a tool that covers all aspects of an SBOM. You need a comprehensive tool that provides an up-to-date and accurate inventory of your supply chain components. An end-to-end tool will cover all the technology stacks and programming languages used in your organization. Otherwise, you may generate SBOMs that do not paint the correct picture of your software inventories.
• Use a tool that makes your life easy. You need a versatile tool that will point out how to address the identified risks, scale comfortably across your software ecosystem, and produce low false-positive rates. With a good tool, you’ll not need to stop and research how to fix a vulnerability or get insufficient SBOM reports, which can affect the quality of the released software.

How Mend SBOM can help

Mend SBOM is a modern, remediation-centric tool that can help you implement SBOMs and ward off supply chain attacks. It focuses on the open source components of your supply chain and provides deep inspection that allows you to identify vulnerabilities in your applications.

With Mend SBOM, you can swiftly and easily produce a software bill of materials that reveals all open source libraries, tracks and documents direct and transitive dependencies, and automatically updates whenever a change is detected in any component. If it discovers a vulnerability, the tool recommends a safe remediation path that ensures no breakages to the build. 

It’s the tool you need to automatically generate accurate and comprehensive SBOMs and take your application security to the next level. 

FAQs

The report, which draws data from several sources, including our industry-leading vulnerability database and Mend Supply Chain Defender, delves into the significant risk posed by the ongoing rise in open source vulnerabilities and software supply chain attacks. According to the report, the number of open source vulnerabilities that Mend identified and added to its vulnerability database in the first nine months of 2022 was 33 percent greater than the first nine months of 2021, reflecting both the growth in the number of published open source packages and the acceleration of vulnerabilities. As businesses continue to heavily rely on their applications for success, this growing threat is a mounting concern. 

Key findings from the report include: 

• 33 percent growth in the number of open source software vulnerabilities that Mend added to its vulnerability database in the first nine months of 2022 compared with the same time period in 2021. This outstrips the estimated 25 percent growth in the amount of open source software available.
• According to a representative sampling of approximately 1,000 North American companies from January to September 2022, only 13 percent of vulnerabilities seen were remediated, compared with 40 percent remediated by those companies using best practices for application security.
• Data from Mend Supply Chain Defender shows a steady quarterly increase in the number of malicious packages published in 2022, with a significant jump in Q3, which increased 79 percent from Q2. 

“As security debt continues to rise, it’s crucial to find a way to prioritize the vulnerabilities that pose the highest risk to avoid falling victim to an attack,” said Jeffrey Martin, VP Product Management at Mend. “Using remediation tools to assess and prioritize the vulnerabilities that can most heavily impact systems is an important element to managing security debt. However, organizations should not just pay attention to severity details to ensure effective prioritization and remediation. They also need to look at the context in which flaws are exploited, both on their own and in conjunction with others.”

While companies remediate thousands of vulnerabilities each month, it takes modern remediation best practices to handle the ongoing wave of new vulnerabilities detected to prevent a growing backlog of vulnerabilities. The increase in open-source vulnerabilities outstrips the estimated 25 percent growth in the amount of open source software available. With applications being the lifeblood of the global economy, regular application security scanning and use of prioritization and remediation tools are essential. 

Let’s take a look at the open source license usage trends in 2021 and compare them to previous years. 

Our research team has collected information from the Mend database, which includes more than 4 million open source packages and 130 million open source files covering over 200 programming languages, to learn which were the most popular open source licenses in 2021. Results show that the use of permissive open source licenses continues to rise, while usage of copyleft licenses, especially GPL licenses, continues to decrease. 

Permissive open source licenses continue to trend

It’s no surprise that permissive open source licenses continue to dominate. The Apache 2.0 license and the MIT License are far more popular than the GPL family, together comprising over 50% of the top open source licenses currently in use. 

Permissive licenses place minimal restrictions on how others can use open source components. They permit varying degrees of freedom to use, modify, and redistribute open source code, and they allow the use of permissive-licensed open source components in proprietary derivative works, requiring nearly nothing in return. 

As open source usage has become common practice in organizations, and open source libraries dominate most corporations’ codebases, companies are showing a clear preference for components with permissive licenses because they place minimal limitations on the users. 

When it comes to open source creators — as demand for permissive licenses rises, so does the supply. Creators attach permissive licenses to their open source projects because they want to reach as wide an audience as possible. While releasing an open source project under a permissive license means that corporations can use them and build on them without having to give much back to the community, so far most open source creators continue to choose the permissive route.  

According to this year’s data, 78% of open source components have permissive licenses. That’s a 2% rise from last year’s 76%. Only 22% of open source licenses are copyleft, compared to 24% last year. 

The Apache 2.0 license takes the lead

We’ve come a long way since the Apache 2.0 license shook things up by pushing the GPL 3.0 license from second to third place in 2017. This year Apache 2.0’s ascent continues, as it takes first place with 30%, rising above the MIT license’s 26%

GitHub’s choosealicense.com explains that the Apache 2.0 license’s main conditions require preservation of copyright and license notices, providing an express grant of patent rights, and allowing licensed works, modifications, and larger works to be distributed under different terms and without source code. Apache 2.0 is the license for quite a few popular open source projects, including Kubernetes, which may be one reason for its rising popularity. Another reason is Apache 2.0’s explicit patent grant, which is often a sticking point for developers. 

The express grant of copyright may be one reason why end users are choosing the Apache 2.0 license as a safer choice that covers the patent angle, as opposed to MIT’s brief license that doesn’t address patent rights. 

The MIT open source license — Not going anywhere

This year, the MIT license took second place, with 26% of open source licenses. While no longer in first place, don’t expect this short and simple license to lose much popularity in the foreseeable future. Ben Balter, attorney, open source developer, and Senior Product Manager at GitHub, said that developers choose the MIT license because “It’s short and to the point. It tells downstream users what they can’t do, it includes a copyright (authorship) notice, and it disclaims implied warranties (buyer beware). It’s clearly a license optimized for developers. You don’t need a law degree to understand it, and implementation is simple.”

GitHub’s choosealicense.com, states that the MIT license “lets people do anything they want with your code as long as they provide attribution back to you and don’t hold you liable.”  A few years ago Facebook very publicly replaced the contentious React license with an MIT license. 

Other popular open source projects licensed under MIT are Angular.js, rails, and .NET Core. 

The GNU GPL family continues to decline in popularity

While GPLv3 keeps its third place position, it dropped from 10% in 2020 to 9% in 2021. GPLv2 also kept its fourth place position, going down to 9% from 10% last year.

This year GPL v3.0, GPL v2.0, and LGPLv2.1, which all came in the top 10, got a combined 21% out of all top 10 licenses, which marks a slight decrease in popularity for the GNU GPL family of licenses. 

The GPL was a trailblazer at the start of the open source revolution and is the OG of the copyleft or viral license. When users incorporate a component licensed under one of the GPL licenses, they must release its source code and the rights to modify and distribute the entire code. In addition, they are required to release their source code under the same GPL license. 

There will always be GPL users. It’s the Linux kernel license, created by a huge open source community. However, it’s clear at this point that business-wise, the preference is for licenses with fewer restrictions and limitations. 

Open source licensing in 2022: What’s next?

The tension between creating a viable business model and maintaining a robust and successful open source project continues to grow. We will continue to see open source projects struggling to find the balance between making a profit and being supportive members of the open source community. 

As much as support for the open source community continues to thrive, we will most probably see more hard-working unpaid creators and maintainers of small but critical projects updating licenses for a better business model or even abandoning projects due to burn-out. 

Of course, we will also have the community in contentious debates over larger enterprises that will update their open source offerings claiming they can’t afford to give away their work. 

The open source community continues to expand and evolve, and new business models will rise and fail, as the decentralized nature of the open source community continues to deliver a wide spectrum of diverse opinions and new ideas that defy the consensus. One thing remains certain: open source is here to stay, and it appears that currently, when it comes to licenses, the less restrictions, the better.