What is Pipelineless Security?

Nir Valtman
December 5, 2022


Code security can be integrated into different stages in the development lifecycle, with the goal of providing feedback as “left” as possible, such as IDE plugins, pre-commit hooks, Checks and CI/CD pipelines. Each of these integrations have challenges that can be solved by using Pipelineless Security. Pipelineless Security facilitates 100% coverage from day one, increases development velocity, and directs accurate results to the appropriate communication channels.

Arnica is now live in Beta!
Arnica is now live. Come see how Arnica is mitigating software supply chain risks.
Get Started Today


Challenges with integrating security into CI/CD pipelines

When security is integrated into CI/CD pipelines, specific application security tools can run tests as part of the automation the pipeline executes. Common use cases include code security tools like Static Application Security Testing (SAST), Dynamic/Interactive Application Security Testing (DAST/IAST), Software Composition Analysis (SCA/SBOM), Container Security and more.  


CI/CD pipelines are configured differently per source code repository, and sometimes per branch as well, which leads to inconsistent security coverage across your assets. In some cases, the CI/CD pipelines are used for complete automation from build to cloud deployment, while in other cases source code repositories may not have any associated CI/CD pipelines, such as dependent libraries, innovation projects, custom projects with proprietary automation, data science projects, etc. To emphasize the challenge further, here are a couple of questions you should ask:

  • What percentage of source code repositories have associated CI/CD pipelines?  
  • Of all the source code repositories with CI/CD pipelines, what percentage of them utilize your pipeline-based security controls?  

Development velocity

Any job in a CI/CD pipeline takes time. The longer the pipeline runs, the longer it takes for valuable feedback to reach the developer. Fortunately, there are approaches to shifting the integration and resulting feedback further left into the developers’ workstations, such as IDE plugins and pre-commit git hooks. However, chances are that these approaches do not have 100% coverage due to the lack of central configuration management policy, differences in IDE tools, the ability of developers to easily bypass pre-commit git hooks, or any push-back by the engineering teams.  

Developers need fast feedback and empowerment to make the decision on mitigating a newly introduced risk at their feature branch, before creating a pull request or kicking off a CI/CD pipeline. Below are a couple of questions you should ask the engineering team:

  • How frequently do you discover new security findings as part of the CI/CD pipeline execution, compared to earlier feedback from IDEs or Checks?
  • Are your CI/CD pipelines executed on every code push to provide early feedback, or only when a pull request is opened or merged?  

Results sensitivity

Showing all security vulnerabilities to all users with access to the source code repository is risky, as the exposure of such information can lead to potential exploitation of the system by an insider threat. With that said, certain results may be more sensitive than others, such as exposed hardcoded secrets. It raises the questions:

  • Can you notify the author (and potentially the security team) when code is pushed with sensitive information, such as secrets?  
  • Can you restrict who can see reported security vulnerabilities?

Challenges with integrating security into Checks

Integrating security into Checks means that certain lightweight security scans can run on every pull request, code push or commit. Examples for such checks can be Software Composition Analysis (SCA) to check for vulnerabilities in third party dependencies, or scan for hardcoded secrets.  

Heavy lift  

If Source Code Management (SCM) workflows are not your main business, integrating security into Checks will require heavy lifting, as Checks are essentially events sent via webhooks to a given endpoint, which needs to update the status of the check as part of its execution. For example, a GitHub App is required to setup GitHub Checks, while defining custom service hooks are required on Azure DevOps. If you are using a vendor to provide these capabilities, below are a couple of questions worth asking:

  • How are Checks implemented in a multi-tenant environment to prevent data leakage or tampering?
  • Is Branch Protection configured properly to take an action based on the Checks status?  

Results sensitivity

Similarly to what was highlighted in CI/CD security > Results sensitivity above, showing all alerts to all users is risky. But, not all alerts are equally risky. Again, it begs the questions:  

  • Can you specifically notify the author or security when code is pushed with sensitive information?  
  • Can you restrict who can see reported security vulnerabilities?  

Limited event types

Checks can be triggered based on a small subset of activities, such as git push and pull request events. These triggers vary between the different Source Code Management tools. In general, Checks provide good application security coverage to secure your developed application but lack the ability to identify more complicated events that occur in the audit trail, such as user cloning activity used to identify source code exfiltration.

Challenges with integrating security into IDE plugins or git hooks

Integrating security into IDE plugins or git hooks means that developers can add specific apps or scripts to ensure consistent development patterns. For example, quality and security code linters are typically in this category.  


Developers may have different local environment setups. They can differ in the IDE types (e.g. JetBrains WebStorm vs. Microsoft VS Code), versions, workspace configurations and automated scripts (e.g. git hooks). Due to this challenge, security teams cannot ensure that security linters and git hooks are deployed on all developer workstations consistently, which impacts the ability to get to 100% coverage across the organization. Questions that may help you to understand the depth of the challenge are:

  • What is the breakdown of IDEs and associated versions used by ALL developers in the company?
  • Assuming security can deploy an automated git hook centrally, what is the probability of hitting 100% coverage, even if it covers the engineering teams working on high priority products only?  

Client-side bypass

IDE plugins and git hooks can be bypassed easily, by design. For example, in order to bypass a pre-commit hook, add the “--no-verify” flag to the git command. Such bypass can occur deliberately or maliciously. In both scenarios, code security spell checkers are meant to increase productivity, but not to improve security.

So… what is Pipelineless Security?

Pipelineless Security are automated guardrails, that listen on events from Source Code Management (SCM) tools and trigger automated workflows without requiring code or configuration changes. Pipelineless Security implements 3 principles:

  1. Listen to all important events, e.g. subscribe to code push, pull requests and audit events.  
  2. Kick off out-of-band automated guardrails, e.g. remove a newly pushed hardcoded secret
  3. Provide isolated feedback, e.g. notify the code pusher and security team upon identifying a hardcoded secret (and no one else).

The benefits of Pipelineless Security

Frictionless, 100% coverage from day 1

Technically, Pipelineless Security requires a service that monitors webhooks from your SCM and kicks off the automated security workflows. It is relatively easy to run a script that will subscribe to webhooks, as opposed to asking the engineering teams to modify their CI/CD pipelines.  

Fast and private feedback

Pipelineless Security can be used similarly to a GitHub Check, which means that it runs a relatively lightweight workload. The difference is that the feedback is not reflected only in the SCM but interacts directly with the developer, the security team, or anyone else that needs to be involved.

Differences between IDE, CI/CD pipeline, Checks and Pipelineless

Below is a table that summarizes the difference between these approaches.

Component Security tools in IDEs Security tools in CI/CD pipelines Security tools in Checks Pipelineless Security
Coverage Partial – per developer environment Partial - per repository Full, across authorized repositories Full, across authorized repositories and organizations
Required privilege to setup Minimal on developer environment, in some cases requires local admin Authorized user to change pipelines Privileged users in SCM Privileged users in SCM
Security tool execution location Developer’s workstation Same server as the pipeline External External
Time to trigger tool feedback from setup Manual, Live (as code changes are made), pre-commit or pre-push Next successful pipeline run Next code push or pull request Next code push, pull request, or audit event
Feedback visibility Developer’s environment All users with access to repository All users with access to repository Authorized users and groups
Change feedback status Developer, via client-side bypass Requires a trigger to kickoff pipeline after a fix If the message contains buttons, all users with access to repository. Alternatively, push new code with a fix. Authorized users and groups

Arnica is now live in Beta!
Arnica is now live. Come see how Arnica is mitigating software supply chain risks.
Get Started Today


Hardening software development environments 101
Hardening software development environments 101
September 21, 2022
Four takeaways from the NSA's software supply chain security recommendations
Four takeaways from the NSA's software supply chain security recommendations
September 10, 2022
How to protect stale source code repositories on GitHub
How to protect stale source code repositories on GitHub
July 18, 2022