SOFTWARE SUPPLY CHAIN
What is Pipelineless Security?
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.
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:
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:
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:
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.
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:
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:
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.
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:
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.
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:
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.
Below is a table that summarizes the difference between these approaches to software supply chain security.
.png)