Apr 17, 2023
A Vulnerability Is a Vulnerability Is a Vulnerability
If you’re a security leader who hasn’t heard of Conway’s Law, you can check it out after you read this post. But let me save you the time.
Conway’s Law is a warning: Don’t ship the org chart.
Any organization that designs a system (defined broadly) will produce a design
whose structure is a copy of the organization’s communication structure.
Cybersecurity teams face a pervasive problem today: vulnerability management is fractured across departmental silos. This results in no centralized source of truth for vulnerability management. Modern vulnerability management teams are responsible for VM across security programs, including application security, cloud security, and traditional infrastructure (AKA vulnerability assessment).
Let’s dive into why vulnerability management for AppSec findings should not remain siloed within product security and engineering teams.
Why is AppSec separate from vulnerability management anyway?
Historically, VM programs focused on improving the security posture of IT infrastructure. Vulns were detected across the entire stack — from the operating system to the deployed software. With the adoption of cloud came tremendous growth in virtual assets across hybrid cloud infrastructure. Teams could easily extend VM programs to cover the cloud assets (i.e., virtual machines).
Then came the applications. With digital transformation, every company became a software company. Today’s market forces have pushed most organizations to build and deploy their own custom applications. Because the traditional focus of VM programs was securing 3rd-party devices, operating systems, etc., the job of securing first-party applications fell to product engineering teams.
As time progressed and org charts branched across application, infrastructure, and DevOps teams, so did the job of vulnerability management. And what we’re left with from an organizational perspective are two discrete functions. But if we ignore organizational constructs and focus on the cyber risk lifecycle, the situation becomes clear. A fractured view of your attack surface is not ideal; siloed prioritization is not ideal; partial reporting is not ideal.
It isn’t just the run-time application (the final software product) that extends the attack surface. Many application vulnerabilities are introduced during the development of the software, and the entire CI/CD pipeline (the software factory) becomes the next frontier to reduce the vulnerabilities that matter to your business.
Vulnerability management teams and governments are catching on
According to the Forrester report, The State Of Vulnerability Risk Management, 2023, attack methods vary, but the top two methods are software supply chain breaches and software vulnerability exploits. And the line is blurring between the two. Unsurprisingly, leading VM teams and the U.S. federal government are focused on securing the software being built and used.
VM teams say AppSec is a top tactical priority
The Forrester report also reveals that improving application and product security is a top priority. 28% of respondents cited it as their top tactical priority over the next 12 months, trumping options such as threat intelligence and endpoint security.
You might be wondering about cloud security’s role in all this. It’s there but seen as strategic — not tactical. Better understanding the current threat and vulnerability landscape and cloud security were top strategic priorities.
To reiterate the central point from the previous section, you can’t think in silos anymore. The strategic move to cloud adoption has created an urgent need to secure those cloud applications, as well. Vulnerability management today needs to figure out ways to unify the security findings from across the organization.
Government regulations have begun
The federal government sees poor application security practices as a threat and has begun releasing guidance and expectations to the industry about improving the safety of the software ecosystem.
Security professionals should already be aware of two announcements from the White House about improving the country’s cybersecurity: Executive Order 14028 and a subsequent memorandum, M-22-18. The memorandum outlines actions and responsibilities and provides the expected timelines for government agencies to comply with the EO.
The theme is clear: the industry needs a better way to assess whether or not the software it is building and procuring is secure. This has spurred many security teams to purchase new AppSec scanners, exacerbating the already overwhelming amount of security findings in their organization. More findings from more tools increase the burden on organizations to effectively prioritize the risks that matter most to the business.
A bold vision: VM programs incorporate AppSec findings in addition to traditional IT infrastructure
In the old world of vulnerability management, the attack surface was relatively confined — an IT asset and the software deployed on it. In that world, the VM team covered the attack surface as it existed with relative ease because it was much simpler and smaller.
Now, it’s time for VM programs to catch up to the expanded nature of the attack surface and cover all cloud assets (from the OS to the deployed software) — including applications. This is critically important because software deployed in the cloud is often custom-built and has additional attack surfaces (code, containers, etc.)
VM strategy covering organizational risk must consider IT infrastructure, cloud infrastructure, and application security and blend them into a unified orchestration framework. Security leaders must solve this problem and adjust their organizational structures to support it — not the other way around.
About the author: Alex Babar is the head of product marketing for Brinqa. Previously, he held cybersecurity product management and product marketing roles for identity and access management and application security companies.
