Paraconsistent Logic Slashes AppSec False Positives in Triage

The Problem: Alert Fatigue in Application Security

Application security pipelines, integrating Static Application Security Testing (SAST), Software Composition Analysis (SCA), and Dynamic Application Security Testing (DAST), generate an overwhelming volume of findings with every code commit. The core issue is that each tool operates in isolation, flagging potential vulnerabilities based on its own internal logic and severity metrics. This independent decision-making process floods security teams with alerts, many of which are non-critical. Common culprits include test code, dependencies that have already been mitigated, or transient scanner errors. When the sheer volume of noise crosses a critical threshold, developers experience alert fatigue. This desensitization means genuine, high-severity vulnerabilities can easily be missed, buried under a mountain of false positives.

The goal of this project, initially developed for an undergraduate thesis in Software Engineering, was not to create another security scanner. Instead, it aimed to explore whether correlating the outputs of existing scanners before an alert is generated could significantly improve the accuracy and efficiency of the triage process. The hypothesis is that by looking at the data holistically, rather than as individual tool outputs, teams can better distinguish real threats from noise.

Why Paraconsistent Logic?

Traditional triage mechanisms rely on classical logic. In classical logic, a statement is either true or false, and contradictions are disallowed. When applied to security tool outputs, this means a finding is either a critical alert or it isn't. There is no room for nuance or for acknowledging that a finding might appear problematic from one tool's perspective but benign from another's, especially when considering the context of the entire pipeline. This binary approach contributes to alert fatigue because it often forces a decision on every single output, regardless of its true impact or context.

Paraconsistent logic, however, offers a different paradigm. It is a non-classical logic system that allows for contradictions without leading to the collapse of the entire logical system. In simpler terms, it can handle situations where a statement might be considered both true and false simultaneously, or where conflicting information exists, without breaking down. This characteristic makes it uniquely suited for correlating data from multiple, potentially conflicting, security tools. Instead of treating each tool's output as an absolute truth, paraconsistent logic can weigh and reconcile differing signals. For instance, a SAST tool might flag a piece of code as potentially risky, while a DAST tool might not find any exploitable behavior, and an SCA tool might indicate the dependency is already patched. Classical logic struggles to elegantly handle these divergent signals, often defaulting to flagging the most severe potential issue. Paraconsistent logic, on the other hand, can incorporate all these signals, weigh their implications, and arrive at a more informed, less noisy, final decision about whether an alert warrants human attention.

The LPA2v (Logic Programming Approach to Application Security vulnerability analysis version 2) system leverages this capability. It treats security findings as propositions that can be evaluated within a paraconsistent framework. Instead of an alert being a simple binary state, it becomes a more complex proposition that considers the confluence of evidence from multiple sources. For example, a finding might be classified not just by its severity from a single tool, but by a 'degree of concern' that factors in agreement or disagreement across SAST, SCA, and DAST outputs. This approach aims to filter out the noise by only escalating findings that are consistently flagged across multiple tools or that present a clear, undeniable risk despite potential ambiguities from other sources.

How LPA2v Works: Correlating Scanner Data

The LPA2v system processes outputs from standard security tools. Its architecture is designed to ingest these disparate findings, normalize them, and then apply paraconsistent logic rules for correlation. The process can be broken down into several key stages:

1. Data Ingestion and Normalization: Security tools like SAST, SCA, and DAST produce findings in various formats. LPA2v ingests these outputs and transforms them into a standardized internal representation. This step is crucial for enabling cross-tool analysis. Each finding is typically represented with attributes such as the tool that generated it, the type of vulnerability, its location in the code, a severity score assigned by the tool, and any associated remediation advice.
2. Contextualization: Before applying logical rules, LPA2v enriches the findings with additional context. This can include information about the code itself (e.g., is it test code, production code, or configuration?), the status of dependencies (e.g., already patched, deprecated), and historical data on similar findings. This contextual layer helps in disambiguating findings that might appear critical in isolation but are benign in their operational environment.
3. Paraconsistent Inference: This is the core of LPA2v. The system employs a paraconsistent logic programming engine. Instead of a simple 'alert' or 'no alert' decision, the engine evaluates propositions based on the ingested and contextualized findings. For instance, a rule might state: 'If SAST flags a SQL injection vulnerability at line X, and DAST confirms exploitable input at line X, and the dependency is not known to be patched, then generate a HIGH_RISK alert.' Conversely, a rule might state: 'If SAST flags a potential issue at line Y, but DAST finds no exploitable input, and the dependency is confirmed patched, then classify as LOW_PRIORITY or IGNORE.' The logic allows for conflicting evidence (e.g., SAST flags, DAST does not) to be processed without causing system failure, leading to a more nuanced classification.
4. Alert Generation: Based on the paraconsistent inference, LPA2v generates a final set of alerts. The aim is to significantly reduce the number of alerts compared to traditional methods, focusing human attention only on findings that the correlated logic deems truly significant. The system can also provide a trace of the reasoning, showing which tools contributed to a particular alert and why conflicting information was resolved in a specific way.

The technical trade-offs involved in this approach include the complexity of implementing and maintaining the paraconsistent logic engine and the normalization process. However, the potential gains in reducing alert fatigue and improving the signal-to-noise ratio in application security are substantial. The system effectively acts as an intelligent aggregator and correlator, transforming raw tool outputs into actionable intelligence.

Potential Impact and Future Directions

The primary impact of LPA2v lies in its potential to alleviate the pervasive problem of alert fatigue in application security. By shifting from isolated, tool-centric alerting to a correlated, logic-driven triage process, development teams can regain trust in their security tools. This means less time spent sifting through false positives and more time dedicated to addressing genuine threats.

For developers, this translates to a more efficient workflow. Instead of being bombarded with alerts that often require manual investigation only to be dismissed, they receive a curated list of high-priority issues. This focus allows them to integrate security more seamlessly into their development cycles without becoming overwhelmed. For security teams, it means a more effective use of their limited resources, enabling them to focus on strategic security initiatives rather than being perpetually bogged down in basic triage.

What remains to be seen is how well LPA2v scales across a wider array of security tools and different types of vulnerabilities. While the paper focuses on SAST, SCA, and DAST, modern AppSec pipelines can include many more specialized tools. The effectiveness of the paraconsistent logic approach will depend on its ability to integrate and reason over diverse data streams. Furthermore, the development of robust, easy-to-configure paraconsistent logic rulesets will be critical for widespread adoption. The current implementation, born from an academic project, will need significant engineering to become a production-ready solution, including considerations for performance, integration with CI/CD systems, and user interface design for managing the correlated findings.