Endor Labs AI SAST outperforms traditional SAST tools and frontier models because it can analyze your entire codebase to understand your application. Benchmarked across 8 projects with a hand-verified ground truth, AI SAST found 192 real vulnerabilities, 2.6x more true positives than the next leading tool (Claude Opus 4.7), and 63 findings that no other tool caught. It gets there by building a model of your application first: program analysis constructs a code context graph of your entire codebase, and a semantic index captures what the code is intended to do. Specialized agents then work from that knowledge base to find flaws, triage findings, and score based on severity (the AI SAST whitepaper covers this architecture in depth).
A big part of that understanding, however, comes from context that lives outside your code. AI SAST can pull in that additional information and fold it into the application model to account for things it could never learn from the source alone. That context lets it figure out things like:
- How your application is actually deployed: network boundaries, what talks to what
- What's already handled elsewhere: authentication at a gateway, a WAF out front
- Which findings your team has already ruled on
- Your organization's own rules and trade-offs: the auth libraries you standardize on, the issue classes you always want raised
In this post, we'll look at each type of context AI SAST uses to sharpen its understanding of your application, prioritize the flaws that matter, and reduce false positives:
- Infrastructure as Code: Dockerfiles, Terraform, CloudFormation, Kubernetes YAML, and Helm charts, included automatically
- Repository context: AGENTS.md, CLAUDE.md, skills files, and AI rules files, included automatically
- User feedback on findings: optional, added at the finding level as your team triages
- Architecture and threat model context: optional, for providing detailed security context up front, written in natural language
1. Infrastructure as Code (IaC)
Your repository may contain deployment files in the form of Infrastructure as Code (IaC): a Dockerfile for containers, Terraform or CloudFormation files for cloud deployments, and YAML or Helm charts for Kubernetes. AI SAST analyzes these IaC files to create a deployment model of the application and infer security details such as network boundaries and interactions between components.
This matters because exploitability often depends on deployment. An endpoint that looks exposed in the source code may only be reachable from inside a private network, while a service the code treats as internal may sit behind a public load balancer. Reading the IaC lets AI SAST classify these cases correctly instead of guessing.
IaC context is gathered automatically as part of every AI SAST scan. It is added to the project index and used during PR scans and local developer scans, with no configuration required.
2. Repository Context
With the rise of coding assistants, many projects now include an AGENTS.md, CLAUDE.md, skills files, AI rules files, and other documents that describe the application in a human-readable way. These files exist to give coding agents context, and they are just as useful for a security engine.
AI SAST reads these files to extract security-relevant information, such as details about authentication and authorization, or whether the application serves internal or external users. A CLAUDE.md that says "all API routes are authenticated through our SSO middleware" tells the scanner something no amount of pattern matching would surface.
Like IaC, repository context is gathered automatically during the scan and added to the project index, so PR scans and local developer scans benefit from it immediately.
3. User Feedback
Your team can also teach AI SAST directly as they triage. When reviewing findings, a user can react to each one with a thumbs-up (relevant finding) or a thumbs-down (false positive). If the user disagrees with a finding, they can add the missing information: context that isn't in the repository, trade-offs the team has made, or systems outside the codebase (a security gateway, an authentication bridge) that address the issue.
This feedback does more than dismiss a single finding. Marking findings helps the scanner learn which issue types matter most to your team, so it can adjust severity for entire classes of issues or stop reporting patterns you've explicitly ruled on. As your team investigates and annotates findings, results become more accurate and more relevant with every scan.
4. Architecture and Threat Model Context
Security teams usually have detailed knowledge that predates any scanner: security design documents, threat models, internal detection rules, and coding standards. Rather than waiting for that knowledge to surface one finding at a time, users can add this information directly to provide detailed context up front. You provide this information as plain natural language, and AI SAST verifies it against your code before applying it.
AI SAST processes this material and converts it for use in subsequent scans, automatically classifying it into three categories:
- Project context: how the code should work, including trust boundaries, authentication mechanisms, and the authorization model
- True positives: patterns the scanner should look for, such as classes of vulnerabilities your organization always wants raised
- False positives: patterns the scanner should stop reporting, such as agreed-upon trade-offs or issues remediated in other systems
This context can be scoped to a single project, a set of projects, or every project in your tenant. That scoping lets you layer general security principles across the organization while keeping project-specific details where they belong. See the documentation for more details.
Customer Examples
Two use cases come up most often when customers add context: filling in how authentication and authorization really work, and adjusting severity for issues handled by external security measures. The examples below are anonymized, but they reflect the patterns we see in practice.
Authentication handled outside the application
Authentication and authorization are frequently managed outside the application itself, which makes them hard for any scanner to evaluate from source code alone. A financial services company we work with enforces authorization through metadata annotations that a separate policy service validates at runtime. Nothing in the application code checks roles directly, so a scanner without that context would flag missing authorization checks across the codebase.
With this context, AI SAST stopped reporting authorization findings the team had already designed around, and started raising exactly the gap they cared about: sensitive endpoints missing the annotation.
The reverse pattern is just as common. Some organizations have strict requirements about how authentication must be implemented: a standard set of libraries for all projects, or patterns the code should follow or avoid. Uploaded as security context, that guidance turns organizational policy into scan-time enforcement, and AI SAST raises issues whenever new code deviates from it.
Adjusting severity for external security measures
An online retailer wanted to tune findings for vulnerability classes already mitigated in front of the application. Their public traffic passes through a CDN with a managed WAF ruleset, so reflected XSS on marketing pages carried far less risk than the raw findings suggested. As the team triaged, they added feedback on those findings.
AI SAST learned from this feedback and adjusted severity scoring for that class of flaws in future scans, while still raising stored XSS and anything that bypassed the mitigations at full severity. The team kept visibility into the findings without having them compete with issues that needed immediate attention.
AI SAST Learns More With Every Scan
AI SAST starts from a deep model of your application, built from the code context graph and semantic index. The context sources covered here are how that model comes to better understand your application: IaC and repository files teach it how the application is deployed and intended to work, while user feedback and custom context teach it your team's decisions, standards, and trade-offs over time.
The result is a scanner that gets more accurate the longer you use it, excluding the issues you've already handled and surfacing the ones your organization cares about. To see what AI SAST finds in your own codebase, request a demo.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: