FAQ

How is Dam Secure different from an AI PR review?

Dam Secure offers determinism and knowledge of your codebases. Modern AI PR reviews surface issues using creative evaluation criteria that shift from one PR to the next. Issues get raised, but it's unclear what was actually checked, what was missed, or whether the PR before yours was held to the same standard. There's no defensible answer to "what does our review enforce?"

Dam Secure reviews every pull request through the same fixed set of vulnerability review lenses. The lenses don't change between runs, so you can point to exactly what was checked on any given PR, and build engineering and application security processes, onboarding, and audits on top of that consistency.

How is Dam Secure different from a traditional SAST tool?

Static Application Security Testing (SAST) tools detect vulnerabilities by matching code against signatures and patterns for known classes of issues. That works for surface-level bugs like a hardcoded secret or an obvious SQL string concatenation, but it can't reason about the system around the code.

Dam Secure understands developer intent, system architecture, and how data moves between components. That makes it possible to find vulnerabilities pattern matching can't see, like an order endpoint that returns another customer's data because it never checks ownership, or a user-supplied URL that reaches an internal HTTP client three calls later. Each finding is grounded in how your code actually behaves.

How do I sign in?

Sign in with Google, GitHub, or Microsoft. See Authentication.

Do you support enterprise SSO / SAML?

Yes. Enterprise SSO is available on request, including SAML and major identity providers such as Microsoft Entra ID, Okta, and Google Workspace. Custom SAML integrations are supported as well. See Enterprise SSO.

What access do you need to my code?

For most providers (GitHub, Bitbucket, Azure DevOps), Dam Secure requests read-only access to your repositories. We can read your code to run scans and write comments on pull requests, but we cannot push changes or modify your repository.

info

GitLab is a bit different. Because GitLab's OAuth scopes don't allow webhook management with read-only access, we request read and write access on GitLab in order to set up the webhooks that notify Dam Secure of new pushes. We use that write access solely for webhook registration, not to modify your code. See Adding Your Repositories - GitLab for more detail.

Do you store a copy of my code?

We don't permanently store your code.

During onboarding and scans, our cloud agents create an ephemeral working clone of your repository. We may reuse that clone briefly across nearby jobs to reduce latency, but only while it is actively needed. In production, cleanup runs every 15 minutes. Once a cache is no longer active, it is reclaimed automatically, with a maximum retention window of 1 hour (and often sooner).

To support fast, relevant scans, we generate and store a derived semantic index of your code using embeddings (numerical representations). This helps our tools find related code patterns without storing another human-readable copy of your repository. These numberical embeddings are stored in our database and discarded if you remove the repository.

Use .damsecure-ignore to block agent access to specific files that could expose sensitive data (see repo-specific excludes). Pull request scans apply the latest .damsecure-ignore on your default branch, so merge a new exclusion before opening a pull request that adds the files it protects.

Dam Secure is SOC 2 Type II compliant; see our trust center at trust.damsecure.ai.

What happens when you onboard my repository?

Your codebase is analysed in order to build a security knowledge graph. This knowledge graph provides our engine with the necessary context to find security issues efficiently and work with larger repositories & monorepos.

Below are the high-level steps involved in building the security knowledge graph:

1. Structural Analysis — We walk your repository to discover the projects inside it like services, apps, libraries, infrastructure packages and profile each one with its language and framework. We also select ignore patterns to decide which files won't be scanned for security issues (see file exclusions).
2. Security Indexing — We build the embeddings and analysis artifacts our engine uses to reason about your code. This is what makes scans fast and lets us work efficiently across larger repositories and monorepos.

Additional steps are outlined in repository onboarding.