SOFTWARE SUPPLY CHAIN
Adopting Pipelineless Security Solutions for Modern AppSec Programs
April 10, 2023
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.
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.
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:
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.
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.
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:
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).
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.
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:
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.
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.
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.
.png)