What is Pipelineless Security?

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.  

Achieving 100% coverage

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?  

Maintaining (not disrupting) 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?  

Targeting results to the right people / teams  

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 integration 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?  

Targeting results to the right people / teams

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.  

Achieving 100% coverage

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?  

Easily bypassed

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 and why is it important?

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.

Pipelineless security vs. IDE plugins, CI/CD pipeline integrations, and Checks

Below is a table that summarizes the difference between these approaches to software supply chain security.

‍