While SAST evaluates custom-written code and SCA inspects third-party dependencies, relying solely on this pair can leave significant security gaps. Both are useful controls, but their findings do not establish that an application enforces its intended permissions or business rules.
Cross-service authorization assumptions can fall outside a scanner’s configured models. Broken access control ranks first in the OWASP Top 10:2025, and identifying these flaws often requires context about who should be allowed to do what.
This article examines the strengths and limitations of SAST and SCA, and why application context matters when reviewing AI-generated code.
Advantages of SAST
Static application security testing (SAST) analyzes code without running the application, using rules and program analysis to identify potential vulnerabilities. Depending on its language and framework support, it can flag:
- SQL built by concatenating untrusted input.
- User input flowing into an
evalcall or a shell command. - Hardcoded secrets, when supported by its rules or integrated secret scanner.
- Dangerous functions and insecure cryptographic use.
Catching an injection vulnerability within a pull request gives engineering teams a chance to fix it before release. OWASP’s source code analysis overview describes both this early feedback and the limitations of automated findings. Our guide to AI security code review explains how security checks fit into that pre-merge workflow.
Limitations of SAST
Modern SAST goes beyond matching syntax. Tools such as CodeQL can trace data flow across an entire program. Their coverage still depends on the languages, frameworks, rules, and models they support.
Some flaws depend on business rules that may not be captured by those models:
- An endpoint checks whether a user is authenticated without checking whether they may access the requested resource.
- A price calculation trusts a client-supplied value.
- Two services make incompatible assumptions about which service enforces authorization.
Static analysis can identify possible paths to vulnerable code, but a reported path is not necessarily exploitable in a deployed system. Runtime configuration, upstream safeguards, and missing application context can leave teams with findings that need further validation.
Advantages of SCA
Software composition analysis (SCA) inventories third-party dependencies and checks them against vulnerability advisories. Modern applications rely heavily on external packages, so this is essential hygiene. Depending on the tool and ecosystem, SCA can:
- Flag dependencies with known vulnerabilities.
- Identify licenses and potential policy conflicts.
- Map direct and transitive dependencies.
When a vulnerability is disclosed in a logging library, SCA helps identify services using affected versions. Teams can then assess exposure and plan updates. Dependency inventory and license analysis also support decisions about which packages to introduce or retain.
Limitations of SCA
Basic SCA matches package versions to known advisories. Some tools go further: Semgrep Supply Chain, for example, provides reachability analysis and malware detection. Coverage varies by language, dependency, and vulnerability.
A perfectly patched dependency tree still says nothing definitive about whether your application wired those dependencies together safely. An advisory database does not encode your permission model or the rules governing a refund. Those application-specific questions require additional analysis.
Why passing SAST and SCA checks doesn’t prove your application is secure
SAST and SCA findings help identify risky code and dependencies. Application security also depends on who can access a resource, how data crosses service boundaries, and whether a suspected flaw is exploitable. These questions require evidence about the application’s intended behavior and the controls along each path.
Business logic and authorization flaws
In an owner-only invoice workflow, whether getInvoice(id) is vulnerable depends on who is allowed to see that invoice. A valid session establishes that the caller is signed in; the application must also check whether the caller has permission to access the requested record. Systems with delegated access must validate those permissions too.
Authorization rules can sometimes be expressed in static checks. When the relevant policy is implicit or spans several services, detecting the flaw may require examining the surrounding code, data model, and intended workflow. The CodeRabbit Security introduction walks through a similar missing-authorization example.
Cross-file and cross-service reachability
Data flows across files, services, trust boundaries, and repositories. Whole-program static analysis can trace many paths within its modeled scope. Separate services, queues, runtime configuration, and unavailable code can make an end-to-end path harder to reconstruct.
An unvalidated webhook can pass through a queue and reach a privileged job in another service. The question is whether an attacker can traverse the complete path and whether any control stops them along the way.
Verification and noise
A flagged line might be unreachable, already mitigated upstream, or genuinely exploitable. Scanner-provided paths and reachability information help distinguish these cases, but manual investigation may still be necessary.
Useful findings show the relevant entry point, safeguards, exploitation conditions, and impact. They also state where evidence is incomplete. That makes it easier for a reviewer to decide what needs fixing and what needs more investigation.
The AI multiplier
These gaps existed before coding agents. AI-assisted development adds more changes for teams to evaluate, while retaining familiar security failure modes.
In CodeRabbit’s study of 470 open-source pull requests, some security issue categories appeared up to 2.74 times as often in the AI-co-authored group as in the human-only comparison group. The sample comprised 320 PRs classified as AI-co-authored and 150 classified as human-only. Authorship was inferred from observable signals, so the finding should not be treated as a universal rate for all AI-generated code.
AI also assists vulnerability discovery. Anthropic’s work with Mozilla demonstrated that models could find previously unknown vulnerabilities, while showing that discovering a bug and producing a reliable exploit remain different tasks. These capabilities are available to defenders as well as attackers.
Reasoning-based security analysis
Additional security analysis should examine how the application is meant to behave and test suspected flaws against the available evidence. Useful capabilities include:
- Application context: Examining relationships between files, data flows, authorization checks, and trust boundaries.
- Evidence-grounded findings: Checking reachability and exploitation conditions, and identifying safeguards that may invalidate a finding.
- Coverage before and after merge: Reviewing changes before release and rescanning repositories as the codebase evolves.
- Remediation in the workflow: Bringing proposed fixes into the pull request process developers already use.
These capabilities overlap with features in some SAST and SCA products. Evaluate the actual coverage and evidence a tool provides, rather than relying on its category label. Independent code validation and checks after merge address different points in the change lifecycle.
SAST and SCA remain useful parts of a layered security program. Reasoning-based review complements them, alongside authorization tests, threat modeling, human review, and other controls appropriate to the application.
Security beyond pattern matching with CodeRabbit
CodeRabbit Security applies application context to security analysis as part of the broader Agentic Change Management approach:
- Codebase-wide analysis: Examines paths across files and trust boundaries for security and business-logic risks.
- Evidence-grounded findings: Checks reachability, exploitability, and impact, and retains uncertainty when the evidence is incomplete.
- PR reviews and repository scans: Provides automatic security reviews before merge, plus whole-repository deep scans on demand or on a schedule.
- Fixes through the PR workflow: Drafts proposed fixes for eligible findings. Developers review the patch and run their checks before merging.
Repository scans analyze code; they do not replace monitoring of a running production system. No combination of scanners or AI reviewers guarantees that every vulnerability will be found.
Keep the controls that already catch useful issues, and investigate the application-specific assumptions they may leave unchecked.
