Repository Context

DryRun Security supports two ways to add repository context: a context managed in the dashboard, or an AGENTS.md file committed directly to the repo. Both serve the same purpose - giving DryRun Security's agents a deeper understanding of how your application works so analysis is as relevant as possible to your specific codebase.

Context in the Dashboard #

The DryRun Security dashboard includes a Context section where you can create and manage context without committing anything to the repository. A context is a settings file that captures the security-relevant details of your application - similar to the Security Review Guidelines section of an AGENTS.md - and can be applied to one or many repositories at once through a configuration.

Once a context is saved, it can be applied to a configuration.

To create a context:

1. Log in to the DryRun Security dashboard at app.dryrun.security
2. Select Context from the left-hand navigation
3. Create a new context, give it a name, and add your repository context
4. Once saved, apply it to a configuration under Settings > Configurations - or follow the prompt to go there directly from the Context section

AGENTS.md #

AGENTS.md is a format supported by the Agentic AI Foundation, a Linux Foundation Project. The file is intended to be "a predictable place to provide the context and instructions to help AI coding agents work on your project."

DryRun Security supports AGENTS.md for both core analyzer products: the Code Review Agent and the DeepScan Agent. DryRun Security's agents will look for and review this file to apply the additional context it provides during analysis.

Some teams prefer AGENTS.md over the dashboard context because it keeps context management in the repository itself. Developers can review and update it alongside the code, without needing to log in to the DryRun Security dashboard.

Note: The Code Review Agent checks for AGENTS.md in the root. The DeepScan Agent can discover both root and nested AGENTS.md files.

To best leverage this, add a Security Review Guidelines section to your AGENTS.md with any context related to design assumptions, areas of particular security interest, or other relevant points for an agentic security reviewer.

When to Use Context #

Repository context works best when DryRun Security needs more information about your application to assess findings accurately. If a class of finding keeps appearing because DryRun Security is not aware of a specific pattern, architectural decision, or security control in your codebase, adding context is the right fix. It teaches the system how your application works so that every future scan benefits from that understanding - rather than managing each instance of that finding one at a time.

Good candidates for a context update:

• A vulnerability class that keeps surfacing because of a known, accepted pattern in your codebase (e.g., intentionally public routes, TLS handled upstream)
• Authorization or authentication behavior that does not follow standard patterns but is correct by design
• Security controls that exist outside the code and are not visible to a scanner (e.g., WAF rules, middleware, infrastructure-level protections)

If DryRun Security already has the right context but a specific finding is incorrect or not relevant to your team, that is outside the scope of repository context. The finding tuning page covers how to mark findings as false positives.

What to Include #

Both methods support the same types of context. The following are useful starting points for a Security Review Guidelines section:

• Structure of a monolith, and how authorization works between components
• Collections of routes or controllers that do not follow typical authorization patterns by design
• Specific security requirements coding assistants need to validate against during code generation
• Assumptions about security-impacting configurations not clear in code (e.g., TLS offloading, WAF rules)
• Specific security patterns that must be followed, with examples of allowed and disallowed code snippets

Example Security Review Guidelines Section #

## Security Review Guidelines

### Device Trust for internal routes
All routes that are prefixed with /abc123 are to be recognized
as internal-only routes, and require the use of trusted devices
issued by the enterprise. Device trust is recognized by an Okta
device token, and these routes are verified within Okta for
proper authorization scopes from the IdP and authorization
server, which will not be checked by the application layer
specifically. Row or object-level authorization issues related to
this pattern only for these internal routes can be ignored as
accepted.

### Intentionally Public Routes
Some controllers have embedded routes with authentication and
authorization decorators disabled or skipped on purpose for
public facing content. The routes are intended to allow anonymous
access to these features ONLY IF the specific controller action
does not perform edits or require write access. Validate the read-
only nature of these endpoints and flag any actions that enable
write behavior when the authentication decorations are skipped.

### Ignore HTTPS related issues on cookies and configuration files
This application is always deployed to a kubernetes cluster as a
mesh service. TLS offloading is provided in front of the application.
Ignore any issues related to Cookies missing Secure flags, requiring
HTTPS in build configurations, or certificate requirements in
this application.