How to Make a Case for Buying SCA
The ongoing rise in open source vulnerabilities and software supply chain attacks poses a significant risk, and it will only increase. According to the Mend Open Source Risk Report, modern security best practices such as software composition analysis (SCA) are vital for stemming the rising tide of open source vulnerabilities in applications and software. However, that’s not always clear to the financial decision makers, and application security leaders need to build a compelling business case to help them understand. From highlighting the crucial role of open source software to pointing out the costs of neglect, we’ve put together a five-point plan that makes the case for an SCA purchase. Let’s take a look.
1. Discuss the ubiquity of open source software
Between 70 and 90 percent of all software and applications contain open source components, which represent a growing security risk. In Forrester’s State of Application Security, 2022 report, the research firm found that software applications are the favorite attack vector of malicious actors. According to the research, 53 percent of external attacks involve either exploiting a software vulnerability or come through a web application.
Even more alarming, open source vulnerabilities proliferate at a rapid rate and this growth is expected to continue. The Open Source Risk Report found 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.
Furthermore, 71 percent of IT and security leaders say their portfolios of applications have become more vulnerable to attack. These trends show that vulnerabilities pose a serious risk for every organization that uses open source to help build their applications and software.
Hacker tools already identify which open source components are being used, along with associated vulnerabilities. If they already know this information, you should as well.
2. Show why SCA is the gold standard
SCA is specifically designed to analyze and fix open source vulnerabilities, making it a first-choice solution given the ubiquity of open source components in today’s applications and software.
SCA tools scan the code base of your software and applications to identify all open source components, their license compliance data, and any security vulnerabilities. Modern SCA tools like Mend SCA, also fix open source vulnerabilities by prioritizing and automatically remediating those that pose more serious risks. Previously, there was a trade-off between developers’ productivity and security, but now, SCA tools overcome this issue by working within the current development workflow, making the process of applying security measures as frictionless as possible in the SDLC.
Consequently, modern SCA products can offer better detection, greater accuracy, and faster remediation of vulnerabilities than legacy SCA tools. For example, Mend SCA reduces the time that developers need to spend on remediation by 80 percent, which means that developers’ resources are saved for what they do best — creating great applications and getting them to market faster.
3. Talk to the right people
The people who handle this stuff daily — application security teams, developers, and DevOps, — are your natural starting point. They probably have a keener understanding of security requirements than others in your organization, so their viewpoint is critical. Moreover, developers are increasingly being asked to identify, detect, and remediate these vulnerabilities as part of their role.
However, they might not have a strong voice on where the budget is spent, and others must be convinced of the business case for buying SCA. Who are they, and what can we say to get their backing?
Every organization has many internal stakeholders that are not involved in development and security — such as sales, customer success, R&D, finance, and more — who use the apps and software that developers have created, almost all of which are built with open source components. Additionally, in many cases, external third parties such as customers, are important end users of your apps and software. These users can also provide valuable insight into the benefits they enjoy and the challenges they face when using your apps. So, identify a short list of power users and decision-makers within the organization, who have influence over budgeting decisions. Get their feedback, so you can learn about the state of your application security and you can give them a clearer understanding of why investing in SCA should be a priority.
4. Know what to ask
A consultation is only as thorough as the questions you ask, and different stakeholders will naturally respond better to different questions.
When you’re consulting technical stakeholders, you should get more granular about the software, components, and dependencies they’re handling. These questions provide a solid basis on which to show that SCA is necessary:
- Do you use a fixed, unchanging set of open source components and dependencies?
- Are you fully aware of all the components and dependencies that you use?
- Are you certain these are all tracked, updated, and fixed to avoid vulnerabilities?
- Are you confident you’re aware of all security risks associated with the software you use?
- Are you sure the development and DevOps teams always do scans and updates?
- Are you confident that you do this due diligence easily and effectively?
- Can you comfortably scan and fix the volume of code you currently handle?
- Do you think you can always do so without compromising your productivity?
- Is the detection and remediation of vulnerabilities currently automated?
- Is it integrated into their workflow?
- Are you confident your code base, software, and apps are presently as secure as possible?
Without an SCA tool in place, the chances are that most, if not all of the answers will be “No.” Just one “No” casts doubt on the efficacy of your existing application security measures and shows your decision-makers that you’d benefit from introducing SCA.
When you’re talking with internal and external non-technical stakeholders and customers, aim to get a snapshot of how they feel about the security of your apps and software. Key questions to ask them are:
- Do you encounter any problems with security on our apps?
- Do you feel that security issues could compromise our software and apps?
- Are you concerned about the security of these apps and software?
- Would you welcome an escalation of security measures?
If the answer to any of these questions is “Yes,” then it’s clear that security concerns others both inside and outside your organization. So, to protect your business, security should be prioritized and addressed, and leading the way with open source security involves implementing SCA.
5. Show the cost of neglect
If decision-makers remain hesitant about buying an SCA tool, you can shift focus from its benefits to the implications of not having one or choosing an inappropriate solution.
Without SCA, the process of detecting, identifying, and remediating vulnerabilities is arduous, and far less thorough than a dedicated tool can deliver. Furthermore, without SCA, you risk shipping applications with less robust security, which can detrimentally affect your code base, your products, your services, your customers, and your reputation as a reliable software and applications provider. It could cost you a lot, financially and reputationally. Ultimately, it’s not good for business.
There are numerous examples of the financial and legal impact of the lack of open source application security. Perhaps one of the most prominent was the Equifax case that occurred in September 2017. The credit agency suffered a security breach that exposed the data of 147 million people. Its failure to protect this information cost $700 million in fines.
Hackers used a well-known vulnerability in the Apache Struts open source component in one of Equifax’s customer web portals. They infiltrated the company’s software and stole data, moving from a point of entry in its web portal to other servers because the systems weren’t adequately segmented from one another. When they found usernames and passwords stored in plain text, they could access further systems. Then they pulled encrypted data from the network.
The initial vulnerability should have been patched. Equifax claimed it wasn’t aware that the vulnerable open source component was being used in the customer portal, but investigations revealed there had been failures in the company’s security process, which included failing to renew an encryption certificate in one of its internal security tools Using the right SCA tool, the vulnerability would have been detected and fixed, and this significant breach wouldn’t have happened.
Building your case
Having taken these steps, you’ll have built a strong narrative about why a budget for SCA is essential. You’ll be able to explain how it can meet the desired business value — over and above the benefits — by filling any capability deficit, and you’ll articulate the value of purchasing SCA. It’s a lot to take in, so use this checklist to help you cover all the bases. Answer “yes” to each of the following, and you can be sure that you’ve developed a strong case for buying SCA.
Yes
| No
| |
| Outlined the current risk environment for open source apps, using recent research | ||
| Understood the function and benefits of modern SCA tools | ||
| Identified who to talk to — users, stakeholders, decision-makers | ||
| Understood what their concerns and needs are and how they feel about AppSec and SCA (Asked the right questions) | ||
| Aligned SCA’s value with these concerns and priorities | ||
| Shown how SCA will close any current capability gaps | ||
| Explained what could happen if they don’t buy SCA | ||
| Shared similar customer success stories | ||
| Set out an implementation plan that suits the organization and meets its needs |
Discover more about Mend SCA: How our advanced technology makes it easy to develop secure software without compromising on speed or agility.
