Adopting Pipelineless Security Solutions for Modern AppSec Programs

Simon Wenet
Head of Growth
April 10, 2023
Simon has spent the last decade in security leading product management & growth teams at various companies focused on DNS security, DLP, and now application security.


At Arnica, we’ve set a lofty vision: a world in which software is unimpeded by risk. But software development over the past 10 years has been anything but ‘unimpeded by risks’ with a seemingly unending cascade of high-profile attacks. Before we can address the core software supply chain risks that exist, we need to understand where AppSec is missing the mark today, what the most critical risks are, and where those risks exist. Only then can we understand how to best eliminate risks in the software supply chain: a pipelineless security model.  


The problems with existing AppSec paradigms

More alerts does not mean better visibility

F5 did an impressive study on the evolving Common Vulnerabilities and Exposures (CVE) landscape. In the figure below, you can see the significant upward trend of reported CVEs over the past 8 years. The report points out that the number of weekly published CVEs has grown 10% per year since 2016. In 2025, they project an average of 547 new CVEs being published weekly – nearly 30,000 CVEs to be published that year.  

The number of CVEs published each week according to an F5 study on the evolving Common Vulnerabilities and Exposures (CVE) landscape

In security, I often hear sales reps pushing their latest dashboard say, “you can’t fix what you can’t see.” And this is true, but a more accurate statement would be to say that you can’t fix what you don’t understand. We, as an industry, have over indexed on seeing any possible risk, which has resulted in security product teams fixating on showing any possible risk, indiscriminately. While full risk visibility is important, the current model of rampant false positives and alert fatigue mean more is not always better. Better is better. And in AppSec, better should mean:  

  • High confidence that a found risk is valid
  • Clear priority of the risk based on what is important to you (a high CVSS\CVE score alone doesn’t necessarily make it a critical risk)
  • An easy and accurate path to fixing the risk  
  • The right person (with the most context & ability) is prompted to make the fix

An example would be when you’re using a set of APIs from a third party and those APIs have been deprecated in a recent release version. This is important information to know. This is certainly a compatibility risk (and likely a major headache), but the security risk is unclear and it should probably not be presented as a critical security risk, unless it will cause a denial of service to an important system to the business

We don’t need more alerts; we need fewer, better alerts with resolution context.  

The (avoidable) false choice between features and security  

Development friction caused by security is a tale as old as software development itself. But before discussing how to fix this problem, we need to get clear on what the problem is. Contrary to much of the discourse, development friction is not caused by security teams. It is caused by 1) the presence of vulnerabilities that need to be fixed (which we see from above is increasing) and 2) the difficulty involved in making necessary fixes. This may sound like semantics, but it is a critical distinction when approaching the problem.  

In the current AppSec paradigm, scanners integrated into the CI/CD pipeline kick out a list of risks as part of the build process and then DevOps & Security go through the unenviable process of trying to figure out who is responsible for fixing each risk. As a result of this lack of context, many of the identified risks get added to a security backlog without clear (or correct) ownership assigned – more on the backlog, shortly.

The impact to engineering is that they get handed a security to-do list – one that is typically light on context, prioritization, and actionability. Developers who are provided limited security training are then forced to spend time investigating these missing pieces and possible remediations. Only then can they implement the fix.  

Inevitably this pits the handling of critical security tasks against pushing new features into production. And if fixing vulnerabilities means not pushing to prod, or delaying a build, developers are much more likely to defer critical fixes (let alone medium or low severity fixes). In the absence of vulnerabilities disappearing entirely (and thus eliminating the critical need for security), the best way to remove the friction between new features and security is to make fixing vulnerabilities way easier.

AppSec is going where developers are not  

In 2022, JupiterOne published a report that found the average security team has to navigate an average backlog of over 120,000 security findings. With such bloated security backlogs, it’s clear that finding the risks is only half of the battle (maybe less).  

There are some obvious and often discussed contributing factors that make it harder for security teams to keep pace with vulnerably like the security talent gap, an increase in published vulnerabilities, and especially time wasted on published vulnerabilities that are not even valid. But one key factor that gets less attention: we are putting security vulnerabilities in a place that developers don’t actually want to be: Jira tickets!  

This is a problem for a few reasons:  

  1. If security tasks live where developers don’t want to be, they are less likely to pick up the task, or possibly even see it.  
  1. The developer that does actually pick up the ticket is seldom correlated to the developer best suited to handling the ticket.  
  1. Developers are not always capable of fixing the problem efficiently, especially when eliminating a risk from history requires deep knowledge of git commands, such as when fixing hardcoded secrets.  

Effective AppSec solutions need to live where developers work and provide automated fixes by creating rich integrations into the tools they use every day (e.g. Slack, Teams, GitHub).  

To-do lists are out. Done lists are in.

For the last 20 years, the security industry has focused on showing security teams what risks exist in their ecosystem. This is true from DNS security to cloud security to pen testing to endpoint security. Some very cutting-edge security tooling will recommend changes. But in an enterprise world of increasing speed and automation, list-oriented security tools are not going to cut it.   

This is especially true for AppSec when collaborating with developers to create a secure development lifecycle. For developers, unactionable to-do lists equate to another item in the backlog that will be quickly forgotten and so everyone loses. Developers get annoyed by “another ask” from security and security is no better off for it.  

What risks exist?  

In the process of taking Arnica from an idea to a full-fledged software supply chain security solution, we took two research angles: 1) we studied the most prominent software supply chain attacks that have occurred since 2018 and 2) we interviewed (literally) 100s of CISOs, Application Security experts, and DevSecOps leaders. What we found was relatively consistent trend of what supply chain risks were most pressing and prevalent:  

  • Code risks such as vulnerable dependencies can be used to execute malicious code in your software.  
  • Excessive permissions or misconfigured branch security policies are often exploited to increase the blast radius of an attack.
  • Hardcoded secrets make it easier for attackers to obtain sensitive information or access to critical infrastructure, such as your cloud environment.  
  • Developer & code anomalies, indicating account takeover or insider threats, can lead to source code exfiltration, malicious code injections, or data breaches.

Choosing the right tool for the job  

So, at this point we know that we need a solution that a) fixes (not just finds) the most pressing supply chain risks and b) does so in a way that aligns to the modern software development lifecycle. We believe this can best be accomplished with a pipelineless approach to security.

The benefits of Pipelineless Security

Earliest detection of the most important risks  

By integrating with your source code management tools (like GitHub and Azure DevOps), Pipelineless Security solutions are able to detect and respond to risks early in the development process: at the point that developers push code, but rather than pushing the work required to fix a risk “left” to the developer, a pipelineless approach pushes detection and an automated fix left instead.  

Prioritization & context

A pipelineless solution that is directly integrated into the source code management tool can provide critical context for security and development teams including which code repositories carry the greatest business impact. Understanding this context helps developers prioritize business-critical vulnerabilities.

In addition to prioritization, the surrounding context of an identified risk is critical. For example, in surfacing a risk through Software Composition Analysis (SCA), addressing the risk becomes far simpler with all the details that can be provided from the source: the pusher, time of push, package name and version, all known CVEs (including severity and patch version), and more.  

Full coverage from day one

Compared to high-effort and context-light pipeline integrations or coverage-challenged and un-auditable IDE plugins, using a pipelineless approach allows security teams to easily establish and maintain 100% security scanning across the software supply chain from day one. This opens the door to run security workflows earlier and more frequently – on code push rather than at testing or deployment time.  

No pipeline integration required  

Rather than shifting work to the developer and requiring them to push code changes in order to set up an integration into the CI/CD pipeline (and for each subsequent change), a pipelineless solution leverages native integrations into your source code management systems, alleviating developer time spent on establishing and maintaining pipeline integrations, and tightening the iterative development process.  

Targeted alerting

Rather than dumping security to-do list items into a ticket to wither away without response, security risks should be contextualized and automatically sent to the best equipped individuals to mitigate the risk. We can identify this person(s) by referencing the code contributor, required reviewers, or admins of the impacted repositories. Not only should the alert go to the most relevant parties, but it should also include mitigation steps. Or even better, the recipient should be able to fix the risk with an automated one-click mitigation.  

Summary: Use a pipelineless security approach to AppSec

A modern approach to Application Security dictates modern methodologies that balance the needs of Security, DevOps, and Developers. Pipelineless Security provides security teams with the most elegant approach to implementing an AppSec program that not only doesn’t disrupt developers but actually relieves them of busy work and empowers them to easily drive security impact.  


More from our blog

SBOM For Your Software Supply Chain: Added Visibility or Security Risk?
SBOM For Your Software Supply Chain: Added Visibility or Security Risk?
September 19, 2023
Trying to identify spoofing in GitHub? May the 4th be with you!
Trying to identify spoofing in GitHub? May the 4th be with you!
May 4, 2023
How insurance tech companies are leading the way on Application Security
How insurance tech companies are leading the way on Application Security
May 3, 2023