APPSEC
Minimize AppSec Effort and Maximize AppSec Coverage with Pipelineless Security Scanning
January 23, 2024
Pipeline-dependent security scanners offer an incomplete picture of your threat landscape, as they only see the code that actually reaches your pipelines. A pipelineless security approach and thoughtful development oriented workflows can provide better visibility, decrease overall risk, improve developer experience, and a reduce overall effort across security and development teams.
While CI/CD pipelines enable the automation of software delivery tasks, they fail to provide complete security coverage. By only running scans within CI/CD pipelines, you neglect risks that may never enter a pipeline but still present vulnerabilities to your code. Even if a risk will ultimately reach a pipeline-dependent scanner, you are overlooking the threats posed by code that has yet to reach your pipeline (i.e., any changes that are only present in development and test branches), and you are waiting until risks are deployed to production to prioritize and fix them.
Without first ensuring complete coverage across your development ecosystem, you cannot achieve a secure software development lifecycle (SSDLC). Adopting a pipelineless security scanning model, where all code is checked for threats from day one, reduces the risk to your organization.
With traditional pipeline-dependent security scanning methods, code coverage is only as good as the time and effort you're willing to invest in integrating and maintaining your scanners within your CI/DC pipelines. And unless you configure scanners in every single instance, coverage will be incomplete. Often, organizations configure simple scans that cover only high-priority product areas. While this leaves gaps in coverage, it is “accepted” since obtaining 100% coverage would require significantly more resources and ongoing maintenance. Thus, many projects, environments, and code paths end up being omitted from security scans as the effort involved is too great.
New repositories frequently fall into this category. Developers and product teams want to implement new features, not configuring scan jobs in a pipeline. And as a result, by the time a pipeline scanner is introduced, unsafe dependencies, hardcoded secrets, and other code risks could have already been committed to the project.
Moreover, organizations often lack a consistent method for integrating scanning tools within new projects. Project templates can help ensure a default CI/CD configuration is applied, but these still require adjustment on a per-team or per-language basis. Only companies with highly mature DevSecOps functions tend to have fully automated processes for configuring new projects with effective pipeline security configurations, which leads to large maintenance and labor costs.
Old code in legacy projects and outdated third-party dependencies is frequently the source of security issues. However, they're often omitted from security scans because they predate the pipeline’s introduction, or DevSecOps teams are unaware that they are missing the coverage.
Failure to run scans against legacy code and dependencies used in your projects means you're only getting a partial view of your threat landscape. Unmaintained systems can still contain security issues and should be subject to regular scans as long as they are used in your business. Risks in this old code may not be visible to solutions that scan during the build process, but leave your entire development ecosystem open to attack.
The average software development team uses 25 tools within its software development lifecycle (SDLC). Code will be touching all these CLIs, IDEs, and SaaS platforms; while in large organizations, different teams may actually be using different version control and CI/CD systems. Even in a hypothetical (and nearly impossible) scenario where all developers use the same IDE and the same plugin to scan, the developers likely have different versions of the plugin and can manually edit which rules and alerts are active in their particular scans.
Integrating security across all these verticals is challenging. Security scans must be universal in order to be effective, but achieving this requires configuring and maintaining each of the scan tools you use. Failure to do so could allow security issues to enter the project before there’s an opportunity to identify them, such as when a developer commits and pushes vulnerable code that they were unable to scan in their local environment.
Acquisitions of teams, products, and environments make it even more challenging to achieve complete and consistent scan coverage. Integrating external systems into your SDLC is time consuming as new assets will typically come with their own toolchains, configurations, and security policies that are separate from your existing workflows.
Similarly, remote environments and distributed work make it challenging to enforce standardized processes and tools. Unifying tools and workflows is key to ensuring all employees are able to run security scans, but this is difficult to achieve in practice when each team or business unit is used to having its own autonomy.
Integrating security scans into pipelines requires you to edit the pipeline's configuration, ensure it applies to all your projects, and then wait while your CI/CD runners process the job each time a pipeline is executed. Scans only run when your pipelines do, which won't necessarily be each time code changes.
This means there are multiple holes through which issues can enter your projects, then linger until they’re detected (if they ever are). For example, if security scans only run before code is merged into your main branch, dev branches could still acquire hardcoded secrets that become visible in your repositories, before a pull request is created.
There is a way to achieve complete coverage without the high-effort demands of pipeline-dependent security scanning. Pipelineless security scans provide 100% coverage from day one by integrating as a native app to your source code management tools like GitHub, GitLab, Bitbucket, or Azure DevOps. Security scans run asynchronously in response to simple trigger events, such as code pushes and pull request creations.
Because pipelineless coverage sits outside your projects, it's easy to achieve 100% coverage. You can connect the scan service to your source repositories and it will automatically respond to webhooks that fire whenever code is changed. New projects will be automatically covered by scans as soon as their repositories are created, without requiring any manual setup. This ensures there are no coverage gaps in your security scans.
Lifting security scans out of pipelines also tightens the SDLC feedback loop, making it easier to detect and eliminate remaining risks. Developers get quick and actionable results wherever they are working—whether in a chat application or inline comments in a PR—and as events occur, reducing time to remediation. This workflow not only matches the speed of your development team, but also eliminates the antiquated process where tools simply generate lists that require manual investigation and resource assignment.
Adopting pipelineless security means you'll finally have complete coverage of the threats you face. Your next concern should be accurately prioritizing these risks so you can identify those that require your immediate attention.
Business importance and context of security risks
This requires classifying each threat based on its business importance and context. High-severity issues found in internal repositories that are rarely used may be less urgent than moderate-severity ones in critical customer-facing applications, for example.
Because it is integrated directly into your source code management (SCM) system, a pipelineless security scanner can identify the business importance of different repos by inspecting the role they hold within your organization, as well as historical data about the project’s protection and any previous vulnerabilities. Looking at the number of issues introduced by commits and pull requests can help you see whether your developers are practicing secure coding techniques, for example. A high number of deployment pipeline runs signals the project is being actively developed and used—which could mean new risks should be assigned a higher resolution priority.
Exploitability of a risk
It's also important to acknowledge that not all threats are actionable. Indirect vulnerabilities nested deep in a chain of third-party dependencies might not be exploitable in your project, even if they're nominally high-severity issues. As pipelineless provides complete coverage, you are likely to find problems you can't fix. Ideally, your pipelineless workflow should include software composition analysis (SCA) to allow automatic labeling of unresolvable threats that are inherited from deep within your supply chain. Bonus points if it can provide multiple mitigation paths for upgrading your direct dependencies, allowing you to eliminate some or all of the vulnerabilities from your indirect dependencies.
Validity of a risk and minimizing false positives
The final step in threat prioritization is the need to validate that risks are genuine. Even urgent issues that appear directly in your code can turn out to be lower severity than expected when considered in the context of your project. For example, hardcoded secrets could be innocuous if they turn out to be values for demo environments or if the secrets have already expired. Likewise, if only a few users are able to access the affected repository, the threat may be less risky than similar issues in repos that permit broader access.
Regularly monitoring and reviewing the severity and exploitability of risks will keep you informed of changes and enable accurate prioritization. The dynamic risk landscape means the severity of threats can change over time as more information about them is revealed.
Once you’ve found and prioritized your risks, you must take action to mitigate them. It’s key to invest the minimum amount of effort required to efficiently resolve the most impactful issues, without having to wait for security teams or specially trained developers to intervene.
Using pipelineless tools that support automated remediations helps ensure a faster, more reliable, and consistent mitigation process. As soon as a problem has been detected, your developers should be alerted where they are working, then be able to apply suggested fixes directly from those platforms. This minimizes the time and effort required for resolution.
Risks found by SAST and SCA tools should be presented in a way that allows your developers to immediately understand the threat context, then make informed decisions about how to respond. Tools that can provide a summary of the affected workloads alongside a list of changes required to remove each threat support developers in applying timely mitigations, without requiring too much specialist knowledge.
In some cases, there could be multiple possible courses of action—such as for vulnerabilities in a third-party package where you can either upgrade to a new major version for total protection or apply a minor patch that solves only the most high-risk issues. Tools capable of presenting these options allow developers to focus on analyzing the security impact and development effort of each solution—instead of having to create each solution themselves—thus streamlining remediation efforts.
Pipelineless supports this process by providing timely insights throughout the development lifecycle, before code reaches your pipelines. Applying mitigations therefore requires less effort; issues are addressed without code entering your main branch, avoiding complicated remediations further down the pipeline and keeping your attack surface small.
Some threats, such as hardcoded secrets require immediate response and increase in risk, the longer they exist. Using a pipelineless approach, you can find secrets as they appear, notify developers, and even apply automated mitigations in real-time.
One-click mitigations are the best form of protection, cutting security response times to seconds, compared to hours or days for manual resolutions. Automated mitigations mean anyone can deal with issues, even if they aren’t trained security engineers. Because pipelineless security solutions operate continuously with complete code coverage, the most critical risks can be automatically mitigated before they ever reach production code.
Arnica’s pipelineless security solution gives you 100% code coverage from day one. It monitors your source repositories, analyzes them for vulnerabilities, and provides the full threat context to inform accurate prioritization.
In addition to providing a holistic view of your threat landscape, Arnica integrates with your developer source code management tools (GitHub, Azure DevOps, and BitBucket) and ChatOps solutions (Slack and Microsoft Teams) to send actionable alerts in real time along with mitigation recommendations that you can apply straight from the alert.
Gain complete control over your threat landscape with Arnica. Book a demo today.
