APPSEC
Building an AppSec Program, Powered by Pipelineless Security
August 20, 2024
So you’re building an AppSec program? Any time you start something from scratch, it can be overwhelming, and an Application Security program is hardly the exception. You’re juggling SAST, SCA, secrets, anomaly detection, permissions, infrastructure as code. However, what makes Application Security programs so ripe with upside opportunity is how AppSec has historically handled cross-functional and developer interaction. If you think it’s “not that bad,” do a search for “developer vs. security conflict” and skim through the search results. See you back here in a week, once you’re done looking… 🙂
Fortunately it doesn’t have to be this way! With the right processes, tools, and culture, AppSec can be great. Let’s take a look at how…
It’s critical to understand what the full menu of assets even is within your software development environment. What repos, orgs, and projects exist within the company? Getting a correct and complete answer relies on both technology and relationships.
As a starting point, your AppSec and software supply chain security tools should not require you to pick and choose what assets you have visibility into. This can be a challenge when your tools lack integration coverage – for example, plugin support for a given IDE – or require per-repository setup, as with CI/CD pipeline deployed scanners. A pipelineless approach guarantees 100% coverage by integrating directly into your source code management platforms like GitHub, GitLab, Azure DevOps, and Bitbucket.
With full-coverage tooling, you’re now technically able to examine, across all repositories: What type of code exists where? What is being pushed to production? What is not being deployed to production? And based on that, you can prioritize – or at least understand – what may be important to protect throughout the software development lifecycle.
Finally, using your integrated AppSec tools, you should be able to identify any repos that are dependent on other repos. For example, you may have a Terraform repo or GitOps repo that everyone is dependent on. So while this repository isn’t a product, per se, it is highly important!
Now that we’ve eliminated coverage concerns, the next question then becomes: “what do we focus on protecting?” On the human front you may want to engage your CFO or Finance team to understand what products are, to put it bluntly, the cash cows. Or perhaps it’s the General Managers across business lines who’ll be able to point you in the right direction. You can build relationships across your organization in order to prioritize products or SKUs that are “mission critical” to the business and use that lens to inform priority within your AppSec program.
Now that you have a sense of coverage and priority, it’s time to build. The processes and technologies that you implement will, by nature of the application security function, impact developers. Whether that impact is positive, neutral, or negative is up to you!
Developers are tribalist. They care deeply about the tools and technologies they use. And so any time you’re evaluating an addition to your AppSec tool suite, you should consider whether that tool is going to require direct adoption by developers and how likely that adoption is.
IDE security plugins are a perfect example of the challenges that can arise in AppSec from poor developer adoption. If you push security left to the IDE, but only 20% of developers are actively leveraging the security plugin (hint: this is the average we see across all our customers before they move to Arnica), you’re left with a significant coverage gap. If you mandate security IDE plugin adoption, you risk a revolt of finding-fatigued developers who are tired of having their development efforts bombarded by indistinguishable high- and critical-severity alerts.
Regardless of your tool choice, there is impact. Tools attempting to secure software development can create friction, be impact neutral, or even, yes, accelerate development velocity. The difference is often in the workflows. Unnatural workflows require developers to step outside of or delay their normal processes to achieve a desired outcome. Waiting until risks are detected in code by in-pipeline SAST and SCA scanners and then putting every risk into a Jira ticket to be triaged in weekly sprint planning is an unnatural, frictionful workflow. Alerting developers that “a SAST risk exists in your code but you have to log into a different tool to see what it is or if it’s important,” is an unnatural, frictionful workflow. Sending a developer a direct message in Slack when code is pushed with an important, prioritized risk type that contains a quick fix that can be implemented in the feature branch while the developer is still working on that code is a natural workflow.
Developers can make a huge, positive impact in your overall security efforts if engaged effectively. It’s critical to understand that the balance at play with tool implementation is how do you maximize developer adoption and minimize developer disruption. As we will discuss shortly, Arnica and pipelineless security provide a possible answer.
Developers might adopt a tool completely with zero or even positive impact on their day-to-day but if the tool can’t effectively address risk, the entire point is mute. As you establish your tool stack, it’s important to evaluate how effective it is at both reducing risks that exist in your environment today and preventing new risks from being added tomorrow.
Stopping the Bleed: Eliminate New AppSec Risks
If new risks are constantly being added to your production environment, your developers are going to be hard pressed to make a dent in the overall risk that exists in production. Implementing tools that optimize for eliminating risks early, before they’re pushed to production, is critical. Finding tools that either automate the mitigation of risks (as is possible with some risk types, like secrets) or get the developer as close to a fix with a little work or disruption as possible, is important to building a program that optimizes both developer experience and security outcomes.
Working The Backlog: Eliminating Existing Risks
With new risks under control, it’s equally important that tools empower your processes to eliminate existing risks. Ensuring that tools incorporate rich environmental context reduces the effort required to make a fix, and increases the clarity provided to the developer as to why a prioritized risk is important. The questions that should be answered include:
This rich context empowers your process so that when you work with developers to prioritize a risk, the “why” is clear. With context clearly communicated, the same principle of automating or easing the effort to mitigate a risk holds true here as well.
There have been a number of approaches to the Shift Left movement. All have come with great promise and have been seemingly iterative improvements on the last. Unfortunately, each has brought unintended consequences as well. You can check out our deep dive on CI/CD Pipelines and IDE plugins compared to Arnica’s pipelineless approach here.
Integrating application security scanners via a CLI execution in the CI/CD pipeline was a revelation when it was introduced. It dramatically simplified governance and enabled the implementation of consistent security gates.
Deploying in the CI/CD pipeline does, however, require engineering to make code changes in the pipeline that will integrate your security scanner. And if you want to change a policy, with most tools you’ll often need the engineering team to step back in and make that change. And because engineering attention is needed, security teams often prioritize which repositories they want security scanners deployed in, leaving possible gaps.
The next challenge arises when there is a finding. What happens when a finding should be marked as a false positive? Or what if you need to push a risk acceptance? You’ll need to go to the external tool again.
The final challenge is that, from a psychological standpoint, developers don’t like their name next to a failed pipeline execution. And you, as a security practitioner, don’t want your security tool to put their name next to a failed pipeline execution. In fact, this is often a direct contributor to developer-security tension. With CI/CD pipeline deployed security tools, developers get the “stick” rather than the “carrot.”
The AppSec world was set ablaze when IDE security plugins were popularized by Snyk. Developers get immediate feedback and as the space has evolved, it’s where all the code co-pilots live!
When it comes to security however, the IDE is so far left that the appropriate gates are ill-defined. The result: the developer sees every risk. They see every high severity vulnerability. It could be 5, 50, or 500. But which ones are important? Which one is most important now? Assuming that the developers are getting some false positives, how do they report them or request anyone else to help them review? Unfortunately, in most cases, the developer would need to CLI or call an API to ingest the finding into an external tool, but developers don’t want to log into yet another tool.
On top of that, at Arnica anyway, we haven’t seen a single company where more than 30% of developers actively use the IDE security plugin. So again you’re left with serious coverage issues.
Status checks are a relatively new approach based entirely on event based webhooks. Status checks, as a mechanism for security scanning, combine consistent gates with 100% coverage. However, if you’re providing security feedback to developers for the first time at the status check, it’s too late.
Developers commonly build their feature in a feature branch and open a Pull Request to have it reviewed. Well, if the security feedback comes the moment that the feature is ready to be reviewed by a peer developer, it’s too late! The developer is working against a timeline that did not account for this late stage security feedback. And that is often why vulnerabilities end up in production; the developers are time bound to deliver a feature and they don’t necessarily have time to fix the security issues raised this late in the process.
It’s time to rethink how we build and implement application security tools. Full coverage is non-negotiable. Granular prioritization is non-negotiable. Neutral or better developer impact is non-negotiable. Arnica’s pipelineless approach provides a path!
Pipelineless security – you guessed it – eliminates the dependence on traditional scanners across IDE plugins and CI/CD pipelines in favor of a code-native workflow engine to bridge the human conflict in the development lifecycle with modern AppSec requirements. More specifically, by integrating security scanning directly into your source code management (SCM) tools – e.g. GitHub, GitLab, Azure DevOps, and Bitbucket – you empower real-time security feedback on code changes such as git pushes and pull requests. Then, feedback is triaged through workflows integrated directly into the productivity tools your teams already use like Slack, Microsoft Teams, and Jira.
A pipelineless approach provides 100% coverage from the moment you integrate into your source code management tools. Security scans are triggered on every single code change in every feature branch, which means feedback can be provided immediately and, critically, with all of the context to make addressing the feedback as easy as possible. Equally important is where the feedback is provided. With pipelineless security, findings are rich with context derived from the source code and delivered where the developers live: Slack & GitHub (for example). Developers should get all of the feedback on the important violations of the specific gates that will prevent them from merging their code later on so that they can fix it early, or get peer developer review as needed, before they get to the pull request. And when they do make the fix, they should see that feedback in real-time as well!
Traditional pipeline-based security can slow down the development process because scans only run during specific pipeline stages, which can delay feedback. Pipelineless security gives you the ability to surface the important risks with full context to the developer earlier in the development lifecycle. Because of the deep integration into both the source code management and collaboration tools like Jira, Slack, and Microsoft Teams, a pipelineless approach also enables the facilitation of mitigations more effectively.
Not only are the workflow themselves frictionful, as we mentioned, CI/CD based scanning requires engineering to configure (and sometimes manually update policies) per pipeline. A pipelineless approach unburdens your developers by requiring no development work to deploy and automatically covers every new asset that is added to the development environment from that point on.
Lastly, because feedback is being given early on the most important risks, the developer is able to respond early as well. This means fewer risks making it into the backlog and less context switching for developers.
A pipelineless security approach leverages the entire context of the development environment based on developer activity and logs. This empowers a greater ability to augment severity scoring such as EPSS, CVSS, and KEV, prioritize risks based on this context as well as the perceived (or explicitly stated) business importance of the various assets within the environment. Organizations, as a result, can then focus on the most critical vulnerabilities first, rather than dealing with a long list of potential issues without proper context or prioritization.
With pipelineless security, developers receive context-rich security feedback directly in the workflows they already use – in chat platforms, their git repositories, and ticket management tools. Ideally, all users are mapped across these platforms so that you know, for example, who pushed a known risk and you can send them a direct message. You know all of the context of a risk like the type, where it exists, and who is best suited to fix it because you’re integrated into the source code management tool.
Security teams can leverage these deep integrations to set up highly deterministic responses based on the type of risk, its severity, and context. It’s critical to understand the specific impact of well orchestrated feedback and mitigation loops. Here are just a few key examples:
By building thoughtful, well-timed feedback loops that contain deep context for a given risk, developers are able to quickly understand and address security issues, improving the overall security outcomes along with the developer experience.
The combination of 100% visibility and integrations into the tools that your entire company uses, like Slack, Teams, or Jira, opens the door to other teams beyond security and engineering. A pipelineless approach gives security the ability to provide this visibility to anyone who may benefit from it.
As an example, while the legal team has no understanding of source code, they do have certain licensing requirements that they need your organization to adhere to. For that reason, you might work with the legal team to establish a policy wherein they are notified via Slack any time there is an open source package violation such as a GPL license. Or perhaps, going beyond just notification, there is an approval request sent to the legal team on behalf of the developer that is requesting approval for that license (and its associated risk).
This same pattern can be replicated for security champions, project managers, general managers, or any other number of parties that the security team wants to provide visibility to and establish partnership with.
Building an effective Application Security program can be a daunting task, but with the right approach and tools, it can be both manageable and successful. The pipelineless security approach offers a transformative way to achieve full coverage, real-time feedback, and reduced development friction, all while enhancing risk prioritization and developer engagement.
By eliminating the dependency on traditional scanner integrations, pipelineless security integrates directly into your development ecosystem and tools to ensure comprehensive coverage from the moment code is pushed. This allows for immediate and context-rich feedback, helping developers address security issues early in the development lifecycle and reducing the chances of vulnerabilities making it into production.
Pipeplineless security unlocks your ability to deliver the right feedback, to the right people or teams, at the right time.
