2022 will be the year of broadened supply chain security -- here's why
Even a year after the SolarWinds infiltration in late 2020, software supply chain risk continues to dominate the security conversation. Take the Log4Shell vulnerability that recently came to light and caught everyone off guard. Not only is this flaw insanely easy to exploit but the impacted Log4j library is used in nearly every enterprise Java installation -- and the vulnerability gives attackers ultimate power to download, delete, install, and server-hop as they please. As even massive companies like Google, PayPal, Apple, and Netflix are impacted by this flaw via the software supply chain, it’s another one that makes organizations wonder: are we using that too?
In 2022, IT leaders will intensify their supply chain focus to answer this very question, expanding their scrutiny from their own applications to the components they buy and integrate. Widening the scope of the supply chain is crucial; outside software and components need their checks and balances just as code created internally does. This deepened understanding of supply chain risk will increase demands to test and secure everything, from the most seemingly insignificant open source package to the most extensive APIs and third-party components.
If the Log4Shell exploit and the SolarWinds attack taught us anything, it’s that the risks in software supply chains are not always obvious, making the threat that much greater. These incidents gave us whiplash and forced us to come to grips with the fact that every component, process, and human can undermine the security of software, threatening consumers, businesses, and public institutions.
SEE ALSO: What are Log4Shell and log4j and should you be worried about them?
That unseen threat lurking in the shadows of software security can come as a nasty shock, especially when organizations don’t know the full scope of their assets, what they are made of, and the level of security (or lack thereof) that’s applied to configurations and third-party integrations. When organizations lack clarity on everything they run and all the security risks they face, from their sprawling application environments to multiple software stacks with all their components, software supply chain becomes a major risk.
As we look ahead to 2022, a serious question emerges: if you don’t know who has had their code sitting in your software from build to deployment and management, how do you know that it’s truly safe from these and other common vulnerabilities?
My take on why 2022 will without a doubt be the year of supply chain security:
The Software Bill of Materials gets a White House-level boost
Though not a new concept, a Software Bill of Materials (SBOM) is a powerful and important mechanism for clarity into production processes and the discovery of otherwise unseen issues throughout the supply chain. In the future of AppSec, the SBOM is set to play a crucial role in helping to secure the software supply chain so that security issues are easier to find and tackle. That baking list of ingredients ensures that everyone from end users to regulators and stakeholders knows what has gone into creating the very software they’re touching, and makes it easier to react quickly and effectively when new threats emerge.
An SBOM is particularly useful when it comes to open source code and third-party libraries that stem from external sources but are embedded into a proprietary application. Typically created through tools like Software Composition Analysis (SCA), SBOMs are a necessity after the explosive adoption of open source and third-party components. Not only do they help organizations understand their risk posture, but also they uncover components in the perimeter and minimize the threat of using software that has known vulnerabilities. They’re crucial for ensuring that organizations can easily pinpoint where breaches might have occurred, and to assure customers and partners that the most secure, up-to-date components are in use.
It’s a matter of national security, too. The May 2021 United States Executive Order on Improving the Nation’s Cybersecurity underscores the need for SBOMs and directs the Commerce Department to lay out general guidance for providing them to purchasers. But beyond buyers, the EO notes that SBOMS are especially important for visibility into updates and building action plans around exploits. "Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities," the EO says.
The Executive Order also states that SBOMs are more impactful when collected in a repository that’s easy to query with other systems so that discovering security risk is a more streamlined process. It all ties back to clarity and the bigger picture view of your assets, knowing what you have, and creating a battle plan for securing your entire threat landscape. Riding the tailwinds of the EO, SBOMs show promise of making a positive impact on the security landscape in 2022.
Lingering debt adds to the exploitable flaw buffet for bad actors
In the same spirit as gaining a fuller picture of your assets and connected components, getting a handle on your security debt is imperative. Lingering security debt hovers over your assets and casts the shadow of unseen, lurking risk. This debt can stem from a variety of places, whether that be security knowledge gaps by the DevOps teams contributing to existing threats, inadequate tooling causing gaps in coverage, or developers forced to make hard decisions about which steps of testing to sacrifice in the race to market.
Our own research this year found that 70 percent of teams always or frequently skip security steps when completing projects, only adding to that lingering debt. And if it sits unchecked, a molehill of security debt quickly becomes a mountain to climb; we estimate that it would take IT teams an average of 112 hours (two weeks) per team member to address their current backlog of security issues. And that’s only if they shrug off their other projects and duties to focus on debt.
If security debt is like leaving a buffet to threat actors by constantly growing your attack surface, why do so many organizations struggle to bring it down? It’s often a case of "out of sight, out of mind" -- and SBOMS combined with asset discovery can help as they bring more clarity to the supply chain and existing environments. As teams become smarter about tracking and monitoring all of the commits and dependencies across their software development lifecycle, eliminating entry points for threat actors should become an easier task.
Wayward web APIs widen attack surfaces in the shadows
Web APIs play a critical role in functionality and innovation, but they also come with security challenges. They add a mostly-hidden attack surface to the mix, increasing risk for organizations that overlook or willfully ignore the shadowy corners of their application security. Whether they creep in through your in-house apps or third-party products, having unknown, undocumented, or untested APIs in your application environments is now a fact of life. Easy to add but hard to find and test, API endpoints can lurk under the radar for months if not years, increasing risk around the clock if left unchecked.
It’s estimated by Gartner that nearly all (90 percent) of web apps will soon have more of an exposed attack surface through API as opposed to their interfaces, which emphasizes the need for security that includes those seen and unseen APIs. Gaps or errors in API security have already shown up as the root causes of some major cybersecurity breaches in 2021, like the LinkedIn incident in which attackers were able to siphon sensitive data from over 700 million LinkedIn users via the social site’s API. Malicious traffic around APIs grew by an alarming 348 percent in 2021 too, signaling that threat actors aren’t waving the white flag on APIs anytime soon.
That exposed attack surface noted by Gartner is worrisome, especially as API usage continues to thrive. As of January 2021, the total number of Postman Collections (folders where API developers group their API requests) surged past 46 million -- and that is only one of many API platforms. These numbers will continue to grow as more organizations look for ways to streamline complex functionality and boost innovation. So having an SBOM to keep tabs on your software components is a start, but it’s just the tip of the security iceberg when it comes to a holistic AppSec plan that covers all the bases.
Flipping the lightswitch on the dark corners of AppSec in 2022
Lingering supply chain risks, security debt, and web API issues don’t have to taunt you from the shadows with a well-rounded approach to AppSec. Start with a discovery tool to get an idea of your big-picture landscape and all of the web applications in your inventory. Often, organizations realize that they have far more applications than previously thought, and more third-party products, integrations, and components than previously known.
Integrating and automating continuous application security testing across the entire software development lifecycle is the next critical step to ensuring all of your assets are covered. A flexible but strategic program that includes modern tools, processes, and DevSecOps enablement can put you one step ahead of risks across your application environments and supply chains, even as threats intensify in 2022.
Image credit: Pixabay
Michael George is CEO, Invicti. Michael is an experienced operator with more than 25 years of starting, building and leading growing technology companies. He has a passion for building customer-first cultures and driving product innovation to lead market categories. Most recently, Michael served as CEO of Continuum, a leading provider of SaaS solutions for Managed Security Services Providers (MSSPs), from 2011 to 2019. During his tenure, the company grew revenues by more than 500 percent and expanded from 43 U.S.-based employees to a team of more than 1400 employees on five continents serving more than 6800 customers.