Software supply chain attacks are growing. Gartner reports that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chains, a threefold increase from 2021.
Confronting this AppSec challenge even as budgets tighten in the slowing economy means IT business leaders need to find ways to do more with less.
The good news is that new approaches and technologies for strengthening supply chain security are creating opportunities to be more effective in both security and budget optimization.
AppSec Requirements in the DevOps AgeÂ
The weaponization of the software supply chain presents a substantial challenge. The attack surface is huge and existing application security tools generate so much noise, organizations struggle to recognize real threats.Â
DevOps and open source are transforming the development process, and that transformation is widening the gap between security and development teams. These trends increase autonomy for development teams, but also mean that security teams lack visibility into development tools, configurations, dependencies and environments.
Considering this changed SDLC landscape, organizations need to re-think — and probably re-tool — their AppSec strategy. The ideal solution must help AppSec teams satisfy the following requirements:
- Obtain visibility across the entire software supply chain from end to end
- Provide coverage for all security risks threatening modern software delivery pipelines
- Correlate findings and data across all tools and phases of the SDLC
- Provide deep insights into risks and attack paths
To align resources with these requirements, enterprises need to re-evaluate their AppSec spending and the tools they use based on their ability to accomplish these objectives.
Aligning AppSec Budget Based on Risk Profile
An excellent place to start doing more with less is identifying and correcting misalignments of your organization’s actual risk profile versus software spending based on each tool’s ability to manage risks you actually face
First, examine the use of SAST tools, because SAST takes the lion’s share of the budget in most organizations. The purpose of SAST is to find vulnerabilities in custom code. However, in most environments, applications consist of 80 to 90% open-source components and only 10 to 20% custom code. Moreover, 80% of the findings from SAST come from only 20% of SAST rules finding the same types of problems over and over. Is your SAST tool delivering value consistent with its cost?
Finding and exploiting a flaw in custom code is very expensive to a hacker because that flaw can only be used against a single organization. To justify that effort, the organization must represent an exceptionally interesting target. Hackers often reason that they can get a much better return on their time by finding and exploiting a vulnerability in open-source components that provide access to many users and organizations.
Take a hard look at the attractiveness of your organization to attackers. Are you allocating too much budget to a problem that probably represents a small part of your risk profile and one that is less likely to be targeted by hackers? Correcting a budget misalignment like this can allow those resources to be better applied elsewhere.
Your SCA tool represents another opportunity for savings. This tool is very important because it protects against the highly opportunistic, automated and repeatable attacks that hackers favor. From a risk profile perspective, this also protects 80% of most organizations’ code base.
SCA is marketed as a way to manage the risk of vulnerable dependencies. Yet while vulnerabilities exist in many types of dependencies, legacy SCA is laser focused on only one: known vulnerabilities in open-source libraries. Recent examples like SolarWinds and Jenkins demonstrate how vulnerable development tools can compromise an application, so they should clearly be considered an application dependency. The same is true of those tools’ dependencies, such as Jenkins plugins and build modules in GitHub.
The limited scope of legacy SCA tools fails to address the full scope of dependency risk in pipelines. Here again, the budget may be misaligned because a licensed tool is not entirely addressing the risk it is intended for, which is to protect the entire supply chain throughout the SDLC.
 SAST and SCA make up the majority of application security budgets but only address 2 of 15 vectors in the modern application attack surface, which implies that the budget is not being efficiently used in many organizations.
Optimizing AppSec Operational Efficiencies and Development Costs
Licensing is just one dimension of the total cost of a tool. Each tool has its own unique installation, configuration, and user experience, and organizations need to either:
- Train users to operate all these distinct tools and understand their differences, increasing operational costs roughly proportional to the number of tools used, or
- Make additional investments to configure, integrate and customize reporting and user workflows to create a consistent user experience that lowers operational costs
Tools that provide a consistent user experience across multiple aspects of risk can reduce both development and operational costs, while at the same time providing better security because they understand multiple dimensions of risk.
Improving Application Security While Reducing Costs
Doing more with less means finding an ideal solution that satisfies all four of the AppSec requirements while reducing development, operational and licensing costs to optimize spending.
The question becomes, what’s the best path forward? Organizations normally consider four alternatives, which are compared below based on their desirability across these seven criteria.
- Collection of Established Point Products. Collecting a series of established point products gives decent coverage, but requires a lot of tools, leaves many risks unaddressed, is very expensive with licenses, has moderately high operational and development costs and doesn’t satisfy correlation or insight requirements for good application security
- DIY using Open Source Tooling. The advantage of low licensing costs is offset by high operational costs and low scores across all other criteria
- Single Pane of Glass. This approach addresses but underserves each of the criteria. Licensing is expensive, development and integration costs are high and insight capabilities are limited
- Next-gen Software Supply Chain Platform. This proves to be the most effective use of budget and the most effective solution for application security
Nex-gen application security platforms can ingest and analyze all the data throughout the software development lifecycle. They’re able to connect the dots between all these tools and coordinate across them. They address all the application security requirements including correlation and insight, and are very desirable from a budget perspective. Compared to open source tooling, they have higher licensing costs which are more than offset by reduced operational and development costs while providing much greater AppSec effectiveness.
Cycode was created specifically as a next-gen AppSec platform that incorporates all eight of the most significant tools for vulnerability detection and pipeline hardening into a single integrated platform. This provides complete SDLC pipeline visibility, hits all the requirements for application security and is more budget efficient.
Want to Learn More?
Additional information is available in our webinar Doing More With Less: How To Improve AppSec Programs When Budgets Decrease.
Schedule a demo to learn how Cycode’s next-gen AppSec platform can help secure your software supply chains.Â
